这周的数据工程新闻，读起来不像新闻。
更像几间办公室里的事故片段：账单任务突然慢下来，实时流重放后顺序乱了，时间序列分区越长越宽，AI 工具的 token 账单开始让人皱眉。
它们说的不是同一家公司，也不是同一套技术栈。可是放在一起看，指向的是同一件事：
数据系统一旦进了生产，就不会按抽象概念运行。它会按账单、延迟、权限、成本和责任运行。
Flink 账单系统：watermark 不是免死金牌
Gorgias 写了一篇关于 Apache Flink 账单系统的复盘。问题不在于他们不懂实时计算，而在于真实账单系统里，事件时间会碰到现实。
来源截图：Gorgias Engineering 原文可读化页面。Medium 原页触发安全验证，因此这里保留可读化截图和文末原文链接。
很多人学 Flink 时会记住一个词：watermark。它像一个承诺，告诉系统“晚到的数据大概到这里了，可以往前算了”。可是到了计费场景，事情没这么干净。
历史数据重放、keyBy 之后的数据重分布、去重和汇总链路里的 key 不一致，都可能让下游窗口出现重叠。Gorgias 的做法不是简单把等待时间拉长，而是把去重和汇总对齐到同一个 customer-user key 上，减少中间重分区，并在事件延迟超过 15 分钟时，把汇总窗口额外延长 1 天。根据 Data Engineering Weekly 的摘要，这组修正让重叠汇总窗口减少了 10 倍，同时没有拖慢实时计费。
这件事对国内数据团队很有意思。我们平时谈实时数仓，容易把话说成“接 Kafka、写 Flink、落 Doris”。可是真正到了钱、账、订单、权益这些场景，实时不是“快一点”这么简单，而是要回答一个更麻烦的问题：
晚到的数据来了以后，之前算过的钱到底怎么算？
这个问题如果没有提前想清楚，最后就会变成周五晚上的临时会。
ClickHouse 变慢：最烦人的瓶颈，往往没有红灯
Cloudflare 的案例更像一次生产事故。
来源截图：Cloudflare Blog 原文页。
他们的计费管道突然变慢，背后是 petabyte 级 ClickHouse 集群里的查询计划瓶颈。麻烦的地方在于，普通监控指标没有直接告诉你“这里坏了”。任务就是慢，锁竞争藏在查询计划阶段。
Cloudflare 最后定位到 MergeTreeData 里的热点：part-list mutex、parts vector copy，以及 namespace prefix 查找方式，在多租户分区场景下把并发查询串了起来。他们做了 3 个上游修复：把独占锁换成 std::shared_lock，延后 parts vector copy，并用二分查找优化已排序前缀。
这不是一篇适合转给所有业务同学看的文章，但适合数据平台团队认真读。
因为很多公司现在把 ClickHouse、Doris、StarRocks 这类 OLAP 引擎当作“快”的代名词。快当然重要，可是到了多租户、计费、权限、历史回刷、峰值查询都叠在一起的时候，真正决定系统稳定性的，经常不是 SQL 写得漂不漂亮，而是底层执行和调度有没有被现实流量撞过。
看起来很高级的引擎，最后也会败给一把锁。
这话不浪漫，但挺真实。
Netflix 的 Cassandra：时间序列最怕“少数人吃太多”
Netflix 这周讲的是 Cassandra 时间序列负载里的动态分区。
来源截图：Netflix TechBlog 原文页。
时间序列数据有一个老问题：一开始你按某个 ID 和时间切分，觉得很合理。后来业务长大，一小部分 ID 变得特别热，事件量远远超过其他 ID，原来的静态分区就会变成宽分区。宽分区带来的不是“看起来不优雅”，而是尾延迟、超时和运维成本。
Netflix 的处理方式，是在 TimeSeries Abstraction 上做动态拆分：后台 worker 负责返回未来的 Time Slice 分区，对单个 ID 做运行时拆分，读的时候再通过 Bloom filter 辅助路由。
这件事听起来离普通团队有点远，但其实不远。
很多公司也有类似问题：某几个门店、某几个渠道、某几个大客户、某几个活动 ID，把原本均匀的数据模型冲歪了。刚开始大家会说“加机器吧”。加机器当然能缓一口气，但如果数据分布本身变了，架构还假装世界没变，机器只是在帮你拖延。
时间序列系统最怕的不是数据越来越多，而是数据越来越不平均。
Agent 成本：数据团队也要开始算 token 账
dbt 的 Analytics Engineering Roundup 这期写了 Snowflake Summit，也写了 token 成本。
来源截图：The Analytics Engineering Roundup 原文页。
最值得国内数据团队注意的，不是某个厂商又发布了多少 Agent，而是大家开始公开讨论一个以前不太体面的事情：AI 工具不是免费的水龙头，它是有账单的。
Roundup 里提到，企业开始给工程师设 token budget，也有人讨论每月几百美元的个人使用上限。这个话题过去更像软件工程圈的事情，但它很快会进入数据团队。
原因很简单：数据团队的 Agent 用法天然容易烧钱。
你让 Agent 看几百张表、几千个字段、几年的需求文档，再让它反复生成 SQL、解释血缘、比较指标口径、生成周报，它消耗的不是“一个问题一次回答”，而是一串上下文、工具调用、重试和验证。
这也是为什么我一直不太相信“给数据库接一个聊天框”就算 AI 问数上线。真正的问题不是能不能问，而是：
- 谁决定 Agent 能看哪些表？
- 谁定义指标口径？
- 谁验证 SQL 没有错得很像对的？
- 谁为 token 成本负责？
- 谁在结果出错时承担解释责任？
到了这一步，AI 问数就不只是模型问题，而是数据平台问题。
拾穗解读：这周的关键词不是新技术，而是生产摩擦
这周几条信息放在一起看，最值得记住的不是 Flink、ClickHouse、Cassandra 或 Agent。
是一个更朴素的词：摩擦。
Flink 的摩擦来自事件时间和真实账单之间的缝隙。ClickHouse 的摩擦来自多租户查询和底层锁之间的竞争。Cassandra 的摩擦来自数据分布变热之后，旧分区策略还在假装世界平均。Agent 的摩擦来自人们兴奋地试用 AI，却还没认真算成本、权限和责任。
这对数据从业者意味着两件事。
第一，不要只学“工具怎么用”，要学“工具什么时候会露出牙齿”。一个技术在 demo 里很顺，在生产里就会开始问你要代价。这个代价可能是延迟，可能是账单，可能是一次事故复盘，也可能是一个没人敢签字的结果。
第二，越是 AI 时代，越要补数据工程的老功夫。口径、血缘、权限、成本、质量、延迟、重放、回滚，这些词听起来不新，但它们会决定 AI 能不能真的进业务。
有些东西不会因为模型变强就消失。
它们只会换一种方式回来找你。
这也是这期周刊我最想提醒的一点。
不要把“生产摩擦”只理解成平台团队的事。很多普通数据分析师、数仓开发、BI 工程师也会遇到它，只是名字不同：一个指标迟迟对不上，一张看板每周都要手工改，一个 AI 问数结果没人敢直接转发，一个实时链路出了问题但没人知道影响哪些报表。
这些事情都不宏大，但它们会消耗信任。
数据团队真正的基本功，往往就藏在这种不体面的地方：把晚到数据说清楚，把口径改动留下记录，把查询成本算进方案，把 AI 生成结果放回可审核链路里。
这不是反对新工具。
恰恰相反，只有把这些旧问题补上，新工具才有机会进入真实工作。
本周其他值得看
Jack Vanlightly 写了 broker-visible parallelism 和 client-local parallelism 的差异。一个很有意思的数字是，文章里讨论的 60K msg/sec 工作负载，可以从 60,000 个 consumers 降到 60 个。这个话题适合做消息系统并发模型的朋友继续读。
Helpshift 也写了从 monolithic orchestrator 迁移到 Apache Airflow 的过程。这个主题不新，但很适合提醒我们：调度系统迁移最难的地方，往往不是把任务搬过去，而是把历史约定、失败重试、依赖关系和人的操作习惯一起搬过去。
如果你最近也在公司里推进 AI 问数、实时链路、指标口径或数据质量，可以加我微信聊聊：shisuidata。备注「数据周刊」就行。
来源：
- Data Engineering Weekly #273：https://www.dataengineeringweekly.com/p/data-engineering-weekly-273
- Gorgias：When Event Time Meets Reality: Lessons from Building Billing on Apache Flink：https://medium.com/gorgias-engineering/when-event-time-meets-reality-lessons-from-building-billing-on-apache-flink-581ff895c60d
- Cloudflare：Our billing pipeline was suddenly slow. The culprit was a hidden bottleneck in ClickHouse：https://blog.cloudflare.com/clickhouse-query-plan-contention/
- Netflix：Dynamic Repartitioning for Time Series Workloads：https://netflixtechblog.com/dynamically-splitting-wide-partitions-in-cassandra-for-time-series-workloads-0eded064f456
- Analytics Engineering Roundup：Hunting for Tokens. Snowflake Summit. Agent Use Cases.：https://roundup.getdbt.com/p/hunting-for-tokens-snowflake-summit
- Jack Vanlightly：Broker-Visible vs Client-Local Parallelism：https://jack-vanlightly.com/blog/2026/6/3/broker-visible-vs-client-local-parallelism
