vlambda博客
学习文章列表

数据仓库分层模型【数据仓库系列07】

(一)写在前面的话


数据仓库中,我们常听到要做分层计算,包括ads、dwd、dws、ads、dim,那为什么要这么区分,有什么意义?今天就来好好讲述一下。


(二)传统意义上的数据分成


在2012年前后,早期的大数据平台是以Hadoop为核心,数据开发也是以MapReduce为主,Hive等sql类开发极少应用。因此当数据从多个源头采集上来之后,格式化便成为了原始数据。原始数据经过MR的开发之后,生成了各个报表数据,然后统一导入到Mysql或者Oracle平台之后,便可以直接看到报表。在数据量相对有限并且看数据的人较少的情况下,这种方式是非常高效并且实用的。开发结构图如下:



但是情况很快有了变化,别的部门在看到Hadoop的性能之后,放弃了原有编写的数据库存储过程,转而将逻辑应用了进来,这时候平台就不可以避免的膨胀了,各种逻辑杂糅使得逻辑变得模糊不清,这时候我们就需要做功能上的耦合了。这时候的平台长这个样子:



随后,你看着公司的规模一路飙升,数据团队也从几个人快速增长到了十几个人,架构也发生了更多的变化,这个时候你就意识到了,我们可能要有一套系统的理论来组织数据仓库了。


(三)标准分层图


笔者在进行季度汇报时使用过的一张图:


(四)各层涵义


ODS:通常而言,原始数据的种类是非常丰富的,我们可能从几十个业务方把数据拉回来,然后格式化放到HDFS上。但很多时候,情况并不这么简单,虽然有很多的损坏数据、脏数据等是不需要统计的,但是我们需要来看为什么会产生脏数据,这时候原始数据就会提供很好的样板。再有些时候,针对一些流量作弊的数据,如果按照统一规则,很容易就给过滤掉了,然后运营就问过来为什么对方提供的数据与我们的差异这么多大,这时候同样需要去看原始日志。因而,ODS的意义,在于保存最完整的数据现场,便于一些特殊场景下的问题排查使用。


DWD:如果采集的数据没有问题了,我们这里就需要做数据的预处理了。通常情况下,预处理指将数据变成半格式化或者是格式化数据,例如存在HDFS上的标准格式,我们就用字符串的格式来统一存储。还有时候因为场景要求,需要直接转成Parquent等列存格式,也需要在这里做转换。但预处理并不是简单的转换格式,还需要处理一些脏数据,例如字段缺失、格式错误、乱码、空值,等等,在这一层处理好之后,后续的计算便不需要再担心各种各样的异常情况,对于开发效率的提升有着极大的帮助。有些时候还要发挥一些特定作用,因为业务的意外导致各种各样的错误数据进来,也是时有发生的。比如客户消费了,金额总得是正的吧,但如果业务那边产生了一些错误,需要将金额设置成负值,虽然业务那边好处理了,但数据这里就头疼了。所以还需要经常打一些补丁,来处理金额负值这种异常情况。还有各式各样的反作弊要求,也是需要在DWD进行处理的。所以看起来DWD像是多余的一层,但当业务场景足够复杂之后,它所发挥的作用还是很大的。这里数据预处理主要采用MR来进行,基本上遇不到数据倾斜等问题。


DWS:当所有的数据都存好了,处理完脏数据之后,下一步我们就需要考虑如何处理和组织统计逻辑了。数据仓库之所以叫数据仓库,正是因为DWS层的重要。数据模型有很多,如:范式模型、维度模型、Data Vault等,但最常用的还是星型模型。通常我们会根据主题来进行表数据的统计,这里还有一个常用的说法,叫“中间层”。例如我们数据层次自上往下分别是:用户、广告投放计划、计划详情,用户本身有行业、主体公司等属性,广告投放计划包括了单元、创意等属性,计划详情包括了投放类型、投放地域等属性。那么我们在这个DWS层,就需要针对所有可能的维度,包括用户、行业、主体公司、广告投放计划、单元、创意、计划详情、投放类型、投放地域做统计,每个类型都尽可能的冗余维度信息,例如用户维度的统计要把行业、主体公司等维度冗余进来,放到一张表里。这么做虽然特别违反三范式的原则,也违反很多模型,但是冗余尽可能多的信息,对于提高下游计算的速度、减少运算数据量、简化业务逻辑、合并计算单元等具有特别大的好处。当然困难也是显而易见的,计算速度慢、数据倾斜等问题也都基本上集中在这个DWS层上。可以说,这里设计好了,整个数据仓库的设计就成功了一半。


