1.2 走进实时数据仓库

1.1 节中我们重点阐述了传统数据仓库的特点和经典架构，那么实时数据仓库和传统数据仓库有什么区别和联系呢？

1.2.1 实时计算和离线计算

在分析实时计算与离线计算的区别之前，我们先来了解两个概念——流数据和批数据。

在日常生活中，这两种数据都是十分常见的。例如，在即时通信软件中，两个人在聊天，一条接一条发送的数据就构成了一个数据流，用户对一条接一条到来的数据进行回复和处理，就是对流数据的分析处理。当然，我们也可以通过邮件进行信息沟通，把所有想要表达的内容全部呈现在一封电子邮件中，这样就是一个批数据。用户再将邮件发送至对方的邮箱中，收件人打开邮件，对邮件中的信息统一处理回复，这就是对批数据的分析和处理。

我们把对流数据的分析处理称作实时计算，对批数据的分析处理称作离线计算。

传统离线数据仓库通常进行的就是离线计算，离线计算指的是在计算开始前已经得到了所有输入数据，并且输入数据不会再发生变化。离线计算的计算量级一般比较大，计算时间比较长，如在每天凌晨一点，把前一日累积的所有日志数据，计算出所需结果并生成统计报表。离线计算虽然统计指标、报表繁多，但是对时效性不敏感。从技术操作的角度来讲，离线计算部分属于批处理的操作，即根据确定范围的数据一次性计算。

随着互联网的迅速发展，越来越多的企业和用户对计算的时效性提出了更高的要求。例如，互联网企业需要实时看到用户数量的变化，以观察某个促销活动是否达到了预期目标，通过实时的指标变化趋势，企业可以更好地调整活动策略，获得更高的收益。再如，用户希望互联网应用能根据自己的需求变化实时地提供更贴心的商品和服务推荐，更精准的推荐能很好地提升用户使用体验，增强用户黏性。这些需求的实现都离不开实时计算。

实时计算是指输入数据以序列的方式一个个地输入并进行处理，在计算的时候并不需要知道所有的输入数据。与离线计算相比，运行时间更短，计算量级相对较小，但是更强调计算的时效性和用户的交互性。实时计算更侧重于对当日当时数据的实时监控，业务逻辑相对于离线计算来说通常比较简单，统计指标也少一些。从技术操作的角度，实时计算属于流处理的操作，对源源不断到达的数据进行计算。

1.2.2 实时数据仓库的构建目的

普通实时计算和实时数据仓库实际上是实时计算的两个重要阶段。在实时计算的发展初期，企业的实时需求通常较少，所以优先考虑计算时效性，而不去考虑整体实时架构的搭建，采用直线型开发模式，从数据源采集，到经过实时计算框架直接得到计算结果，并直接推送至实时应用服务中，如图1-1所示。这样的计算模式一开始确实满足了企业的开发需求，且具有很好的时效性，但是也存在很大的弊端。

因为计算过程中的中间计算结果没有沉淀下来，所以当实时计算需求越来越多时，计算的复用性差的缺点会逐渐突显，开发成本更是直线上升。随着需求数量、需求的种类日益增多，有的实时需求需要得到明细数据，有的实时计算需要对计算结果进行即时分析，如此一来，单一的开发模式很难满足多样化的需求。简单的实时计算通路通常也没有建立起有效的监控和优化体系，维护成本高且开发效率低。

为了解决上述问题，人们参照离线数据仓库的概念和模型对实时计算重新进行了规划和设计，实时数据仓库应运而生。实时数据仓库基于一定的数据仓库理念，对数据处理流程进行规划、分层，如图1-2所示，大大提高了数据复用性。

实时数据仓库相较于普通实时计算而言，最重要的一点改变就是对实时计算进行了分层设计。首先，统一对数据源进行采集的工作，减小了多个实时计算对数据源采集数据造成的压力。采集到的数据再通过实时数据仓库系统统一对外提供数据订阅服务。其次，对所有实时分析需求进行统一的分析汇总，最终的需求也决定了实时数据仓库的分层如何设计，以使计算更加合理和高效。

1.2.3 实时技术发展

在实际对流数据的处理中，我们知道想要同时保证流处理的高性能及准确性是非常困难的。第一代流处理引擎，以Storm为例，是实时分布式计算框架，针对流式数据可以做到来一条数据处理一次，能够提供极低的延迟。但是Storm的低延迟是通过牺牲结果的准确性得到的。Storm只能支持最多一次或至少一次的数据消费语义，并且不能提供状态编程。但是人们对流式处理系统有着更高的要求，要求在具有低延时的同时，还希望具有较高的数据准确性。仅凭Storm显然无法实现这一点。针对这一点，工程师们将低延时但不能保障数据一致性的Storm与高延时但是强一致性的批处理结合在一起，进而提出了Lambda架构。

