数仓类项目走过的坑

1.SQL遇到NULL值容易导致各种问题，应考虑ODS层以上数据表字段的空值处理规则。比如维度属性默认设置为-1，度量字段默认为0.
若觉得范围太大，最起码日常分析的维度属性、度量值要考虑空值的处理。

2.金额等数字小位数要尽量多预留，避免加工汇总的金额与明细存在尾差较大的问题。

3.不要相信上游系统的数据质量，各种你想象不到的数据质量问题。应在开发阶段或之前，进行生产数据的探查，了解各字段的数据分布情况、各属性枚举值、空值情况，做对应处理。异常值的处理方案需要业务确认。
同时有必要引入自动数据质量检查机制，针对关键性、重要数据进行检查、发现后告警或者自动修正。

4.ODS数据源层数据保持与上游一致，便于后续粗粒度数据的核对、数据溯源、以及应对后续各种新需求。特殊情况：采用拉链表保存历史数据。

5.数据明细层(DWD)务必保持最细颗粒度，应默认包含全部数据，谨慎剔除字段或记录(如失败交易也有分析价值)。此层封装逻辑的加工，数据一致性处理(如统一客户号格式、统一维度属性)，为后续各层提供统一数据视图。

6.数据仓库建模之前，需要充分了解业务日常分析需求，分析痛点，可采用分析业务日常报表、面谈、及熟悉源系统业务。缺乏业务视角的数据模型通常失败。

7.数据仓库最核心的是数据模型，良好的模型设计易于扩展、解耦，可避免数据重复加工、数据不一致性、性能低下等问题。建议DWD/DWS/DIM的模型设计必须由架构师/高等级人员审核。

8.宽表可以减少表之间的关联，但若设计不当，反而影响性能。
比如上亿级别的宽表，把小维度表的维度属性过多放入宽表，导致宽表越来越大，性能还不如关联小微表。

9.遵守数仓分层建模规范，可以避免很多坑，理论指导实践，同时结合实际。