数据开发流程规范_数据开发规范

一、背景

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

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

二、数据开发流程

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

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

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

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

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

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

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

具体开发流程

1. 需求：与运营产品讨论需求。业务方把需求提交到JIRA，并且和产品沟通过。

2. PRD评审：产品评审PRD文档。

3. 技术方案讨论：最好是负责人先沟通一个初级的方案，然后找大家一起讨论（可能比直接头脑风暴效率高，根据负责人的经验来讨论）；然后找大家一起讨论。

4. 技术设计评审：设计评审叫上测试。

5. 设计评审的原则：评审会议应该是设计方案大家基本认同的前提下，做方案的文档。

6. 设计接口：重点准确描述输入和输出。

7. 设计字段：根据需求定义字段，并确定字段指标和获取来源，建立数据字典。

8. 开发：开分支，写代码。做好测试case的建立，然后自测。

9. 代码review：叫上测试和一个其他开发同学，给出review的结果。目的是让其他同学帮忙review其中的逻辑。

10. 提测：给出提测报告，包括罗列测试点。

11. 上线：提前告知运维，提前申请机器资源，根据业务预估好CPU、存储、带宽等资源。

12. 文档：开发完成后，文档记录一下流程以及提供数据表字段说明，方便重构。

数据需求流程

各个角色职责

这个流程针对的是项目开发，在项目立项的开始，就需要明确各个角色的职责，而且需要和多个角色进行配合。作为数据开发人员，需要协调和各个角色之间的交互：

• 需要和产品评估该需求的合理性，现有技术栈能否支持该需求，例如：公司想要做个实时数据大盘，如果没有实时数仓的架构，是没法完成这块需求。一旦确定开发，需要协调资源，包含开发资源、设备资源等等。

• 需要和业务方、产品方评估数据可行性，数据开发的数据源并不是凭空出现的，需要和业务方明确已有数据能否支撑需求开发，如果缺少数据，则需要另行规划缺失数据的抽取方案。

• 需要自己评估技术可行性，数据开发可能涉及到数据传输、数据同步、ETL、实时开发、离线开发等等，要评估从数据源获取到数据展现一套流程的可行性，例如：数据源如果为多个地方产出，可能需要从binlong获取、Kafka读取、业务库同步、HDFS读取等等，数据输出也可能到各个地方，例如：mysql、hive、ES、Kafka、redis等等多个存储，需要在开发之前确定整套数据的流程。

• 需要确定是否满足安全与合规要求，对于一些敏感数据如何处理，是一个很重要的组成部分，作为数据开发人员，可能接触的数据比较多，但是哪些数据可以展现、哪些数据脱敏后可以展现、哪些数据不能落地等等，而且在数据流转过程中，也要关注数据的安全性，能否落地、能否转存等等。

• 需要和测试同学同步数据处理逻辑，并将一些逻辑的SQL进行文档化，方便测试同学进行单元测试，在交付测试之前，需要对代码进行自测，以便保障流入到测试执行环节的代码达到一定的质量标准。同时最好能让代码通过配置在不同环境进行切换，方便测试同学在测试环境、预发环境进行测试，测试通过后同一套代码能够直接上线。

三、日常数据支撑

除了项目式的开发外，数据开发人员大部分情况下都会面对产品提出来的一些临时性的数据需求，例如拉取一下近半年的销售情况、用户访问情况等等，这部分数据支撑不需要后端配合、可能也不需要进行测试，而是在已明确的数据指标的基础上，定期或者不定期的提供一个数据报表。这部分的数据开发模式相对来说比较简单和快速，但是也需要明确：

• 明确数据需求模板、常规需求申请单等等，提供需求单的目的是避免长时间的沟通，特别是已经有的数据指标，只需要让产品提供一份详细的数据需求单，按照需求单的模版进行提供数据即可。模版如下：

指标需求中通常会涉及到下表中的约定项，如果需要自定义约定项，可以在自定义格式列进行填写。

• 明确需求的指标含义，和所需求的字段明细、统计周期、开发周期等。

四、注意

• 需求评审完成后，如果发生需求变更或者迭代，一定需要提供迭代/变更的需求申请单，或者提供JIRA，避免需求不可追溯。

• 对于一些重要指标的定义，就算文档中写了，也要和产品进行确定，例如产品需要近半年的所有销量，那么要明确这个销量是否包含退款、是按照成交时间还是付款时间来计算等等。避免数据指标不匹配，导致二次开发。

• 开发过程中，文档要规范，先设计再开发，而且在做系统建设的时候，要有全局视野，不局限某一个点，并不是发布完成了，就算结束，代码开发完成只是第一步，后续的文档建设、代码复盘、数据监控、数据告警、稳定性等等，都需要在开始规划好。

• 及时反馈，在开发过程，不论进行到哪个阶段，项目期间每天都需要和前后端同步一下进度，避免延期的风险。

• 故障处理，在程序上下后，可能会因为客观或者代码的原因出现一些BUG，不同的故障处理方案不同，但是注意复盘和故障记录，避免下次出现相同的BUG。

故障等级定义：

P0 ：
1.全局问题，影响所有用户，例如系统必现崩溃，主要功能不可用，严重影响用户正常交易。
2.涉及到用户资金损失的问题。
解决时间：2小时内。
反馈时间：0.5小时。
反馈方式：comments自动邮件方式+即时通信：例如QQ\微信\钉钉\电话

P1：
1.全局问题，影响所有用户，例如系统次要功能不可用，系统偶现崩溃且崩溃率超过50%。
2.局部问题，影响超过20%的用户，例如系统主要功能不可用，系统必现崩溃。解决时间：待定不过夜。
反馈时间：1小时。
反馈方式：comments自动邮件方式+即时通信：例如QQ\微信\钉钉\电话

P2：
1.局部问题，影响用户10%-20%，例如系统次要功能不可用，或者系统某一个逻辑不可用，系统崩溃率20-50%。
解决时间：待定48小时。
反馈方式：comments自动邮件方式。

P3：
1.局部问题，影响用户10%以下，例如系统次要功能不可用，系统部分逻辑不正常，仅在某一单一机型或单一用户出现的问题。
解决时间：待定下个版本发布。
反馈方式：下个版本的需求计划中体现。

P4：
1.系统文本错误，系统样式错误，系统交互友好性等不影响用户正常使用的功能。（包含全局性质）
解决时间：下个版本上线时。
反馈方式：下个版本的需求计划中体现