在大数据时代，规范地进行数据资产管理已成为推动互联网、大数据、人工智能和实体经济深度融合的必要条件。贴近业务属性、兼顾研发各阶段要点的研发规范，可以切实提高研发效率，保障数据研发工作有条不紊地运作。而不完善的研发流程，会降低研发效率，增加成本与风险。

总而言之，数据资产管理实际上是对物的管理，而研发流程规范管理则是对人的行为的管理。只有落实了作为基础的后者，才能进一步实行数据资产管理方法论。

数据仓库研发规范旨在为广大数据研发者、管理者提供规范化的研发流程指导方法，目的是简化、规范日常工作流程，提高工作效率，减少无效与冗余工作，赋能企业、政府更强大的数据掌控力来应对海量增长的业务数据，从而释放更多人力与财力专注于业务创新。

阶段规划

鉴于对日常数据仓库研发工作的总结与归纳，本文将数据仓库研发流程抽象为如下几点：                    

1. 需求阶段：数据产品经理应如何应对不断变化的业务需求

2. 设计阶段：数据产品经理、数据开发者应如何综合性能、成本、效率、质量等因素，更好地组织与存储数据

3. 开发阶段：数据研发者如何高效、规范地进行编码工作

4. 测试阶段：测试人员应如何准确地暴露代码问题与项目风险，提升产出质量

5. 发布阶段：如何将具备发布条件的程序平稳地发布到线上稳定产出

6. 运维阶段：运维人员应如何保障数据产出的时效性和稳定性

角色职责

• 数据产品经理：负责承接、评估业务方提出的数据需求，并组织需求评审、产出产品需求文档，同时需要把控其它更为细化的技术评审

• 设计人员：根据已定稿的产品需求文档所述需求，进行数据探查，了解数据形态（数据质量、数据分布），同时根据探查结果实现表设计、Mapping设计、调度设计等系分设计工作

• 开发人员：根据设计人员产出的稿件，制定计划并实现代码，同时进行单元测试与代码评审

• 测试人员：负责验证需求与结果的一致性，发现代码问题与项目风险

• 运维人员：负责发布任务，并处理数据、程序、调度、监控告警等异常事件，保障数据产出时效、程序高效运行和生产稳定性

• 信息安全与合规人员：在需求评审前期，负责需求实现的安全性与合规性

数据仓库研发规范整体流程

下图为根据阶段规划与角色职责的内容，整理出的数据仓库研发规范的整体流程。

需求阶段

数仓的最基本职责是定义和发现在企业决策中使用的信息，随着企业战略方向的改变与业务方对行业判断的变化，需求会不断变化。该特性决定了数据仓库需求的多样性和迭代性。

完成需求阶段的工作后，数据产品经理会产出最终版本的产品需求文档，以供设计人员进行设计工作。

设计工作包含数据探查和系分设计两部分：

• 数据探查旨在了解来源数据的数据形态，例如数据质量、数据分布等。结合业务场景，帮助分析和判断需求实现的可行性以及找出潜在的数据问题和风险。

• 系分设计则包括表设计、Mapping设计和调度设计等最实际的设计工作。

设计完毕后，最终将产出供开发人员参照实施开发的ETL设计文档、数据探查文档、调度设计文档，为需求的有效实现打下坚实基础。

设计阶段的流程包括以下步骤：                  

1. 数据探查                        

数据探查的目的是了解数据的形态，找到潜在问题与风险。数据探查是决定数据可靠性的关键步骤。数据探查报告可以为后续开发提供指导，并作为依据指定开发计划。              

数据探查的内容主要包括但不限于以下内容：

• 源表数据主键字段重复数

• 源表字段空值/异常值的统计数

• 源表之间关联关系

• 源表字段的数据格式

• 源表增量规则

探查完成后，最终产出数据探查报告。如果发现当前数据无法支撑需求的实现，则要将需求退回给数据产品经理，由数据产品经理发起迭代需求流程。   

2. 系分设计                        

系分设计包括表设计、Mapping设计和调度设计三部分。

表设计是指依据需求设计目标产出表、中间产出表。包含表名、表名解释、字段名、字段类型、字段注释以及字段安全等级等。表设计的步骤如下所示：

• 设计表名、字段名：要求相同的字段在不同表中的字段名相同，相关规范请参见命名规范

• 设计主键和外键

• 设计字段注释：通过标注字段注释、枚举值来表明字段含义，如果枚举值过多，建议为枚举值创建维表

