数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理和决策。数据仓库的数据来源一般有两类：一种是日志类型的数据源，主要 通过客户端埋点上报，从而收集用户的行为日志，以及一些后端日志。另一种是业务数据库，主要通过Canal收集binlog，然后放入到消息队列当中，最终再导出到 HDFS中。这两类数据源最终都会将数据落地到HDFS的ODS层，也就是操作数据层(或者叫贴源数据层)，它的数据与原始数据源中的数据基本是一致的。一般会对ODS中 的数据进行清洗加工、归一化，从而得到DWD明细层数据，这些数据既包含指标类型的数据，也包含统一的维度数据。在DWD明细层之上，一般会根据分析场景、分析实 体去组装数据，形成一些分主题的汇总数据DWS，这样的汇总属于轻度汇总数据。在DWS层之上还会按照应用场景再次进行开发，从而得到能够直接提供给业务使用的数 据，这样的数据是高度汇总的、能直接被使用的，一般存放在HBase、Redis、Kylin甚至是MySql中。一般还会对其中的一部分数据封装成统一的接口提供给业务方 使用。当然，也会有一些报表工具、基于OLAP的产品等。这就是传统的离线数仓的整个架构，以及应用场景。
传统的离线数仓架构时效性较差，一般都是T+1的数据，周期性较长。为了提升效率，Storm的作者提出了一种Lambda的架构，它采用离线+实时的方式来产生实时的 数据。之所以这样，主要是因为早期的实时计算框架如Storm等都不是很完善，无法保证计算结果的精确性。因此采用在原有的离线数仓架构的基础上增加实时部分，再 用离线数据修正实时数据，从而在保证数据的最终精确性的同时，也将原来的T+1的数据产出时间缩短到了分钟级，甚至是秒级。它存在的缺陷是，实时部分和离线部分 的数据逻辑基本一致，但是却必须同时维护两套，这对于开发和运维的成本来说，都是比较高的。基于这样的问题存在，于是产生了Kappa架构。
Kappa架构将离线数仓移除，其数据生产全部使用实时数仓，其消费消息队列，并将消息队列作为了一种数据的暂存。如果需要重刷历史数据，可以直接重新消费消息队 列中的数据。当然这会涉及到大量实时数据的处理，为了减轻这些处理的复杂性，也可以考虑将聚合、分析、计算交由OLAP引擎来处理，从而使数据仓库的处理更加轻 量简单。