3.3 大数据的计算模式

大数据的计算模式可以分为批量计算（batch computing）和流式计算（stream computing）两种形态。如图3-4左图所示，批量计算首先进行数据的存储，然后对存储的静态数据进行集中计算。Hadoop是典型的大数据批量计算架构，由HDFS分布式文件系统负责静态数据的存储，并通过MapReduce将计算逻辑分配到各数据节点进行数据计算和价值发现。

如图3-4右图所示，在流式计算中，无法确定数据的到来时刻和到来顺序，也无法将全部数据存储起来。因此，不再进行流式数据的存储，而是当流动的数据到来后，在内存中直接进行数据的实时计算。例如Twitter的Storm、Yahoo的S4就是典型的流式数据计算架构，数据在任务拓扑中被计算，并输出有价值的信息。

流式计算和批量计算分别适用于不同的大数据应用场景。对于先存储后计算，实时性要求不高，同时数据的准确性、全面性更为重要的应用场景，批量计算模式更合适；对于无须先存储，可以直接进行数据计算，实时性要求很严格，但数据的精确度要求稍微宽松的应用场景，流式计算具有明显优势。流式计算中，数据往往是最近一个时间窗口内的，因此数据延迟往往较短，实时性较强，但数据的精确程度往往较低。流式计算和批量计算具有明显的优劣互补特征，在多种应用场合下可以将两者结合起来使用。通过发挥流式计算的实时性优势和批量计算的精度优势，满足多种应用场景在不同阶段的数据计算要求。

目前，关于大数据批量计算相关技术的研究相对成熟，形成了以谷歌的MapReduce编程模型、开源的Hadoop计算系统为代表的高效、稳定的批量计算系统，在理论上和实践中均取得了显著成果。现有的大数据流式计算系统实例有Storm系统、Kafka系统、Spark系统等。本节对这几款大数据流式计算系统进行实例分析。

3.3.1 流式计算的应用场景

流式大数据呈现出实时性、易失性、突发性、无序性、无限性等特征，对系统提出了很多新的更高的要求。2010年，Yahoo推出了S4流式计算系统，2011年，Twitter推出了Storm流式计算系统，在一定程度上推动了大数据流式计算技术的发展和应用。但是，这些系统在可伸缩性、系统容错、状态一致性、负载均衡、数据吞吐量等诸多方面仍然存在着明显不足。如何构建低延迟、高吞吐且持续可靠运行的大数据流式计算系统是当前亟待解决的问题。

大数据流式计算主要用于对动态产生的数据进行实时计算并及时反馈结果，但往往不要求结果绝对精确的应用场景。在数据的有效时间内获取其价值，是大数据流式计算系统的首要设计目标。因此，当数据到来后，将立即对其进行计算，而不再对其进行缓存，等待后续全部数据到来再进行计算。大数据流式计算的应用场景较多，按照数据的产生方式、数据规模大小以及技术成熟度高低3个不同维度，金融银行业应用、互联网应用和物联网应用是3种典型的应用场景，体现了大数据流式计算的基本特征。从数据产生方式上看，它们分别是被动产生数据、主动产生数据和自动产生数据；从数据规模上看，它们处理的数据分别是小规模、中规模和大规模；从技术成熟度上看，它们分别是成熟度高、成熟度中和成熟度低的数据。

（1）金融银行业的应用

在金融银行领域的日常运营过程中，往往会产生大量数据，这些数据的时效性往往较短。因此，金融银行领域是大数据流式计算最典型的应用场景之一，也是大数据流式计算最早的应用领域。在金融银行系统内部，每时每刻都有大量的结构化数据在各个系统间流动，并需要实时计算。同时，金融银行系统与其他系统也有着大量的数据流动，这些数据不仅有结构化数据，也会有半结构化和非结构化数据。通过对这些大数据的流式计算，发现隐含于其中的内在特征，可以帮助金融银行系统进行实时决策。在金融银行的实时监控场景中，大数据流式计算往往体现出了自身的优势。

• 风险管理：包括信用卡诈骗、保险诈骗、证券交易诈骗、程序交易等，这些需要实时跟踪发现。