• 设计表分区：建议所有表都创建为分区表

• 设计数据生命周期

企业应根据自身实际情况来进行设置，也可以参考如下数值：

Mapping设计采用图形化或伪代码的形式编写规划以下内容：

• 每个字段的生成逻辑

• 表与表之间的关系

• 目标字段与原字段间的算法逻辑

将上述内容产出为ETL文档留存，ETL将作为后续开发流程的第一参考依据。
调度设计

1. 依赖设计                              

   将ETL抽象为多个相互依赖的代码节点形成上下游依赖关系，要求如下：              

• 一个节点仅产出一张表，一张表仅由一个节点产出

• 下游节点的输入数据来自于上游节点的产出数据

• 多并行、少串行（在分布式系统下可发挥其优势）

2. 运行周期                              

   如果数据研发的场景是在常见T+1离线计算场景，则应将不同调度任务按照实际业务需求，赋予小时、日、周、月和季度等不同的调度粒度。

   说明   

• 程序必须支持重跑。

• 如果SQL语句优化后，单次执行仍超过30分钟，建议拆表重新设计，建议每个节点运行时长不超过1小时。

3. 设置基线：在传统T+1（每日计算的是前一日产生的业务数据）的场景下，数据理应在第二天某个时间点按时产出以支撑BI或其他应用场景，因此应设置如下基线报警策略。详情请参见基线管理。                              

• 最终产出任务基线：规定产出最终数据的任务必须在公司规定的X点X分完成，否则视为破线（同时推送相应报警）。

• 中间任务报警：产出最终数据的任务的上游任务应稳定、按时运行完成。如果出现出错、变慢（运行时间明显长于历史过往平均运行时间）等可能影响最终任务完成时间的事件，则应第一时间推送报警给第一任务责任人。

4. 设置优先级：基于有限的计算资源来设置任务优先级，以保证在已有资源被充分调配利用的情况下，可以按照顺序产出数据，保证重要任务的准时产出。调度设计完成后，需要产出调度设计文档。

5. 数据流设计                              

   ETL过程中，数据流向有如下限制：                                  

• 数据流向仅支持由低到高，即ODS->DWD->DWS->ADS。

• 数据不能且不能跨层引用、逆向引用。

• DWS层不同集市的数据不能相互引用，必须沉淀到DWD层。

开发阶段

您在完成需求评审、模型与调度设计后，即可进入数据开发阶段。

开发阶段的主要任务是将设计阶段的产出转化为具体代码。开发过程中，开发人员必须保证代码的规范性、准确性。同时进行适当的单元测试，以便后续测试工作可以顺利开展。

开发阶段的流程包括以下步骤：

• 代码开发

• 单元测试

• 代码评审（Code Review）                

测试阶段

开发阶段已经完成了代码的实现，为了发现代码问题、暴露项目风险、提升产出质量，需要进入测试阶段，通过测试用例对代码进行分析，为最终发布提供决策的依据。

测试阶段的流程包括以下步骤：                                   

1. 测试分析 

2. 准备测试用例

3. 执行测试

4. UAT测试：交付测试、数据测试完成后，数据产品经理需要站在在业务角度，对产出数据进行验收测试，最终提供验收测试报告

发布阶段

发布是将具备发布条件的程序发布到线上系统，并以生产标准进行数据产出的过程。

发布分为正常发布和紧急发布：                  

• 正常发布：发布节奏在原则上是可预见性、周期性的，发布计划可提前制定和公布。正常列入排期计划的需求，都必须按照正常的节奏安排发布计划

• 紧急发布：紧急发布是为应对突发性、紧急性状况而额外开启的可选发布，如线上BUG紧急修复、突发性需求等              

  在接到紧急发布需求后，第一时间应评估是否可以随最近一次正常发布窗口期发布。如果不可以，则根据企业实际情况发起紧急发布申请

发布阶段的流程主要包括发布申请、发布审批和发布执行。

运维阶段

开发人员根据需求将代码发布上线后，还需要及时处理数据、程序、调度、监控告警等的异常事件，保障数据产出时效、程序高效运行和生产稳定性。

数据开发人员主要需要处理以下事项：                    

• 程序异常处理、性能优化。

• 调度异常处理。

• 数据质量监控规则异常分析、规则优化。

• 数据异常的核查。

运维阶段的流程包括分析影响、制定与实施方案和验证实施方案。

操作步骤：

1. 分析影响

2. 制定与实施方案

3. 验证实施方案