本文将解释什么是流式处理，然后讨论实时计算的基本概念和适用场景，它们都与实时数据仓库的实施密不可分。最后从技术实现的角度介绍几种流行的实时数据仓库架构。

一、流式处理

流式处理，顾名思义，是一种处理数据流的技术。与传统的批处理方式不同，流式处理不是等待一大批数据积累完毕再进行处理，而是实时处理数据流中的每一条信息。这种方法使得系统能够即时响应变化，进行实时决策。

人们对数据流并不陌生，数据从业务系统产生，经过一系列转换进入数据仓库，再进入分析系统提供报表、仪表盘展现分析结果，最终经过数据挖掘和机器学习以辅助决策，整个过程就形成了一个数据流。当然除了直觉以外，严格的定义更有意义。数据流是无边界数据集的抽象表示。无边界意味着无限和持续增长，无边界数据集之所以是无限的，是因为随着时间的推移，新的记录会不断加入进来。这个定义已经被包括Google和Amazon在内的大部分公司所采纳。

除无边界外，数据流还有其它一些属性：有序、不可变、可重放。数据的产生总有先后顺序，这是数据流与数据库表的不同点之一，数据库表里的记录是无序的。数据一旦产生就不能被改变。假设你熟悉数据库的二进制日志（binlog）、预写日志（Write Ahead Log，WAL）和重做日志（redo log）的概念，那么就会知道，如果往数据库表插入一条记录，然后将其删除，表里就不会再有这条记录，但日志里包含了插入和删除两个事务。可重放是数据流非常有价值的一个属性。对于大多数业务来说，重放发生在几天前（甚至几个月前）的原始数据流是一个很重的需求。可能是为了尝试使用新的分析方法纠正过去的错误，或是为了进行审计。

知道什么是数据流以后，是时候了解“流式处理”的真正含义了。流式处理是指实时处理一个或多个数据流。流式处理是一种编程范式，就像请求与响应范式和批处理范式那样。下面对这三种范式进行比较，以便更好地理解如何在软件架构中应用流式处理。

请求与响应

这是延迟最小的一种范式，响应时间处于亚毫秒到毫秒之间，而且响应时间一般非常稳定。这种处理方式一般是阻塞的，应用程序向处理系统发出请求，然后等待响应。在数据库领域，这种范式就是联机事务处理（OLTP）。

批处理

这种范式具有高延迟和高吞吐量的特点。处理系统按照预定的时间启动处理进程，比如每天凌晨两点开始启动，每小时启动一次等。它读取所有的输入数据（从上一次执行之后的所有可用数据），输出结果，然后等待下一次启动。处理时间从几分钟到几小时不等，并且用户从结果里读到的都是滞后数据。在数据库领域，它们就是传统的数据仓库或商业智能系统。它们每天装载巨大批次的数据，并生成报表，用户在下一次装载数据之前看到的都是相同的报表。从规模上来说，这种范式既高效又经济。但在近几年，为了能够更及时、高效地做出决策，业务要求在更短的时间内能够提供可用数据。这就给那些为探索规模经济而开发却无法提供低延迟报表的系统带来了巨大的压力。

流式处理介于上述两种之间。某些业务不要求毫秒级的响应，不过也接受不了要等到第二天才知道结果。大部分业务流程都是持续进行的，只要业务报告保持更新，业务产品线更够保持响应，那么业务流程就可以进行下去，而无需等待特定的响应，也不要求在几毫秒内得到响应。

流式处理的整个处理过程必须是持续的。一个在每天凌晨两点启动的流程，从流里读取500条记录，生成结果，然后结束，这样的流程不是流式处理。对数据仓库来说，也许从粒度的角度理解流式处理更容易。

二、实时计算

要做到实时读写数据，必须采用有别于传统数据仓库的实现技术，实时计算的概念和技术引擎应运而生，它们是成功创建实时数据仓库的前提条件。实时计算一般针对海量数据处理，并且要求响应时间为秒级。由于大数据兴起之初，以Hadoop为代表的分布式框架并没有给出实时计算解决方案，随后便出现了Storm、Spark Streaming、Flink等实时计算框架，而Kafka、ES的兴起使得实时计算领域的技术越来越完善，而随着物联网、机器学习等技术的推广，实时流式计算将在这些领域得到充分应用。实时计算是流式处理的一种具体实现方式，因此必然具有无限数据、无界数据处理、低延迟等特征。

现在大数据应用比较火爆的领域，比如推荐系统在实践之初受技术所限，可能要一分钟、一小时、甚至更久才能对用户进行推荐，这远远不能满足需要，我们需要更快的完成对数据的处理，而不是进行离线的批处理。实时计算的应用场景主要包括实时智能推荐、实时欺诈检测、舆情分析、物联网、客服系统、实时机器学习等。

在某些场景中，数据的价值随着时间的推移而逐渐减少。所以在传统数据仓库的基础上，逐渐对数据的实时性提出了更高的要求。于是随之诞生了实时数据仓库，并且衍生出了两种主流技术架构：Lambda和Kappa。