ADS:当需求足够多时,我们要提供的报表就不是几十张的概念了,而是成百上千张,这么多的表怎么保证数据的一致性呢?怎么保证需求响应的速度呢?基本上都是ADS层需要面临的问题。在前一个层次DWS中,我们把所有的主题都尽可能多的冗余了维度信息,因此这里需要尽量从单一中间层表中进行数据统计,中间层的数据一致性,就代表了最终业务数据的一致性。响应速度同理,在某些不得不关联的业务场景下,因为中间层的存在,使得数据量减少了很多,需求响应速度也就提升了很多。


DIM:维度信息,这里涉及到了元数据等概念,后续会进行详细介绍。


(五)面对的挑战


在数据分层理论中,尽管理解不是什么难事,但在实际应用中的技术挑战是非常大的。这里简单列几个:


1. 关联范围广:在很多时候,有些数据是需要跨多个业务线的,每个业务线的数据都很大,这时候不仅是计算逻辑复杂无比,一个SQL几百行,而且对于数据倾斜的问题挑战更大,Hive运算的时间也非常长。这种情况下需要适当考虑在运算节点中加入一些MR的运算过程,以提高计算速度,单纯的优化Hive SQL并不是一个好主意。


2. 血缘关系乱:尽管DWS是统计中间层的数据,但由于业务的变化多种多样,一个中间层需要关联几张甚至十几张表,每张表都有自身的业务逻辑,关联很多,这就导致了一张完整的中间表上游特别多,发现某个数据异常时非常难以追溯问题。这时候你需要额外的技术支持:元数据平台,通过分析这张表的上游关联关系,来进行问题的定位。元数据的问题等到后续再统一讲解。


3. 产出时间长:某些DWS表动辄需要几个小时的计算时间,对于数据的准时产出影响很大。同时如果需要做小时级的报表统计,那么太过于复杂的中间层设计就显得很累赘。建议这个过程有产品经理的介入,以梳理需求的重要性和优先级,如果非必要统计,尽量的就不要做中间层,开放一些sql查询的权限也是可以的,这里做好数据安全管理即可。


4. 重构难度大:分层理论尽管听上去容易理解,但真的需要到这个理论时,你所搭建的数据平台势必已经非常大了,而需要适应这套理论,原有的统计逻辑大多数都要重写,这里花上几个月的时间都是很常见的,并且很可能需要双平台同时进行数据计算,以渡过重构的不稳定期。这个阶段的挑战就是如何解释投入产出比,要有充分的的信心,详情这项工作完成后,节省的开发时间至少是一个数量级的。原来1天的开发工作,因为有了数据分层,1小时甚至几分钟,都是可以开发完的。


(六)扩展阅读:命名规则


我们在做Hive表时,如果表特别多,非常容易混乱,因此有需要进行命名方式的统一,以降低维护的复杂度。这时候,分层理论就有用了,例如一张每天统计的行业报表,是中间层,来自于A业务线,用于统计B的业务信息,表可以这样起名:DWS_A_B_DAY,看起来就清晰多了。当然可以设置的更复杂,基本的规则都是利用分层的思想,起个DWS_A_B_C_D_E_DAY也是可以的,不要怕名字长,就怕看不明白。


(七)写在最后的话


数据仓库的难度在于,你几乎不可能一开始就设计好,因为业务模式的多种多样,还有规模扩张带来的复杂性问题,是没谁能够预料到的。所以作为数据开发人,一开始就要有这个觉悟:我所写的代码,在不久的将来就要被重构。要记住的时,看得懂,比写的简单,更重要,或许今天省了功夫,但以后要补偿回来的,而且大概率是在下一个开发来接盘之前。