写点什么

数仓建设之路 (一)

用户头像
undefined
关注
发布于: 23 小时前
数仓建设之路(一)

前言

这是关于实践阿里 Maxcompute 数仓建设方案,后续会补充更多关于生产级别数仓实践经验的系列文章。

在免运维的情况下构建敏捷数仓,主要目的是在团队人手不充足的前提下,通过数据积极探索业务、风控等领域的未知问题;

本方案是查阅各种视频、文档后,整理出来的后续开展数仓工作的基础方案,初入数据行业,中间描述如有问题,还请多多指教,共同学习。

数仓建设讲究可持续发展,前期规划会避免过度设计,中期规划需要完成成本可控、性能不断提升、数据安全且可高度共享、数据价值得到充分体现等阶段性任务,后期通过不断治理、优化降低风险面积;

总体设计

数仓分层设计



  • 数据引入层 ODS(Operation Data Store):存放未经过处理的原始数据至数据仓库系统,结构上与源系统保持一致,是数据仓库的数据准备区。主要完成基础数据引入到数仓的职责,同时记录基础数据的历史变化。

  • 数据公共层 CDM(Common Data Model,又称通用数据模型层),包括 DIM 维度表、DWD 和 DWS,由 ODS 层数据加工而成。主要完成数据加工与整合,建立一致性的维度,构建可复用的面向分析和统计的明细事实表,以及汇总公共粒度的指标。

  • 公共维度层(DIM):基于维度建模理念思想,建立整个企业的一致性维度。降低数据计算口径和算法不统一风险。公共维度层的表通常也被称为逻辑维度表,维度和维度逻辑表通常一一对应。

  • 明细粒度事实层(DWD):以业务过程作为建模驱动,基于每个具体的业务过程特点,构建最细粒度的明细层事实表。可以结合企业的数据使用特点,将明细事实表的某些重要维度属性字段做适当冗余,即宽表化处理。明细粒度事实层的表通常也被称为逻辑事实表。

  • 公共汇总粒度事实层(DWS):以分析的主题对象作为建模驱动,基于上层的应用和产品的指标需求,构建公共粒度的汇总指标事实表,以宽表化手段物理化模型。构建命名规范、口径一致的统计指标,为上层提供公共指标,建立汇总宽表、明细事实表。公共汇总粒度事实层的表通常也被称为汇总逻辑表,用于存放派生指标数据。

  • 数据应用层 ADS(Application Data Service):存放数据产品个性化的统计指标数据。根据 CDM 与 ODS 层加工生成。

数据分类架构


数据流向示意


数仓建设规范

分层调用规范

ADS 应用层优先调用数据仓库公共层数据。如果已经存在 CDM 层数据,不允许 ADS 应用层跨过 CDM 中间层从 ODS 层重复加工数据。CDM 中间层应该积极了解应用层数据的建设需求,将公用的数据沉淀到公共层,为其他数据层次提供数据服务。同时,ADS 应用层也需积极配合 CDM 中间层进行持续的数据公共建设的改造。避免出现过度的 ODS 层引用、不合理的数据复制和子集合冗余。总体遵循的层次调用原则如下:

  • ODS 层数据不能直接被应用层任务引用。如果中间层没有沉淀的 ODS 层数据,则通过 CDM 层的视图访问。CDM 层视图必须使用调度程序进行封装,保持视图的可维护性与可管理性。

  • CDM 层任务的深度不宜过大(建议不超过 10 层)。

  • 一个计算刷新任务只允许一个输出表,特殊情况除外。

  • 如果多个任务刷新输出一个表(不同任务插入不同的分区),DataWorks 上需要建立一个虚拟任务,依赖多个任务的刷新和输出。通常,下游应该依赖此虚拟任务。

  • CDM 汇总层优先调用 CDM 明细层,可累加指标计算。CDM 汇总层尽量优先调用已经产出的粗粒度汇总层,避免大量汇总层数据直接从海量的明细数据层中计算得出。

  • CDM 明细层累计快照事实表优先调用 CDM 事务型事实表,保持数据的一致性产出。

  • 有针对性地建设 CDM 公共汇总层,避免应用层过度引用和依赖 CDM 层明细数据。


