规范约束的是数仓建设的全流程，以及后续的迭代和运维。事实上，数仓规范文档，应该随着架构设计文档，在数仓开发启动之前，分发给所有相关人员，且是所有人都必须严格遵守的约定。

俗话说的好，无规矩不成方圆，没有规范岂不乱套了? 个人觉得，规范是为了解决团体作战中的效率和协同问题，是对最终交付质量的有力保证。
大家工作中有没有遇到类似的问题？

• 接到了一个需求，不知道该从那张表出数，表A貌似可以，表B好像也行。问了同事甲，他说他每次都是从C表出的。对着三张表探索了好久，发现谁跟谁都对不上，算了吧，我从源头再算一次吧，结果又变出来一张表D。
• 数据库里几千张表，好像我用到的也就那么十几张，其它的都是干啥用的呢，问了一圈没有人知道，删掉吧？更没有人敢动。
• 有个流程报错了，领导让我去看一下，点进去后，屎一样的代码完全看不懂，另外，找了好久死活找不到上游依赖。
• 有位同事要离职，他负责的那部分内容，换了一个人接手，累死累活好多天依然捋不出个所以然，一气之下又走了一个人。

由于以上种种问题，造成数仓团队的整体开发效率、产出质量、工作幸福感、数仓维护成本等等越来越差。随着人员流动，通常受累的往往是那些任劳任怨、对公司忠诚的员工。
相信做过数据开发的人，多多少少都会有过上边提到的部分苦恼。我觉得问题的根源通常在于没有规范或者规范没有得到贯彻。大家有时候为了按时完成业务侧的需求，走些捷径也是可以理解的，但是欠下的技术债应该尽早还上，并且组织不应该苛责员工，这个锅应该领导来背。领导重视大家就都重视，领导不重视，岂不各个放飞自我了？
数据仓库，是我们数据工程师的无形产品。数据规范是数仓体系建设的"语言"，是数据使用的说明书和翻译官，同时也是数据质量的保驾护航者。为了数据体系能够长久健康的发展，数仓管理，应该从人治逐步转变到制度化、规范化、工具化的道路上了来。

从 0 到 1，从无到有，这个环节应该有 Leader 或架构师，充分考虑公司实际情况，参考行业标准或约定俗成的规范，综合统一制定。
也可以将规范拆分后交由各个部分核心开发人员编写， Leader 或架构师统一整合。比如我们之前的团队就是，模型设计师负责模型设计规范，ETL 工程师负责 ETL 开发规范，BI 开发人员制定前端开发规范，部署上线规范直接采用项目上已有的即可。
总体上，初稿应该尽量保证规范的完整性和各个部分间的兼容性。

初稿完成后，难免有考虑不周的情况，这时候最好有 Leader  牵头，组织部分核心成员（人数不易太多，三五个即可。人多容易造成混乱、决策困难、没有人提意见造成 Leader 一言堂等等问题。）进一步完善各个细节，纠正初稿的不足。
多人共同完善的规范，理论上来讲不会有什么大问题了。

定稿后，规范已经具备了全面推广的条件，可以下发所有团队成员。

• 可以通过群聊天，也可以通过正式回邮件的方式，当然为了引起大家的重视，可以专门组会宣讲。
• 分发宣讲后进入执行阶段，所有人必须严格遵守，如有违犯给予警告，严重的给予惩罚，屡劝不改的取消年终调级调薪等。

为了确保规范的贯彻落实，除了通过以上两点引起全员重视外，还需要组织、制度、流程上的多方面保障。

• 数据模型应该有统一归口，比如数据架构师，架构师定期检查模型是否合理合规。
• 组织数据开发人员，定期 Review 每个人的代码，但不必针对个人更不要上纲上线，目的是通过对比和讨论让大家明白什么样的才是好代码，最终使“写好代码”成为基本素养。没有条件的话就有 Leader 负责定期检查，有问题的私下指出来帮助组员逐渐规范。
• 入职新人，熟读规范后，还应该安排专人指导，是合规性检查的重点关注对象。

规范的执行监督，上边提到的，更多是依靠制度流程以及相关人的自觉性，制度流程又依赖于人。这会带来如下几个问题：
短期坚持还好，但长期的专注很难。
有时候人忙起来了，快速产出和规范该选哪个？代码 Review 还要不要做？新建的表要不要找数据架构师审核？
数据建模最好是有专门的人或者小团队去做，其他人使用，这往往会影响整体效率，所以通常都是谁用谁建，但撒出去后再想靠人去检查合规性，真的就太难了。
有条件的最好引入相应的工具加强监管。
比如，我们有指标体系元数据、有词根库元数据、有建表的元数据、有 ETL 流程的元数据等等。
那我们是否可以开发部分报表或其它页面，通过 UI 辅助人去检查，或者通过校验元数据的方法去监管（比如备注是否为空、字段或表命名里的词根是否都在词根库里存在、表或页面等用到的指标是否都存在于指标体系、数据血缘中是否存在闭环或者孤立的节点）。

