大纲
数据仓库的发展，本文摘自：Java大数据与数据仓库 ，作者刘不二
下图为历史发展中的各类数仓架构。
我们再看一下数仓在历史平台的意义：
数仓演进的历程：
什么是数仓，数据仓库是一个面向主题的（Subject Oriented）、集成的（Integrate）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策，数据仓库在数据平台中的建设有两个环节：一个是数据仓库的构建，另外一个就是数据仓库的应用。
我们来看一下历史上数仓的发展：
什么是离线数仓：随着互联网时代来临，数据量暴增，开始使用大数据工具来替代经典数仓中的传统工具。此时仅仅是工具的取代，架构上并没有根本的区别，可以把这个架构叫做离线大数据架构
Lambda架构
后来随着网络技术、通信技术的发展，使得终端数据的实时上报传输成为可能，从而业务实系统发生变化，进而导致了我们对需求的时性要求的不断提高开始之前我们先看一下，网络技术和通信技术到底对我们的生活有什么样的影响。
为了应对这种变化，开始在离线大数据架构基础上加了一个加速层，使用流处理技术直接完成那些实时性要求较高的指标计算，然后和离线计算进整合从而给用户一个完整的实时计算结果，这便是Lambda架构。
为了计算一些实时指标，就在原来离线数仓的基础上增加了一个实时计算的链路，并对数据源做流式改造（即把数据发送到消息队列），实时计算去订阅消息队列，直接完成指标增量的计算，推送到下游的数据服务中去，由数据服务层完成离线&实时结果的合并。
需要注意的是流处理计算的指标批处理依然计算，最终以批处理为准，即每次批处理计算后会覆盖流处理的结果（这仅仅是流处理引擎不完善做的折中），Lambda架构是由Storm的作者Nathan Marz提出的一个实时大数据处理框架。Marz在Twitter工作期间开发了著名的实时大数据处理框架Storm，Lambda架构是其根据多年进行分布式大数据系统的经验总结提炼而成。Lambda架构的目标是设计出一个能满足实时大数据系统关键特性的架构，包括有：高容错、低延时和可扩展等。Lambda架构整合离线计算和实时计算，融合不可变性（Immunability），读写分离和复杂性隔离等一系列架构原则，可集成Hadoop，Kafka，Storm，Spark，Hbase等各类大数据组件。
存在的问题
同样的需求需要开发两套一样的代码，这是Lambda架构最大的问题，两套代码不仅仅意味着开发困难（同样的需求，一个在批处理引擎上实现，一个在流处理引擎上实现，还要分别构造数据测试保证两者结果一致），后期维护更加困难，比如需求变更后需要分别更改两套代码，独立测试结果，且两个作业需要同步上线。
资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分）。
实时链路和离线链路计算结果容易让人误解，昨天看到的数据和今天看到的数据不一致**。
下游处理复杂，需要整合实时和离线处理结果，这一部分往往是我们在呈现给用户之前就完成了的。
Kappa架构
再后来，实时的业务越来越多，事件化的数据源也越来越多，实时处理从次要部分变成了主要部分，架构也做了相应调整，出现了以实时事件处理为核心的Kappa架构。当然这不要实现这一变化，还需要技术本身的革新——Flink，Flink 的出现使得Exactly-Once 和状态计算成为可能，这个时候实时计算的结果保证最终结果的准确性。
Lambda架构虽然满足了实时的需求，但带来了更多的开发与运维工作，其架构背景是流处理引擎还不完善，流处理的结果只作为临时的、近似的值提供参考。后来随着Flink等流处理引擎的出现，流处理技术很成熟了，这时为了解决两套代码的问题，LickedIn 的Jay Kreps提出了Kappa架构。
Kappa架构可以认为是Lambda架构的简化版（只要移除lambda架构中的批处理部分即可）。在Kappa架构中，需求修改或历史数据重新处理都通过上游重放完成。
Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。
总结对比：
在真实的场景中，很多时候并不是完全规范的Lambda架构或Kappa架构，可以是两者的混合，比如大部分实时指标使用Kappa架构完成计算，少量关键指标（比如金额相关）使用Lambda架构用批处理重新计算，增加一次校对过程。
这两个架构都是实时架构，都是对离线架构的扩展。
