数据仓库 - 数据分层

简述

在上篇博客‘数据仓库建模方法’中我们探讨过数据模型的相关问题,实际场景中,我们团队在确定了数据模型使用经典的星型模型和3NF之后,接下来要进行讨论的问题则是,每天大批量的数据,应该怎样的放进库中,怎么存放合理。在数据对接业务之前,要经过哪些提炼的过程,在整个提炼的过程中,要分成几个步骤,还是一步到位的直接从原始数据ETL给业务人员。


其中提到的这个提炼过程,也就是数据分层的过程,分层设计的好,数据分布合理,节约计算资源,避免多余的数据开发。所以,数据分层是数据仓库建设中,重要的一环。
各种重复计算,严重浪费了计算资源,需要优化性能。

为什么要数据分层

我们对数据进行分层的一个主要原因就是希望在管理数据的时候,能对数据有一个更加清晰的掌控,详细来讲,主要有下面几个原因:

  • 清晰数据结构:每一个数据分层都有它的作用域,这样我们在使用表的时候能更方便地定位和理解。

  • 数据血缘追踪:简单来讲可以这样理解,我们最终给业务诚信的是一能直接使用的张业务表,但是它的来源有很多,如果有一张来源表出问题了,我们希望能够快速准确地定位到问题,并清楚它的危害范围。

  • 减少重复开发:规范数据分层,开发一些通用的中间层数据,能够减少极大的重复计算。

  • 把复杂问题简单化。讲一个复杂的任务分解成多个步骤来完成,每一层只处理单一的步骤,比较简单和容易理解。而且便于维护数据的准确性,当数据出现问题之后,可以不用修复所有的数据,只需要从有问题的步骤开始修复。

  • 屏蔽原始数据的异常。

  • 屏蔽业务的影响,不必改一次业务就需要重新接入数据。

    怎么分层

    在这里,就拿我们团队对我们公司设计的数据仓库来举例。首先呢,我们公司的数据量级和数据主题复杂度,相当于一个二线互联网公司,数据主题目前这一版数据仓库可以分为用户行为,订单,游戏活动等7个主题数据,业务并不是很复杂。
    所以在数据分层上,总共分成三层。

  • 源数据层 (dw = staging)

  • 宽表数据层 (dw = dw)

  • 指标数据层 (dw = subjectName)


源数据层

源数据层拉取业务表有20张左右,使用spark读取底层RDBMS来获取数据,写入到Hive中,在这一层中,除了选择合适的分区字段,我们的分析业务中,时间粒度多为天为单位,业务数据来源于多个产品线,所以这一层,会以snapshot_date(‘YYYY-MM-DD’)和product_id为分区字段,对数据表进行分区外,不做任何数据处理,不做脏数据处理,不做合并,保持数据的原始性,随时可以做到追本溯源。


我们对于近源数据层的定位是可以”快速”的构建基础数据平台. 不做业务相关的处理可以让这部分的工作专注在大数据架构正确性和稳定性的问题,近源数据层出现以后, 实际上我们已经可以开始主要的数据分析工作了。

宽表数据层

宽表数据层的数据是从源数据层经过ETL字段清洗,计算并且相关主题表,维度表进行join而来的。例如订单表:Orders表
order_*为订单主题(order_id,order_number,order_amount,create_date…)
t_users_dim 用户维度表(user_id,city,last_login_time,device_type…)
t_activity_dim 活动维度表(activity_id,activity_name,create_date…)
t_promotion_dim 优惠维度表(promotion_id,promotion_name,promotion_type…)
t_deposit 充值表(deposit_id,deposit_type,channal,deposit_time…)
以上五张表经过相关键join就组成了订单宽表 如下图所示:
p2.png

指标数据层

指标数据层是从宽表数据层计算而来,这一层我们采用的策略是由总到分,关联时间维度表,缩小时间粒度到小时级别。可以对运营人员提供小时级别的数据指标。


对于一些金额相关数据表,也会经过计算添加一些常用的数据模型,例如某用户近20次充值的max值和min值,中位数,四分位数等字段。


这一层也是最不稳定的一层,经常要根据业务的变化增加字段或者新加指标数据表。由于的依赖Hive建设的数据仓库,那么对于增加字段的这件事,要小心对数据的影响,注意选择合适的Hive表格式。


这层就不画图了 有点困了 困了~~~~


这篇数据仓库数据分层设计,是根据我们公司的业务数据和主题来设计的,也是我们大数据工程团队的这几个渣渣工程师和架构师一起商讨的结果方案,对于其他行业和大规模海量数据肯定是不能全部适用的。在写这篇文章前,我有看过美团技术团队美团点评酒旅数据仓库建设实践这篇文章,发现业务复杂度和数据规模对数据建模和数据分层的影响很大,像我们公司的数据量量级要完全按照美团数仓去做,是完全没有必要的,而且会弄的更加复杂,所以在这里想表明的就是,对于数仓的建设,要选择适合自己的,对自己量身定制,照搬某个公司的,是没有意义的,反而可能会增加使用的难度。