ToB企服应用市场:ToB评测及商务社交产业平台

标题: 2024数据仓库建设规范指南 [打印本页]

---

作者: 络腮胡菲菲    时间: 2024-12-21 05:51
标题: 2024数据仓库建设规范指南
01 为什么要有数仓规范？


俗话说的好，无规矩不成方圆，没有规范岂不乱套了? 个人觉得，规范是为了解决团体作战中的效率和协同问题，是对终极交付质量的有力包管。

大家工作中有没有遇到雷同的问题？

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

由于以上种种问题，造成数仓团队的整体开发效率、产出质量、工作幸福感、数仓维护本钱等等越来越差。随着职员运动，通常受累的往往是那些任劳任怨、对公司忠诚的员工。

信赖做过数据开发的人，多多少少都会有过上边提到的部分苦恼。我觉得问题的根源通常在于没有规范大概规范没有得到贯彻。大家偶然候为了按时完成业务侧的需求，走些捷径也是可以理解的，但是欠下的技术债应该尽早还上，并且组织不应该苛责员工，这个锅应该领导来背。领导器重大家就都器重，领导不器重，岂不各个放飞自我了？

数据仓库，是我们数据工程师的无形产品。数据规范是数仓体系建设的'语言'，是数据使用的说明书和翻译官，同时也是数据质量的保驾护航者。为了数据体系能够恒久健康的发展，数仓管理，应该从人治逐步转变到制度化、规范化、工具化的道路上了来。


02 数仓规范该怎么落地？

1、规范订定


从 0 到 1，从无到有，这个环节应该有 Leader 或架构师，充分考虑公司实际情况，参考行业尺度或约定俗成的规范，综合统一订定。

也可以将规范拆分后交由各个部分核心开发职员编写， Leader 或架构师统一整合。好比我们之前的团队就是，模子设计师负责模子设计规范，ETL 工程师负责 ETL 开发规范，BI 开发职员订定前端开发规范，摆设上线规范直接采用项目上已有的即可。

总体上，初稿应该尽量包管规范的完备性和各个部分间的兼容性。

2、规范讨论


初稿完成后，难免有考虑不周的情况，这时间最好有 Leader  牵头，组织部分核心成员（人数不易太多，三五个即可。人多轻易造成杂乱、决策困难、没有人提意见造成 Leader 一言堂等等问题。）进一步完善各个细节，纠正初稿的不敷。

多人共同完善的规范，理论上来讲不会有什么大问题了。

3、规范推行


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

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

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

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

4、规范的执行监督


规范的执行监督，上边提到的，更多是依靠制度流程以及相关人的自觉性，制度流程又依赖于人。这会带来如下几个问题：

短期坚持还好，但长期的专注很难。

偶然候人忙起来了，快速产出和规范该选哪个？代码 Review 还要不要做？新建的表要不要找数据架构师考核？

数据建模最好是有专门的人大概小团队去做，其他人使用，这往往会影响整体效率，以是通常都是谁用谁建，但撒出去后再想靠人去检查合规性，真的就太难了。

有条件的最好引入相应的工具加强羁系。

好比，我们有指标体系元数据、有词根库元数据、有建表的元数据、有 ETL 流程的元数据等等。

那我们是否可以开发部分报表或别的页面，通过 UI 辅助人去检查，大概通过校验元数据的方法去羁系（好比备注是否为空、字段或表定名里的词根是否都在词根库里存在、表或页面等用到的指标是否都存在于指标体系、数据血缘中是否存在闭环大概孤立的节点）。

5、规范完善


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


03 数仓规范有哪些？


为了让大家了解到数仓规范全貌，特意花鼎力大举气整理出以上分类。欢迎大家推广普及运用。由于只是一家之言，大家如有差别的见解、更好的方案大概有可以再增补的，欢迎关注我们一起进步。

这里，把数仓规范一共分为四大类：设计规范、流程规范、质量管理规范、安全规范。

设计规范，又划分为四部分：数据模子设计、定名规范、指标体系设计、词根库。

流程规范，主要是从数仓管理的角度，对数仓场景下的各种流程进行约束。核心流程一共提炼出来五类：需求提交、模子设计、ETL开发、前端开发、上线流程。

质量管控规范，之以是单独列出来，是因为数据质量，跟模子设计一样，对数仓建设的成败关系极大。试想下，一个数据质量都无法包管的数据仓库，有谁会用?  数据质量规范，主要是从数据运动的角度分为三类：源端管控、数仓管理、应用管控。