如图1-3所示，Lambda架构主要分为三部分：批处理层（Batch layer）、流处理层（Speed layer）和在线服务层（Serving layer）。

在批处理层，先将流式数据采集落盘到大数据的文件存储系统中，再使用批处理计算引擎——Mapreduce 或 Spark 等，对固定时间间隔的数据进行批量计算，时间间隔可能是一个小时、一天，甚至一个月。批处理层对数据处理的速度比较慢，但是对结果的准确性有很高的保证，计算性能也有很高的可扩展性，通过扩增节点数量就可以提高计算性能。

为了能更快地拿到实时的计算结果，在批处理的基础上，Lambda架构增加了一个流处理层。在将流数据采集落盘到大数据文件存储系统的同时，也发送至流处理层处理。在流处理层会对数据进行实时的处理，处理的结果也会发送至数据服务层，供分析人员使用。早期的流处理引擎，如Storm只能提供一个近似准确的计算结果，但是分析人员也因此可以查看近一个小时甚至几分钟内的数据计算结果，相当于牺牲了一定的结果准确性换取了实时性。

在线服务层用于直接面向数据用户提供数据计算结果，因此需要将来自批处理层的数据计算结果和来自流处理层的数据计算结果做融合，融合过程主要是将来自批处理的有准确性保障的数据覆盖来自流处理层的数据。

Lambda 架构满足了数据用户的关键需求：系统提供低延迟但不准确的数据，后续通过批处理系统纠正之前的数据，最终给出一致性的结果。从流处理系统演变的角度来看，Storm 确实为大家带来了低延迟的流式实时数据处理能力，但是它是以牺牲数据强一致性为代价的，这反过来又带来了Lambda架构的兴起。Lambda架构在实时性和准确性之间做了一个平衡，能够解决很多大数据处理的问题，曾被各大互联网公司广泛应用，但是也存在很大的缺点。Lambda 架构同时使用批处理和流处理系统，如果一边有任何改动，需要在两边同步更新，维护成本高且迭代时间周期长。并且数据经常需要在不同的存储系统和数据格式中做数据迁移和转换，造成了额外的运维策划成本。随着互联网企业规模的不断壮大，数据量级也不断增大，批处理部分的计算时间也不断增长，增加了计算结果合并的复杂性。

Lambda架构的提出，是基于批处理层和流处理层的综合使用，可以满足数据用户的不同需求。批处理层可以提供高准确性的计算结果，流处理层可以提供低延时性的计算结果。那么我们很容易想到，如果批处理层具有了更低的延时，或者流处理层的数据准确性更高，是不是就能简化Lambda架构，解决Lambda架构的种种问题呢？

为了解决以上Lambda架构存在的问题，LinkedIn公司的Jay Kreps提出了Kappa架构。Kappa架构是Lambda架构的简化版本，去掉了原Lambda架构的批处理层，只保留流处理层。Kappa架构的提出得益于流处理引擎的进一步发展，第二代和第三代流处理引擎都可以保障较高的数据准确性，不需要再维护一条批处理线来校正最终的计算结果。

第二代流处理引擎以 Spark 为代表。Spark 最初设计的定位就是改进 Hadoop 的 MapReduce 计算引擎，能更快地进行批处理。Spark做到了这一点，其基于内存的计算能力、对SQL的完美支持、在迭代计算和机器学习领域做出的重要贡献，都值得大受褒奖。在流处理方面，Spark做出的重要贡献就是Spark Streaming，Spark Streaming通过将数据划分为一个个很小的批次，对每个批次的数据进行批处理的计算来处理流数据。这种办法通过Spark本身强大的批处理引擎解决了很多麻烦的问题。Spark Streaming相对于Storm来说，具有更高的吞吐量，并且具有更完善的故障处理保障，同时可以提供数据一致性语义保证。但是Spark Streaming的处理结果，仍然仰赖于事件到来的时间和顺序，无法按照事件真正发生的时间顺序进行数据处理，更无法处理迟到数据。即使有一些缺点，Spark Streaming仍然得到了非常广泛的应用。

第三代分布式流式数据处理引擎的出现，解决了结果对到达事件的时间和顺序的依赖性。结合精确一次（exactly-once）的故障语义，这一代系统是第一个具有计算一致性和准确结果的开源流处理器。通过基于实际数据来计算结果，这些系统还能够以与“实时”数据相同的方式处理历史数据。另一个改进是解决了延迟和吞吐量无法同时保证的问题。先前的流处理器仅能提供高吞吐量或者低延迟，而第三代系统能二者兼顾。这一代的流处理器使得Lambda架构显得更加过时，并且更好地支持Kappa架构。当然这一代流处理以Flink为代表。

