聚焦数仓架构、规范设计、建模和数据赋能

聚焦数仓架构、规范设计、建模和数据赋能

传统数据库实时报表开发架构

准实时数仓--->准实时报表

传统经典数仓架构

经典离线数仓，基于传统关系数据库或大数据数仓工具Hive

数仓规范设计

1. 规范设计有哪些好处

规范设计是在数仓具体开发之前就要制定好的，如果从0到1，前无古人，则可以迭代式改进和优化沉淀，总体还是在具体开发过程中不断完善。规范设计的目标是为了让整个部门的小伙伴“对齐”认知
，从而按照同一个标准或者流程进行开发，保证数据的一致性，让数仓建设流程清晰且稳定。

【降本增效】 一个良好的规范设计，能够提高团队开发效率、提升开发质量、降低沟通成本、降低运维成本。

重点规范

• 设计规范
  逻辑架构
  技术架构
  分层设计
  主题划分
  方法论
• 命名规范
  各层级的规范
  任务规范
  表命名
  字段级别的命名
  指标命名
  标签命名
• 模型规范
  建模方法
  建模工具
  血缘关系
  维度退化
  一致性维度
  元数据管理
• 开发规范
  脚本注释
  字段别名
  编码规范
  脚本的格式
  数据类型
  缩写规范
• 流程规范
  需求流程
  工程流程
  上线流程
  调度和表生命周期管理

1. 设计规范-指标

• 面向主题域管理
  为了提高指标管理的效率，需要按照业务线（业务板块）、主题域（数据域）、业务过程三级目录方式来进行指标管理
• 划分原子指标和派生指标
  时间周期+统计粒度+修饰词+原子指标+（原子指标）=派生指标
  
• 进行指标的命名规范
  原则：简单易懂+统一
  易懂：直接判断这个指标到底属于哪个业务过程
  统一：确保派生指标和它继承的原子指标命名是一致的

对于原子指标，指标名称适用于“动作+度量”
的命名方式：比如：注册+用户数 登录+用户数 贷款申请+用户数 (user, 1)

对于派生指标，严格遵循“时间周期+统计粒度+修饰词+原子指标”

• 指标分级 指标比较多，很难管理，需要按照原则或者等级进行划分：
  一级指标：核心指标 管理层战略指标、集团分公司；
  二级指标：原子指标和业务部门创建的派生指标

1. 命名规范-表命名
   常规表
   需要固化、正常使用、基本不会下线、长时间需要去维护的表。
   规范：分层前缀[dwd|dws|ads|app].业务域(CMS/APP/EBS)_主题域(event)_xxx_更新频率(all/inc)增量/全量

dwd.xxx_xxx_d_all 每日全量  
dwd.xxx_xxx_d_inc 每日增量  
dwd.xxx_xxx_m_all 每月全量  
dwd.xxx_xxx_m_inc 每月增量

复制

中间表-临时表-辅助表
tmp/mid_table_name_time(20210822)_dim/ods

维度表
基于底层数据，抽象出来具有描述性质的表，也可以手动维护 dim_xxx

1. 开发规范

• 表和列的注释是否有缺失，复杂的指标计算逻辑是否有注释
• 任务是否支持多次重跑而输出不变，不能有insert into这个语句
• ETL和SQL规范

参考业界标准：https://help.aliyun.com/document_detail/115496.html

1. 流程规范
   需求阶段，需求变更、不断变化的数据需求如何应对；
   设计阶段
   开发阶段
   测试阶段
   发布阶段
   运维阶段

参考业界标准：https://help.aliyun.com/document_detail/115496.html

图片来自阿里云官方文档。

1. 数仓规范里的分层设计
   数仓为啥要分层，分层有啥好处？
   为啥非要建数仓，数仓的价值和作用是什么？

数仓

• 整合公司的所有业务，建立统一的数据中心。
• 分析业务系统数据、用户行为埋点日志数据，通过数据挖掘来降低投入成本，提高投入产出效果。
• 作为各个业务的数据源，形成业务数据互相反馈的良性循环。
• 提供数据报表和BI底层数据，用于公司的决策支持

