跳转至

附录 E 常见问题（FAQ）

面包屑

本书主页 › 附录 › 附录 E

这一附录收集读者最常问的问题。如果你在阅读中产生疑问，先来这里看看是否已有答案。

架构与选型类

Q1：这个架构适合小型团队吗？

简答：不太适合。这套架构的成分很重——AWS 自组装 + Terraform + Glue/Step Functions + Redshift，它是为中型企业、100TB+ 规模、多业务域、强合规场景设计的。它的复杂度来自"可治理、可演进"这两个硬需求。小型团队（<5 人、<1TB、单业务域）拿这套来用，属于过度工程，会把自己绕进去。

更适合小型团队的方案：直接用 Snowflake 或 Databricks 一体化平台，省去 IaC 和组件集成的运维负担。详见 Ch 52 的主流方案对比与选型建议。

引申

判断"是否需要这套架构"的简单标准：如果你的数据量 <1TB、源系统 <5 个、没有 GxP/PIPL 合规要求、团队 <5 人，优先选一体化平台。当规模或合规复杂度上升到"自组装的灵活性收益超过集成成本"时，再考虑本书的方案。

Q2：为什么不直接用 Snowflake / Databricks？

简答：不是不想用，是当时用不了。项目起步时（四年前），Snowflake 和 Databricks 还没进中国大陆提供商用服务，数据驻留逼着我们只能选 AWS China。这是历史约束，不是技术偏好。详见 Ch 2 的选型争论和 Ch 3 的 AWS China vs Global 差异。

如果今天重新选型：Ch 52 给了"如果重来"的建议——一体化平台（Snowflake-first）和湖仓开源（Databricks Lakehouse）会是首选。本书方案（AWS 自组装）是特定历史约束下的务实选择，但书里的架构思想——五层模型、配置驱动、治理体系——跟选什么方案没有绑定。

数据工程类

Q3：如何迁移现有的 Airflow DAG 到这个平台？

简答：本书平台的编排走的是 Step Functions + EventBridge，不是 Airflow。但迁移思路是通用的：

  1. 梳理 DAG 依赖：把 Airflow DAG 里任务之间的依赖关系映射成 Step Functions 状态机的节点拓扑（Ch 10、Ch 33）
  2. 任务实体化：每个 Airflow Task 对应到一个 Glue Job 或 Lambda 上，用配置驱动来声明（Ch 12）
  3. 调度迁移：Airflow 的 schedule 换成 EventBridge 定时规则
  4. 渐进迁移：先拿非关键 DAG 试水验证，再分批迁关键 DAG

Trade-off

如果你已经在 Airflow 上跑得很熟了，手里也有大量 DAG 在生产——那别强行迁到 Step Functions。Airflow 本身是很成熟的编排工具。Ch 52 里也说了，"单线程 DAG"是我们的遗憾，Airflow 的有界并发反而更成熟。迁不迁取决于"统一编排栈"和"迁移成本"这两头怎么权衡。

Q4：增量加载的水位管理有什么坑？

简答：坑主要有三个，详见 Ch 14：

  1. 硬删除漏数据：时间戳水位拿不到被物理删除的行 → 定期全量校准兜底
  2. 迟到数据：源系统延迟，updated_at 落后于水位 → 加回溯窗口（3 天），用分区幂等覆盖
  3. 水位回退：重跑时水位被覆盖了 → 水位存在 DynamoDB，重跑前先备份原来的值

Agentic BI 类

Q5：Agentic BI 的 LLM 成本怎么控制？

简答：三层控制，详见 Ch 47 成本分析：

  1. 缓存命中（35%）：语义相似度 ≥0.92 的查询直接返回缓存 SQL，跳过 LLM 调用（Ch 42）
  2. 简单查询强路由：术语绑定直接命中 metric 定义，跳过规划器（Ch 40）
  3. 多 Provider 抽象：简单查询用便宜模型，复杂查询才用强模型（Ch 47 Roadmap P1）

量级参考：日均 500 次查询，大概 ¥15,000/月，远低于替代它的传统 BI 人力成本。成本失控的信号很容易识别——如果所有查询都走完整 LLM 流程，意味着缓存和强路由没生效。把它改成"简单查询走缓存/强路由，复杂查询才走完整流程"就正常了。

Q6：Agentic BI 上线准确率只有 75%，业务不信任怎么办？

简答：这个数在 30 天磨合期里太正常了，别想着上线第一天就 93%。关键是要把"用户反馈、语义资产修正、准确率提升"这个闭环跑起来。用户每纠正一次，就进到 Correction Memory（Ch 45），下次变成 few-shot 喂进去。30/60/90 天的递进曲线（75%→85%→93%+）是这条路上的正常形态（Ch 51）。刚开始可以先开"咨询模式"（Ch 44）——只展示 SQL 不自动执行，业务确认了再跑，信任建立之后再切自动。

Q7：Steiner 树查询规划太难，能不能直接让 LLM 推理 join？

