【漫谈数据仓库】 如何优雅地设计数据分层 ODS DW DM层级

转载http://bigdata.51cto.com/art/201710/554810.htm

1、文章主题

本文主要讲解数据仓库的一个重要环节：如何设计数据分层!其它关于数据仓库的内容可参考以前的文章。

本文对数据分层的讨论适合下面一些场景，超过该范围场景 or 数据仓库经验丰富的大神就没必要浪费时间看了。

• 数据建设刚起步，大部分的数据通过粗暴的数据接入后就直接对接业务。
• 数据建设发展到必定阶段，发现数据的使用杂乱无章，各类业务都是从原始数据直接计算而得。
• 各类重复计算，严重浪费了计算资源，须要优化性能。

2、文章结构

最初在作数据仓库的时候遇到了不少坑，因为自身资源有限，接触数据仓库的时候，感受在互联网行业里面的数据仓库成功经验不多，网上很难找到实践性比较强的资料。而那几本经典书籍里面又过于理论，折腾起来真是生不如死。还好如今过去了那个坎，所以多花一些时间整理本身的思路，帮助其余的小伙伴少踩一些坑。文章的结构以下：

• 为何要分层?这个问题被好几个同窗质疑过。所以分层的价值仍是要说清楚的。
• 分享一下经典的数据分层模型，以及每一层的数据的做用和如何加工得来。
• 分享两个数据分层的设计，经过这两个实际的例子来讲明每一层该怎么存数据。
• 给出一些建议，不是最好的，可是能够作参考。

0x01 为何要分层

咱们对数据进行分层的一个主要缘由就是但愿在管理数据的时候，能对数据有一个更加清晰的掌控，详细来说，主要有下面几个缘由：

• 清晰数据结构：每个数据分层都有它的做用域，这样咱们在使用表的时候能更方便地定位和理解。
• 数据血缘追踪：简单来说能够这样理解，咱们最终给业务诚信的是一能直接使用的张业务表，可是它的来源有不少，若是有一张来源表出问题了，咱们但愿可以快速准确地定位到问题，并清楚它的危害范围。
• 减小重复开发：规范数据分层，开发一些通用的中间层数据，可以减小极大的重复计算。
• 把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。并且便于维护数据的准确性，当数据出现问题以后，能够不用修复全部的数据，只须要从有问题的步骤开始修复。
• 屏蔽原始数据的异常。
• 屏蔽业务的影响，没必要改一次业务就须要从新接入数据。

数据体系中的各个表的依赖就像是电线的流向同样，咱们都但愿它是规整、流向清晰、便于管理的，以下图：

可是，最终的结果大多倒是依赖复杂、层级混乱，想梳理清楚一张表的声称途径会比较困难，以下图：

0x02 怎样分层

1、理论

咱们从理论上来作一个抽象，能够把数据仓库分为下面三个层，即：数据运营层、数据仓库层和数据产品层。

• ODS 全称是 Operational Data Store，操做数据存储.“面向主题的”，数据运营层，也叫ODS层，是最接近数据源中数据的一层，数据源中的数据，通过抽取、洗净、传输，也就说传说中的 ETL 以后，装入本层。本层的数据，整体上大可能是按照源头业务系统的分类方式而分类的。可是，这一层面的数据却不等同于原始数据。在源数据装入这一层时，要进行诸如去噪(例若有一条数据中人的年龄是 300 岁，这种属于异常数据，就须要提早作一些处理)、去重(例如在我的资料表中，同一 ID 却有两条重复数据，在接入的时候须要作一步去重)、字段命名规范等一系列操做。
• 数据仓库层(DW)，是数据仓库的主体.在这里，从 ODS 层中得到的数据按照主题创建各类数据模型。这一层和维度建模会有比较深的联系，能够多参考一下前面的几篇文章。
• 数据产品层(APP)，这一层是提供为数据产品使用的结果数据

在这里，主要是提供给数据产品和数据分析使用的数据，通常会存放在 ES、Mysql 等系统中供线上系统使用，也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。

如咱们常常说的报表数据，或者说那种大宽表，通常就放在这里。

2、技术实践

这三层技术划分，相对来讲比较粗粒度，后面咱们会专门细分一下。在此以前，先聊一下每一层的数据通常都是怎么流向的。这里仅仅简单介绍几个经常使用的工具，侧重中开源界主流。

1. 数据来源层→ ODS层

这里其实就是咱们如今大数据技术发挥做用的一个主要战场。 咱们的数据主要会有两个大的来源：

业务库，这里常常会使用 Sqoop 来抽取，好比咱们天天定时抽取一次。在实时方面，能够考虑用 Canal 监听 Mysql 的 Binlog，实时接入便可。

埋点日志，线上系统会打入各类日志，这些日志通常以文件的形式保存，咱们能够选择用 Flume 定时抽取，也能够用用 Spark Streaming 或者 Storm 来实时接入，固然，Kafka 也会是一个关键的角色。

其它数据源会比较多样性，这和具体的业务相关，再也不赘述。

