数据仓库系列篇之实现架构

@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架构。具体架构流程，如下图：

Lambda架构，即在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成实时应用的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。

• Lambda架构缺点：

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

实时架构之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