简答：可以，但复杂查询的准确率会掉一大截。Steiner 树的价值正好在这里——把"join 路径选择"这件事从"让 LLM 猜"变成"用算法算"。简单查询 LLM 推理够用，一到多表 join + 聚合，LLM 经常选错路径（鸿沟陷阱、扇出陷阱）。加 Steiner 树之后，复杂查询准确率提了大概 12%（Ch 43、Ch 47）。如果团队暂时搞不了规划器，至少先把五层护栏（Ch 44）上上去兜底。

治理类

Q8：医药行业的 GxP/PIPL 合规，最小必要投入是什么？

简答：三件套，缺一不可，详见 Ch 18、Ch 48：

  1. 数据驻留：选 AWS China（cn-north-1），满足数据不出境
  2. 字段级脱敏：至少实现 mask/md5/aes_encrypt 三种策略 + 配置驱动（Ch 18 决策表）
  3. 全链路审计：审计日志 + RLS/CLS 权限控制（Ch 48）

合规不是事后打补丁的活，是架构第一天就要嵌入的非功能需求。事后补的代价远大于一开始就做进去。

基础设施 / Terraform 类

Q9：Terraform state 锁死了怎么办？

简答：DynamoDB lock 偶尔会锁死（apply 崩了没释放 lock）。紧急用 terraform force-unlock <LOCK_ID>，但有规矩：① 两个人确认（ChatOps 审批）；② 操作记 audit log；③ 事后查清楚锁死的根因（多半是 apply 进程被 kill 了）。详见 Ch 21。绝对不要直接去 DynamoDB 里删 lock 表项——先确认真的没有别的 apply 在跑。

Q10：如何升级 Terraform 模块版本？

简答：改业务仓里 ?ref=vX.Y.Z 这个指针，然后走 DEV→QA→PROD 完整发布流（Ch 24）。Major 版本（破坏性变更）要做的：① 读模块 CHANGELOG 确认 breaking changes；② 在 DEV 跑 terraform plan 看 diff；③ 准备回滚方案（把指针指回旧版号）。Minor/Patch 通常向后兼容，但 QA 验证不能省。

Q11：Drift Detection 发现漂移了怎么办？

简答：周级 terraform plan -detailed-exitcode 扫到漂移（有人手动改过 AWS 资源），两种情况：① 手动修改是错的→提修复 PR，把 Terraform 代码改到和实际一致，或用 terraform apply 把资源改回代码定义的状态；② 手动修改是必须的→更新 Terraform 代码把它纳管进来。不管哪种，都要补 audit log 写清楚"为什么漂了"。详见 Ch 28。

团队 / 组织类

Q12：数据平台团队该怎么招人？

简答：平台需要四类人——数据工程师（ETL/Spark）、IaC 工程师（Terraform/CI/CD）、平台运维（监控/排障/成本）、AI 工程师（Agentic BI，后期才需要）。最难找的是"既懂数据工程又懂 IaC"这种两头都通的——建议内部培养比外部招聘靠谱：先招底子扎实的数据工程师，再给他补 IaC。详见 Ch 53 团队结构。

Q13：知识转移怎么度量？

简答：咨询式交付真正的终点是"把自己交付到不需要自己"（Ch 53）。度量指标：① 甲方团队独立解决的 issue 占比（目标 >70%）；② 甲方独立添加新数据源的 lead time（目标 <1 周）；③ 文档完备度（每个流程有 runbook）。知识转移不是"培训完就散场"，是"甲方能独立运营"才叫完成。

Agentic BI 类

Q14：Agentic BI 用多家 LLM Provider 怎么管理？

简答：抽象一个 Provider 层，简单查询走便宜模型、复杂查询走强模型（Ch 47 Roadmap P1）。关键是统一接口——llm.complete(prompt, model) 把各家 API 的差异吃掉，切 Provider 只改配置不动代码。中国区要特别注意 Provider 的可用性（Bedrock 模型子集跟 Global 不一样，见 Ch 3）。

Q15：SQL 缓存的相似度阈值 0.92 怎么调？

简答：0.92 是在准确率和命中率之间找的一个平衡点（Ch 42）。往上调（0.95），命中率下来但更安全；往下调（0.85），命中率上去但可能吐出不够精确的 SQL。建议：① 先用 0.92 跑一个月，统计缓存命中后用户有没有纠正（纠正率高就说明阈值偏低了）；② 按查询类型分级——简单查询阈值可以放低（0.88），复杂查询阈值要收紧（0.95）。

Q16：HITL 审批会不会拖慢效率？

简答：审批只对高风险操作触发（DDL/大批量 DELETE/跨租户导出，Ch 42），这类操作本身频次就很低。关键是审批通道要快——推到企业 IM（如 Slack/Teams），业务负责人手机上就能批，超时自动拒绝省得悬着。HITL 不是"每条查询都审"，是"少数高风险操作把个关"，对整体效率影响不到 5%。

下一部分

附录 F Agentic BI 快速启动指南 —— 如果你想动手搭一个 Agentic BI，这份 checklist 是从零到一的五步路线图。

评论