规范约束是数仓建设的全流程，以及后续的迭代和运维的参照。事实上，数仓规范文档，应该随着架构设计文档，在数仓开发启动之前，分发给所有相关人员，且是所有人都必须严格遵守的约定。
有人会问，没有规范直接开干，行吗？当然可以，在一些临时的短期项目，为了快速出活尽快看到效果，没有必要强制执行规范而影响了效率。但从 个人专业素养 的角度看，即使项目没有规范，该有的约定俗成的好习惯还是得有的，比如缩进、换行、空行、注释......
网上搜索，大家可以搜到很多相关文章，但碎片化严重。本文争取说透数仓规范，让大家不仅能了解到数仓规范的目的、内容、边界，更会给大家介绍相关规范如何在企业落地。
欢迎大家结合自己公司的实际情况，构建、完善自己的数仓规范体系。然后大家多多交流，共同进步。
俗话说的好，无规矩不成方圆，没有规范岂不乱套了? 个人觉得， 规范是为了解决团体作战中的效率和协同问题，是对最终交付质量的有力保证 。
大家工作中有没有遇到类似的问题？
由于以上种种问题，造成数仓团队的整体开发效率、产出质量、工作幸福感、数仓维护成本等等越来越差。随着人员流动，通常受累的往往是那些任劳任怨、对公司忠诚的员工。
相信做过数据开发的人，多多少少都会有过上边提到的部分苦恼。我觉得问题的根源通常在于没有规范或者规范没有得到贯彻。大家有时候为了按时完成业务侧的需求，走些捷径也是可以理解的，但是欠下的技术债应该尽早还上，并且组织不应该苛责员工，这个锅应该领导来背。领导重视大家就都重视，领导不重视，岂不各个放飞自我了？
数据仓库，是我们数据工程师的无形产品。数据规范是数仓体系建设的"语言"，是数据使用的说明书和翻译官，同时也是数据质量的保驾护航者。为了数据体系能够长久健康的发展，数仓管理，应该从人治逐步转变到制度化、规范化、工具化的道路上了来。
从 0 到 1，从无到有，这个环节应该有 Leader 或架构师，充分考虑公司实际情况，参考行业标准或约定俗成的规范，综合统一制定。
也可以将规范拆分后交由各个部分核心开发人员编写， Leader 或架构师统一整合。比如我们之前的团队就是，模型设计师负责模型设计规范，ETL 工程师负责 ETL 开发规范，BI 开发人员制定前端开发规范，部署上线规范直接采用项目上已有的即可。
总体上，初稿应该尽量保证规范的完整性和各个部分间的兼容性。
初稿完成后，难免有考虑不周的情况，这时候最好有 Leader 牵头，组织部分核心成员（人数不易太多，三五个即可。人多容易造成混乱、决策困难、没有人提意见造成 Leader 一言堂等等问题。）进一步完善各个细节，纠正初稿的不足。
多人共同完善的规范，理论上来讲不会有什么大问题了。
定稿后，规范已经具备了全面推广的条件，可以下发所有团队成员。
为了确保规范的贯彻落实，除了通过以上两点引起全员重视外，还需要组织、制度、流程上的多方面保障。
讲到这里，大家有没有看出来一个问题？
规范的执行监督，上边提到的，更多是依靠制度流程以及相关人的自觉性，制度流程又依赖于人。这会带来如下几个问题：
有条件的最好引入相应的工具加强监管。
比如，我们有指标体系元数据、有词根库元数据、有建表的元数据、有 ETL 流程的元数据等等。
那我们是否可以开发部分报表或其它页面，通过 UI 辅助人去检查，或者通过校验元数据的方法去监管（比如备注是否为空、字段或表命名里的词根是否都在词根库里存在、表或页面等用到的指标是否都存在于指标体系、数据血缘中是否存在闭环或者孤立的节点）。
哈哈，讲了这么多，了解过数据治理的读者，会不会感觉很熟悉？数仓建设的一开始就需要考虑这些的，最好的管理在于治未病。
发行稿，从大面上应该不会有啥问题，但细节上可能会有考虑不周的情况，在宣讲阶段、执行阶段遇到问题阻碍的时候，应该根据实际情况对规范做出调整，唯有经过实践检验才能愈发完善，相信经过一段时间的持续实践， 规范会成为组织文化的一部分，进而降低沟通成本、提高开发效率、保证交付质量，从而实现团队和个人的双赢 。
为了让大家了解到数仓规范全貌，特意花大力气整理出以上分类。欢迎大家推广普及运用。由于只是一家之言，大家如有不同的见解、更好的方案或者有可以再补充的，欢迎加我微信，大家共同研究。
这里，我把数仓规范，一共分为四大类：设计规范、流程规范、质量管理规范、安全规范。
（这个在后续章节-ETL篇-会详细介绍）
（这个在后续章节-应用篇-会详细介绍）
分别从设计规范、流程规范、质量管控、数据安全四个方面，详细阐述了数仓规范。应该已经涵盖了数仓规范的方方面面。如有遗漏或者更好的分类方法，欢迎加我微信详聊。
本篇写作的初衷，就是找到一种合理的分类方式，把数据规范详尽穷举的罗列给大家，让大家了解全貌。但是，在实际落地实践中不一定能用到这么多，没有最好的只有最合适的，大家需要结合现实场景选取需要的子集落地即可。
在我经历过的几家公司、好多个项目里，也没有哪个项目完整的使用过以上所有规范，互联网大数据公司比之前的传统数仓项目用到的规范还更少些而且侧重点也不太一样。大数据公司可能由于互联网基因吧，更加侧重数据安全、工具化等，对数据质量、数据模型等要求不太高。而传统数仓对数据建模、数据质量的要求很高（我有一位同事，曾因为一块钱，被甲方财务主管扣下，对了一整天的数据~），内网环境数据安全被提的不是很多，另外可能是由于做项目的原因吧，工具化不太被人关注，管理基本靠人治，元数据基本靠文档。
系统的设计一个指标体系
如何搭建一个数据仓库
数据仓库之维度建模篇
OneData建设探索之路：SaaS收银运营数仓建设
One ID中的核心技术ID-Mapping究竟是怎么实现的？
网易云音乐数据服务之路
网易云音乐数仓维度建模实践-模型设计篇
数仓建模 - 维度 vs 关系
行业标准为星型模型
按客户化可成为雪花型模型
数据按用户视角分为事实和维度
比如销售领域
销售数据就是事实 会有一张行数巨大的销售事实表
而客户需要的分析关注角度就为维度
比如地区维度表，时间维度表，客户维度表，产品维度表等
事实表和维度表呈标准星型关联
事实表在中间 维度表在周围环绕
维度表可按各属性变化快慢客户化拆分成雪花型
你可以去了解下数据仓库之父所定义的总线结构
可以很好的搭建各个数据集市，进行平行的扩展
数据仓库数据建模的几种思路
数据管理一直在演进，从早期的电子表格、蛛网系统到架构式数据仓库。发展至今以维度建模和关系建模为主，而随着互联网的发展，数据从GB到PB的裱花，企业业务迭代更新亦是瞬息万变，对维度模型的偏爱渐渐有统一互联网数仓建模标准的趋势。
数仓模型不分高下，都是一种观察现实的角度。维度模型以实体与实体之间发生的事务/实为切入，而关系建模则以实体与实体之间的关系来组织数据。在当前的环境下，互联网更倾向于维度建模，而传统行业则较多沿用关系建模。
个人先后经历金融、互联网数仓建设，有多个0到1的项目经历，对于数仓建设仍在持续学习中。如有错误之处，还请多指出交流。
以事实表为核心，多个维度表作为手臂形成的星型模型，是维度建模的典型实现方式。
事实表，记录业务过程中发生的可度量事件，如订单中的消费金额，折扣金额或是库存数量等，在实际业务中事实表占据主要的存储，如订单表；而维度表，则是对业务过程度量有关的文本环境，描述“谁、什么、哪里、何时、如何、为什么”，常用的维度表有日期、产品、用户、地址等。一般维度表会冗余信息，有超过100个列的维度表，这样的不规范化带来数据组织上的简单。
关系建模，被称为“实体-关系”模型，以一种“标准化”的方式存在，强调数据之间非冗余，满足3NF。在建设过程中，将数据标准化到细节级数据，如用户主题下，会有用户与姓名、用户与年龄、用户与住址等。在传统行业中，成熟的关系建模有ls-ldm模型，面向金融行业形成10大主题。
维度建模 ： 从实际的需求出发进行数据建设，一般面向部门/业务形成独立的数据集市，这样的方式带来鲜明的特点，高效。但由于基于需求出发，往往导致频繁的需求迭代带来的维护成本较高，一旦业务过程发生调整，模型有可能会重来的风险。
关系建模 ：面向企业进行模型建设，具有较强的抽象性。建设时以3NF的方式建设无冗余的数据，使模型具有很高的灵活性，但由于不能直接面向需求，效率上不如维度模型。另外面向企业建设，周期相比于维度建模，要长的多，但也有个好处：企业数据集成更容易。
在企业内，这两种建模方式往往同时存在，基础数据仓库的建设使用关系建模，技术的优雅换来了数据的精简，保证高度抽象、高度一致性，要求业务稳定；往上维度建模更合适一些，偏向于直接面对业务，靠数据的冗余带来了可用性，保证查询效率。两者优势互补
在大数据的环境下，数据存储和发展已发生很大变化，曾经的维度建模和关系建模在当前的场景下都有各自的不足之处。那数据仓库在大数据环境下如何发展、成熟？Inmon等就提出了data vault模型
data valult是一个面向细节的、历史追溯的并且唯一链接的规范化表集，能给支持一个或者多个业务功能区；是一种中心辐射式模型，其设计重点围绕着业务键的集成模式。data vault有三种基本的实体(结构)
从建模风格上看，它采用了一种由第三范式方法与维度建模方法混合而成的方式，以二者的独特组合来满足企业需求。
数据仓库数据建模的几种思路主要分为一下几种
1. 星型模式
星形模式(Star Schema)是最常用的维度建模方式。星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样。星形模式的维度建模由一个事实表和一组维表成，且具有以下特点：a. 维表只和事实表关联，维表之间没有关联；b. 每个维表主键为单列，且该主键放置在事实表中，作为两边连接的外键；c. 以事实表为核心，维表围绕核心呈星形分布；
2. 雪花模式
雪花模式(Snowflake Schema)是对星形模式的扩展。雪花模式的维度表可以拥有其他维度表的，虽然这种模型相比星型更规范一些，但是由于这种模型不太容易理解，维护成本比较高，而且性能方面需要关联多层维表，性能也比星型模型要低。所以一般不是很常用
雪花模式
3．星座模式
星座模式是星型模式延伸而来，星型模式是基于一张事实表的，而星座模式是基于多张事实表的，而且共享维度信息。前面介绍的两种维度建模方法都是多维表对应单事实表，但在很多时候维度空间内的事实表不止一个，而一个维表也可能被多个事实表用到。在业务发展后期，绝大部分维度建模都采用的是星座模式。
星座模型
以上就是关于数据仓库开发规范全部的内容，如果了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
