虾皮数据开发面经：数仓建模、数据治理与智能问数 Agent

《面试题目》

1. 请做一下自我介绍。
2. 你最擅长哪部分？
3. 你的项目是离线数仓，你觉得当前数仓建模存在什么问题，有哪些可优化点？
4. 你们建模的过程是怎样的？
5. 分层是怎么设计的？
6. 如何避免重复建表？其他人可能不知道已有同一张表，重复新建。
7. 站在数据架构和数据治理角度，业务希望需求尽快上线，同时资源紧张，既要时效，又要控制存储，如何平衡？
8. 口径变更时，为什么选择新建表切换依赖，而不是直接在原表上改造？
9. 搭建这条数据链路整体思路是什么？
10. 其他同学也能说出这些内容，对比其他人，你的突出优势是什么？
11. 你说优势是全链路思维，那在 AI 使用这块，相比其他人你的优势在哪里？
12. 你是做 AI 模型，还是 Agent 这类平台？
13. 在这个过程中你学到了什么？智能问数 Agent 存在哪些问题？
14. 从架构和实现上，你理解智能问数 Agent 是怎么做的？
15. 检索增强的时候，怎么检索到和业务意图最匹配的片段？
16. 如果跨业务域查询，怎么规避跨域错误调用？
17. 没有看底层代码，你是怎么学习 Agent 执行流程的？
18. 你怎么快速学习业务知识？
19. 平时还在学习哪些新知识？

《参考解析》

怎么避免重复建表：把「有没有现成的表」变成一秒能查到的事

重复建表的根因是信息不可发现：新人不知道已有同口径的 DWD/DWS 表，也没人能立刻告诉他。治理要同时上三件东西。① 元数据可检索：把表的中文名、业务过程、粒度、维度、指标口径、负责人、更新时间收进元数据平台或数据地图，支持按「指标名 / 业务过程 / 维度组合」反查表，而不是靠记表名。② 命名与分层规范：表名里带上分层、业务域、粒度、更新频率（如 dws_trade_order_shop_1d），让人从名字就能判断是不是自己要找的东西；同一业务过程只允许一个「官方」实现，其余变体必须标注用途。③ 流程卡口：建表走工单/评审，提交时强制填写业务过程与口径，系统自动做相似表推荐（按表名、字段相似度、血缘）并需要申请人确认「为什么不能复用」；上线后由血缘与冷热分析定期清理长期无人读的冗余表。这三条里最有效的是元数据 + 相似表推荐，因为它作用在「人刚要动手」的那一刻。

口径变更为什么新建表切换依赖，而不是原地改

口径变更的本质是「语义变了」，而数据一旦落盘就带着当时的语义。原地改表的问题是：历史分区要么和新逻辑不一致（同一张表里混了两个口径，下游谁都不敢用），要么必须全量重刷（成本高、时间长、重刷期间数据不可用）；一旦新逻辑有问题，回滚时历史数据已被覆盖，没有退路。

新建表 + 切换依赖的做法把变更变成一次可回滚的发布：新表按新口径全量/增量重跑，期间旧表继续对外服务；跑完后做双跑对账（新旧表在共同维度上比对，差异要能逐条解释），确认无误再把下游依赖从旧表切到新表，旧表保留一个观察期再下线。代价是短期内存储与调度成本翻倍、血缘关系变复杂、需要有人负责切换与清理。所以实践里通常折中：小范围、语义等价的改动（加字段、加枚举值）直接演进；影响核心指标口径的改动走新建表切换。判断标准是「这个改动会不会让历史数据的含义发生无法自动对齐的变化」。

时效、成本与存储的平衡：按需求分级，别用一套标准

三者不可能同时最优，可行的方法是先给需求分级再匹配资源。① 把需求按「决策价值 × 时效敏感度」分层：实时看板、风控、投放这类分钟级诉求走实时链路（Flink + 消息队列 + 列存/OLAP 表）；T+1 经营分析走离线数仓；探索性分析走即席查询或抽样数据。② 存储上做生命周期管理：明细层按业务保留期做分区过期与冷热分层（热数据放高性能存储、冷数据转低频/归档），中间层可重算的表不必永久保留，只保留可回溯的窗口。③ 计算上做增量与复用：能用增量就不要全量重跑，公共中间层（DWD 明细、常用维度）一次加工多处复用，避免每个需求各拉一遍原始数据。④ 治理上要能说清代价：给业务方展示「这个需求要新增多少存储、多少算力、延迟能到多少」，让取舍由业务拍板而不是数据团队默默扛。面试里最好再补一句兜底原则：优先保证按时交付核心口径的数据，宁可牺牲部分维度的时效，也不要让核心指标不准。

智能问数 Agent 的架构与跨域错误调用怎么防

架构上通常分四层：语义层（指标定义、维度、同环比等计算规则、表与字段的业务别名，这是准确率的天花板）、理解层（把自然语言问题拆成「指标 + 维度 + 过滤条件 + 时间范围」，歧义时反问而不是猜）、执行层（受控的查询工具，从语义层选指标生成 SQL/DSL，带权限与资源限制）、呈现层（结果 + 图表 + 生成 SQL + 数据来源，支持追问与下钻）。难点不在生成 SQL，而在「问的到底是什么」——所以澄清机制（口径歧义、时间范围缺失、指标不存在时给候选并让用户确认）是必备件。

跨业务域的错误调用有几种落法：① 在语义层显式声明每个指标/数据集所属的业务域与授权范围，用户或会话带有域上下文，工具只暴露该域下的对象；② 做「域路由」——先用分类或检索判断问题属于哪个域，再只把该域的 schema 注入上下文，模型看不到别的域的表，自然调不到；③ 跨域问题不硬拼，识别到需要多域数据时显式走审批过的跨域视图/宽表，或告知用户不支持；④ 执行前做一次静态校验，检查 SQL 里引用的表/字段是否都在授权集合内，不在就拒绝而不是执行后报错。最后加上全链路审计：谁在什么上下文问了什么、选中了哪些指标、生成了什么 SQL、返回多少行，出问题时才能复盘是语义层缺定义还是路由判错。