联友科技数据开发面经（10.9）

《面试题目》

1. 自我介绍。
2. 介绍一下你的实习情况？
3. 实习给你带来哪些学习和技术能力提升？从企业项目里得到什么启发？
4. 你在接触完整大数据链路时，工作主要负责哪一块？
5. 那在整个流程里，从采集、模型设计到数据治理、BI 应用，哪一块你最熟悉？
6. 介绍一下数仓分层，DWS 层跟 ADS 层的差异是什么？什么场景下构建主题层？怎么从主题层到分析层？
7. 什么样的模型适合放在 DWS 层？
8. 换一个场景，客户画像的客户标签数据，这类标签模型放在哪一层合适？标签表设计适合选用什么技术栈？建模时一般设置哪些维度？维度之间的数据如何关联？
9. 简历提到性能调优、处理数据倾斜，解释一下数据倾斜，一般哪些场景会产生数据倾斜？
10. 你提到加盐打散，加盐打散是怎么实现的？
11. 你提到 Iceberg，Iceberg 属于数据湖吗？讲一下数据湖和传统 Hadoop 数仓的区别。
12. 还有建表分层、分区、分桶，在建表逻辑里，这三者分别通过什么方式实现？
13. 你也接触数据治理，介绍一下数据治理主要分为哪几部分？
14. 实习过程中，哪些场景使用 AI 实现或者辅助做提效？
15. 你认为大数据领域后续借助 AI Agent 做优化，哪些方向适合用 Agent 落地？哪些工作可以由 Agent 替代？

《参考解析》

数仓分层与 DWS、ADS 的差异。分层的目的不是把表拆得好看，而是让每一层承担固定职责、让下游只依赖稳定的上游。常见四层：ODS 贴源，几乎不做清洗，保留原始全量与增量；DWD 明细，做去重、清洗、维度退化，粒度是「一行一个业务事件」；DWS 轻度汇总，按主题域和维度预聚合，粒度是「某维度组合下的一批事件」；ADS 面向报表与接口，按具体指标和展示口径组织，通常是宽表或结果表。DWS 与 ADS 的差别在三点：粒度（维度组合级 vs 指标结果级）、来源（从 DWD 汇总 vs 从 DWS 甚至跨主题拼装）、稳定性（DWS 相对通用、ADS 随需求频繁变）。主题层一般就是按主题域组织的 DWS：当同一批明细要被多个下游以相同粒度反复聚合时，就该把它固化成主题层；从主题层到分析层，则是再按口径算指标、拼维度、落到报表。

什么模型适合下沉到 DWS，标签模型放哪一层。判据是复用度：被两个以上下游以同一粒度使用、口径已经稳定、更新频率和时效要求一致，就值得下沉；只服务单一报表、口径还在变的，直接放 ADS 甚至临时表，别过早抽象——DWS 表数量和粒度组合一旦膨胀，就会退化成一层更难维护的明细。客户标签这类数据通常单独放标签层（有的团队叫 DWT 或 TAG 层），它的驱动是「对象」而不是「事件」，粒度为一行一个用户、一列一个标签，还会按天做快照便于回溯历史。技术栈选择看场景：标签宽表 + 即席查询可以用 ClickHouse、Doris；标签量大、人群圈选要求毫秒级时用位图（RoaringBitmap），把「标签值 → 用户位图」存起来，圈选就是位运算求交并差，这是主流做法；需要按对象点查和频繁更新则用 HBase、Redis 这类 KV。建模时设三类维度：对象标识、标签本身（枚举或数值）、时间（生效时间/快照日期），维度之间通过对象标识关联，标签组合靠位图交集或宽表 join，同时要定义标签的时效与多来源覆盖规则。

数据倾斜的成因与加盐实现。倾斜的本质是某个 key 的数据量或计算量远超其他 key。常见来源：业务上天然存在大客户、大卖家，占比可能到 90%；join 键存在大量 NULL 或默认值；group by 的维度组合分布极不均匀；大小表 join 没走 map join 导致大表 shuffle；上游文件大小不均导致单个 task 读得特别多；count distinct 在大基数列上放大中间结果。加盐打散分两步：先给热点 key 拼上随机前缀做局部聚合，把一个大 key 拆成若干份并行算；再去掉前缀做全局聚合。代价是多一轮 shuffle 与额外网络开销，所以只对确认的热点加盐；更通用的写法是两阶段聚合，先按「key + 随机数」聚合，再按 key 聚合。

数据湖与 Iceberg。传统 Hive 数仓是 schema on write：写入时就要定好表与分区，数据是裸文件，元数据在 metastore，更新删除靠重写分区，没有事务与快照，读者可能读到正在写入的半成品。数据湖（Iceberg、Hudi、Delta）是在文件之上加了一层表格式：用元数据文件记录快照、manifest 与数据文件的对应关系，从而支持 ACID、行级更新删除、schema evolution、时间旅行与增量读，还能做隐藏分区。Iceberg 仍然属于数据湖范畴——它管的是表格式与元数据，数据文件还是放在 HDFS、S3、OSS 上。选型上，湖适合既要明细存储又要更新的场景（CDC 入湖、准实时数仓），传统数仓适合口径稳定、以批量离线报表为主的场景，实际项目常常混用：ODS/DWD 放湖里，DWS/ADS 仍用 Hive 或 MPP 引擎。

建表时分层、分区、分桶的实现。Hive 里分层靠库表命名与依赖约定（ods_/dwd_/dws_/ads_ 前缀、只允许逐层引用），分区靠 PARTITIONED BY 落到目录结构，分桶靠 CLUSTERED BY (col) INTO N BUCKETS，写入时按 hash 分文件，目的是同桶 join 免 shuffle 或便于抽样。Iceberg 里分区不写进数据路径，而是用 partition spec 的 transform（identity、bucket、truncate、days 等）表达，分桶用 bucket transform，查询时靠元数据做分区裁剪，用户不必在 SQL 里写分区条件。要注意分桶数一旦写入就影响后续读写与扩容代价，分区键要选查询里过滤最多的列，否则会产生大量小文件和元数据压力。

数据治理与 AI 提效。数据治理通常分几块：元数据与血缘（影响分析与故障定责的基础）、数据质量（规则、稽核、告警与阻断）、标准与建模规范（命名、口径、维度一致性）、安全与权限（分级分类、脱敏、行列级权限）、成本与生命周期（存储分级、TTL、任务资源治理）。AI 目前在数据开发里落地较好的方向是：SQL 生成与改写、血缘和影响面解析、任务异常诊断与根因推荐、质量规则自动生成、口径文档解释；不适合交给 Agent 的是口径拍板、资源与权限审批，以及没有确定性验收标准的决策——这些仍然要人负责，Agent 只提供候选建议。回答时把「哪些能替、哪些只能辅助」的边界讲清楚，比罗列工具名更有说服力。