背景：

当一个新的数据仓库、数据集市从零开始建设时，我们通常会纠结如何按照经典的数仓分层理论进行设计，然后按照经验规范进行所有的开发工作；但从实际开发过程中，会发现这种思路类似建设一个大型系统，想在设计阶段就把各种需求考虑完整，然后再花时间统一建设，这种思路需要非常完整的专家领域经验及建模方法论，对人员及时间的要求非常高，不适合当前快速发展的业务需要，所以我们需要对数仓建设的敏捷实践进行探索。

数据层次的阶段变化：

在不同的发展阶段，数据层次会呈现出不同的状态：

阶段一：

起步阶段，数据资产从零开始建设，各种adm应用层数据直接按需求口径从ods贴源数据表获取，数据复用不考虑层次问题，会出现各种 adm + ods 混合处理 产出新的 adm 数据，慢慢出现所谓的蜘蛛网结构

阶段二：

初步治理阶段，开始对复用数据进行治理，按需衍生出新的 dwd 中间层数据，但需求发展较快的情况下，dwd 中间层 并不能快速进行需求迭代，又开始形成 ods + dwd 混合处理 产出新的 dwd 或者 adm 数据，也就出现了模糊的层次结构

阶段三：

规范治理阶段，开始对 中间层 复用数据进行重新设计和重构，制定中间层的开发规范，这个阶段 dwd + dwd 模式可以满足大部分的数据需求，但并不能避免 dwd + ods 混合产生 dwd 或者 adm 数据，这是 数仓特性 所决定，新的数据 和 新的需求 需要在不断的处理过程中慢慢被整理和规范化使用，这种 dwd 中间层不断迭代的阶段是我们通常所处的阶段，有清晰的结构和流转层次

阶段四：

敏捷开发阶段，为了权衡 开发的规范要求 与 交付协作的时效性，开始按敏捷思路进行 dwd 中间层共建，dwd + ods 多版本共存管理，按周期性进行 dwd + ods 治理，沉淀统一口径的dwd中间层数据，这个阶段要求开发团队有较成熟的设计和管理能力，可以长时间的保持 清晰的层次结构和模块设计

敏捷模式下的数据治理：

从上文中的四个不同阶段可以看出，在实际工作中需要制定不同的数据治理策略，保证数据流转的层次可控及较高的交付效率；综合起来可以先从以下几点开始：

1、从规范上要求避免 adm 应用层互相依赖的情况，特殊情况可以使用 临时表 解决，牺牲一些计算代价

2、在初期明确 敏捷dwd中间层 共建方法，方便对多版本进行管理与后续治理

3、对涉及 口径处理 的字段或指标 上升到dwd层处理

4、周期进行 敏捷dwd多版本治理 与 ods穿透治理

5、对dwd层次进行管理和要求，混合层次不要超过三层

6、定期整理治理需求，短期敏捷迭代治理 

敏捷模式下的数据质量保障：

由于敏捷模式下，中间层会频繁迭代及多版本合并，对数据质量保障会有更高的要求，需要从人员能力及流程规范上严格要求：

1、安排专人负责中间层迭代或合并开发，必须进行全量数据对比测试及代码review

2、所有中间层资产 必须明确业务主键 并 配置dqc规则

3、下游adm替换修改由团队共建，按风险等级进行结果数据验证

总结：

数据的敏捷开发本质上为了解决业务需求时效要求与中间层建设投入在 时间和协作 上的矛盾，在常规的数据中台架构下，无法充分的发挥敏捷协作的优势，需要对中间层的建设规范与协作模式进行探索，在保障业务侧业务需求的情况下，最大程度的保持数仓层级结构上的合理性，让一线需求开发同学进行中间层多版本共建，并在规范上进行一些约束，可能会是我们后续继续探索的方向，希望可以给大家在数仓建设方面一些启发。