ODS 层规范

  • 使用场景:从业务系统获取的最原始的数据,是其他上层数据的源数据。

  • 命名规范:ods_{源表所属 BU}_{源表名}_{单分区增量全量标识}[_{刷新周期标识}_{临时表标识}]

  • 全量基线表用_base 后缀进行标识

  • 增量表用_delta 后缀进行标识,按小时增量需要再补充_{hh}后缀

  • ETL 过程临时表用_tmp_{输出表}进行标识

  • 一个系统的源表只允许同步一次到数仓

  • 数据集成同步全量数据时会直接进入全量表的当日分区

  • 增量数据同步可以使用数据集成节点 T+1 定时同步,特殊时效数据拉取场景采用实时同步节点进行

  • 数据存储及生命周期管理规范(按天分区):

  • 流水型全量表:不可再生数据永久存储,日志类型数据保留 24 个月;

  • 镜像型全量表:重要的业务表及需要保留历史的表视情况保存,ODS 全量表的默认生命周期为 2 天;

  • 增量表:有对应全量表,最多保留最近 14 天分区数据;无对应全量表,需要永久保留数据;

  • ETL 过程临时表:最多保留最近 7 天分区;

  • DBSync 非去重数据:由应用通过中间层保留历史数据,默认 ODS 层不保留历史数据;

  • 数据质量规范:

  • 每个 ODS 全量表必须配置唯一性字段标识。

  • 每个 ODS 全量表必须有注释。

  • 每个 ODS 全量表必须监控分区空数据。

  • 建议对重要表的重要枚举类型字段进行枚举值变化及枚举值分布监控。

  • 建议对 ODS 表的数据量及数据记录数设置周同环比监控,如果周同环比无变化,表示源系统已迁移或下线。


CDM 公共维度层规范

  • 使用场景:基于维度建模理念,建立整个企业的一致性维度;

  • 维表命名规范:dim_{业务板块名称/pub}_{维度定义}[_{自定义命名标签}],pub 是与具体业务板块无关或各个业务板块都可公用的维度;

  • 存储方式为按天分区,模型设计者根据自身业务需求设置表的生命周期管理,可依据 3 个月内的最大需要访问的跨度设置保留策略;

  • 一致性维度规范:公共层的维度表中相同维度属性在不同物理表中的字段名称、数据类型、数据内容必须保持一致(特殊情况下必须是规范的维度属性的别名);

  • 维表设计时,需要明确定义维度、确定主维表(中心事实表)、确定相关维表、确定维度属性;


CDM 明细层规范

  • 使用场景:以业务过程驱动建模,基于每个具体的业务过程特点,构建最细粒度的明细层事实表,可以结合企业的数据使用特点,将明细事实表的某些重要维度属性字段做适当冗余,即宽表化处理;

  • 命名规范:dwd_{业务板块/pub}_{数据域缩写}_{业务过程缩写}[_{自定义表命名标签缩写}] _{单分区增量全量标识}

  • 单分区增量全量标识通常为:i 表示增量,f 表示全量,即_di_df

  • pub 表示数据包括多个业务板块的数据;

  • 存储方式为按天分区,事务型事实表一般永久保存,周期快照型事实表根据业务需求设置生命周期管理,可依据 3 个月内的最大需要访问的跨度设置保留策略;

  • 目的是充分使用了维度退化以提升查询效率;

  • 明细数据表分为事务型事实表、周期快照型事实表、累计快照事实表:

  • 事务型事实表:事务型事实表主要用于分析行为与追踪事件。

  • 周期快照型事实表:周期快照型事实表主要用于分析状态型或者存量型事实。快照是指以预定的时间间隔来采样状态度量。

  • 累计快照事实表:累计快照事实表主要用于分析事件之间的时间间隔与周期。


CDM 汇总层规范

  • 使用场景:以分析的主题对象作为建模驱动,基于上层的应用和产品的指标需求构建公共粒度的汇总指标事实表,公共汇总层的一个表通常会对应一个派生指标;

  • 命名规范:dws_{业务板块缩写/pub}_{数据域缩写}_{数据粒度缩写}[_{自定义表命名标签缩写}]_{统计时间周期范围缩写}

  • 离线计算应该包括最近一天(_1d),最近 N 天(_nd)和历史截至当天(_td)三个表;

  • 对于小时表(无论是天刷新还是小时刷新),都用_hh 来表示;

  • 对于分钟表(无论是天刷新还是小时刷新),都用_mm 来表示;

  • 存储方式为按天分区,事务型事实表一般会永久保存,周期快照型事实表根据业务需求设置生命周期管理,可依据 3 个月内的最大需要访问的跨度设置保留策略;

数仓质量规范

  • 保证数据的完整性、准确性、一致性;通过数据及时性监控,保证数据的及时性。



发布于: 23 小时前阅读数: 13
用户头像

undefined

关注

还未添加个人签名 2017.10.17 加入

还未添加个人简介

评论

发布
暂无评论
数仓建设之路(一)