数据工程

Lambda vs Kappa 架构取舍：双链路口径漂移的量化与监控 一、现象或背景 在数据工程领域，Lambda 架构（离线批 + 实时流）与 Kappa 架构（全流式）的取舍一直是争论的焦点。我们团队在去年将核心指标从 Lambda（S

【背景】 做了 10 年数据工程，这几年我遇到的最大架构争论不是「用哪个引擎」，而是「要不要把离线批链路拆掉、全走实时」。我们团队去年把核心指标从 Lambda（Spark 离线 T+1 + Flink 实时）往 Kappa（Flink 全

«结论先行：在 800 万行用户行为日志上计算「连续活跃 ≥ N 天」标签，窗口函数（LAG + 行号差值法）P99 = 2.1s，自连接 P99 = 25.3s，临时表迭代 P99 = 18.7s——12 倍和 9 倍差距。但窗口函数方案

【背景】 做了 8 年数据工程，最近半年在帮三个不同团队看 OLAP 链路，发现一个反复出现的"看似简单、其实没人说得清"的取舍： 业务方要一个运营看板，核心指标是「近 1 小时 / 近 24 小时 / 近 7 天」的 PV、UV、GMV、

背景 站内聊「幂等」「异步化」「缓存一致性」都聊得很透了，但有一个我作为数据工程师天天被追问、却几乎没人正面展开的问题：线上数据已经错了，怎么修？ 我习惯从现象倒推。上个月我们一张核心指标表出错了——不是 bug，是上游口径悄悄改了字段语义

背景 在数据工程和后端高并发领域，"缓存和数据库不一致"几乎是每个团队都撞过的墙。但每次聊起来，发现大家的做法差异非常大，而且往往跟业务场景、团队规模、运维能力强相关——没有银弹，只有取舍。我做了 10 年数据工程，见过从"纯 TTL 兜底