这周的数据工程新闻，有一个共同的味道。
AI 已经开始进到很细的工作里了。它不只是写一段 SQL、画一张图，而是开始帮人看 Spark SQL Plan，帮人理解存储瓶颈，帮人做上线前的历史流量测试。
可是这些新闻放在一起，反而提醒了一件朴素的事：
AI 想帮你，得先有证据。
没有执行计划，它只能猜为什么慢；没有历史样本，它没法判断这次改动会不会伤到旧逻辑；没有口径边界，它会把“看起来差不多”的两个数，说成同一个答案。
这事对普通数据从业者很实在。下次老板、业务或面试官问你“这活你到底怎么做的”，你不能只说用了 AI、用了 Spark、用了实时架构。你最好能拿出 3 份东西：问题发生时的现场证据、你做判断的中间过程、最后能复查的结果。
Databricks 推 Lakebase：统一很好，边界更重要
Data Engineering Weekly #277 里第一条值得看的是 Databricks 的 Lakebase 和 LTAP。
LTAP 可以粗略理解为一件事：同一套数据底座，既想服务事务型操作，也想服务分析型查询。过去很多团队会把在线业务库和分析数仓分开看，前者管写入和交易，后者管统计和分析。分开当然有成本，所以“统一”听起来很诱人。
Databricks 在 Lakebase 文章里强调，AI 应用会带来新的数据访问方式：既需要低延迟读写，又需要和 Lakehouse 里的分析数据打通。
但 Regatta 的反方文章也提醒了另一个问题：存储统一不等于一致性问题自动消失。两个系统看的是不是同一个时间点的数据？写入延迟怎么处理？在线查询和分析查询冲突时谁优先？这些问题如果没写清楚，统一之后只是把麻烦搬到了更大的房间。
对做数据工作的朋友来说，这条新闻不是让你立刻研究某个产品，而是提醒你：以后再遇到“两个数不一样”，不能只回答“一个是实时，一个是离线”。
你至少要说清楚：
- 两个数分别来自哪条链路；
- 数据窗口差了多少；
- 哪些字段会延迟到达；
- 这个差异在业务上能不能接受。
能说清这些，你才不是在背概念，而是在交付判断。
Meta AI Storage：模型再聪明，也怕数据喂不动
Meta 这周写了 AI Storage Blueprint at Scale。标题听起来很基础设施，但里面有个信号很值得普通数据人看：大模型训练和 AI 应用的瓶颈，不总是在模型本身。
有时候问题在存储、缓存、跨区域读取、数据准备和吞吐。
这和很多公司内部做 AI 问数、AI 分析很像。演示时大家盯着模型回答快不快、准不准，真上线以后才发现，真正拖住人的，是数据链路本身：表不新、字段乱、权限慢、历史数据取不动、特征和指标找不到来源。
数据从业者如果只说“模型不够好”，很容易把问题讲窄。
更成熟的说法是：这条数据链路能不能稳定喂给 AI？它的输入在哪里排队？哪一段数据要反复搬运？哪些热门数据应该提前准备？哪些冷数据根本不该每次都现查？
这些问题不花哨，但很值钱。
AI 时代的数据能力，不只是会调用模型。你得知道模型吃进去的东西，是不是干净、及时、可追溯。
Expedia 用 LLM 看 Spark SQL Plan：先别急着让 AI 调参
Expedia Group 的文章讲了一件很具体的事：用 LLM 分析 Spark SQL Plans，帮助调试长时间运行的任务。
这条我建议做 Spark、SQL、数仓、ETL 的朋友都看一下。它最有价值的地方，不是“AI 会调 Spark 参数了”，而是它把 Spark 慢任务拆成了可以被模型阅读的证据。
Spark SQL Plan 本来就是一种很好的中间证据。它记录了查询怎么被优化、怎么执行、哪里可能 shuffle、哪里可能扫描过多、哪里 join 代价很高。
问题是，大部分人在任务跑慢的时候，第一反应不是收集证据，而是问一句：“是不是 executor 太少了？”
这就像医生还没看检查单，先问要不要加药。
如果你希望 AI 真帮上忙，至少先准备 3 份东西：
- 执行计划：让它看到任务到底怎么跑；
- 运行指标：让它看到慢在哪里；
- 业务上下文：让它知道哪些逻辑不能随便改。
没有第三项尤其危险。AI 可能会建议你把一个 join 改掉，把一个过滤条件前移，把一个字段裁掉。技术上也许更快，业务上可能直接错。
这也是本周最值得记住的一句话：AI 调优之前，先让证据站起来。
Stripe 用 Spark 重放历史流量：上线前多看一次旧世界
Stripe 的技术博客讲了他们用 Apache Spark 做微服务测试。
它的重点不是“Spark 很强”，而是用历史请求数据去重放、比较新旧系统行为。对普通数据从业者来说，这个思路很实用。
很多数据事故不是因为没人测试，而是测试太干净。
测试环境里只有几条人工样本，边界情况都很乖。真正上线以后，历史数据里那些奇怪的用户、缺失字段、跨天订单、重复支付、异常退款，全都出来了。
如果上线前能多重放一次历史数据，很多锅其实不用背。
你不一定能在公司里马上做出 Stripe 那样的系统，但可以把这件事缩小成一个动作：
下次改指标、改模型、改调度、改同步逻辑前，别只测今天的样本。拿一段真实历史数据重跑一遍，看看新旧结果差在哪里。差异不是坏事，没解释的差异才是坏事。
本周其他值得看
Target 写了用 AI 支持营销活动预测和历史案例匹配。它提醒的是另一个方向：很多业务问题不是从零开始回答，而是从历史相似案例里找证据。
这对数据分析师也很实用。你下次写复盘，不要只给一个结论，可以补一段“历史上相似活动怎么表现”。这比凭感觉说“我认为”稳很多。
拾穗解读：这周别只记新词，记住 3 份证据
这周这些新闻看起来分散：LTAP、AI Storage、Spark Plan、历史流量回放。
但它们指向同一件事：AI 进入数据工作以后，真正稀缺的不是“有人会问它问题”，而是“有人能把问题整理成可验证的材料”。
对一个普通数据从业者来说，未来一段时间最值得补的，不一定是又学一个新工具。你可以先练 3 个动作：
第一，遇到慢任务，先留执行计划和运行指标，不要只截图最后报错。
第二，遇到两个数不一样，先写清数据窗口、链路来源和口径差异，不要只说实时/离线。
第三，遇到上线改动，尽量拿一段历史数据重放，看看新旧结果差异，而不是靠一组干净样本安慰自己。
这些动作听起来笨。
可是很多时候，职业差距就是这么拉开的。别人只会说“我用 AI 查了一下”，你能拿出证据，说清判断，留下可复查的记录。
这就够不一样了。
我叫石头，在数据行业里摸爬滚打了十几年，越来越觉得好工具要配得上好证据。这里写的，就是这些教训——我觉得值得说出来的那部分。
来源：Data Engineering Weekly #277 · Databricks Lakebase · Regatta 对 LTAP 的讨论 · Meta AI Storage · Expedia Spark SQL Plan · Stripe Spark 测试
