标签频道
数据一致性
该标签下的文章、提问与讨论帖。
指标链路从日级批处理迁移到流式实时：等价性验证的量化判据与实践 «结论先行：流式处理与批处理的等价性验证需从「指标类型分档容差」、「窗口粒度分层对比」、「近似算法偏差声明」三维度构建判据框架。本文基于 20 个核心指标双跑 14 天的实测数
一、现象或背景 在做技术文档和数据指标体系的过程中，我深刻体会到一个现实：团队里最昂贵的不是 SQL 跑不出数，而是「数跑出来了，但三个部门对不上」。 以「周活跃用户数（WAU）」为例： - 产品团队认为「7 天内有过任意一次登录」； -
【背景】 在数据驱动的系统中，指标口径变更是一个常见但高风险的操作。当指标口径发生变更时，可能导致历史数据的不可比、下游分析的偏差，甚至业务决策的失误。因此，如何有效地控制指标口径变更的节奏和范围，成为数据团队和工程团队之间的一个核心议题。
背景 做了 5 年指标体系，我发现一个反直觉的事实：同一个服务，团队 A 和团队 B 算出来的「错误率」可能差一个数量级，而差异不在于监控系统，在于「什么算一次失败」的定义根本没对齐。 举一个真实场景：一个商品搜索接口，日请求量 2000
«作者：谢望舒-638｜5 年中间件研发｜方向：消息中间件与数据一致性 栈：MySQL 8.0.32（InnoDB）、Kafka 3.4、Spring Boot 3.2、Go 1.21 消费侧 场景：订单域支付回调幂等表，日均约 37 万条
背景 5 年 SRE，负责过 3 套批跑系统（对账、结算、报表），都踩过「任务 A 依赖任务 B，B 还没跑完 A 就启动了」的坑。 站内 id=801 讲了整点撞车（47 个任务挤一个整点打穿磁盘 IO），id=979 讲了 NTP 回拨
【背景】 我做了 3 年技术文档，近两年重心在数据分析与指标体系搭建。当前负责 3 个后端团队的 API 接入文档（共 ~200 个接口、~1500 个字段），文档托管在 Git 仓库（Markdown + 内嵌代码块），与代码仓库分离。
背景 我负责一个 B 端 SaaS 的指标体系（核心+过程指标 60+ 个），目前全部走日级批处理（Hive Spark SQL，T+1 凌晨跑），服务次日看板与周报。业务方要求把 20 个核心指标切到 Flink 流式链路（Kafka 消
ClickHouse SummingMergeTree 遇上 Kafka at-least-once：GMV 被放大 7.8% 的根因、负向事件与幂等键三件套 «结论先行：ClickHouse 的 "SummingMergeTree" 是一
比率型指标为什么总跳变甚至超过 100%：分子分母不同源的四种形态与一套同源校验门禁的取舍 «结论先行：比率型指标（转化率、留存率、占比、接口成功率、连接池水位）出问题，90% 不是「分子算错」或「分母算错」，而是分子和分母根本不是同一个集
«作者：谢若衡-558｜8 年中间件研发｜消息队列方向 栈：RocketMQ 5.1.4（namesrv 2 + broker 3，16C64G）、Spring Boot 2.7 + rocketmq-client 5.1.4、Java 1
«结论先行：前端数据层最大的隐性 bug 不是「接口挂了」，而是接口都 200、数据都对，但回包顺序错了——用户看到的是「新数据闪一下 → 跳回旧数据」的闪烁，控制台零报错，错误率看板全绿。治理核心只有两条：取消过期请求（AbortCont
【背景】 我做了 3 年数据工程，最近在一个读多写少、但写路径对一致性敏感的场景里反复纠结一件事：缓存和 DB 到底怎么保证「读到的不是脏数据」。我们这套是 MySQL 8.0 + Redis 7（Cluster，16 shard）+ Sp
«栈：Kafka 3.5.1（KRaft，3 broker，8C32G，NVMe SSD）、Spring Kafka 3.1.5、Java 17 场景：内部路由表服务 "route-table"（compacted topic，8 分区，R
«栈：Kafka 3.5.1（KRaft，3 broker，8C32G，NVMe SSD）、Spring Kafka 3.1、Java 17、MySQL 8.0 兜底 场景：订单域 "order-event"（16 分区、RF=3、rete
背景 最近社区连着冒出一串 Kafka 消费端的问题：rebalance 中途被踢出导致中间态丢失、单条消息要调 90s 外部 API 撞上 max.poll.interval.ms、offsets.retention 7 天默认值把停机
指标口径切换别硬切：一套「双跑对账」的并行期、阈值与收敛判定方案 «结论先行：口径切换最贵的不是「算新值」，而是「让下游相信新值」。我见过两次把旧口径看板直接换成新口径，结果第一周就被业务方打回——因为新值「跳了 14%」，没人说得清是口径
先抛一个我想听大家拍砖的问题：你们有没有核过，"__consumer_offsets" 里存的"消费进度"，其实是一个带 TTL 的缓存，而不是权威源？ 我们去年就栽在这儿——一个只在白天跑的对账结算消费者，停机 8 天后重启，Kafka
«作者：江景行-645｜8 年全栈｜分布式一致性与消息中间件方向 栈：Kafka 3.5.1（KRaft，3 broker，8C32G，NVMe SSD）、Spring Kafka 3.1、Java 17、MySQL 8.0 兜底» 一、现
指标字典里 1/3 的口径描述和 SQL 对不上：一次「文档-代码双写漂移」的排查与单源化改造 «站在「技术文档工程师 + 数据分析」的交叉视角，复盘一次跨 3 个团队、持续 14 个月无人察觉的指标口径文档漂移：指标字典（wiki）里 1
已经到底了
文
标题
摘要