Posts

很多数据分析师和数据开发已经开始用 AI 写 SQL、查资料、整理分析，但每次提问都要重新解释业务背景、指标口径和项目约束。问题不一定是 AI 记性差，而是你的工作没有沉淀成说明书。本文从普通数据从业者视角，讲怎么把反复解释的内容变成可复用的项目说明、指标说明和判断记录。

很多数据分析师和数据开发以为 AI 项目卡住，是模型不够聪明、Prompt 不够好。Meta 的 AI Storage Blueprint 提醒了另一件事：模型能不能发挥作用，取决于数据能不能稳定、及时、可追溯地喂进去。本文从普通数据从业者视角，拆解为什么数据链路比模型演示更早决定 AI 项目的上限。

很多数据分析师和数据开发上线指标、SQL、模型或同步任务前，只用几条干净样本测试，结果上线后才被历史边界数据打脸。Stripe 用 Apache Spark 做历史流量回放测试提供了一个启发：普通数据从业者也可以在上线前多重放 1 次真实历史数据，提前发现口径、异常和兼容问题。

老板在会上问两个销售额为什么不一样，很多数据分析师会回答一个是实时、一个是离线。但在 LTAP、Lakehouse 和 AI 问数越来越常见的环境里，这个回答远远不够。本文用 Databricks Lakebase 和 Regatta 反方讨论作背景，讲普通数据从业者如何解释实时数、离线数、数据窗口和一致性边界。

Spark 任务跑了 3 小时，很多数据开发第一反应是问 AI 要不要改 executor、shuffle、分区数。但慢任务不是靠一句调参解决的。本文结合 Expedia 分析 Spark SQL Plan 的实践，说明普通数据开发为什么要先拿出执行计划、运行指标和业务上下文这 3 份证据。

很多数据分析师和数据开发刷了 30 个 SQL、Spark、建模、BI 教程，面试时却讲不清一个真实项目。问题不一定是学得少，而是教程留下的是知识点，面试要的是场景、选择、证据和结果。本文从一次项目追问说起，拆解普通数据从业者怎么把学习变成可讲清的项目证据。

本期数据周刊关注 Data Engineering Weekly #277：Databricks Lakebase、Meta AI Storage、Expedia 诊断 Spark SQL Plan、Stripe 重放历史流量。对数据分析师、BI 和数据开发来说，为什么 AI 能帮忙之前，先要准备 3 份证据？

很多数据分析师接到问题后，会不断加维度、拆人群、补图表，最后报告越来越厚，结论却越来越不清楚。真正成熟的数据分析，不是把所有可能性都查完，而是在证据足够支撑行动时停下来。本文讨论数据从业者如何用动作目标、停手三问和复查点判断分析该继续还是该收手。

很多数据分析报告最后只剩一页截图：几张图、几行字、一个模糊建议。业务看完不知道该怎么行动，过几天也没人记得结论。本文给一套 Pro 结论交付模板，帮助数据分析师把活动复盘、渠道分析和经营异常报告拆成问题、证据、判断、选项、风险、责任和下一步。

数据分析师经常要汇报坏消息：指标下滑、活动无效、渠道变差、数据异常、老板期待的结论站不住。问题不是能不能说，而是怎么说。本文给一套 Pro 表达模板，帮助数据从业者把坏消息拆成事实、影响、原因、边界、选项和建议，讲清楚问题又不把责任全背到自己身上。

老板在会上常说“你就给我一个结论”，但很多数据问题并不适合立刻下判断。数据分析师如果硬给答案，很容易把假设说成事实，把趋势说成因果。本文讨论数据从业者如何在真实会议压力下用事实、判断、建议和边界表达结论，既不逃避决策，也不把自己逼成算命先生。

很多数据分析师开会前准备了 SQL、图表和结论，到了现场却发现真正难的不是被问倒，而是说完以后没人信。老板问口径，业务问例外，产品问是不是样本太少。本文从一次经营会讲起，说明数据从业者如何把结论讲成别人愿意相信、愿意行动的表达。

Microsoft 2026 Work Trend Index 把企业推向 Frontier Firm，Databricks 也开始强调治理 AI agents 能做什么。对数据团队来说，Agent 进公司流程前最该问的不是能不能自动跑，而是谁给它身份、权限、审批和日志边界？

很多数据团队一听语义层，就想到老 BI、指标平台和数据治理文档。但 Power BI、Databricks、MIT 和 Lyft 最近都在重新谈 semantic layer。对数据分析师和数据工程师来说，真正的问题是：怎么从 20 个高频业务问题开始，把指标、维度、权限、质量和拒答规则写成 AI 能调用的数据说明书？

很多公司做 AI 问数时，先关心模型会不会写 SQL，却忽略了一个更普通的问题：公司有没有一本能说明指标口径、数据来源、权限边界和适用场景的指标说明书？对数据分析师和 BI 同学来说，AI 最先暴露的往往不是模型能力，而是组织没有把业务语义写下来。

Power BI、Databricks 和 MIT 最近都在把语义模型、治理台和 GenAI 放到一起讲。对数据分析师和 BI 同学来说，问题不只是报表会不会被 AI 取代，而是你的指标、权限、口径和解释，能不能变成 AI 也能调用的业务接口？

本期数据周刊关注 6 月最后一周的 5 个信号：Power BI 把语义模型接到 AI 应用，Databricks 继续强化 Unity Catalog 治理，MIT 讨论 GenAI 语义层，Lyft 公开指标语义层实践，Shopify 训练 AI 拒答。数据分析师和数据工程师该准备什么？

很多公司做数据治理时会建指标字典、数据标准、血缘文档和质量规则，但业务仍然在群里问口径、导 Excel、临时找人解释。数据治理失败不一定是没人做，而是做完没有进入真实工作流。本文从一次治理项目复盘讲起，拆解治理没人用的 4 个原因和 3 个更小的落地入口。

很多数据从业者一焦虑就去学新工具：Python、Flink、ClickHouse、AI Agent、各种 BI 平台。但涨薪真正买单的，往往不是工具数量，而是你能不能减少业务不确定性、讲清项目价值、承担更复杂问题。本文从一个课程收藏夹讲起，拆解普通数据人涨薪前更该补的 4 种能力。

数据同学最怕业务反复改口径：今天按下单，明天按支付，后天又要排除退款。很多人第一反应是改 SQL，但真正该问的是业务到底要用这个指标做什么。本文从一次复购指标争议讲起，拆解口径反复背后的 4 个问题，以及一张指标变更卡应该记录什么。

AI 问数和 Text-to-SQL Demo 往往很顺：输入一句话，模型生成 SQL，图表立刻出现。但一到真实企业上线，就会遇到权限、口径、表名、脏数据和责任边界。本文从一次上线评审讲起，拆解 AI 问数翻车的 4 个原因，以及上线前必须补的 5 个基础动作。