注意： 在这层，理应不是简单的数据接入，而是要考虑必定的数据清洗，好比异常字段的处理、字段命名规范化、时间字段的统一等，通常这些很容易会被忽略，可是却相当重要。特别是后期咱们作各类特征自动生成的时候，会十分有用。后续会有文章来分享。

2. ODS、DW → App层

这里面也主要分两种类型：

1. 每日定时任务型：好比咱们典型的日计算任务，天天凌晨算前一天的数据，早上起来看报表。 这种任务常用 Hive、Spark 或者生撸 MR 程序来计算，最终结果写入 Hive、Hbase、Mysql、Es 或者 Redis 中。
2. 实时数据：这部分主要是各类实时的系统使用，好比咱们的实时推荐、实时用户画像，通常咱们会用 Spark Streaming、Storm 或者 Flink 来计算，最后会落入 Es、Hbase 或者 Redis 中。

0x03 举个例子

网上的例子不少，就不列了，只举个笔者早期参与设计的数据分层例子。分析一下当初的想法，以及这种设计的缺陷。上原图和内容。

当初的设计总共分了 6 层，其中去掉元数据后，还有5层。下面分析一下当初的一个设计思路。

缓冲层(buffer)

• 概念：又称为接口层(stage)，用于存储天天的增量数据和变动数据，如Canal接收的业务变动日志。
• 数据生成方式：直接从kafka接收源数据，须要业务表天天生成update,delete,inseret数据，只生成insert数据的业务表，数据直接入明细层
• 讨论方案：只把canal日志直接入缓冲层，若是其它有拉链数据的业务，也入缓冲层。
• 日志存储方式：使用impala外表，parquet文件格式，方便须要MR处理的数据读取。
• 日志删除方式：长久存储，可只存储最近几天的数据。讨论方案：直接长久存储
• 表schema：通常按天建立分区
• 库与表命名。库名：buffer,表名：初步考虑格式为：buffer日期业务表名,待定。

明细层(ODS, Operational Data Store,DWD: data warehouse detail)

• 概念：是数据仓库的细节数据层，是对STAGE层数据进行沉淀，减小了抽取的复杂性，同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式，将各个专业数据进行集中，明细层跟stage层的粒度一致，属于分析的公共资源
• 数据生成方式：部分数据直接来自kafka，部分数据为接口层数据与历史数据合成。

canal日志合成数据的方式待研究。

• 讨论方案：canal数据的合成方式为：天天把明细层的前天全量数据和昨天新数据合成一个新的数据表，覆盖旧表。同时使用历史镜像，按周/按月/按年 存储一个历史镜像到新表。
• 日志存储方式：直接数据使用impala外表，parquet文件格式，canal合成数据为二次生成数据，建议使用内表，下面几层都是从impala生成的数据，建议都用内表+静态/动态分区。
• 日志删除方式：长久存储。
• 表schema：通常按天建立分区，没有时间概念的按具体业务选择分区字段。
• 库与表命名。库名：ods,表名：初步考虑格式为ods日期业务表名,待定。
• 旧数据更新方式：直接覆盖

轻度汇总层(MID或DWB, data warehouse basis)

• 概念：轻度汇总层数据仓库中DWD层和DM层之间的一个过渡层次，是对DWD层的生产数据进行轻度综合和汇总统计(能够把复杂的清洗，处理包含，如根据PV日志生成的会话数据)。轻度综合层与DWD的主要区别在于两者的应用领域不一样，DWD的数据来源于生产型系统，并未满意一些不可预见的需求而进行沉淀;轻度综合层则面向分析型应用进行细粒度的统计和沉淀
• 数据生成方式：由明细层按照必定的业务需求生成轻度汇总表。明细层须要复杂清洗的数据和须要MR处理的数据也通过处理后接入到轻度汇总层。
• 日志存储方式：内表，parquet文件格式。
• 日志删除方式：长久存储。
• 表schema：通常按天建立分区，没有时间概念的按具体业务选择分区字段。
• 库与表命名。库名：dwb,表名：初步考虑格式为：dwb日期业务表名,待定。
• 旧数据更新方式：直接覆盖

主题层(DM，data market或DWS, data warehouse service)

• 概念：又称数据集市或宽表。按照业务划分，如流量、订单、用户等，生成字段比较多的宽表，用于提供后续的业务查询，OLAP分析，数据分发等。
• 数据生成方式：由轻度汇总层和明细层数据计算生成。
• 日志存储方式：使用impala内表，parquet文件格式。
• 日志删除方式：长久存储。
• 表schema：通常按天建立分区，没有时间概念的按具体业务选择分区字段。
• 库与表命名。库名：dm,表名：初步考虑格式为：dm日期业务表名,待定。
• 旧数据更新方式：直接覆盖

应用层(App)

• 概念：应用层是根据业务须要，由前面三层数据统计而出的结果，能够直接提供查询展示，或导入至Mysql中使用。
• 数据生成方式：由明细层、轻度汇总层，数据集市层生成，通常要求数据主要来源于集市层。
• 日志存储方式：使用impala内表，parquet文件格式。
• 日志删除方式：长久存储。
• 表schema：通常按天建立分区，没有时间概念的按具体业务选择分区字段。
• 库与表命名。库名：暂定apl，另外根据业务不一样，不限定必定要一个库。
• 旧数据更新方式：直接覆盖。

