一、文章主题
本文主要讲解数据仓库的一个重要环节:如何设计数据分层!其它关于数据仓库的内容可参考之前的文章。
本文对数据分层的讨论适合下面一些场景,超过该范围场景 or 数据仓库经验丰富的大神就不必浪费时间看了。
- 数据建设刚起步,大部分的数据经过粗暴的数据接入后就直接对接业务。
- 数据建设发展到一定阶段,发现数据的使用杂乱无章,各种业务都是从原始数据直接计算而得。
- 各种重复计算,严重浪费了计算资源,需要优化性能。
二、文章结构
最初在做数据仓库的时候遇到了很多坑,由于自身资源有限,接触数据仓库的时候,感觉在互联网行业里面的数据仓库成功经验很少,网上很难找到实践性比较强的资料。而那几本经典书籍里面又过于理论,折腾起来真是生不如死。还好现在过去了那个坎,因此多花一些时间整理自己的思路,帮助其他的小伙伴少踩一些坑。文章的结构如下:
- 为什么要分层?这个问题被好几个同学质疑过。因此分层的价值还是要说清楚的。
- 分享一下经典的数据分层模型,以及每一层的数据的作用和如何加工得来。
- 分享两个数据分层的设计,通过这两个实际的例子来说明每一层该怎么存数据。
- 给出一些建议,不是最好的,但是可以做参考。
0x01 为什么要分层
我们对数据进行分层的一个主要原因就是希望在管理数据的时候,能对数据有一个更加清晰的掌控,详细来讲,主要有下面几个原因:
- 清晰数据结构:每一个数据分层都有它的作用域,这样我们在使用表的时候能更方便地定位和理解。
- 数据血缘追踪:简单来讲可以这样理解,我们最终给业务诚信的是一能直接使用的张业务表,但是它的来源有很多,如果有一张来源表出问题了,我们希望能够快速准确地定位到问题,并清楚它的危害范围。
- 减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算。
- 把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。而且便于维护数据的准确性,当数据出现问题之后,可以不用修复所有的数据,只需要从有问题的步骤开始修复。
- 屏蔽原始数据的异常。
- 屏蔽业务的影响,不必改一次业务就需要重新接入数据。
数据体系中的各个表的依赖就像是电线的流向一样,我们都希望它是规整、流向清晰、便于管理的,如下图:
但是,最终的结果大多却是依赖复杂、层级混乱,想梳理清楚一张表的声称途径会比较困难,如下图:
0x02 怎样分层
一、理论
我们从理论上来做一个抽象,可以把数据仓库分为下面三个