发行稿，从大面上应该不会有啥问题，但细节上可能会有考虑不周的情况，在宣讲阶段、执行阶段遇到问题阻碍的时候，应该根据实际情况对规范做出调整，唯有经过实践检验才能愈发完善，相信经过一段时间的持续实践，规范会成为组织文化的一部分，进而降低沟通成本、提高开发效率、保证交付质量，从而实现团队和个人的双赢。

为了让大家了解到数仓规范全貌，特意花大力气整理出以上分类。欢迎大家推广普及运用。由于只是一家之言，大家如有不同的见解、更好的方案或者有可以再补充的，欢迎关注我们一起进步。
这里，我把数仓规范，一共分为四大类：设计规范、流程规范、质量管理规范、安全规范。
设计规范，又划分为四部分：数据模型设计、命名规范、指标体系设计、词根库。
流程规范，主要是从数仓管理的角度，对数仓场景下的各种流程进行约束。核心流程一共提炼出来五类：需求提交、模型设计、ETL开发、前端开发、上线流程。
质量管控规范，之所以单独列出来，是因为数据质量，跟模型设计一样，对数仓建设的成败关系极大。试想下，一个数据质量都无法保证的数据仓库，有谁会用?  数据质量规范，主要是从数据流动的角度分为三类：源端管控、数仓管理、应用管控。
安全规范，随着国家、社会、企业对数据的越来越重视，另一方面随着互联网的普及使得个人隐私变的越来越难以保证，数据泄露时有发生。数据安全对于数据仓库的重要程度急速提升，所以安全规范被单列了出来。从大的层面上安全规范分为三类：网络安全、账号安全、数据安全。

横向分层

• 说明
• 分层设计是数据架构设计的产出之一，在模型设计环节做为强制规范遵守。
• 分层规范
• 应用层，面向最终应用。
• 主题域划分，依据是最终应用。生命周期也与应用同步。
• 汇总数据层+主题宽表。
• 数据域划分，依据参考下边的纵向分域。
• 对数据源做清洗、转换、补全、编码转换后加载到明细数据层。
• 数据域划分，依据参考下边的纵向分域。
• 贴源层，原始数据不做变化或者仅做最简单的补全后存入。
• 数据域划分，依据是数据源。
• ODS
• DWD
• DWS
• ADS
• 层次调用规范
• 禁止反向调用
• ODS 只能被 DWD 调用。
• DWD 可以被 DWS 和 ADS 调用。
• DWS 只能被 ADS 调用。
• 数据应用可以调用 DWD、DWS、ADS，但建议优先考虑使用汇总度高的数据。
• ODS->DWD->DWS>ADS
• ODS->DWD->ADS
  
纵向分域

• 定义
• 主题域通常是联系较为紧密的数据主题的集合，方便寻找和使用数据。
• 基本原则
• 高内聚、低耦合。
• 数量不能太多。建议不超过十个。
• 必须保持稳定。既能涵盖当 前所有的业务需求，又能在新业务进入时无影响地被包含进已有的数据域中或扩展新的数据域。
• 需要结合团队和业务的实际情况，比如业务是否稳定、团队成员建模水平等。
• 适度的抽象。太低不好适应变化，太高不易于理解使用。
• 分类
• 面向分析场景，实现较难，对业务理解、抽象能力等要求高。
• 依据业务流程划分，实现相对容易。
• 数据/业务主题域
• 分析主体域
• 划分依据
• 按照业务或业务过程划分：比如一个靠销售广告位置的门户网站主题域可能会有广告域，客户域等，而广告域可能就会有广告的库存，销售分析、内部投放分析等主题。
• 根据需求方划分：比如需求方为财务部，就可以设定对应的财务主题域，而财务主题域里面可能就会有员工工资分析，投资回报比分析等主题。
• 按照功能或应用划分：比如微信中的朋友圈数据域、群聊数据域等，而朋友圈数据域可能就会有用户动态信息主题、广告主题等。
• 按照部门划分：比如可能会有运营域、技术域等，运营域中可能会有工资支出分析、活动宣传效果分析等主题。基本原则
• 高内聚和低耦合
• 核心模型与扩展模型分离
• 公共处理逻辑下沉及单一
• 成本与性能平衡
• 数据可回滚
• 一致性
• 命名清晰、可理解
  附加字段
• 维表：创建时间、更新时间
• 事实表：ETL 日期、更新时间
  其它要求
• 表、字段的备注信息，必须言简意赅，在描述清楚的前提下尽量简洁。
• 字段类型的约束：比如字符串用 String，数值用 Int，年月日都用 String 比如 yyyyMMdd 等。

*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。