• 营销管理：如根据客户信用卡消费记录，掌握客户的消费习惯和偏好，预测客户未来的消费需求，并为其推荐个性化的金融产品和服务。

• 商业智能：如掌握金融银行系统内部各系统的实时数据，实现对全局状态的监控和优化，并提供决策支持。

（2）互联网领域的应用

随着互联网技术的不断发展，特别是Web 2.0时代的到来，用户可以实时分享和提供各类数据。不仅使得数据量大为增加，也使得数据更多地以半结构化和非结构化的形态呈现。据统计，目前互联网中75%的数据来源于个人，主要以图片、音频、视频数据形式存在，需要实时分析和计算这些大量、动态的数据。在互联网领域中，大数据流式计算的典型应用场景如下。

• 搜索引擎：搜索引擎提供商们往往会在反馈给客户的搜索页面中加入点击付费的广告信息。插入什么广告、在什么位置插入这些广告才能得到最佳效果，往往需要根据客户的查询偏好、浏览历史、地理位置等综合语义进行决定。而这种计算对于搜索服务器而言往往是大量的：一方面，每时每刻都会有大量客户进行搜索请求；另一方面，数据计算的时效性极低，需要保证极短的响应时间。

• 社交网站：需要实时分析用户的状态信息，及时提供最新的用户分享信息给相关的朋友，准确地推荐朋友，推荐主题，提升用户体验，并能及时发现和屏蔽各种欺骗行为。

（3）物联网领域的应用

在物联网环境中（如环境监测），各个传感器产生大量数据。这些数据通常包含时间、位置、环境和行为等内容，具有明显的颗粒性。由于传感器的多元化、差异化以及环境的多样化，这些数据呈现出鲜明的异构性、多样性、非结构化、有噪声、高增长率等特征。所产生的数据量之密集、实时性之强、价值密度之低是前所未有的，需要进行实时、高效的计算。在物联网领域中，大数据流式计算的典型应用场景如下。

• 智能交通：通过传感器实时感知车辆、道路的状态，并分析和预测一定范围、一段时间内的道路流量情况，以便有效地进行分流、调度和指挥。

• 环境监控：通过传感器和移动终端对一个地区的环境综合指标进行实时监控、远程查看、智能联动、远程控制，系统地解决综合环境问题。

上述这些应用场景对计算系统的实时性、吞吐量、可靠性等方面都提出了很高要求。大数据流式计算的3种典型应用场景的对比如下。

• 从数据的产生方式看，金融银行领域的数据往往是在系统中被动产生的，互联网领域的数据往往是人为主动产生的，物联网领域的数据往往是由传感器等设备自动产生的。

• 从数据的规模来看，金融银行领域的数据与互联网、物联网领域的数据相比较少，物联网领域的数据规模是最大的，但受制于物联网的发展阶段，当前实际拥有数据规模最大的是互联网领域。

• 从技术成熟度来看，金融银行领域的流式大数据应用最为成熟，从早期的复杂事件处理开始就呈现了大数据流式计算的思想，互联网领域的发展将大数据流式计算真正推向历史舞台，物联网领域的发展为大数据流式计算提供了重要的历史机遇。

3.3.2 流式大数据的特征

图3-5用有向无环图（Directed Acyclic Graph, DAG）描述了大数据流的计算过程。其中，圆形表示数据的计算节点，箭头表示数据的流动方向。

与大数据批量计算不同，大数据流式计算中的数据流主要体现了如下5个特征。

1. 实时性

流式大数据是实时产生、实时计算的，结果反馈往往也需要保证及时性。流式大数据价值的有效时间往往较短，大部分数据到来后直接在内存中进行计算并丢弃，只有少量数据才被长久保存到硬盘中。这就需要系统有足够的低延迟计算能力，可以快速地进行数据计算，在数据价值有效的时间内体现数据的有用性。对于时效性特别短、潜在价值又很大的数据可以优先计算。

2. 易失性

