02 | 如何评价数仓建设的好坏

评价一个数据仓库（数仓）建设的好坏，不能只看技术指标，而应从业务价值、数据质量、系统能力、团队协作等多个维度综合评估。以下是系统化的评价框架：

---

一、业务价值维度（是否“有用”？）

这是数仓存在的根本目的。

指标	说明
需求响应速度	业务提出新指标/报表需求，从接收到上线平均耗时多久？（理想：小时级/天级）
历史回溯能力	口径变更后，能否快速重算历史数据？（如：1天内完成1年数据回溯）
自助分析覆盖率	业务人员能否通过BI工具自助取数？占比多少？（越高越好）
决策支持度	核心经营指标（如GMV、DAU、ROI）是否由数仓统一提供？是否被高管信任？

✅ 好数仓：业务方主动提需求，认为“离了数仓没法干活”。
❌ 坏数仓：业务自己拉原始日志算数，或抱怨“数仓给的数据不准、不及时”。

---

二、数据质量维度（是否“可信”？）

数据质量是数仓的生命线。

指标	说明
准确性	关键指标与业务系统/财务数据是否一致？（如订单金额、用户数）
完整性	数据是否丢失？（如每日分区是否齐全，记录数是否符合预期）
一致性	同一指标在不同报表中结果是否一致？（如“活跃用户”定义是否统一）
及时性	T+1 数据是否在约定时间（如早9点）前产出？延迟率多高？
监控告警	是否有数据质量监控（空值率、波动阈值、主键重复等）？异常能否自动告警？

✅ 好数仓：有完善的DQC（Data Quality Check）体系，问题在影响业务前被发现。
❌ 坏数仓：业务先发现问题，再找数仓“救火”。

---

三、架构与技术能力维度（是否“健壮”？）

指标	说明
分层清晰度	是否遵循 ODS → DWD → DWS → ADS 分层？各层职责是否明确？
模型规范性	是否采用维度建模？事实表/维度表设计是否合理？
可扩展性	新增业务域（如直播、广告）是否容易接入？
性能效率	核心任务运行时长是否合理？资源消耗是否优化？（如避免小文件、数据倾斜）
元数据管理	字段含义、血缘关系、负责人是否可查？（如通过数据地图）
血缘追溯	能否快速定位某指标的数据来源和加工逻辑？

✅ 好数仓：新人接手1周内能看懂核心链路；改一个口径只需动1-2个任务。
❌ 坏数仓：逻辑散落在上百个脚本中，没人敢动“祖传代码”。

---

四、运维与治理维度（是否“可持续”？）

指标	说明
任务稳定性	核心链路任务失败率是否低于1%？重试机制是否完善？
成本可控性	存储和计算资源是否有优化？是否存在大量冗余表/无效任务？
权限与安全	是否按角色控制数据访问权限？敏感字段是否脱敏？
文档完备性	是否有数据字典、ER图、调度说明等文档？是否及时更新？

✅ 好数仓：资源利用率高，月度成本可预测；权限最小化，安全合规。
❌ 坏数仓：存储费用每月暴涨，谁都能查全量用户手机号。

---

五、团队协作维度（是否“高效”？）

指标	说明
需求管理流程	是否有明确的需求评审、排期、验收机制？
跨团队协同	与业务、产品、数据科学团队沟通是否顺畅？
知识沉淀	经验是否文档化？是否避免“人走数亡”？

---

六、量化评估表示例

评估维度	优秀（5分）	良好（3分）	差（1分）
需求响应速度	<1天	1-3天	>1周
数据准确性	关键指标0误差	误差<0.5%	经常被质疑
分层规范	严格四层，逻辑清晰	基本分层但有混用	无分层，脚本堆砌
血缘追溯	100%字段可追溯	核心指标可追溯	完全不可追溯
自助分析率	>70%	30%~70%	<10%

---

✅ 总结：好数据仓库的五大特征

1. 业务驱动：紧密支撑业务决策，而非技术自嗨。
2. 质量可信：数据准确、及时、一致，成为“唯一真相源”。
3. 架构清晰：分层合理、模型规范、易于扩展和维护。
4. 高效敏捷：快速响应变化，支持历史回溯和自助分析。
5. 治理完善：有监控、有文档、有权限、有成本意识。

📌 终极检验标准：
“当业务方说‘这个数不对’时，你能在5分钟内定位到是数据问题、逻辑问题，还是业务理解偏差。”
如果能做到，说明你的数仓建设是成功的。