数据仓库分层设计

最近在做数据仓库相关的工作，项目快要收尾了，总结下数据仓库数据分层设计的一些心得；虽然以前做过很多olap相关的工作，就像流量统计分析这种，这种类型分析，我们往往就弄一张大宽表和几张维度表；所有的统计分析都基于这张大宽表与维度表，在这种简单的应用场景，这种设计倒没有什么问题，简单明了；但是如果业务场景复杂，数据种类多，维度多，那数据仓库的设计就尤为重要，特别是在数据出了问题情况下，要进行排查，结构清晰明了的数据仓库设计将大有裨益，废话不多说直接上图

ODS原始数据

这里的原始数据来源有两部分：hdfs和mysql

mysql中的数据，数据量大的表我们会按天归档到hdfs上，数据量少的就直接使用，我们的计算引擎使用的是presto，支持hive表和mysql表关联这种跨数据源查询；presto跨数据源的这种特性，使得我们在mysql归档到hdfs的工作十分高效简单,大多数情况下也就是一条sql

insert hive.catalog.hivetable select * from mysql.db.tablename where id>111

之前导过订单从库，几千万的数据走id索引归档导hdfs，也就十几分钟的事，这种工作最好在夜间访问量低的时候做；刚开始的时候你可能需要全表导一次，之后就是每天增量导入对应的分区里。这里的数据不会存储太久，一个月或者几个月，没有硬性规定，为了方便追溯问题，尽量保存时间不要太短

DWD明细视图，拉链表

这一层的数据依赖于ODS层，在这一层我们会做一些过滤，转换，剔除脏数据的工作，当然还有一点非常重要的就是做拉链表；为什么要做拉链表？ODS数据有部分是来源mysql，mysql中的数据是时刻会变化的，今天导入到hdfs中的数据，明天就会发生变化，这个是不可避免的，具体怎么做，可以参照下面这个链接
https://blog.csdn.net/zhaodedong/article/details/54177686
其实如果你不需要知道数据的变化历史，而且数据量也不是特别大的话，增量数据也不是特别多的话（例如十几万）完全可以每次导全表；这里的数据需要永久存储的

维度建模

维度建模，数据拆分成事实表和维度表，这里不多说，参照
https://www.cnblogs.com/muchen/p/5310732.html

写的很赞，找不到第二篇更好的了，推荐多读几遍

DM宽表，数据视图，数据集市

这个叫啥的都有，但说到底，就是把同种类别的数据组合起来，做成每种业务做成一张大宽表，方便业务快速生成报表，通常会做成视图

APP应用层

这个就是最终展示给用户看的报表，通常都是聚合存储在mysql

表命名规范

数据层_bussiness_分区类别|视图
或者
bussiness_分区类别|视图_数据层

ods_bussiness_day
dwd_bussiness_month
dm_bussiness_view
或者
bussiness_day_ods
bussiness_day_dwd
bussiness_day_view

我们这边采用的是前者，各有优劣

小看法

关于数据仓库个人的一些粗俗看法：数据分层没有严格的规则，只要你做到以下几点，怎么分都可以

• 处理好数据变化问题，保证数据和原始数据保持一致，减少数据冗余
• 快速支撑报表生成，数据清晰易懂
• 快速定位问题，数据尽量做到小改动，或者不动

而且数据仓库为什么这么分，往往都是随着业务发展不断演变而来的。
数据仓库设计写的有什么不对的地方，大家多指正

参考

• https://blog.csdn.net/zhaodedong/article/details/54177686
• http://tech.weli.cn/2017/12/29/dataware-intro/
• https://blog.csdn.net/u010454030/article/details/74589791