分布式流处理综述

分布式流处理综述

随着互联网技术的发展，越来越多的行业领域对数据和数据处理提出了较高

的要求，其高速产生的海量数据的处理需求日渐增多，近几年来更是呈现出爆炸式增长的趋势。很多领域，这些处理需求已经成为了当务之急。

1.简介

当前被业界广泛采用的大数据处理架构是MapReduce，在处理传统大数据时，MapReduce十分有效，但是它并不适合大数据的高速实时处理。主要原因是因为

它是一个批处理计算模型，并不适合于其他类型的计算。

一般来讲，我们将大数据的批处理模式和流处理模式看成两种不同的模式。

虽然都是面对海量数据的处理，两者之间还是有很多不同点。传统的批处理模式更倾向与重视数据处理的吞吐量，因此会在处理的时效性上略显不足，而在很多场合下，数据处理的时效性是非常关键的，对数据处理过程的整体延迟要求非常高，要求很快的得出处理结果并进行下一步计算，因此流处理模式得到发展。

在批处理模式中，静态数据的中间结果数据被持久化到外部存储介质上，等

待节点处理完毕之后才会发送到下一个节点，这种方法显然会浪费大量的I/O时间，从而成为数据处理实时性的瓶颈。

在流处理模式中，处理的中间结果在写入缓存后直接发送给下一个节点，因此，不仅拥有更低的处理延迟，还可以应对不断更新的动态数据，不断的进行数据输入的同时，不断的进行数据处理并且很快的产生结果，因此得到很多需要实时处理的系统的使用。

在分布式数据流处理产生之前，就有很多早期的数据流处理系统出现，这也

是流处理模式最早的起源和应用，尽管采用相似的流处理模式进行数据处理，但是传统的集中式架构无法适应海量数据处理的需求，而且传统系统普遍面向单一的应用领域，模块之间具有较高的耦合度，扩展性差，难以适应和发展。

面对这些问题，Hadoop平台的出现指出了解决方向，并行化和平台式成为主流，分布式大数据流处理技术成为了理想的解决方案，提出了很多可以高性能低延迟的处理大数据流的平台，例如Storm，Spark Streaming，Samza等。这些平台采

用分布式架构，其数据处理能力可以随着分布式节点的数目增长而增长，可以良好

的适应海量数据的处理，同时实现了平台化，即自身只有基础模块，负责数据传输和任务分配等工作，而逻辑模块由用户自己编码开发，因此具有很高的扩展性，可以方便的用于实现各类系统。

2.特性

一个典型的数据处理系统可以有几个分类维度，例如数据形态、依托介质和

处理粒度。传统的MapReduce是面向静态数据，依托磁盘的粗粒度处理模式，因

此可以有很高的数据吞吐量，适合用于海量静态数据的处理，但是由于其依托于磁盘，因此获得处理结果需要相对长的时间，一般形象的称之为离线处理。

和之相对的就是面向动态数据，依托内存的细粒度处理模式，即分布式流处

理模式，数据进行流式的动态输入并且同样的实时产生流式的处理结果，处理延迟低，由于数据是不断产生输入并处理的，因此理论上只要在高峰期不产生数据堆积，系统不需要很高的吞吐量，相对的，则对延迟提出了更高的要求，因此要求系统是细粒度的，从而更及时的产生数据处理结果。

目前世面上存在很多种分布式流处理平台，各有特色，但是其中很大一部分

的核心思想是有很大共同之处的。和传统分布式系统中所应用的MapReduce思想

相同，分布式流处理同样是将需要处理的数据流进行切分，然后采用多个节点进行计算，从而实现低延迟快速处理大量数据的效果。如图所示。

显然，用这种方法去实现一个分布式流处理系统，首要的问题在于如何实现

并行化。不管什么分布式系统，如何实行有效的并行化都是系统处理效率的关键，对此，不同的实现方案在细节上有很大不同。

3.面临问题

3.1数据模型

首先是需要解决的是数据模型的问题，和程序语言中数据结构的概念相似，

任何数据处理系统都需要解决的数据抽象问题，即数据以什么样的形式输入到系统中并在系统中进行传递。显然，数据建模的好坏直接决定了一个分布式流处理系统的可行性和执行效率。常见的如，Storm使用元祖（tuple），Spark Streaming使用DStream，而Samza使用消息等等。每种数据模型都各有特色，和各自的系统模型

互相契合，从而达到良好的使用效果。

3.2数据模型

接下来需要解决的是系统模型的问题，也是任何一个数据处理系统无法回避

的最重要的问题。对于一个分布式数据处理系统，有很多系统模型上的难点。首先，

为了实现分布式处理，并行化模型是必不可少的。合理高效的并行化方案可以很大程度的提高系统的效率。现有的分布式流处理系统有诸多不同，不过如果将其高度抽象来看，大部分都可以采用图的方式来加以理解。图的节点代表数据的处理节点，而图的边则代表数据的流动方向，这样，一个分布式流处理系统就可以抽象为一个有向图，数据从上游节点流向下游节点，每个节点都可以从上游接收数据并将处理后的数据发往下游。但是具体如何建立节点和管理节点对数据的处理，不同的系统之间有很大不同，稍后叙述。

从节点的角度来看，分布式系统通常可以分为中心化和去中心化的两种形式，根据中心化的程度还可以进行进一步的细分，如可以有弱中心化的标准等等。中心化和去中心化两种模式的比较已经是很常见的问题了，优缺点也都很明确，中心化的架构即有一些节点负责整个系统的调度，这种架构往往会表现出更有“秩序”，执行效率更高，但是面临着一旦中心节点发生问题，系统很可能会陷入崩溃的风险。相对的，去中心化的架构是靠节点间彼此相互协调来完成系统的调度的，因此某个或某些节点的问题基本不会使得系统崩溃，但是节点间的交流协调势必要比中心化架构中的中心节点“发号施令”的模式消耗更多的通信资源。在分布式流处理系统的架构选择上，没有一个统一的方案，不过由于要追求更高的效率和更短的延迟，分布式流处理系统很多时候需要复杂的调度，比如接下来要谈的负载均衡问题，在负载均衡问题上，去中心化的架构带来的昂贵的沟通成本是难以接受的，因此很多时候会选择中心化的架构，然后用额外的手段来保护系统在中心节点故障的时候免于崩溃。

3.3负载均衡

负载均衡问题也是分布式系统常见的系统层级的问题之一，理想的分布式系

统情况是，所有处理节点共同处理一个问题，同时完成处理然后进入下一个处理阶段，但是在实际系统中，这是难以做到的，因为实际面临的问题是很难进行均匀分配的，而且现代的分布式系统不同的计算节点性能也不尽相同，因此势必会产生负载问题。而在分布式流处理系统中，节点多是分级存在的，上级节点的处理结果会作为下级节点的输入，因此如果不加以控制，一个不合理的初始负载分配给系统效率带来的影响是很大的。为了解决这个问题，我们可以有静态策略和动态策略两种方案，静态策略即事先分配好一个合理的状态，然而作为输入的数据流很多时候难以估算，峰值和低谷时往往差距很大，且变化快速，因此，事先规划好的静态方案很多时候难以适应当前的实际情况，因此动态策略是急需的。