三、Lambda架构

Lambda属于较早的一种架构方式，早期的流处理不如现在这样成熟，在准确性、扩展性和容错性上，流处理层无法直接取代批处理层，只能给用户提供一个近似结果，还不能为用户提供一个一致准确的结果。因此在Lambda架构中出现了批处理和流处理并存的现象。

在Lambda架构中，每层都有自己所肩负的任务。批处理层使用可处理大量数据的分布式处理系统预先计算结果。它通过处理所有的已有历史数据来实现数据的准确性。这意味着它是基于完整的数据集来重新计算的，能够修复任何错误，然后更新现有的数据视图。输出通常存储在只读数据库中，更新则采用全量替换方式，完全取代现有的预先计算好的视图。流处理层通过提供最新数据的实时视图来最小化延迟。流处理层所生成的数据视图可能不如批处理层最终生成的视图那样准确或完整，但它们几乎在收到数据后立即可用。而当同样的数据在批处理层处理完成后，在速度层的数据就可以被替代掉了。

Lambda架构经历多年的发展，其优点是稳定，对于实时计算部分的计算成本可控，批量处理可以用晚上的时间来整体批量计算，这样把实时计算和离线计算高峰分开，这种架构支撑了数据行业的早期发展，但是它也有一些致命缺点，并在当今时代越来越不适应数据分析业务的需求。

Lambda架构的缺点

使用两套大数据处理引擎：维护两个复杂的分布式系统，成本非常高。

批量计算在计算窗口内无法完成：当数据量越来越大，经常发现夜间只有4、5个小时的时间窗口，已经无法完成白天20多个小时累计的数据，保证早上准时出数据已成为每个大数据团队头疼的问题。

数据源变化都要重新开发，开发周期长：每次需求变更后，业务逻辑的变化都需要针对ETL和Streaming做开发修改，整体开发周期很长，业务反应不够迅速。

资源占用增多：同样的逻辑计算两次，整体资源占用会增多（多出实时计算这部分）。

导致Lambda 架构的缺点根本原因是要同时维护两套系统：批处理层和速度层。我们已经知道，在架构中加入批处理层是因为从批处理层得到的结果具有高准确性，而加入速度层是因为它在处理大规模数据时具有低延时性。那我们能不能改进其中某一层的架构，让它具有另外一层架构的特性呢？例如，改进批处理层的系统让它具有更低的延迟，又或者是改进速度层的系统，让它产生的数据视图更具准确性和更加接近历史数据呢？另外一种在大规模数据处理中常用的架构——Kappa，便是在这样的思考下诞生的。

四、Kappa架构

Kappa架构可以被认为是Lambda架构的简化版，只是去除掉了Lambda架构中的离线批处理部分。

这种架构只关注流式计算，数据以流的方式被采集，实时计算引擎将计算结果放入数据服务层以供查询。Kappa架构的兴起主要有两个原因：

消息队列（如Kafka）支持数据持久化，可以保存更长时间的历史数据，以替代Lambda架构中批处理层数据仓库部分。流处理引擎以一个更早的时间作为起点开始消费，起到了批处理的作用。

流处理引擎解（如Flink）决了事件乱序下计算结果的准确性问题。

Kappa架构相对更简单，实时性更好，所需的计算资源远小于Lambda架构，最大的问题是流式重新处理历史的吞吐能力会低于批处理，但这个可以通过增加计算资源来弥补。随着实时处理的需求在不断增长，更多的企业开始使用Kappa架构，但这不意味着Kappa架构能够取代Lambda架构。Lambda和Kappa架构都有各自的适用领域，对于流处理与批处理分析流程比较统一，且允许一定的容错，用Kappa比较合适，少量关键指标，例如交易金额、业绩统计等使用Lambda架构进行批量计算，增加一次校对过程。还有一些比较复杂的场景，批处理与流处理产生不同的结果，如使用不同的机器学习模型、专家系统，或者实时计算难以处理的复杂计算，可能更适合Lambda架构。

五、实时数据仓库解决方案

从传统的经验来讲，数据仓库有一个很重要的功能是记录数据变化历史。通常，数据仓库都希望从业务上线的第一天开始有数据，然后一直记录到现在。但实时处理技术，又是强调当前处理状态的一门技术，所以当这两个相对对立的方案重叠在一起的时候，它注定不是用来解决一个比较广泛问题的方案。于是，我们把实时数据仓库建设的目的定位为解决由于传统数据仓库数据时效性低解决不了的问题。

实时数据仓库也引入了类似于离线数据仓库的分层理念，主要是为了提高模型的复用率，同时兼顾易用性、一致性以及计算成本。通常离线数据仓库采用空间换取时间的方式，所以层级划分比较多从而提高数据计算效率。实时数据仓库的分层架构在设计上考虑到时效性问题，分层设计尽量精简，避免数据在流转过程中造成的不必要的延迟响应，并降低中间流程出错的可能性。