一、背景
在大数据时代，规范地进行数据资产管理已成为推动互联网、大数据、人工智能和实体经济深度融合的必要条件。贴近业务属性、兼顾研发各阶段要点的研发规范，可以切实提高研发效率，保障数据研发工作有条不紊地运作。而不完善的研发流程，会降低研发效率，增加成本与风险。
数据研发规范旨在为广大数据研发者、管理者提供规范化的研发流程指导方法，目的是简化、规范日常工作流程，提高工作效率，减少无效与冗余工作，赋能企业、政府更强大的数据掌控力来应对海量增长的业务数据，从而释放更多人力与财力专注于业务创新。
二、数据开发流程
鉴于对日常数据仓库研发工作的总结与归纳，将数据仓库研发流程抽象为如下几点：
需求阶段：数据产品经理应如何应对不断变化的业务需求。
设计阶段：数据产品经理、数据开发者应如何综合性能、成本、效率、质量等因素，更好地组织与存储数据。
开发阶段：数据研发者如何高效、规范地进行编码工作。
测试阶段：测试人员应如何准确地暴露代码问题与项目风险，提升产出质量。
发布阶段：如何将具备发布条件的程序平稳地发布到线上稳定产出。
运维阶段：运维人员应如何保障数据产出的时效性和稳定性。
具体开发流程
需求：与运营产品讨论需求。业务方把需求提交到JIRA，并且和产品沟通过。
技术方案讨论：最好是负责人先沟通一个初级的方案，然后找大家一起讨论（可能比直接头脑风暴效率搞，根据负责人的经验来讨论）；然后找大家一起讨论。
设计评审的原则：评审会议应该是设计方案大家基本认同的前提下，做方案的文档。
设计字段：根据需求定义字段，并确定字段指标和获取来源，建立数据字典。
开发：开分支，写代码。做好测试case的建立，然后自测。
代码review：叫上测试和一个其他开发同学，给出review的结果。目的是让其他同学帮忙review其中的逻辑。
上线：提前告知运维，提前申请机器资源，根据业务预估好CPU、存储、带宽等资源。
文档：开发完成后，文档记录一下流程以及提供数据表字段说明，方便重构。
数据需求流程
各个角色职责
这个流程针对的是项目是开发，在项目立项的开始，就需要明确各个角色的职责，而且需要和多个角色进行配合。作为数据开发人员，需要协调和各个角色之间的交互：
需要和产品评估该需求的合理性，现有技术栈能否支持该需求，例如：公司想要做个实时数据大盘，如果没有实时数仓的架构，是没法完成这块需求。一旦确定开发，需要协调资源，包含开发资源、设备资源等等。
需要和业务方、产品方评估数据可行性，数据开发的数据源并不是凭空出现的，需要和业务方明确已有数据能否支撑需求开发，如果缺少数据，则需要另行规划缺失数据的抽取方案。
需要自己评估技术可行性，数据开发可能涉及到数据传输、数据同步、ETL、实时开发、离线开发等等，要评估从数据源获取到数据展现一套流程的可行性，例如：数据源如果为多个地方产出，可能需要从binlong获取、Kafka读取、业务库同步、HDFS读取等等，数据输出也可能到各个地方，例如：mysql、hive、ES、Kafka、redis等等多个存储，需要在开发之前确定整套数据的流程。
需要确定是否满足安全与合规要求，对于一些敏感数据如何处理，是一个很重要的组成部分，作为数据开发人员，可能接触的数据比较多，但是哪些数据可以展现、哪些数据脱敏后可以展现、哪些数据不能落地等等，而且在数据流转过程中，也要关注数据的安全性，能否落地、能否转存等等。
需要和测试同学同步数据处理逻辑，并将一些逻辑的SQL进行文档化，方便测试同学进行单元测试，在交付测试之前，需要对代码进行自测，以便保障流入到测试执行环节的代码达到一定的质量标准。同时最好能让代码通过配置在不同环境进行切换，方便测试同学在测试环境、预发环境进行测试，测试通过后同一套代码能够直接上线。
一、上线前
需求沟通，需求评审会。数据分析师、产品经理、数据产品经理，参与会议。判断是否需要客户端or服务端埋点，判断是否需要埋点同学参与。如果是数据API，如服务接口、线上人群包等还需要server同学参与会议。会议主要三个方面：业务背景与收益、数据模型与拉齐口径、排期及可能隐患与风险点。
数据探查、数据调研。数据源，主要是要熟悉客户端埋点全链路、服务端埋点探查追踪、db数据的binlog的生成解析与集成。尤其是接到一个需求或主题域模型设计之前，如何数据探查（数据调研、数据摸底），可以从以下几点展开：
1.量级。如果是埋点数据，这个可直接推测是否重复上报或少上报，如果是db数据，这个可有效评估数据集成是增全量的抽取策略（建议db数据统一走binlog）。
2.schema。字段含义、业务描述，枚举值解释，空置率、单位等。特别注意一点，json、struct等复杂数据类型的结构、key等。
3.主键。db数据主键一般没有问题，服务端埋点上报的数据需要格外注意。
4.一致性。如供给侧与消费侧的一致、B端与C端的一致。
以上都建议配置到数据治理DQC里，每天自动化监控，充分保障数据质量与及时发现问题止损、降低数据故障风险。
公共模型设计与开发。dwd dws dim 通用数据模型，是否可复用已有模型，是否收口模型。需求导向丰富已有模型，尤其是一些大公司。如果是一块新业务，可能还需要梳理业务流程图、CDM、领域模型。梳理维度指标矩阵、模型血缘依赖。同时考虑设计几个模型，维度如何具象，粒度如何变化，是否高内聚低耦合，及复用性等。
特别的，公共模型禁止耦合线上业务逻辑。
应用层数据开发。相对简单，但不可大意。需要考虑透出形式、量级、粒度、幂等、是否需要cube等。
模型评审。补充这一点，开发前一定要模型评审。既能及时发现规避模型设计中自己没注意到的问题，又能让其它同事快速了解相关模型与业务。公司越大越要评审，哪怕AB角。
小插曲，工作中经常会遇到与同事、leader建模理念与思想不合，也可能是业务角度和出发点不同，这在工作中很常见也很正常。如果工作中遇到了，不必有心理负担，几种处理方式可以参考：
平心。晓之以情，动之以理。
上卷。德不配位，取而代之。
中空。心有乾坤，敷衍于事。
下沉。决不惯着，跳槽离职。
当然圈子真的很小，说不定哪一天又是同事了，最好还是要冷静处理，争取最佳方式。
规范核查。再次检查模型设计、字段命名、表命名、性能、生命周期等是否符合规范。
三、日常数据支撑
除了项目式的开发外，数据开发人员大部分情况下都会面对产品提出来的一些临时性的数据需求，例如拉去一下近半年的销售情况、用户访问情况等等，这部分数据支撑不需要后端配合、可能也不需要进行测试，而是在已明确的数据指标的基础上，定期或者不定期的提供一个数据报表。这部分的数据开发模式相对来说比较简单和快速，但是也需要明确：
指标需求中通常会涉及到下表中的约定项，如果需要自定义约定项，可以在自定义格式列进行填写。
四、注意
对于一些重要指标的定义，就算文档中写了，也要和产品进行确定，例如产品需要近半年的所有销量，那么要明确这个销量是否包含退款、是按照成交时间还是付款时间来计算等等。避免数据指标不匹配，导致二次开发。
开发过程中，文档要规范，先设计在开发，而且在做系统建设的时候，要有全局视野，不局限某一个点，并不是发布完成了，就算结束，代码开发完成只是第一步，后续的文档建设、代码复盘、数据监控、数据告警、稳定性等等，都需要在开始规划好。
及时反馈，在开发过程，不论进行到哪个阶段，项目期间每天都需要和前后端同步一下进度，避免延期的风险。
故障处理，在程序上下后，可能会因为客观或者代码的原因出现一些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.系统文本错误，系统样式错误，系统交互友好性等不影响用户正常使用的功能。（包含全局性质）
解决时间：下个版本上线时。
反馈方式：下个版本的需求计划中体现。
P0\P1级别问题在规定时间内无法解决的，需要该问题的研发同学在问题comments内说明无法在规定时间内解决的合理的解释，并告知该问题具体的解决时间点同时邮件说明。
CIO之家 www.ciozj.com 公众号:imciow