数据采集层
数据采集层的任务就是把数据从各种数据源中采集和存储到数据仓库（存储系统）上，期间有可能会做一些ETL（抽取extract、转化transfer、装载load）操作。数据源种类一般会有多种：日志；业务数据库；三方接口；人工上报数据。

数据存储与分析
HDFS、Hive，离线数据存储解决方案，数据量越大越好，适合PB级别+的数据处理。数据计算：HiveSQL（MapReduce、Tez；SparkSQL；Presto；Impala。

数仓分层

• 数仓基本要求
  数仓要满足高效率：数仓的分析数据一般分为日、周、月、季、年等，可以看出，以日为周期的数据要求的效率最高，要求24小时甚至12小时内，客户能看到昨天的数据分析。由于有的企业每日的数据量很大，如果数仓设计的不好，需要延时一到两天才能显示数据，显然不能出现这种情况。
  数仓要实现高质量：数仓提供的各种信息，肯定要准确的数据。数仓通常要经过数据清洗、装载、查询、可视化展现等多个流程，如果复杂的架构会有更多层次，那么由于数据源有脏数据或者代码不严谨都可以导致数据不准确或者有错误，如果客户看到错误的信息就可能导致分析出错误的决策，造成经济损失。
  数仓要支持高可扩展性：之所以有的大型数仓系统架构设计复杂，是因为考虑了未来3-5年的扩展性，因为如果在未来需要扩展一些新的功能了，就可以不用重建数仓系统，就能很稳定运行。毕竟重建一个数仓比较耗费人力和财力。可扩展性主要体现在数据建模的合理性。

• 数仓分层原因
  首先要达到上述数仓基本要求。
  用空间换时间，通过数据预处理提高效率，通过大量的预处理可以提升应用系统的用户体验（效率），但是数仓会存在大量冗余的数据。
  增强可扩展性，方便以后业务的变更。如果不分层的话，当源业务系统的业务规则发生变化的时候，整个数仓都需要重建，将会影响整个数据清洗的过程，工作量巨大。
  通过分层管理来实现分步完成工作，简化数据清洗的过程，使得每一层处理逻辑变得更简单。因为把原来一步的工作分到了多个步骤去完成，相当于把一个复杂的工作拆成了多个简单的工作，把一个大的黑盒变成一个白盒，每一层的处理逻辑都相对简单和容易理解，这样就比较容易保证每一个步骤的正确性，当数据发生错误的时候，往往我们只需要局部调整某个不走即可。

数仓具体分层
标准数仓分层：stg数据缓冲层，ods数据贴源层，dw:dwd dws dwt数仓层，ads数据集市层，app应用层。

数据标准层（ods） --- 数据治理

stg：源数据缓冲层，和源系统数据是同构的，而且这一层数据粒度是最细的，数据层与业务源的数据结构一一对应，是数据存储的临时存储区域，数据在其中只做暂时性保存，当新的数据到达缓存区时，现有数据被删除或覆盖。【也可以把业务数据库作为stg】

ods：对数据标准化处理，主要由公共代码标准化、数据类型标准化和数据格式标准化，未来可以做客户信息标准化，它的数据是干净的数据，是一致的准确的，也就是清洗后的数据。它的数据一般都遵循数据库第三范式，数据粒度和stg基本一致。

1. 从0到1案例：dwd层是怎么设计的，设计思路？

复杂业务场景下，业务流程特别复杂，数据量非常大，如何通过模型方式进行调优。

了解业务过程
当数据产品经理或者数据分析师提出数据需求的时候，能够清晰的指导数据在数仓哪一层，或者哪个业务系统数据库表有这个数据，或者能够加工出这个指标。

业务建模：梳理业务流程
领域建模：数仓分域/主题
逻辑建模：指标体系梳理、实体关系调研、维度梳理、数仓分层；
物理建模：模型建立

业务流程
找到公司核心业务流程，找到谁，在什么环节，做什么关键工作，得到什么结果。比如：XXX业务模式，从第一步到最后一步。
业务流程图，角色、动作、留下哪些数据、背后是哪些数据表（事实表，实际上是关系表）、哪些字段；
信息流（数据是如何流动的）；
资金流（比如资金划转过程）。整个业务过程，从一个动作A、到动作B、再到动作C，每一个动作都可以做一个模型。

数据建模高级分析文档模板【收入是名词，业务分析找动词、操作行为】

