avatar

目录
数据仓库体系 - 简介(1)

数据仓库简介

数据仓库,英文名称为Data Warehouse,可简写为DW或DWH。数数据仓库是伴随着企业信息化发展起来的,在企业信息化的过程中,随着信息化工具的升级和新工具的应用,数据量变的越来越大,数据格式越来越多,决策要求越来越苛刻,数据仓库技术也在不停的发展。

数据仓库的趋势:

  • 实时数据仓库以满足实时化&自动化决策需求;
  • 大数据&数据湖以支持大量&复杂数据类型(文本、图像、视频、音频);

数据仓库的发展

数据仓库有两个环节:数据仓库的构建与数据仓库的应用。

早期数据仓库构建主要指的是把企业的业务数据库如ERP、CRM、SCM等数据按照决策分析的要求建模并汇总到数据仓库引擎中,其应用以报表为主,目的是支持管理层和业务人员决策(中长期策略型决策)。

随着业务和环境的发展,这两方面都在发生着剧烈变化。

  • 随着IT技术走向互联网、移动化,数据源变得越来越丰富,在原来业务数据库的基础上出现了非结构化数据,比如网站log,IoT设备数据,APP埋点数据等,这些数据量比以往结构化的数据大了几个量级,对ETL过程、存储都提出了更高的要求;
  • 互联网的在线特性也将业务需求推向了实时化,随时根据当前客户行为而调整策略变得越来越常见,比如大促过程中库存管理,运营管理等(即既有中远期策略型,也有短期操作型);同时公司业务互联网化之后导致同时服务的客户剧增,有些情况人工难以完全处理,这就需要机器自动决策。比如欺诈检测和用户审核。

总结来看,对数据仓库的需求可以抽象成两方面:实时或者离线产生结果、处理和保存大量异构数据。

数据仓库架构的演变

数据仓库概念是Inmon于1990年提出并给出了完整的建设方法。随着互联网时代来临,数据量暴增,开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代,架构上并没有根本的区别,可以把这个架构叫做离线大数据架构

后来随着业务实时性要求的不断提高,人们开始在离线大数据架构基础上加了一个加速层,使用流处理技术直接完成那些实时性要求较高的指标计算,这便是Lambda架构

再后来,实时的业务越来越多,事件化的数据源也越来越多,实时处理从次要部分变成了主要部分,架构也做了相应调整,出现了以实时事件处理为核心的Kappa架构

离线大数据架构

数据源通过离线的方式导入到离线数仓中。

下游应用根据业务需求选择直接读取DM或加一层数据服务,比如 Mysql 或 Redis。

数据仓库从模型层面分为三层:

  • ODS,操作数据层,保存原始数据;
  • DWD,数据仓库明细层,根据主题定义好事实与维度表,保存最细粒度的事实数据;
  • DM,数据集市/轻度汇总层,在DWD层的基础之上根据不同的业务需求做轻度汇总;
    传统数仓一般为Greenplum、Vertica、Oracle、Mysql,典型的大数据数仓存储是HDFS/Hive,ETL可以是MapReduce脚本或HiveSQL。
    UTOOLS1575599375193.png

Lambda架构

随着大数据应用的发展,人们逐渐对系统的实时性提出了要求,为了计算一些实时指标,就在原来离线数仓的基础上增加了一个实时计算的链路,并对数据源做流式改造(即把数据发送到消息队列),实时计算去订阅消息队列,直接完成指标增量的计算,推送到下游的数据服务中去,由数据服务层完成离线&实时结果的合并。

注:流处理计算的指标批处理依然计算,最终以批处理为准,即每次批处理计算后会覆盖流处理的结果。(这仅仅是流处理引擎不完善做的折中)