0x04 如何更优雅一些

前面提到的一种设计其实相对来说已经很详细了，可是可能层次会有一点多，并且在区分一张表到底该存放在什么位置的时候可能还有不小的疑惑。咱们在这一章里再设计一套数据仓库的分层，同时在前面的基础上加上维表和一些临时表的考虑，来让咱们的方案更优雅一些。

下图，作了一些小的改动，咱们去掉了上一节的Buffer层，把数据集市层和轻度汇总层放在同一个层级上，同时独立出来了维表和临时表。

这里解释一下DWS、DWD、DIM和TMP的做用。

• DWS：轻度汇总层，从ODS层中对用户的行为作一个初步的汇总，抽象出来一些通用的维度：时间、ip、id，并根据这些维度作一些统计值，好比用户每一个时间段在不一样登陆ip购买的商品数等。这里作一层轻度的汇总会让计算更加的高效，在此基础上若是计算仅7天、30天、90天的行为的话会快不少。咱们但愿80%的业务都能经过咱们的DWS层计算，而不是ODS。
• DWD：这一层主要解决一些数据质量问题和数据的完整度问题。好比用户的资料信息来自于不少不一样表，并且常常出现延迟丢数据等问题，为了方便各个使用方更好的使用数据，咱们能够在这一层作一个屏蔽。
• DIM：这一层比较单纯，举个例子就明白，好比国家代码和国家名、地理位置、中文名、国旗图片等信息就存在DIM层中。
• TMP：每一层的计算都会有不少临时表，专设一个DWTMP层来存储咱们数据仓库的临时表。

0x05 问答

有朋友问了一些问题，有一些以前的确没讲清楚，补到这里。

问答一： dws 和 dwd 的关系

问：dws 和dwd 是并行而不是前后顺序?

答：并行的，dw 层

问：那其实对于同一个数据，这两个过程是串行的?

答：dws 会作汇总，dwd 和 ods 的粒度相同，这两层之间也没有依赖的关系

问：对呀，那这样 dws 里面的汇总没有通过数据质量和完整度的处理，或者单独作了这种质量相关的处理，为何不在 dwd 之上再作汇总呢?个人疑问其实就是，dws的轻度汇总数据结果，有没有作数据质量的处理?

答：ods 直接到 dws 就好，不必过 dwd，我举个例子，你的浏览商品行为，我作一层轻度汇总，就直接放在 dws 了。可是你的资料表，要从好多表凑成一份，咱们从四五份我的资料表中凑出来了一份完整的资料表放在了 dwd 中。而后在 app 层，咱们要出一张画像表，包含用户资料和用户近一年的行为，咱们就直接从dwd中拿资料， 而后再在 dws 的基础上作一层统计，就成一个app表了。固然，这不是绝对，dws 和 dwd 有没有依赖关系主要看有没有这种需求。

问答二： ods 和 dwd 的区别

问：仍是不太明白 ods 和 dwd 层的区别，有了 ods 层后感受 dwd 没有什么用了。

答：嗯，我是这样理解的，站在一个理想的角度来说，若是 ods 层的数据就很是规整，基本能知足咱们绝大部分的需求，这固然是好的，这时候 dwd 层其实也没太大必要。 可是现实中接触的状况是 ods 层的数据很难保证质量，毕竟数据的来源多种多样，推送方也会有本身的推送逻辑，在这种状况下，咱们就须要经过额外的一层 dwd 来屏蔽一些底层的差别。

问：我大概明白了，是否是说 dwd 主要是对 ods 层作一些数据清洗和规范化的操做，dws 主要是对 ods 层数据作一些轻度的汇总?

答：对的，能够大体这样理解。

问答三：app 层是干什么的?

问：感受数据集市层是否是没地方放了，各个业务的数据集市表是应该在 dwd 仍是在 app?

答：这个问题不太好回答，我感受主要就是明确一下数据集市层是干什么的，若是你的数据集市层放的就是一些能够供业务方使用的宽表表，放在 app 层就行。若是你说的数据集市层是一个比较泛一点的概念，那么其实 dws、dwd、app 这些合起来都算是数据集市的内容。

问：那存到 Redis、ES 中的数据算是 app层吗?

答：算是的，我我的的理解，app 层主要存放一些相对成熟的表，能供业务侧使用的。这些表能够在 Hive 中，也能够是从 Hive 导入 Redis 或者 ES 这种查询性能比较好的系统中。

0xFF 总结

数据分层是数据仓库很是重要的一个环节，它决定的不只仅是一个层次的问题，还直接影响到血缘分析、特征自动生成、元数据管理等一系列功能的建设。所以适于尽早考虑。

另外，每一层的名字没必要太过在乎，本身按照喜爱就好。

本文分享了笔者本身对数据仓库的一些理解和想法，不必定准确也不必定通用，可是能够做为一个参考的思路。有什么问题欢迎多交流。