@Author : Spinach | GHB
@Link : http://blog.csdn.net/bocai8058
前言
通过收集资料、个人经验总结整理了【数据仓库系列篇】,有不足之处多多包涵,可参考如下:
《数据仓库系列篇之基本概述》
《数据仓库系列篇之分层思想》
《数据仓库系列篇之管理规范》
《数据仓库系列篇之实现架构》
架构历史演变
数据仓库概念是Inmon于1990年提出并给出了完整的建设方法。随着互联网时代来临,数据量暴增,开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代,架构上并没有根本的区别,可以把这个架构叫做离线大数据架构。
后来随着业务实时性要求的不断提高,人们开始在离线大数据架构基础上加了一个加速层,使用流处理技术直接完成那些实时性要求较高的指标计算,这便是Lambda架构。再后来,实时的业务越来越多,事件化的数据源也越来越多,实时处理从次要部分变成了主要部分,架构也做了相应调整,出现了以实时事件处理为核心的Kappa架构。

离线大数据架构
具体架构流程,如下图:

数据仓库从模型层面分为三层:
- ODS,操作数据层,保存原始数据;
- DWD,数据仓库明细层,根据主题定义好事实与维度表,保存最细粒度的事实数据;
- DM,数据集市/轻度汇总层,在DWD层的基础之上根据不同的业务需求做轻度汇总;
典型的数仓存储是HDFS/Hive,ETL可以是MapReduce脚本或HiveSQL。
实时架构之Lambda架构
随着技术的发展,由于业务的需要,和数据处理能力的提升,包括spark streaming 、flink的出现,对实时数仓的需求也越来越多。先后出现了两种兼容实时数仓的架构,即Lambda架构和Kappa架构。具体架构流程,如下图:
扫描二维码关注公众号,回复: 17496551 查看本文章![]()

Lambda架构,即在原来离线数仓的基础上增加了一个实时计算的链路,并对数据源做流式改造(即把数据发送到消息队列),实时计算去订阅消息队列,直接完成实时应用的计算,推送到下游的数据服务中去,由数据服务层完成离线&实时结果的合并。
- Lambda架构缺点:
- 同样的需求需要开发两套一样的代码,这是Lambda架构最大的问题,两套代码不仅仅意味着开发困难(同样的需求,一个在批处理引擎上实现,一个在流处理引擎上实现,还要分别构造数据测试保证两者结果一致),后期维护更加困难,比如需求变更后需要分别更改两套代码,独立测试结果,且两个作业需要同步上线。
- 资源占用增多:同样的逻辑计算两次,整体资源占用会增多(多出实时计算这部分)。
实时架构之Kappa架构
Lambda架构虽然满足了实时的需求,但带来了更多的开发与运维工作,其架构背景是流处理引擎还不完善,流处理的结果只作为临时的、近似的值提供参考。后来随着Flink等流处理引擎的出现,流处理技术很成熟了,这时为了解决两套代码的问题,LickedIn 的Jay Kreps提出了Kappa架构。具体架构流程,如下图:

- Kappa架构移除了原离线数据仓库的批处理逻辑,而改用流处理来处理离线数仓的需求。
- Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理,这个需要通过增加计算资源来弥补。
Lambda架构与Kappa架构的对比
对比项 | Lambda架构 | Kappa架构 |
---|---|---|
实时性 | 实时 | 实时 |
计算资源 | 批和流同时运行,资源开销大 | 只有流处理,仅针对新需求开发阶段运行两个作业,资源开销小 |
重新计算时吞吐 | 批式全量处理,吞吐较高 | 流式全量处理,吞吐较批处理低 |
开发、测试 | 每个需求都需要两套不同代码,开发、测试、上线难度较大 | 只需实现一套代码,开发、测试、上线难度相对较小 |
运维成本 | 维护两套系统(引擎),运维成本大 | 只需维护一套系统(引擎),运维成本小 |
引用:https://developer.aliyun.com/article/691499、https://developer.aliyun.com/article/691541