9ikun 数据开发二面：湖仓一体、DQC 与 Agent 追问

《面试题目》

1. 请做一下自我介绍。
2. 介绍湖仓一体，为什么企业要搭建湖仓一体？
3. 湖仓一体有哪些缺点，为什么传统数仓没有被淘汰？
4. 湖仓一体数据治理难，具体难在哪些地方？
5. 在实际项目中，你如何解决湖仓一体口径混乱、数据质量差的治理难题？
6. 每层 ETL 后 DQC 检查具体如何实现？
7. 除了缺失值、数值范围，DQC 还有哪些监控规则？
8. 指标细节询问 1。
9. 数据上游询问。
10. 项目细节：指标边界如何统计界定？
11. Agent 项目询问。
12. Agent 开发过程细节询问。
13. 你打算如何优化这个 Agent，保证分析结果准确可信？
14. 三段实习中你最喜欢哪一段，原因是什么？
15. 后续规划。

《参考解析》

湖仓一体的取舍：一份存储、多引擎消费

湖仓一体的本质是把数据湖的「开放存储」和数仓的「事务与管理能力」合到一层。存储仍然是对象存储 + 开放列式文件（Parquet/ORC），但在上面加一层表格式（Iceberg / Hudi / Delta Lake），由它提供 ACID 事务、快照与时间旅行、Schema 演进、隐藏分区这些原本只有数仓才有的能力，于是 Spark、Flink、Trino、Presto 这些引擎可以直接读同一份数据，不再需要「湖里存一份、仓里再搬一份」。企业愿意搭它，动机通常是三个：消除湖到仓的重复搬运与冗余存储、让实时与离线共用同一份明细、以及把 Schema 变更从「重刷历史」变成「元数据操作」。

它的代价也要能说出来：表格式的元数据服务本身就是新的运维对象（catalog、manifest、小文件合并、快照过期都要人管）；小文件与 compaction 做不好，查询性能会明显退化；权限与治理在开放格式上更依赖外围系统。传统数仓没被淘汰，是因为它在中等数据量、强事务与强一致口径、固定报表场景下依然便宜好用，团队也更熟悉——湖仓更适配海量、多类型数据与多引擎场景，小体量业务上湖仓性价比很低。

口径治理：Schema 演进 + 前置对齐 + 分层 DQC + 看板复检

口径混乱的根因往往不是技术，而是「同一指标在不同链路里被各写一遍」。可落地的四步：① 用表格式的 Schema 演进能力做加法——Iceberg 支持新增列、改列类型（受控的 promotion），加字段时历史数据不需要全量重刷，这消掉了大部分「改口径就要重跑历史」的工作量；确实要改语义时新建字段/新表并保留旧字段，靠视图对外保持兼容。② 需求进 ETL 之前就和业务、研发把指标定义对齐并写进文档/语义层，从源头锁口径，而不是等对不上账再回头查。③ 在 ODS、DWD、DWS 每层产出后都挂 DQC 校验，让问题在最近的一层被拦住，避免脏数据往下游扩散。④ 交付到 BI 看板后再做阈值复检，把异常通过告警工具推给责任人。面试官常追问的是「新建表切换依赖 vs 原地改」——新建表能双跑对账、可回滚、不污染历史快照，代价是存储与血缘复杂度，这才是选择它的理由。

分层 DQC 怎么实现：规则分类 + 基准对比 + 阻断或告警

DQC 落地要先分清「能自动判定的」和「需要业务确认的」。可自动判定的规则大致几类：非空/缺失率、唯一性（主键重复）、值域与枚举、数值范围（固定值或浮动区间）、行数与分位数波动、表间一致性（主外键、汇总与明细对账）、及时性与新鲜度（分区是否按时产出）。实现方式上，浮动区间比固定值实用：先建立基准指标表，每次产出后统计行数、空值占比、均值/分位数等描述性指标，与基准按容忍度比较，超界才算异常。触发后的动作要分级——核心链路（影响对外交付的字段）可以直接熔断下游任务并告警，非核心链路只推告警、由人判断，否则一次误报就会把整条链路卡死。规则本身也要有元数据管理：每条规则记清楚负责人、影响范围、最近一次触发原因，避免规则越加越多却没人敢删。

怎么让 Agent 的分析结果准确可信

把「可信」拆成可工程化的几件事。第一，缩小自由度：不要让 Agent 自由写 SQL 打全库，而是让它从受治理的语义层/指标定义里选指标、选维度，SQL 由模板生成，口径天然统一。第二，限定工具边界：只暴露白名单的查询工具，强制带分区/时间范围与行数上限，敏感表做行级权限，越权直接拒绝而不是靠提示词约束。第三，给出处：每个数字都要能回溯到具体表、分区、生成 SQL，让用户能复核，这在面试里是高频追问点。第四，加校验器：结果出来先做量级与对账检查（与昨日/环比是否突变、汇总是否等于明细之和），异常就降级成「需要人工确认」而不是硬答。第五，坦诚兜底：问题超出语义层覆盖范围、或口径有歧义时，明确说不知道并给出可选项，比编一个看起来合理的数字代价小得多。