@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架构缺点：
- 同样的需求需要开发两套一样的代码，这是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