安全规范，随着国家、社会、企业对数据的越来越器重，另一方面随着互联网的普及使得个人隐私变的越来越难以包管，数据泄漏时有发生。数据安全对于数据仓库的重要水平急速提升，以是安全规范被单列了出来。从大的层面上安全规范分为三类：网络安全、账号安全、数据安全。




04 设计规范

1、数据模子设计


横向分层
纵向分域

• 说明
  
  
  
  • 分层设计是数据架构设计的产出之一，在模子设计环节做为强制规范服从。
    
  
  
• 分层规范
  
  
  
  • 应用层，面向终极应用。
    
  • 主题域划分，依据是终极应用。生命周期也与应用同步。
    
  • 汇总数据层+主题宽表。
    
  • 数据域划分，依据参考下边的纵向分域。
    
  • 对数据源做清洗、转换、补全、编码转换后加载到明细数据层。
    
  • 数据域划分，依据参考下边的纵向分域。
    
  • 贴源层，原始数据不做变化大概仅做最简单的补全后存入。
    
  • 数据域划分，依据是数据源。
    
  • 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 等。
  

2、定名规范

统一规范

• 采用蛇形定名法，即采用一个下划线分隔词根。
  
• 优先使用词根中已有关键字（数仓尺度配置中的词根管理），- - 定期 Review 新增定名的不公道性。
  
• 禁止采用非尺度的缩写。
  
• 定名同等采用小写，只能以字母开头。
  
• 定名不宜过长。专有规范
  
• 表
  
  
  
  • 分层-分域-分词根-分时间周期
    
  • 正式表，所在层级名称+数据域+表形貌+时间周期或加载策略，如增量、快照、拉链/小时、日、周、月、季、年
    
  • 中间表,对应正式表+_mid+阿拉伯数字
    
  • 临时表，z+创建者姓名检查+表名
    
  
  
• 视图
  
  
  
  • 参照表定名规范+_v
    
  
  
• 字段
  
  
  
  • 优先从词根中取，多次出现的要增长到词根库
    
  
  
• 使命
  
  
  
  • 与目标表名相同
    
  
  
• 指标
  
  
  
  • 一个原子指标＋多个修饰词（可选）＋时间周期
    
  • 原子指标+时间周期（可选）
    
  • 原子指标
    业务修饰词 + 词根
    
  • 衍生指标
    
  • 派生指标
    
  
  

3、代码设计规范

• 脚本是否有备注、复杂盘算逻辑是否有注释释。
  
• 使命是否支持多次重跑而输出稳固，不能有 insert into 语句。
  
• 分区表是否使用分区键过滤并且有有效裁剪。
  
• 外连接的过逑条件是否使用精确，例如在左连接的 where 语句存在右表的过滤条件。
  