除了以上讨论过的特性（如容错、性能和结果准确性），流处理器还不断添加新的操作功能（如高可用性设置），与资源管理器（如YARN和Kubernetes）的紧密集成，以及能够动态扩展流应用程序。其他功能包括支持升级应用程序代码，或将作业转移到其他集群或新版本的流处理器，而不会丢失当前状态。

1.2.4 实时数据仓库现状分析

实时计算在实际生活中为互联网企业解决了众多问题，随着实时计算的广泛发展，需求也日益丰富。

1.报表展示

没有实时计算的时候，不同规模的企业都会制作自己的日常统计报表，通过对日常数据的分析和计算，为企业决策提供支持，这也体现了数据分析的重要性。但是对于各企业的运营管理层面来说，仅仅依靠离线计算得到的统计报表决策，数据的时效性往往无法满足，决策的准确性和针对性也不能得到保障。通过实时计算获得分钟级、秒级，甚至亚秒级的数据分析结果，更便于企业对业务快速反应与调整。

但是仅仅有实时计算的结果也是不够的，所以实时计算结果往往要与离线数据合并或者对比展示在BI或者统计平台中。如图1-4所示，多网页的浏览量PV统计，将多种渠道不同时间段的浏览量PV做对比展示，可以给决策制定者更直观的感受。

2.实时数据大屏

实时数据大屏是指将多个实时分析指标同时展示在数据大屏上，相对于 BI 工具或者数据分析平台是更直观的数据可视化方式。现在很多电商平台都会开发自己的实时数据大屏，对交易额、PV、UV等关键指标进行实时展示，如图1-5所示，这不仅是对关键指标的密切监控，也是对外营销的一种重要手段。

3.风险预警

通过对大数据进行实时计算，可以得到一些风险预警提示，及时的风险预警提示可以让企业的风控部门更快地做出应对。例如，用户在电商或金融平台中进行非法或欺诈类操作时，通过实时分析计算可以将情况快速筛选出来，并发送给风控部门处理，甚至直接屏蔽；或者检测到用户对于某些产品具有强烈的购买意愿时，将此类信息推送到营销部门，可以针对此类用户推出更有针对性的服务或优惠。

风险预警提示系统对数据的时效性要求很高，若某用户在使用非法手段暴力破解密码，企图窃取私密信息，如果不能及时得到风险提示，那么将给用户带来重大损失。

4.实时推荐

实时推荐系统是指根据用户自身属性，结合用户当前的访问行为，经过实时计算，将用户可能喜欢的商品、新闻、视频等推送给用户。实时推荐系统的准确与否，除了与实时计算的时效性紧密相关，还与实时推荐算法有很大的关联。

实时推荐系统应该反映的是用户最近一段时间用户的偏好，所以一般是由一个用户画像系统和一个用户行为分析的流处理系统组合而成的。由于实时推荐系统对于时效性有较高的要求，算法的计算量级不能太大，过于复杂的计算会降低用户体验，也正因为这样，对于实时推荐系统的精度要求可以适当放宽，得到的计算结果合理即可。

以上几种需求在互联网企业中很常见，各大互联网企业都认识到实时计算对业务发展的重要性，需要实时数据仓库来对业务赋能。随着流计算引擎越来越成熟完善，使得流计算的运维成本和开发成本都逐步降低，越来越多的企业谋求更体系化的实时计算模式，也就是实时数据仓库。

当前各企业构建的实时数据仓库同传统离线数据仓库的结构类似，一般分为三大部分：数据采集部分、数据仓库部分和数据应用部分。

数据采集部分需要满足实时计算需求，将采集到的数据形成数据流，而不是像离线数据仓库一样，直接落盘到大数据存储体系中。针对此种需求，一般采用如Flume、Maxwell、Canal等实时数据采集工具，可以实时采集变动的用户行为日志数据和业务数据等，并将采集到的数据发送至消息中间件中，形成一条稳定的数据流，供后续的流式计算引擎进行分析。

而在数据仓库部分，为了避免与“烟囱式”开发相同，浪费计算资源，数据中间结果不能复用，则应同传统离线数据仓库一样，参照一定的数据模型构建。通过构建数据模型，将数据仓库中的数据划分主题、分层组织，就能大大提高数据的复用性和易用性。在这一部分，与传统离线数据仓库除了在数据模型方面有相似外，在数据存储介质和数据计算引擎方面有很大不同。在实时数据仓库中，要处理的数据是流式数据，而不是批数据，所以数据不能存放在HDFS中，而是存储在消息队列中，一般选用Kafka。数据计算引擎也不能使用传统的MapReduce，而是使用可以满足状态编程、保障数据一致性的流式计算引擎，如Spark、Flink等。

数据应用部分则会根据企业不同的业务需求进行不同的设计。一般情况下，会将实时计算的结果数据写入外部存储中，如HBase、ClickHouse等，然后通过数据可视化工具对结果数据做展示。