4. 数据标准与数据模型设计：主数据管理、数据模型分层、数据字典建设
数据标准是数据治理的“语言规则”，主数据管理解决核心实体一致性，模型分层决定数据复用与易用性，数据字典则是元数据落地的关键。面试中重点考察候选人对标准体系的理解、分层建模的实践、以及字典建设与业务对齐的能力。
公司侧重点与面试官画像
| 公司类型 | 侧重点 |
|---|---|
| 互联网大厂 | 数据模型分层复用、元数据血缘、自动化字典建设 |
| 金融/银行 | 主数据一致性、编码标准合规、监管数据质量 |
| 政企/传统 | 数据标准落地流程、字典维护制度、模型评审机制 |
| 面试官画像 | 数据架构师 / 数据治理负责人，深度关注候选人对“标准与模型”从理论到落地的闭环认知，偏好具体项目数据、量化指标、异常处理经验。 |
问答卡片
面试问题：请谈谈你对主数据管理的理解，以及在实际项目中是如何落地的？
考察点：是否理解主数据与交易数据的区别；是否有统一编码、数据分发、质量监控的实战经验。
回答框架：
① 定义主数据（客户/产品/组织）及核心特征（相对稳定、跨系统共享）；
② 落地步骤：统一标准→唯一标识→清洗去重→分发同步→持续治理；
③ 举例：某项目整合3套CRM系统客户数据，建立MDM平台，月度匹配率提升至99.5%。
简短示例回答：
“主数据是企业的核心实体，如客户、产品。我在XX项目中，通过制定统一编码规范、搭建MDM平台，将来自CRM、ERP的客户数据去重合并，每日增量同步，实现90%+的自动匹配率，并建立质量监控看板。”
可能追问：主数据与参考数据有何区别？如何处理冲突数据？
避坑提醒：避免只讲理论，一定要结合具体实体（如客户ID生成规则）和冲突解决策略（如置信度投票）。
面试问题：数仓建模中的分层设计你是如何做的？每一层的作用是什么？
考察点：对数据模型分层（ODS/DWD/DWS/ADS）的深入理解；分层解耦与复用思想；数据冗余与性能的平衡能力。
回答框架：
① 分层原则：解耦、复用、减少重复计算；
② 各层定义：ODS保留原始痕迹，DWD清洗标准化，DWS轻度汇总，ADS面向业务指标；
③ 举例：电商订单数据，ODS存JSON，DWD拆字段并去重，DWS按天聚合，ADS输出GMV报告。
简短示例回答：
“我们采用四层模型：ODS保留全量业务快照，DWD做数据清洗与标准化，DWS按维度汇总（如用户日活跃），ADS直接输出报表。某次需求变更只需调整DWD层，下游模型不受影响，节省30%开发人力。”
可能追问：数据倾斜在分层中如何解决？如果ODS层数据量巨大怎么办？
避坑提醒：不要只背书各层定义，要结合实际场景说明分层带来的可维护性收益和性能取舍。
面试问题：数据字典在你的项目中是如何建设与维护的？如何保证字典与实际数据的一致性？
考察点：元数据管理意识；字典字段定义的规范程度；字典更新与血缘联动的自动化能力。
回答框架：
① 字典内容：字段名称、类型、业务含义、枚举值、来源表、负责人；
② 建设方式：工具（如Atlas、DataHub）自动采集+人工补全；
③ 一致性保障：通过数据血缘定时校验字典与实际表结构，不一致时触发告警。
简短示例回答：
“我们使用DataHub采集Hive元数据，人工补充业务描述，并建立字段级血缘。每天凌晨跑校验任务，对比字典字段与表结构，发现新增字段自动同步，不一致字段推送给负责人，字典变更落地率达98%。”
可能追问：字典变更后如何通知下游？历史版本如何处理？
避坑提醒：不要只说“字典很重要”，要具体到工具、自动化流程和版本管理，否则显得缺乏工程落地经验。
项目案例模板
业务背景：集团旗下6家子公司使用不同ERP系统，客户、商品数据严重不一致，报表难以汇总。
规模指标：覆盖100万+客户、50万+SKU，月数据增量500GB。
技术栈：Hadoop（Hive/Spark）、DataHub、阿波罗配置中心、自研MDM服务（Java）。
核心难点：统一编码规则难定（各子公司有历史包袱）；去重匹配效率低（百万级模糊匹配）。
面试高频追问：
- 你们用什么算法做客户去重？（编辑距离+SimHash，准确率92%）
- 字典变更如何通知下游？（Webhook + 钉钉机器人，变更后触发模型重跑）
- 遇到子公司抵制统一编码怎么办？（分阶段推行，先映射后替换，保留原编码作为历史字段）
“我们项目最大的收获是‘标准先行’：先成立数据标准委员会，确定编码规范后再开发MDM系统。后续字典建设通过血缘自动同步，将治理流程嵌入日常发布，避免二次人工维护。”
大厂模拟面试
面试官提问：“你们公司的数据模型分层是几层？为什么没有用更少的层？”
候选人回答（普通）：“我们用了四层：ODS、DWD、DWS、ADS。大多数公司都这样，我觉得挺好的。”
候选人回答（优秀）：“我们采用四层设计，因为业务需求既有明细查询又有多维分析。ODS保留源数据，DWD清洗标准化，DWS按主题轻度汇总，ADS直接对接报表。这样既能快速响应临时取数，又能避免重复计算，目前已运行一年，维护成本很低。”
候选人回答（专家）：“我们原本是三层（ODS-DWD-ADS），后来发现业务方频繁要求不同粒度的汇总，导致DWD层冗余严重。因此我们引入DWS层，按业务域（如用户、订单、商品）做轻度汇总。同时通过数据血缘自动识别哪些字段可以被下游复用，避免‘越层引用’。调整后，模型复用率提升40%，查询响应时间降低60%。如果数据量继续增长，我们计划引入ClickHouse作为ADS加速层，保持分层不变。”
面试官追问：“DWS层如果设计不当，会导致数据膨胀，你怎么控制？”
优秀回答方向：“严格控制DWS字段数量，只保留核心维度（如时间、地域、产品）和关键指标，非必要不添加；使用维度建模的星型结构，避免宽表；定期通过血缘分析清理长期未使用的DWS表。”
→ 主数据管理强调“唯一标识+分发同步”；
→ 模型分层强调“复用与解耦”，用具体指标证明收益；
→ 数据字典建设强调“自动化采集+血缘校验”，避免纯手工维护。