傅一平评语：
三流水平的去码代码，二流水平的去做架构，一流水平的人去写规范，建章立制的人总是牛逼的。
很久没看到这么有逻辑而清晰的数仓文章了，如果你知晓数仓却没做过梳理，读这篇文章可以让你把知识点串起来，有助于巩固自己的知识体系；如果你是个新手，那么按图索骥就是第一步要做的事情数据库表命名规范，这样可以确保你做数仓有一个较高的起点，在做的过程中你会体会到规范的力量。本文的主要内容包括七个部分：
1、为什么要有规范？
2、规范该怎么落地？
3、数仓规范有哪些？
4、设计规范
5、流程规范
6、质量管控规范
推荐读一读。
正文开始
这是数据仓库系列的第三个话题，排序在架构之后、建模之前。为什么会提的这么靠前呢？
因为规范约束的是数仓建设的全流程，以及后续的迭代和运维。事实上，数仓规范文档，应该随着架构设计文档，在数仓开发启动之前，分发给所有相关人员，且是所有人都必须严格遵守的约定。
有人会问，没有规范直接开干，行吗？当然可以，在一些临时的短期项目，为了快速出活尽快看到效果，没有必要强制执行规范而影响了效率。但从个人专业素养的角度看，即使项目没有规范，该有的约定俗成的好习惯还是得有的，比如缩进、换行、空行、注释......
网上搜索，大家可以搜到很多相关文章，但碎片化严重。本文争取说透数仓规范，让大家不仅能了解到数仓规范的目的、内容、边界，更会给大家介绍相关规范如何在企业落地。
欢迎大家参考此文，结合自己公司的实际情况，构建、完善自己的数仓规范体系。然后大家多多交流，共同进步。
01
—
为什么要有规范？
俗话说的好，无规矩不成方圆，没有规范岂不乱套了? 个人觉得，规范是为了解决团体作战中的效率和协同问题，是对最终交付质量的有力保证。
大家工作中有没有遇到类似的问题？
由于以上种种问题，造成数仓团队的整体开发效率、产出质量、工作幸福感、数仓维护成本等等越来越差。随着人员流动，通常受累的往往是那些任劳任怨、对公司忠诚的员工。
相信做过数据开发的人，多多少少都会有过上边提到的部分苦恼。我觉得问题的根源通常在于没有规范或者规范没有得到贯彻。
大家有时候为了按时完成业务侧的需求，走些捷径也是可以理解的，但是欠下的技术债应该尽早还上，并且组织不应该苛责员工，这个锅应该领导来背。领导重视大家就都重视，领导不重视，岂不各个放飞自我了？
数据仓库，是我们数据工程师的无形产品。数据规范是数仓体系建设的"语言"，是数据使用的说明书和翻译官，同时也是数据质量的保驾护航者。为了数据体系能够长久健康的发展，数仓管理，应该从人治逐步转变到制度化、规范化、工具化的道路上了来。
02
—
规范该怎么落地？
规范制定
从 0 到 1，从无到有，这个环节应该有 或架构师，充分考虑公司实际情况，参考行业标准或约定俗成的规范，综合统一制定。
也可以将规范拆分后交由各个部分核心开发人员编写， 或架构师统一整合。比如我们之前的团队就是，模型设计师负责模型设计规范，ETL 工程师负责 ETL 开发规范，BI 开发人员制定前端开发规范，部署上线规范直接采用项目上已有的即可。
总体上，初稿应该尽量保证规范的完整性和各个部分间的兼容性。
规范讨论
初稿完成后，难免有考虑不周的情况，这时候最好有 牵头，组织部分核心成员（人数不易太多，三五个即可。人多容易造成混乱、决策困难、没有人提意见造成 一言堂等等问题。）进一步完善各个细节，纠正初稿的不足。
多人共同完善的规范，理论上来讲不会有什么大问题了。
规范推行
定稿后，规范已经具备了全面推广的条件，可以下发所有团队成员。
可以通过群聊天，也可以通过正式回邮件的方式，当然为了引起大家的重视，可以专门组会宣讲。
分发宣讲后进入执行阶段，所有人必须严格遵守，如有违犯给予警告，严重的给予惩罚，屡劝不改的取消年终调级调薪等。
为了确保规范的贯彻落实，除了通过以上两点引起全员重视外，还需要组织、制度、流程上的多方面保障。
讲到这里，大家有没有看出来一个问题？
规范的执行监督，上边提到的，更多是依靠制度流程以及相关人的自觉性，制度流程又依赖于人。这会带来如下几个问题：
有条件的最好引入相应的工具加强监管。
比如，我们有指标体系元数据、有词根库元数据、有建表的元数据、有 ETL 流程的元数据等等。
那我们是否可以开发部分报表或其它页面，通过 UI 辅助人去检查，或者通过校验元数据的方法去监管（比如备注是否为空、字段或表命名里的词根是否都在词根库里存在、表或页面等用到的指标是否都存在于指标体系、数据血缘中是否存在闭环或者孤立的节点）。
哈哈，讲了这么多，了解过数据治理的读者，会不会感觉很熟悉？数仓建设的一开始就需要考虑这些的，最好的管理在于治未病。
规范完善
发行稿，从大面上应该不会有啥问题，但细节上可能会有考虑不周的情况，在宣讲阶段、执行阶段遇到问题阻碍的时候，应该根据实际情况对规范做出调整，唯有经过实践检验才能愈发完善，相信经过一段时间的持续实践，规范会成为组织文化的一部分，进而降低沟通成本、提高开发效率、保证交付质量，从而实现团队和个人的双赢。
如果能完全按照上篇中的流程落地，就能够保障数仓建设、迭代的整体质量。
在实际操作中往往会事不由人，但是基于规范的重要性，有些事情我们还是必须要要去做的。
在上面的内容中有说过如今网络上流传的数仓规范，碎片化严重。
下面，我会根据过往实践经验，结合网络文章，尽量给大家提供一套完整的规范范本数据库表命名规范，供大家学习参考。
01
—
数仓规范有哪些？
为了让大家了解到数仓规范全貌，特意花大力气整理出以上分类。欢迎大家推广普及运用。由于只是一家之言，大家如有不同的见解、更好的方案或者有可以再补充的，欢迎拉到文章底部，加我微信，大家共同研究。
这里，我把数仓规范，一共分为四大类：设计规范、流程规范、质量管理规范、安全规范。
02
—
设计规范
数据模型设计
横向分层
纵向分域
基本原则
附加字段
其它要求
命名规范
统一规范
专有规范
代码设计规范
指标体系建设
词根库
03
—
流程规范
需求提交流程
模型设计流程
ETL开发流程
（这个在后续章节-ETL篇-会详细介绍）
前端开发规范
（这个在后续章节-应用篇-会详细介绍）
上线流程
04
—
质量管控规范
源端管控
数仓管理
应用管控
05
—
安全规范
网络安全
账号安全
数据安全
06
—
总结
我们分别从设计规范、流程规范、质量管控、数据安全四个方面，详细阐述了数仓规范。应该已经涵盖了数仓规范的方方面面。如有遗漏或者更好的分类方法，欢迎加我微信详聊。
本篇写作的初衷，就是找到一种合理的分类方式，把数据规范详尽穷举的罗列给大家，让大家了解全貌。但是，在实际落地实践中不一定能用到这么多，没有最好的只有最合适的，大家需要结合现实场景选取需要的子集落地即可。
在我经历过的几家公司、好多个项目里，也没有哪个项目完整的使用过以上所有规范，互联网大数据公司比之前的传统数仓项目用到的规范还更少些而且侧重点也不太一样。大数据公司可能由于互联网基因吧，更加侧重数据安全、工具化等，对数据质量、数据模型等要求不太高。而传统数仓对数据建模、数据质量的要求很高（我有一位同事，曾因为一块钱，被甲方财务主管扣下，对了一整天的数据~），内网环境数据安全被提的不是很多，另外可能是由于做项目的原因吧，工具化不太被人关注，管理基本靠人治，元数据基本靠文档。