手把手教你数据仓库建设

来源:范钢 孙玄 数仓宝贝库 日期:2021-10-11

本文转载自微信公众号「数仓宝贝库」,作者范钢 孙玄 。转载本文请联系数仓宝贝库公众号。

前面部分是对数据的采集,然后经过ETL过程,最终存入数据仓库。这部分是通过一切手段收集数据,然而它的建设与数据应用需求无关。因为数据仓库存储的是过去数年的数据,而数据应用需求总是在变。如果数据应用需求一变化,就需要修改数据仓库的表结构,那么这数年的数据都必须要重新计算,系统就会始终处于一种十分不稳定的状态,维护成本极高。所以,只有数据仓库的建设与数据应用需求无关,才能保证需求变更对数据仓库没有影响,才能让系统稳定运行。

后面部分是根据不同的数据分析需求,从数据仓库中获取数据,完成各自的数据分析,将最终的分析结果写入数据集市。数据集市的建设是与各自的数据分析的需求息息相关的,每次需求变更时,变更的是各自的数据集市,而不是数据仓库。

01多维数据建模

经过前面一系列的ETL过程(什么是ETL?一文掌握ETL设计过程),我们最终将数据装载到数据仓库中。数据仓库是按照多维数据模型的思路进行建设的。在多维数据模型中,动态数据就转化为了事实表,静态数据就转化为了维度表。进项发票事实表、销项发票事实表都是事实表,但从其中关联出来了日期维度表、纳税人维度表、税务机关维度表、地域维度表与行业维度表。

多维数据模型的设计有两种思路:雪花模型与星形模型,如下图所示。

雪花模型与星形模型

左图是雪花模型的设计,它最大的特点是在维度表上还要关联维度表,如在纳税人维度表的基础上还要关联行业维度表。这样设计比较容易理解,但会造成频繁的join操作,在海量数据中降低查询性能。譬如,要对进项发票进行地域的统计,就需要将进项发票事实表与纳税人维度表相关联,再关联税务机关维度表、地域维度表,才能完成,这极大影响了系统性能。因此,为了提升查询性能,基于空间换时间的思想,我们又提出了星形模型。

右图是星形模型的设计,它最大的特点是不会再有维度与维度的关联,而是所有维度表都只与事实表关联。譬如对进项发票进行地域分析,只需要进项发票事实表关联地域维度表就可以了,在海量数据中的性能将得到极大的提升。

接着,在以上事实表的基础上,还可以从不同的维度与粒度对数据进行汇总,形成聚合表。譬如,对进项发票事实表按照行业进行汇总,或者按照地域进行汇总,形成“进项发票行业聚合表”与“进项发票地域聚合表”,等等。

以上的分析都是在“开票主题域”中进行的,但是按照业务流程,还有“申报主题域”“征收主题域”“稽查主题域”等,如下图所示。这样,数据中台就按照业务模块划分为了多个主题域,然后在各个主题域进行多维建模,形成数据仓库。但各个主题域可以拥有共同的维度表,如纳税人维度表、税务机关维度表等。

主题域模型

02数据中台的分层

数据中台的建设,除了按照主题域进行纵向划分,还要通过分层进行横向划分。数据中台通过分层,划分为原始数据层(STAGE)、细节数据层(ODS/DWD)、轻度综合层(MID/DWS)与数据集市层(DM),如下图所示。每一层的数据都存储在Hive数据库中,然后通过Schema划分出不同的层次。

数据中台的系统分层

最底层是原始数据层(STAGE)。所有的原始数据都在这里,通过Schema进行划分,来自哪个数据来源就存储在哪个Schema中,并且表名与原始库的表名一致。

接着是细节数据层(ODS/DWD),它是经过ETL过程以后导入数据仓库的事实表与维度表。ETL过程的中间临时表存入名为etl的Schema,数据仓库的事实表与维度表存入名为dw的Schema。同时,制订命名规范,事实表以dw_fact_xxx命名,如订单事实表dw_fact_order,维度表以dw_dim_xxx命名,如日期维度表dw_dim_date。

紧接着是轻度综合层(MID/DWS),它是在事实表的基础上按照不同维度与粒度形成的聚合表。聚合表以dw_agg_xxx命名,如进项发票按纳税人聚合表dw_agg_jxfp_nsr、进项发票按税务机关聚合表dw_agg_jxfp_swjg等。

最后,是在数据仓库之上的数据集市层(DM),它通过抽取前两层中的事实表与聚合表的数据,按照不同的用户需求进行数据分析,最后形成数据结果。数据集市既包括最终结果表,也包括中间结果表。数据集市以dw_dm_xxx命名,如“购车人未缴纳车辆购置税预警”属于“机动车消费税”分析模块,它需要计算出应免税数据dw_dm_jdcxfs_ms,然后计算出未缴税数据dw_dm_jdcxfs_wjs。大多数常规数据分析就是这样通过SparkSQL进行的。

    A+
声明:本文转载自其它媒体,转载目的在于传递更多信息,并不代表赞同其观点和对其真实性负责。