在大数据流式计算环境中，数据流往往是到达后立即被计算并使用。在一些应用场景中，只有极少数的数据才会被持久化地保存下来，大多数数据往往会被直接丢弃。数据的使用往往是一次性的、易失的，即使重放，得到的数据流和之前的数据流往往也是不同的。这就需要系统具有一定的容错能力，要充分地利用好仅有的一次数据计算机会，尽可能全面、准确、有效地从数据流中得出有价值的信息。

3. 突发性

在大数据流式计算环境中，数据的产生完全由数据源确定，由于不同的数据源在不同时空范围内的状态不统一且发生动态变化，导致数据流的速率呈现出了突发性的特征。前一时刻的数据速率和后一时刻的数据速率可能会有巨大的差异，这就需要系统具有很好的可伸缩性，能够动态适应不确定流入的数据流，具有很强的系统计算能力和大数据流量动态匹配的能力。一方面，在突发高数据速率的情况下，保证不丢弃数据，或者识别并选择性地丢弃部分不重要的数据；另一方面，在低数据速率的情况下，保证不会太久或过多地占用系统资源。

4. 无序性

在大数据流式计算环境中，各数据流之间、同一数据流内部各数据元素之间是无序的：一方面，由于各个数据源之间是相互独立的，所处的时空环境也不尽相同，因此无法保证数据流间的各个数据元素的相对顺序；另一方面，即使是同一个数据流，由于时间和环境的动态变化，也无法保证重放数据流和之前数据流中数据元素顺序的一致性。这就需要系统在数据计算过程中具有很好的数据分析和发现规律的能力，不能过多地依赖数据流间的内在逻辑或者数据流内部的内在逻辑。

5. 无限性

在大数据流式计算中，数据是实时产生、动态增加的，只要数据源处于活动状态，数据就会一直产生和持续增加下去。可以说，潜在的数据量是无限的，无法用一个具体确定的数据实现对其进行量化，需要系统具有很好的稳定性，保证系统长期而稳定地运行。

3.3.3 流式计算关键技术

针对具有实时性、易失性、突发性、无序性、无限性等特征的流式大数据，理想的大数据流式计算系统应该表现出低延迟、高吞吐、持续稳定运行和弹性可伸缩等特性，这其中离不开系统架构、数据传输、编程接口、高可用技术等关键技术的合理规划和良好设计。

1. 系统架构

系统架构是系统中各子系统间的组合方式，属于大数据计算所共有的关键技术。当前，大数据流式计算系统采用的系统架构可以分为无中心节点的对称式系统架构（如S4、Puma等系统）和有中心节点的主从式架构（如Storm系统）。对称式系统架构如图3-6的左图所示，系统中各个节点的功能是相同的，具有良好的可伸缩性。但由于不存在中心节点，在资源调度、系统容错、负载均衡等方面需要通过分布式协议实现。例如，S4通过ZooKeeper实现系统容错、负载均衡等功能。

主从式系统架构如图3-6的右图所示，系统存在一个主节点和多个从节点，主节点负责系统资源的管理和任务的协调，并完成系统容错、负载均衡等方面的工作；从节点负责接收来自主节点的任务，并在计算完成后进行反馈。各个从节点间没有数据往来，整个系统的运行完全依赖于主节点控制。

2. 数据传输

数据传输是指完成有向任务图到物理计算节点的部署之后，各个计算节点之间的数据传输方式。在大数据流式计算环境中，为了实现高吞吐和低延迟，需要更加系统地优化有向任务图以及有向任务图到物理计算节点的映射方式。在大数据流式计算环境中，数据的传输方式分为主动推送方式（基于push方式）和被动拉取方式（基于pull方式）。

主动推送方式是在上游节点产生或计算完数据后，主动将数据发送到相应的下游节点，其本质是让相关数据主动寻找下游的计算节点，当下游节点报告发生故障或负载过重时，将后续数据流推送到其他相应节点。主动推送方式的优势在于数据计算的主动性和及时性，但由于数据是主动推送到下游节点的，往往不会过多地考虑下游节点的负载状态、工作状态等因素，可能会导致下游部分节点负载不够均衡。