• 关联小表，是否使用/*+ map join * /。
  
• 不允许引用别的盘算使命临时表。
  
• 原则上不允许存在一个使命更新多个目标表。
  
• 是否存在笛卡尔积。
  
• 禁止在代码里面使用 drop、create、rename 等 DDL 语句。
  
• 使用动态分区时，有没有检查分区键值为 NULL 的情况。
  
• 对于重要的使命 DQC 质量监控规则是否配置，严禁裸奔。
  
• 代码中有没有进行得当的规避数据倾斜语句。
  

4、指标体系建设

• 指标层级划分方式
  
  
  
  • 一级分类
    
  • 二级分类
    
  • 三级分类
    
  • 一级分类
    
  • 二级分类
    
  • 按分析主题
    
  • 按业务过程
    
  
  
• 指标界说
  
  
  
  • 原子指标(某一业务变乱举动下的度量，不可再拆分的指标) 例如：订单金额
    
  • 衍生指标（对原子指标进行四则运算）
    
  • 派生指标（统计周期+统计粒度+业务限定+原子指标）例如：最近一天+新创建的+订单个数（阿里大数据之路对于派生指标的界说：派生指标=原子指标+时间周期修饰词+别的修饰词。唯一归属于某一个原子指标，继承原子指标的数据域）
    
  • 唯一性
    
  • 可扩展
    
  • 易理解
    
  • 所属分类
    
  • 指标类别
    
  • 名称
    
  • 形貌
    
  • 口径/算法
    
  • 计量单位
    
  • 适用维度
    
  • ...
    
  • 内容
    
  • 原则
    
  • 类别
    
  • 说明：网上对于指标分类说法不统一，大家知道咋回事儿就行了。搜了一下阿里的大数据之路，没有衍生指标的概念。说法一：衍生指标=派生指标。那么用我上边派生指标的界说即可。说法二：衍生指标是对原子指标进行四则运算得到的。那么衍生指标就是原子指标增长减少几个修饰词大概时间周期扩大缩小后得到的。以是感觉衍生指标有点鸡肋搞不好就变成原子/派生指标了。
    
  
  
• 指标管理流程
  
  
  
  • 指标新增申请
    
  • 初审：明确指标口径，检查指标库是否包罗
    
  • 二审：考核指标界说需要的各项元素是否精确完备
    
  • 入指标库
    
  
  

05 流程规范

• 
  
  
  
  • 公共字段=词根组合+别的关键词。
    
  • 公共字段放入词根库不太严谨，但字段定名时间可以直接取用，降低了定名不一致的风险，以是工具化不太完善的公司推荐这样使用。
    
  
  

1、需求提交流程

• 提出需求
  
  
  
  • 需求提出人：以文档的形式提出需求（写清晰需求内容、交付物、盼望交付日期），发给数仓 Leader。
    
  
  
• 沟通需求
  
  
  
  • 数仓 Leader 将需求分配给相关人承接，同时协商好实际交付日期。
    
  • 如果需求提出人的交付日期与数仓 Leader 的交付日期不一致，双方需要进一步协商一致。
    
  
  
• 开发交付
  
  
  
  • 需求承接人，需按照协商一致的交付日期，按期交付。
    
  
  

2、模子设计流程

• 数据调研、业务调研、需求调研
  
• 数据建模
  
  
  
  • 确定业务过程->声明粒度->确定维度->确定事实
    
  • 业务建模->逻辑建模->物理建模
    
  • 构建总线矩阵
    
  • 构建指标体系
    
  • 根据已有的分层分域，分治、各个击破。
    
  • 总体思绪
    
  • 多种方式结合使用
    
  
  
• 评审
  
  
  
  • 除了模子设计，还需要拉上必要的开发、业务、分析师、产品司理、数仓运维等。
    
  
  
• 上线、迭代、完善
  

3、ETL开发流程

• 需求理解
  
• 数据探查
  
• 程序开发
  
• 流程依赖
  
• 配置调理
  

前端开发规范

• 接口规范
  
• 代码摆设规范
  

4、上线流程

• 申请
  
  
  
  • 上线时间
    
  • 上线功能范围
    
  • 对别的模块、上下游依赖的影响
    
  • 上线支持团队清单
    
  • 上线详细操纵步骤
    
  • 测试报告
    
  • 回滚方案
    
  
  
• 评审
  
  
  
  • 代码 Review
    
  • 上下游影响分析
    
  
  
• 上线
  

06 质量管控规范

• 
  
  
  
  • 上线支持团队就绪
    
  • 严格按照上线操纵步骤执行
    
  • 失败回滚
    
  
  

1、源端管控

• 源端变动，必须提前关照数仓侧。
  
• 有条件的话，使用工具监控源端重点内容的变动。
  

2、数仓管理

• 对已有规范没有贯彻的给予警告、处罚：建模规范、开发规范、上线规范
  
• 使用工具加强数据质量监控，发现问题及时关照、告警。建立数据质量解决机制，责任到人。
  
• 定期复盘
  
  
  
  • 重要常见问题入告警规则
    
  • 源端数据质量问题，协调源端解决
    
  • 存储模子、ETL开发、上线流程等引起的问题，需要订定符合的解决方案
    
  
  

3、应用管控

• 统一指标界说
  
• 统一指标口径
  
• 统一外部数据输出归口
  

07 安全规范

网络安全

• 内外网隔离，外网情况访问内网需要登录 VPN；
  
• 核心数据存储、功能模块，只开放给特定的少部分人。
  

账号安全

• 每个人分配独立的账号，赋予公道的权限，禁止相互借用。
  
• 数据库、大数据组件开通多个角色账号。好比只读、部分表读写、管理员等。固然还可以按实际需求细分。Hive、ODPS 的话也是可以实现单人单号的。
  
• 服务器登录。也是单人单号。
  
• 公司内部应用账号。单人单号。
  

数据安全

• 至少做到表级别的权限控制，着实不行就分库。
  
• ODS 层不对外开放，只对 ODS-DWD 层相关部分开发职员可见。
  
• 特别敏感数据，如用户年龄、号码、身份证好、地点等，应该放到专门的数据库里，数仓主库只存放用户 ID 和别的必须字段。例如年龄应该脱敏成年龄区间或开发特定的 UDF 转化函数。
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/)

Powered by Discuz! X3.4