什么是数据分层，数据分层的作⽤!
⼤数据环境下该如何优雅地设计数据分层
0x00 前⾔
最近出现了好⼏次同样的对话场景：
问：你是做什么的？
答：最近在搞数据仓库。
问：哦，你是传统⾏业的吧，我是搞⼤数据的。
答：......
发个牢骚，搞⼤数据的也得建设数据仓库吧。⽽且不管是传统⾏业还是现在的互联⽹公司，都需要对数据仓库有⼀定的重视，⽽不是谈⼀句⾃⼰是搞⼤数据的就很厉害了。数据仓库更多代表的是⼀种对数据的管理和使⽤的⽅式，它是⼀整套包括了etl、调度、建模在内的完整的理论体系。现在所谓的⼤数据更多的是⼀种数据量级的增⼤和⼯具的上的更新。 两者并⽆冲突，相反，⽽是⼀种更好的结合。
话说，单纯⽤⽤Hadoop、Spark、Flume处理处理数据，其实只是学会⼏种新的⼯具，这是搞⼯具的，只是在数据仓库中etl中的⼀部分。
当然，技术的更新往往能领到⼀个时代的变⾰，⽐如Hadoop的诞⽣，光是深⼊研究⼀个⼤数据组件就要花很⼤的时间和精⼒。但是在热潮冷却之后，我们更应该考虑地是如何更好地管理和使⽤⾃⼰的数据。
对于数据的从业者来讲，要始终重视紧跟技术的变⾰，但是切记数据为王，在追求技术的极致的时候，不要忘了我们是搞数据的。
⽂章主题
本⽂对数据分层的讨论适合下⾯⼀些场景，超过该范围场景 or 数据仓库经验丰富的⼤神就不必浪费时间看了。
数据建设刚起步，⼤部分的数据经过粗暴的数据接⼊后就直接对接业务。
数据建设发展到⼀定阶段，发现数据的使⽤杂乱⽆章，各种业务都是从原始数据直接计算⽽得。
各种重复计算，严重浪费了计算资源，需要优化性能。
⽂章结构
最初在做数据仓库的时候遇到了很多坑，由于⾃⾝资源有限，接触数据仓库的时候，感觉在互联⽹⾏业⾥⾯的数据仓库成功经验很少，⽹上很难找到⽐较实践性强的资料。⽽那⼏本经典书籍⾥⾯⼜过于理论，折腾起来真是⽣不如死。还好现在过去了那个坎，因此多花⼀些时间整理⾃⼰的思路，帮助其他的⼩伙伴少踩⼀些坑。
1. 为什么要分层？这个问题被好⼏个同学质疑过。因此分层的价值还是要说清楚的。
2. 分享⼀下经典的数据分层模型，以及每⼀层的数据的作⽤和如何加⼯得来。
3. 分享两个数据分层的设计，通过这两个实际的例⼦来说明每⼀层该怎么存数据。
4. 给出⼀些建议，不是最好的，但是可以做参考。
0x01 为什么要分层
我们对数据进⾏分层的⼀个主要原因就是希望在管理数据的时候，能对数据有⼀个更加清晰的掌控，详细来讲，主要有下⾯⼏个原因：
1. 清晰数据结构：每⼀个数据分层都有它的作⽤域，这样我们在使⽤表的时候能更⽅便地定位和理解。
2. 数据⾎缘追踪：简单来讲可以这样理解，我们最终给业务诚信的是⼀能直接使⽤的张业务表，但是它的来源有很多，如果有⼀张来源
表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。
3. 减少重复开发：规范数据分层，开发⼀些通⽤的中间层数据，能够减少极⼤的重复计算。
4. 把复杂问题简单化。讲⼀个复杂的任务分解成多个步骤来完成，每⼀层只处理单⼀的步骤，⽐较简单和容易理解。⽽且便于维护数据
的准确性，当数据出现问题之后，可以不⽤修复所有的数据，只需要从有问题的步骤开始修复。
5. 屏蔽原始数据的异常。
6. 屏蔽业务的影响，不必改⼀次业务就需要重新接⼊数据。
数据体系中的各个表的依赖就像是电线的流向⼀样，我们都希望它是很规整，便于管理的。但是，最终的结果⼤多是第⼀幅图，⽽⾮第⼆幅图。
0x02 怎样分层
理论
我们从理论上来做⼀个抽象，可以把数据仓库分为下⾯三个层，即：数据运营层、数据仓库层和数据产品层。
1. ODS全称是Operational Data Store，操作数据存储
“⾯向主题的”，数据运营层，也叫ODS层，是最接近数据源中数据的⼀层，数据源中的数据，经过抽取、洗净、传输，也就说传说中的ETL之后，装⼊本层。本层的数据，总体上⼤多是按照源头业务系统的分类⽅式⽽分类的。
例如这⼀层可能包含的数据表为：⼈⼝表（包含每个⼈的⾝份证号、姓名、住址等）、机场登机记录（包含乘机⼈⾝份证号、航班号、乘机⽇期、起飞城市等）、银联的刷卡信息表（包含银⾏卡号、刷卡地点、刷卡时间、刷卡⾦额等）、银⾏账户表（包含银⾏卡号、持卡⼈⾝份证号等）等等⼀系列原始的业务数据。这⾥我们可以看到，这⼀层⾯的数据还具有鲜明的业务数据库的特征，甚⾄还具有⼀定的关系数据库中的数据范式的组织形式。
但是，这⼀层⾯的数据却不等同于原始数据。在源数据装⼊这⼀层时，要进⾏诸如去噪（例如去掉明
显偏离正常⽔平的银⾏刷卡信息）、去重（例如银⾏账户信息、公安局⼈⼝信息中均含有⼈的姓名，但是只保留⼀份即可）、提脏（例如有的⼈的银⾏卡被盗刷，在⼗分钟内同时有两笔分别在中国和⽇本的刷卡信息，这便是脏数据）、业务提取、单位统⼀、砍字段（例如⽤于⽀撑前端系统⼯作，但是在数据挖掘中不需要的字段）、业务判别等多项⼯作。
2. 数据仓库层(DW)，是数据仓库的主体
在这⾥，从ODS层中获得的数据按照主题建⽴各种数据模型。例如以研究⼈的旅游消费为主题的数据集中，便可以结合航空公司的登机出⾏信息，以及银联系统的刷卡记录，进⾏结合分析，产⽣数据集。在这⾥，我们需要了解四个概念：维（dimension）、事实（Fact）、指标（Index）和粒度（ Granularity）。
3. 数据产品层（APP），这⼀层是提供为数据产品使⽤的结果数据
在这⾥，主要是提供给数据产品和数据分析使⽤的数据，⼀般会存放在es、mysql等系统中供线上系统使⽤，也可能会存在Hive或者Druid 中供数据分析和数据挖掘使⽤。
⽐如我们经常说的报表数据，或者说那种⼤宽表，⼀般就放在这⾥。
技术实践
这三层技术划分，相对来说⽐较粗粒度，后⾯我们会专门细分⼀下。在此之前，先聊⼀下每⼀层的数据⼀般都是怎么流向的。这⾥仅仅简单介绍⼏个常⽤的⼯具，侧重中开源界主流。
1. 数据来源层--> ODS层
这⾥其实就是我们现在⼤数据技术发挥作⽤的⼀个主要战场。 我们的数据主要会有两个⼤的来源：
1. 业务库，这⾥经常会使⽤sqoop来抽取，⽐如我们每天定时抽取⼀次。在实时⽅⾯，可以考虑⽤canal监听mysql的binlog，实时接⼊
即可。
2. 埋点⽇志，线上系统会打⼊各种⽇志，这些⽇志⼀般以⽂件的形式保存，我们可以选择⽤flume定时抽取，也可以⽤⽤spark
howsoon
streaming或者storm来实时接⼊，当然，kafka也会是⼀个关键的⾓⾊。
3. 其它数据源会⽐较多样性，这和具体的业务相关，不再赘述。
注意： 在这层，理应不是简单的数据接⼊，⽽是要考虑⼀定的数据清洗，⽐如异常字段的处理、字段
命名规范化、时间字段的统⼀等，⼀般这些很容易会被忽略，但是却⾄关重要。特别是后期我们做各种特征⾃动⽣成的时候，会⼗分有⽤。后续会有⽂章来分享。
2. ODS、DW --> App层
这⾥⾯也主要分两种类型：
1. 每⽇定时任务型：⽐如我们典型的⽇计算任务，每天凌晨算前⼀天的数据，早上起来看报表。 这种任务经常使⽤Hive、Spark或者⽣
撸MR程序来计算，最终结果写⼊Hive、Hba、Mysql、Es或者Redis中。
2. 实时数据：这部分主要是各种实时的系统使⽤，⽐如我们的实时推荐、实时⽤户画像，⼀般我们会⽤Spark Streaming、Storm或者
Flink来计算，最后会落⼊Es、Hba或者Redis中。
0x03 举个例⼦
⽹上的例⼦很多，就不列了，只举个笔者早期参与设计的数据分层例⼦。分析⼀下当初的想法，以及这种设计的缺陷。上原图。
此处@Ruby⼤神。现实是我只是个打酱油的。盗图、盗思想。
当初的设计总共分了6层，其中去掉元数据后，还有5层。下⾯分析⼀下当初的⼀个设计思路。
** 缓冲层(buffer) **
概念：⼜称为接⼝层（stage），⽤于存储每天的增量数据和变更数据，如Canal接收的业务变更⽇志。
china china
数据⽣成⽅式：直接从kafka接收源数据，需要业务表每天⽣成update,delete,inret数据，只⽣成inrt数据的业务表，数据直接⼊明细层
讨论⽅案：只把canal⽇志直接⼊缓冲层，如果其它有拉链数据的业务，也⼊缓冲层。
⽇志存储⽅式：使⽤impala外表，parquet⽂件格式，⽅便需要MR处理的数据读取。
⽇志删除⽅式：长久存储，可只存储最近⼏天的数据。讨论⽅案：直接长久存储
表schema：⼀般按天创建分区
库与表命名。库名：buffer，表名：初步考虑格式为：buffer_⽇期_业务表名，待定。
caption是什么意思
明细层（ODS, Operational Data Store,DWD: data warehou detail）
概念：是数据仓库的细节数据层，是对STAGE层数据进⾏沉淀，减少了抽取的复杂性，同时ODS/DWD的信息模型组织主要遵循企业业务事务处理的形式，将各个专业数据进⾏集中，明细层跟stage层的粒度⼀致，属于分析的公共资源
数据⽣成⽅式：部分数据直接来⾃kafka，部分数据为接⼝层数据与历史数据合成。
canal⽇志合成数据的⽅式待研究。
讨论⽅案：canal数据的合成⽅式为：每天把明细层的前天全量数据和昨天新数据合成⼀个新的数据表，覆盖旧表。同时使⽤历史镜像，按周/按⽉/按年 存储⼀个历史镜像到新表。
⽇志存储⽅式：直接数据使⽤impala外表，parquet⽂件格式，canal合成数据为⼆次⽣成数据，建议使⽤内表，下⾯⼏层都是从impala⽣成的数据，建议都⽤内表+静态/动态分区。
⽇志删除⽅式：长久存储。
表schema：⼀般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名。库名：ods，表名：初步考虑格式为ods_⽇期_业务表名，待定。no smoking
旧数据更新⽅式：直接覆盖
轻度汇总层(MID或DWB, data warehou basis)
概念：轻度汇总层数据仓库中DWD层和DM层之间的⼀个过渡层次，是对DWD层的⽣产数据进⾏轻度综合和汇总统计（可以把复杂的清洗，处理包含，如根据PV⽇志⽣成的会话数据）。轻度综合层与DWD的主要区别在于⼆者的应⽤领域不同，DWD的数据来源于⽣产型系统，并未满意⼀些不可预见的需求⽽进⾏沉淀；轻度综合层则⾯向分析型应⽤进⾏细粒度的统计和沉淀
数据⽣成⽅式：由明细层按照⼀定的业务需求⽣成轻度汇总表。明细层需要复杂清洗的数据和需要MR处理的数据也经过处理后接⼊到轻度汇总层。
⽇志存储⽅式：内表，parquet⽂件格式。
⽇志删除⽅式：长久存储。
表schema：⼀般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名。库名：dwb，表名：初步考虑格式为：dwb_⽇期_业务表名，待定。
fighting意思
旧数据更新⽅式：直接覆盖
主题层（DM，date market或DWS, data warehou rvice）
概念：⼜称数据集市或宽表。按照业务划分，如流量、订单、⽤户等，⽣成字段⽐较多的宽表，⽤于提供后续的业务查询，OLAP分析，数据分发等。
数据⽣成⽅式：由轻度汇总层和明细层数据计算⽣成。
⽇志存储⽅式：使⽤impala内表，parquet⽂件格式。
⽇志删除⽅式：长久存储。
表schema：⼀般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名。库名：dm，表名：初步考虑格式为：dm_⽇期_业务表名，待定。
旧数据更新⽅式：直接覆盖
应⽤层(App)
概念：应⽤层是根据业务需要，由前⾯三层数据统计⽽出的结果，可以直接提供查询展现，或导⼊⾄Mysql中使⽤。
数据⽣成⽅式：由明细层、轻度汇总层，数据集市层⽣成，⼀般要求数据主要来源于集市层。
哈尔滨pm2 5⽇志存储⽅式：使⽤impala内表，parquet⽂件格式。
英语4级报名时间
⽇志删除⽅式：长久存储。
表schema：⼀般按天创建分区，没有时间概念的按具体业务选择分区字段。
库与表命名。库名：暂定apl，另外根据业务不同，不限定⼀定要⼀个库。
旧数据更新⽅式：直接覆盖
0x04 如何更优雅⼀些
前⾯提到的⼀种设计其实相对来讲已经很详细了，但是可能层次会有⼀点点多，⽽且在区分⼀张表到底该存放在什么位置的时候可能还有⼀点点疑惑。 我们在这⼀章⾥再设计⼀套数据仓库的分层，同时在前⾯的基础上加上维表和⼀些临时表的考虑，来让我们的⽅案更优雅⼀些。
下图，做了⼀些⼩的改动，我们去掉了上⼀节的Buffer层，把数据集市层和轻度汇总层放在同⼀个层级上，同时独⽴出来了维表和临时表。
这⾥解释⼀下DWS、DWD、DIM和TMP的作⽤。
DWS：轻度汇总层，从ODS层中对⽤户的⾏为做⼀个初步的汇总，抽象出来⼀些通⽤的维度：时间、ip、id，并根据这些维度做⼀些统计值，⽐如⽤户每个时间段在不同登录ip购买的商品数等。这⾥做⼀层轻度的汇总会让计算更加的⾼效，在此基础上如果计算仅7天、30天、90天的⾏为的话会快很多。我们希望80%的业务都能通过我们的DWS层计算，⽽不是ODS。
DWD：这⼀层主要解决⼀些数据质量问题和数据的完整度问题。⽐如⽤户的资料信息来⾃于很多不同表，⽽且经常出现延迟丢数据等问题，为了⽅便各个使⽤⽅更好的使⽤数据，我们可以在这⼀层做⼀个屏蔽。
triggerDIM：这⼀层⽐较单纯，举个例⼦就明⽩，⽐如国家代码和国家名、地理位置、中⽂名、国旗图⽚等信息就存在DIM层中。
TMP：每⼀层的计算都会有很多临时表，专设⼀个DWTMP层来存储我们数据仓库的临时表。
0x05 问答
有读者问了⼀些问题，是我之前有⼀些没讲清楚，补到这⾥。
问：dws和dwd是并⾏⽽不是先后顺序？
答：并⾏的，dw层
问：那其实对于同⼀个数据，这两个过程是串⾏的？
答：dws 会做汇总，dwd和ods的粒度相同，这两层之间也没有依赖的关系
长痛不如短痛问：对呀，那这样dws⾥⾯的汇总没有经过数据质量和完整度的处理，或者单独做了这种质量相关的处理，为什么不在dwd之上再做汇总呢？我的疑问其实就是，dws的轻度汇总数据结果，有没有做数据质量的处理？
答：ods 之间到dws就好 没必要过dwd，我举个例⼦，你的浏览商品⾏为，我做⼀层轻度汇总，就直接放在dws了。但是你的资料表，要从好多表凑成⼀份，我们从四五分个⼈资料表中 凑出来了⼀份完整的资料表放在了dwd中。然后在app层，我们要出⼀张画像表，包含⽤户资料和⽤户近⼀年的⾏为，我们就直接从dwd中拿资料， 然后再在dws的基础上做⼀层统计，就成⼀个app表了。
问：嗯，最后⼀个疑问，在现实⽣产中，可不可能存在计算dws时，会⽤到dwd表的情况？
答：不 这样依赖就混了，dws不会依赖dwd，dws直接轻度汇总，业务⽤的话都说app。
问：就是说，dwd针对的是对象，它的数据质量处理有点像对⽤户等等的实体信息的纠错和汇总；dws针对的是⾏为，可以在某些维度上上卷的⾏为~
答：你这样理解吧 dws存事实表，dwd 维度表。
0xFF 总结
数据分层是数据仓库⾮常重要的⼀个环节，它决定的不仅仅是⼀个层次的问题，还直接影响到后续的⾎缘分析、特征⾃动⽣成、元数据管理等⼀系列的建设。因此适于尽早考虑。triumphal arch
另外，每⼀层的名字不必太过在意，⾃⼰按照喜好就好。
本⽂分享了笔者⾃⼰对数据仓库的⼀些理解和想法，不⼀定⼗分准确，有什么问题可以多交流。
初步估计在数据仓库⽅⾯，应该还会有三个主题分享：⾎缘分析、特征⾃动⽣成、元数据管理。分享完成之后，数据仓库相关的就告⼀段落了。
参考
《数据仓库》
《数据仓库⼯具箱》
Winston、Ruby的指导
转载⾄