Lambda架构问题:

    1. 同样的需求需要开发两套一样的代码
      这是Lambda架构最大的问题,两套代码不仅仅意味着开发困难(同样的需求,一个在批处理引擎上实现,一个在流处理引擎上实现,还要分别构造数据测试保证两者结果一致),后期维护更加困难,比如需求变更后需要分别更改两套代码,独立测试结果,且两个作业需要同步上线。
    1. 资源占用增多:同样的逻辑计算两次,整体资源占用会增多(多出实时计算这部分)
      UTOOLS1575599525297.png

Kappa架构

Lambda架构虽然满足了实时的需求,但带来了更多的开发与运维工作,其架构背景是流处理引擎还不完善,流处理的结果只作为临时的、近似的值提供参考。后来随着Flink等流处理引擎的出现,流处理技术很成熟了,这时为了解决两套代码的问题,LickedIn 的Jay Kreps提出了Kappa架构

Kappa架构可以认为是Lambda架构的简化版(只要移除Lambda架构中的批处理部分即可)。

在Kappa架构中,需求修改或历史数据重新处理都通过上游重放完成。

Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理,但这个可以通过增加计算资源来弥补。
UTOOLS1575599612095.png

Kappa架构的重新处理过程

重新处理是人们对Kappa架构最担心的点,但实际上并不复杂:

    1. 选择一个具有重放功能的、能够保存历史数据并支持多消费者的消息队列,根据需求设置历史数据保存的时长,比如Kafka,可以保存全部历史数据。
    1. 当某个或某些指标有重新处理的需求时,按照新逻辑写一个新作业,然后从上游消息队列的最开始重新消费,把结果写到一个新的下游表中。
    1. 当新作业赶上进度后,应用切换数据源,读取2中产生的新结果表。
    1. 停止老的作业,删除老的结果表。

Lambda架构与Kappa架构的对比

对比项 Lambda架构 Kappa架构
实时性 实时 实时
计算资源 批和流同时运行,资源开销大 只有流处理,仅针对新需求开发阶段运行两个作业,资源开销小
重新计算时吞吐 批式全量处理,吞吐较高 流式全量处理,吞吐较批处理低
开发、测试 每个需求都需要两套不同代码,开发、测试、上线难度较大 只需实现一套代码,开发、测试、上线难度相对较小
运维成本 维护两套系统(引擎),运维成本大 只需维护一套系统(引擎),运维成本小

在真实的场景中,很多时候并不是完全规范的Lambda架构或Kappa架构,可以是两者的混合,比如大部分实时指标使用Kappa架构完成计算,少量关键指标(比如金额相关)使用Lambda架构用批处理重新计算,增加一次校对过程。

Kappa架构并不是中间结果完全不落地,现在很多大数据系统都需要支持机器学习(离线训练),所以实时中间结果需要落地对应的存储引擎供机器学习使用,另外有时候还需要对明细数据查询,这种场景也需要把实时明细层写出到对应的引擎中。

另外,随着数据多样性的发展,数据仓库这种提前规定schema的模式显得越来难以支持灵活的探索&分析需求,这时候便出现了一种数据湖技术,即把原始数据全部缓存到某个大数据存储上,后续分析时再根据需求去解析原始数据。简单的说,数据仓库模式是schema on write,数据湖模式是schema on read。
UTOOLS1575599925555.png

实时数仓与离线数仓的对比

实时数仓与离线数仓在几方面的对比:

首先,从架构上,实时数仓与离线数仓有比较明显的区别,实时数仓以Kappa架构为主,而离线数仓以传统大数据架构为主。Lambda架构可以认为是两者的中间态。

其次,从建设方法上,实时数仓和离线数仓基本还是沿用传统的数仓主题建模理论,产出事实宽表。另外实时数仓中实时流数据的join有隐藏时间语义,在建设中需注意。

最后,从数据保障看,实时数仓因为要保证实时性,所以对数据量的变化较为敏感。在大促等场景下需要提前做好压测和主备保障工作,这是与离线数据的一个较为明显的区别。

打赏
  • 微信
    微信
  • 支付宝
    支付宝

评论