分域/主题
决定数仓的建设方式，要想快速交活、就用自下而上的建设。要全面支撑，就顶层规划，分步实施，交活稍微慢点。来一个需求出一个报表 VS 模型设计。

主题域（数据域）的划分方式，按需求分、按职责分、按产品功能分等。

指标体系
指标的意义在于统一语言、统一口径，所以指标的定义必须有严格的标准。
业务过程定义+表、字段=原子指标

原子指标+限定条件=派生指标

派生指标+逻辑运算=衍生指标

依据指标体系建设标准，开始梳理指标体系。整个体系同样要以业务为核心进行梳理。同时梳理每个业务过程所需要的维度。维度就是我们观察这个业务的角度，指标就是衡量这个业务结果好坏的量化结果。

在分析业务指标时，不能被现有数据所局限。如果分析出这个业务过程应该有这个指标，但是没有数据，请标注出来，提出收集数据的需求。

实体关系
每个业务动作都会有数据产生。我们将能够获取到的数据，提取实体，绘制ER图，便于之后的维度建模。
源数据库的表结构关系图。

以业务过程为起点向下梳理，此时的核心是业务表。把每张表中涉及的维度、指标都整理出来。

维度整理
维度标准化是将各个业务系统中相同的维度进行统一的过程。其字段名称、代码、名字都可能不一样，需要完全掌握，并标准化。

维度的标准尽可能参照国家标准、行业标准。例如地区可以参照国家行政区域代码。
有些维度存在层级，如区域的省、市、县。绝大多数业务系统中的级联就是多层维度。

数仓分层，一般分为5层，每一层采用的建模方法都不一样，核心是逐层解耦。越到底层，越接近业务发生的记录，越到上层，越接近业务目标。

按照数仓分层的设计理论，根据实际业务场景，就可以梳理出整体的数据流向图。这张图会很清晰的告诉所有人，数据从哪来，到哪里去，最终提供什么样的服务。

建立模型
纯代码阶段。数仓、ETL工具选型；ETL流程开发；cube的建立；任务调度、设定更新方式、更新频率；每日查看日志、监控ETL执行情况等。

总结

1. 数仓建设业务是核心，必须从业务中来，到业务中去。
2. 数仓分层的目的是业务解耦。
3. 无论哪种建模方式，其核心是业务实体。
4. 按领域建设能快速交付，后遗症比较难以解决。
5. 数仓建设应该把75%的时间投入到设计阶段，如果不是，那后续就是从建仓到跑路。
6. 数仓本身也是可以迭代进化的，技术、架构、流程等。

复制

理想的数仓模型长成什么样子

1. 高内聚 低耦合 将业务相近或者相关的、粒度相同的数据设计为一个逻辑模型或者物理模型。将高频率同时访问的数据放在一起，将低频率同时访问的数据分开放、分开存储。
2. 核心模型和拓展模型分离 建立核心模型和拓展模型体系。核心模型包括的字段支持常用的核心业务；拓展模型包括的字段支持个性化或少量应用的需要，比如标签附加信息的加工，不能让拓展模型的字段过于侵入核心模型，保持核心模型的架构间接性、降低可维护成本。
3. 公共处理层逻辑下沉且保持单一 越是底层公用的处理逻辑，越是要在数据底层调度系统的依赖中进行封装和实现。
4. 成本和性能平衡
5. 数据可回滚 不改变处理逻辑、不修改代码的情况下重跑任务，结果保持不变。
6. 数据一致性
   字段命名规范的一致性
   指标定义的口径一致性
7. 命名清晰且容易理解 表的命名，清晰、一致，要让业务使用方见名知意。

从产品侧聚焦数据赋能

从业务产品迭代和数据应用产品两个层面出发，发挥数据的终极决策价值。

1. 数据可以赋能产品做迭代，如改进功能、优化用户体验、提升产品各项指标等，这一层面每个公司的应用方式、方向及深度都略有差异。
2. 数据与产品做一些结合，把数据融合到产品设计中，直接成为产品的一部分。

锚定收益最大化，关注用户决策【过程】，而不是【流程】体验最优；大幅度降低决策成本，从产品到决策的转化过程：注意力 -> 思考 -> 时间 -> 真金白银
。