被动拉取方式是只有下游节点显式进行数据请求，上游节点才会将数据传输到下游节点，其本质是让相关数据被动地传输到下游计算节点。被动拉取方式的优势在于下游节点可以根据自身的负载状态、工作状态适时地进行数据请求，但上游节点的数据可能未必得到及时的计算。

大数据流式计算的实时性要求较高，数据需要得到及时处理，往往选择主动推送的数据传输方式。当然，主动推送方式和被动拉取方式不是完全对立的，也可以将两者进行融合，从而在一定程度上实现更好的效果。

3. 编程接口

编程接口用于方便用户根据流式计算的任务特征，通过有向任务图来描述任务内在逻辑和依赖关系，并编程实现任务图中各节点的处理功能。用户策略的定制、业务流程的描述和具体应用的实现需要通过大数据流式计算系统提供的应用编程接口。良好的应用编程接口可以方便用户实现业务逻辑，减少编程工作量，并降低系统功能的实现门槛。

当前，大多数开源大数据流式计算系统都提供了类似于MapReduce的用户编程接口。例如，Storm提供Spout和Bolt应用编程接口，用户只需要定制Spout和Bolt的功能，并规定数据流在各个Bolt间的内在流向，明确数据流的有向无环图，即可满足对流式大数据的高效实时计算。也有部分大数据流式计算系统为用户提供了类SQL的应用编程接口，并给出了相应的组件，便于应用功能的实现。

4. 高可用技术

大数据批量计算将数据事先存储到持久设备上，节点失效后容易实现数据重放。而大数据流式计算对数据不进行持久化存储，因此批量计算中的高可用技术不完全适用于流式计算环境。我们需要根据流式计算的新特征及其新的高可用要求有针对性地研究更加轻量、高效的高可用技术和方法。大数据流式计算系统的“高可用性”是通过状态备份和故障恢复策略实现的。当故障发生后，系统根据预先定义的策略进行数据的重放和恢复。按照实现策略，可以细分为被动等待（passive standby）、主动等待（active standby）和上游备份（upstream backup）3种。

被动等待策略如图3-7左图所示，主节点B进行数据计算，副本节点B′处于待命状态，系统会定期地将主节点B上最新的状态备份到副本节点B′上。出现故障时，系统从备份数据中进行状态恢复。被动等待策略支持数据负载较高、吞吐量较大的场景，但故障恢复时间较长，可以通过对备份数据的分布式存储缩短恢复时间。该方式更适合精确式数据的恢复，可以很好地支持不确定性的计算应用，在当前流式数据计算中应用得最为广泛。

主动等待策略如图3-7右图所示，系统在为主节点B传输数据的同时，也为副本节点B′传输一份数据副本，以主节点B为主进行数据计算，当主节点B出现故障时，副本节点B′完全接管主节点B的工作。主副节点需要分配同样的系统资源。这种方式故障恢复时间最短，但数据吞吐量较小，也浪费了较多的系统资源。在广域网环境中，系统负载往往不是过大时，主动等待策略是一个比较好的选择，可以在较短的时间内实现系统恢复。

上游备份策略如图3-8所示，每个主节点均记录其自身的状态和输出数据到日志文件，当某个主节点B出现故障后，上游主节点会重放日志文件中的数据到相应的副本节点中，进行数据的重新计算。上游备份策略所占用的系统资源最小，在无故障期间，由于副本节点B′保持空闲状态，数据的执行效率很高。但由于其需要较长的时间恢复状态的重构，故障的恢复时间往往较长。当需要恢复时间窗口为30分钟的聚类计算时，就需要重放该30分钟内的所有元组。可见，对于系统资源比较稀缺、算子状态较少的情况，上游备份策略是一个比较好的选择方案。

此外，大数据流式计算系统也离不开其他关键技术的支持，比如负载均衡策略。实现对系统中的任务动态、合理地分配，动态适应系统负载情况，保证系统中的任务均衡和稳定地运行。数据在任务拓扑中的路由策略促进系统中负载均衡策略的高效实现、数据的合理流动及快速处理。