周六晚上，做数据平台的人最怕一句话。
“这个东西能不能下周上线？”
这句话听起来平常。可它后面常常藏着一长串没有被说出来的问题：源库能不能稳定同步？Schema 变了谁知道？权限是不是跟着人走？模型上线以后会不会漂？Agent 能不能安全地读企业数据？
本期数据周刊，我按 2026-05-30 晚间重新抓了近一周信息源。Data Engineering Weekly 在 2026-05-25 更新了 #271，里面几条大厂工程文章很集中：Netflix 重做 Cassandra 到 Iceberg 的数据移动，Grab 把 CDC 和 Kafka 入湖做成一键自助，Uber 用实时校准守住交通预测模型的生产契约。
再叠加 Databricks 5 月底的产品更新，以及 Snowflake 和 AWS 围绕 Agentic AI 的合作，这周真正值得看的主线就很清楚了：数据平台正在从“能跑”走向“可验证、可治理、可交给 AI 使用”。
下面是本期值得看的几条。
一、Netflix 重做 Cassandra 数据移动：CDC 的难点不在“同步”，在“可信迁移”
Netflix 这周写了一篇很扎实的工程复盘：他们如何重做 Cassandra 到 Iceberg 的数据移动链路。
背景不小。Netflix 的 Cassandra 支撑会员、计费、推荐、订阅等关键业务，历史上靠内部自研的 Casspactor 把 Cassandra 数据移动到 Iceberg。这个系统曾经每天处理大约 1,200 次数据移动，规模约 3PB。
问题也很典型。
旧系统要从多个内部服务拼出“哪份备份可用、是否完整、包含什么内容”。只要其中一个元数据链路不一致，数据移动就可能读到过期或错误的信息。大分区、宽分区还会造成 OOM；多级中间 Iceberg 表又带来存储成本和运维复杂度。
Netflix 的新做法，是把底层备份文件本身作为更可信的元数据来源，直接从 S3 读取 Cassandra 备份，生成标准 Spark DataFrame，再让不同数据抽象在上层构建自己的连接器。
这件事有两个启发。
第一，CDC 和数据移动的核心不是“把数据搬过去”，而是回答：这次搬过去的数据是不是完整、可追溯、可复现。
第二，大规模迁移不能靠“新系统写好了就切”。Netflix 用 shadow testing 并行跑新旧链路，逐行比对差异；用 dashboard 看迁移进度、运行时间和成本；用 Decider Pattern 做新旧连接器切换和失败回退。
国内很多团队做数据迁移，常见问题不是技术选型太落后，而是没有把验证机制设计成产品的一部分。新链路上线前，没人能说清楚旧表和新表到底差几行，延迟差多少，哪些差异是业务合理，哪些差异是事故。
这类能力，才是真正值钱的数据工程能力。
二、Grab 的 Hugo 平台：把“找平台同学开工单”变成几分钟自助入湖
Grab 这周讲了 Hugo 的演进。
Hugo 原本是 Grab 的自助数据入湖平台，后来随着实时数据需求增加，系统里长出了 Kafka Connect、内部 S3 writer、Spark、Hugo 等多套组件。能力是有了，可用户创建一条管道时，要在多个平台之间来回配置。
最麻烦的不是写代码，而是认知负担。
做 MySQL CDC 的人会问：“Kafka Connect 配好了，Hugo 这里还要填什么？”
做 Kafka 入湖的人会问：“Protobuf Schema 更新了，为什么数据湖里的 Schema 没跟着变？”
Grab 的新方案，是用 Apache Flink 和自研自动化层，把 MySQL CDC 与 Kafka 入湖收进一个统一流程里。MySQL CDC 不再绕一跳 Kafka Connect，而是通过 Flink 直接读 binlog，再写到可查询的 Hive 表；Kafka 入湖也改成动态读取 Schema Registry，减少手写映射和手动注册。
这次改造后的指标很实在：Kafka 管道大约 6 分钟完成 onboarding，MySQL CDC 管道大约 3 分钟完成。Grab 还提到，新流程上线后一年的新增 Kafka 和 CDC 管道数量，超过过去五年的总和。
这个数字很有意思。
它说明平台体验不是锦上添花。平台体验一旦足够低摩擦，组织里的数据供给会明显增加。反过来，如果每条管道都要开工单、找人确认字段、手动改 Schema，大家就会倾向于绕路：本地导数、临时脚本、手动 Excel、重复建设。
数据平台的自助化，不是把 UI 做漂亮。真正的自助，是把前置校验、权限、Schema、作业创建、压缩、落表这些脏活藏在系统里，让使用者只面对业务上应该面对的问题。
三、Uber 的 DeepETT：模型上线后，真正麻烦的是持续校准
Uber 这周分享了 DeepETT，一个面向实时交通预测的图感知 Transformer 系统。
这篇文章看起来是模型文章，但对数据团队很有价值。因为 Uber 讲的不是“我们训练了一个更聪明的模型”，而是一个模型如何在生产系统里守住契约。
DeepETT 的接口很清楚：给定道路片段、时间戳和预测窗口，返回该片段的预计通行时间。为了让系统全球可用，它不会让模型在推理时到处遍历复杂图结构，而是提前把道路片段、邻域、区域、历史模式、实时聚合、节假日事件等信息整理成固定形状的输入。
生产链路也很重：Spark 负责离线特征聚合，Flink 每隔几分钟送来实时更新。Uber 提到，这套系统支撑超过每秒 16 万行特征实时摄取，以及大约每秒 200 万次道路片段级预测。
最值得看的，是他们遇到的“反直觉失败”。
新模型的局部预测信息量更高，但接到下游 ETA 模型后，最终到达时间准确性一度下降。原因是 calibration drift：模型刚训练完时校准不错，可一周内校准曲线会随着城市和时段漂移。小小的路段级偏差，累积到整段行程，就会变成明显误差。
Uber 后来用 Flink 做实时校准：把预测按城市和 10 分钟 travel-time bin 分桶，和最新观察到的通行时间连接，实时学习修正量，把路段级校准误差往 0 拉。
这件事对做 AI 和数据应用的人很有提醒。
模型上线不是终点。只要模型结果会进入业务链路，就必须有人回答三个问题：
- 这个模型承诺的输入输出契约是什么？
- 哪些指标证明它还在履约？
- 漂移发生时，系统能不能自动发现并校准？
很多公司做 AI 问数、智能客服、预测模型，最容易漏掉的就是第三个问题。Demo 里回答得像模像样，不代表上线一个月后还可信。
四、Databricks 5 月底更新：AI 数据平台开始把“应用、管道、权限”揉在一起
Databricks 的 5 月产品更新很密集，尤其是 5 月 27 日到 29 日这几天。
几个点放在一起看，方向很明显。
第一，Databricks Apps 开始支持横向扩缩容。一个内部应用可以跑在多个实例后面，支持更高可用、零停机部署和会话粘性。这意味着 Lakehouse 不只是跑 SQL 和任务，也在承接内部数据应用。
第二，Lakeflow Designer 继续增强。它支持 AI 生成算子描述，也允许用户反过来编辑描述来调整算子；支持多输入 Combine、自定义 join 条件、多模态输出预览等。换句话说，低代码数据准备正在和 AI 辅助开发结合。
第三，Unity Catalog 的跨引擎 ABAC 进入 Beta。外部引擎读取 Unity Catalog 管理的 Delta 和 Iceberg 表时，行过滤和列掩码可以在服务端执行。这一点对未来很关键：当更多计算引擎、BI 工具和 Agent 都来读同一批数据时，权限不能散落在各个客户端里。
第四，Lakeflow Spark Declarative Pipelines 的实时模式进入 Public Preview，官方提到可面向欺诈检测、实时个性化、即时决策等操作型流式负载，把端到端延迟压到毫秒级。
这些更新单独看都是产品功能，合起来就是一个趋势：数据平台正在同时变成应用平台、实时管道平台、权限控制面和 AI 开发入口。
这会改变数据团队的工作边界。
过去数据平台更多负责“数怎么进来、怎么算、怎么查”。以后还要负责“谁以什么身份查、AI 工具怎么改管道、内部应用怎么稳定运行、外部引擎如何不绕过权限”。
如果平台团队还只把自己理解成“数仓和调度系统管理员”，会越来越吃力。
五、Snowflake 与 AWS 加码 Agentic AI：企业 AI 的竞争又回到了数据边界
Snowflake 在 2026-05-27 宣布扩大与 AWS 的合作，并承诺未来五年在 AWS 上投入 60 亿美元的 Graviton 计算和 AI 支出。
这类新闻很容易被当成云厂商之间的大生意看过去。但对数据团队来说，真正值得关注的是 Snowflake 反复强调的那句话：把 AI 带到受治理的企业数据旁边，而不是把敏感数据搬来搬去。
这不是口号。
Agentic AI 如果真的进入企业流程，第一关永远是数据：它能读哪些表？能不能跨系统调用？权限怎么继承？自然语言转 SQL 怎么审计？生成的结果能不能追溯？出了错谁负责？
Snowflake 和 AWS 的合作，本质上是在争夺企业 Agent 的数据运行位置。谁能让 AI 更安全地贴近企业数据，谁就更有机会成为企业 AI 工作流的底座。
这件事和 Databricks 的更新放在一起看，会发现一个共同方向：
AI 不是悬浮在数据平台外面的聊天框。它正在往数据目录、权限系统、计算引擎、内部应用和开发工具里钻。
这对数据从业者是压力，也是机会。压力在于，过去可以靠“业务要什么我取什么”应付的工作，会越来越需要治理意识。机会在于，真正懂数据边界、权限、质量、生产链路的人，会成为 AI 落地里很难替代的角色。
六、LinkedIn Crosscheck：AI 榜单也要从“谁第一”走向“对谁有用”
本周还有一篇值得单独看：LinkedIn 发布 Crosscheck，用真实职业场景来比较 AI 模型。
它不只是做一个通用排行榜，而是把模型表现切到角色、行业和任务里看。一个模型在泛化榜单上分数高，不代表它最适合金融行业的产品经理，也不代表它适合数据分析师处理复杂表格。
Crosscheck 的方法也比较克制：用成对比较收集偏好，再用 Bradley-Terry 模型做排名；同时加入时间衰减，让旧模型表现逐渐降权；加入正则化，避免小样本细分榜单过度自信；用 95% 置信区间做分层，只展示统计上有意义的差异。
这事对企业选型很有启发。
现在很多公司选 AI 工具，还是看“哪个模型最强”“哪个榜单第一”。可真正到了内部落地，你会发现问题应该反过来问：
- 我们的数据分析任务，哪个模型更稳？
- 我们的客服场景，哪个模型更少胡说？
- 我们的代码场景，哪个模型更容易被审查和接管？
- 我们有没有足够的样本证明这个判断？
AI 评估如果还停在泛榜单，很快会不够用。它也要像数据分析一样，回到场景、样本、置信区间和可解释判断。
拾穗解读：这周的关键词不是 AI，而是生产契约
把这些新闻放在一起，我看到的不是“AI 又更强了”。
我看到的是一个更朴素的变化：数据和 AI 系统开始要求更清楚的生产契约。
Netflix 讲的是数据移动契约：同一份 Cassandra 数据，迁到 Iceberg 后，行数、内容、元数据和回退路径都要可验证。
Grab 讲的是入湖契约：用户不用理解一堆底层组件，但平台必须把 Schema、权限、校验和落表流程兜住。
Uber 讲的是模型契约：模型不只要离线指标好，还要在上线后持续校准，不让小偏差滚成业务误差。
Databricks 和 Snowflake 讲的是平台契约：当应用、实时管道、权限、外部引擎和 AI Agent 都挤到一起时，访问边界必须回到统一治理面。
LinkedIn 讲的是评估契约：别只说哪个模型第一，要说在什么人、什么任务、多少样本、什么置信度下更好。
这些东西听起来不够性感。
它们不像一个新模型发布，也不像一个酷炫 Demo。它们更像工位旁边那张没人爱填的验收表：数据是否一致，权限是否正确，延迟是否达标，漂移是否监控，回退是否可用。
可是大多数生产系统最后出问题，恰恰出在这些地方。
对数据从业者来说，这期周刊的提醒很明确：不要只追新工具，要学会把生产契约说清楚。
下次你做一条 CDC 管道，不妨多问一句：Schema 变更怎么处理？目标表和源表怎么对账？失败后怎么重跑？
下次你做一个 AI 问数或预测模型，也多问一句：它什么时候算回答错？错了怎么发现？发现后谁有权修正？
下次你参与平台建设，可以试着把“自助化”翻译成更具体的东西：用户少填哪些字段，平台多承担哪些校验，权限在哪里统一收口，审计日志能不能留下证据。
很多时候，所谓高级数据工程，不是会把系统搭得更复杂，而是能让复杂系统在关键时刻说得清、查得到、退得回。
这就是生产契约。
也是 AI 时代数据人的基本盘。
如果你想系统补齐数据工程、数据治理、AI 数据底座和职业成长能力，可以继续看 数据从业者全栈知识库。周刊负责帮你看见风向，知识库负责把能长期复用的东西沉下来。
本周其他值得看
- Pinterest：用户序列数据如何做得更便宜、更快、更好用。这篇适合做用户行为分析、推荐和增长数据的朋友看，重点不是某个模型，而是把用户序列当成一种长期数据产品来治理。
- Yelp：用分区访问可视化降低 Data Lake S3 成本。Data Engineering Weekly 提到 Yelp 通过表分区访问指标来优化存储，数据湖成本治理不再只是“删冷数据”，而是基于访问证据做保留策略。
- Jack Vanlightly：Dimster，Kafka 性能基准工具。Kafka 压测经常难复现，Dimster 强调把配置、硬件、版本和结果一起打包，适合关注基准测试可信度的同学。
- Airbnb：统一身份图谱与知识图谱基础设施。身份、用户、设备、账号之间的关系越来越复杂，图谱基础设施仍然是大规模平台绕不开的底层能力。
我叫石头，在数据行业里摸爬滚打了十几年，越到后来越觉得，真正救命的不是热闹的新词，而是那些能在事故发生时留下证据的设计。这里写的，就是这些教训——我觉得值得说出来的那部分。
来源
- Data Engineering Weekly #271 · Ananth Packkildurai · 2026-05-25
- Netflix Tech Blog：The Evolution of Cassandra Data Movement at Netflix · 2026-05-18
- Grab Engineering：The Hugo evolution: Engineering Grab’s unified, one-click data ingestion platform with Apache Flink · 2026-05-22
- Uber Engineering：Scaling Real-Time Traffic Forecasting with a Graph-Aware Transformer
- Databricks：May 2026 release notes · Last updated 2026-05-29
- Snowflake：Snowflake Expands AWS Collaboration with $6B Commitment to Accelerate Enterprise Agentic AI Adoption · 2026-05-27
- LinkedIn Engineering：Crosscheck: Benchmarking AI Models in the Real World · 2026-05-21
《数据周刊》每周更新一期，挑数据行业值得看的动态，附拾穗的判断。拾穗数据｜https://ss-data.cc