分布式流处理综述随着互联网技术的发展，越来越多的行业领域对数据和数据处理提出了较高 的要求，其高速产生的海量数据的处理需求日渐增多，近几年来更是呈现出爆炸式 增长的趋势。很多领域，这些处理需求已经成为了当务之急。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负载均衡负载均衡问题也是分布式系统常见的系统层级的问题之一，理想的分布式系 统情况是，所有处理节点共同处理一个问题，同时完成处理然后进入下一个处理阶 段，但是在实际系统中，这是难以做到的，因为实际面临的问题是很难进行均匀分 配的，而且现代的分布式系统不同的计算节点性能也不尽相同，因此势必会产生负 载问题。而在分布式流处理系统中，节点多是分级存在的，上级节点的处理结果会 作为下级节点的输入，因此如果不加以控制，一个不合理的初始负载分配给系统效 率带来的影响是很大的。为了解决这个问题，我们可以有静态策略和动态策略两种 方案，静态策略即事先分配好一个合理的状态，然而作为输入的数据流很多时候难 以估算，峰值和低谷时往往差距很大，且变化快速，因此，事先规划好的静态方案 很多时候难以适应当前的实际情况，因此动态策略是急需的。同时，分布式流处理系统普遍具有的节点可扩展性也进一步简化了动态策略 的问题，系统负载较少时，使用较少的节点进行处理，并采用动态策略进行动态分 配任务，尽可能的使每个节点处理相近的任务量，同时，当已有的工作节点逐渐达 到负载上限时启用更多的工作节点从而减轻节点的平均负载，实现系统的负载均 衡。使用合理的数据抽象模型和中心化的架构时，由控制节点进行系统调度，通过 控制合理的数据流粒度，分发给不同的计算节点相似的任务量还是比较容易实现 的。将系统的可扩展性和复杂均衡的动态策略相互结合，从而最大程度的使得系统 获得较高的执行效率是良好的解决方案。3.4高容错性高容错性一直是分布式系统的优势所在，一个合理的分布式系统有多个节 点，可以保证在某些节点失效的情况下仍然能正常运行，但这是基于合理的操作的 基础上的。事实上，分布式系统中出现错误节点的概率是很大的，换句话说，对于 合理的分布式系统，带有错误节点正常工作时运行的一种常态。这种常态需要系统 在某些节点失效时及时采取合理操作，如采用其他节点接替失效节点的工作，同 时，需要尽快将失效节点恢复正常，理论上，恢复速度应该大于失效的产生速度， 这样才能保证系统正常运行。3.5恢复恢复是相当重要的，尤其是在中心化架构中，当主节点发生故障时，如果不 能尽快的恢复主节点，系统很可能就会陷入崩溃。一个简单的故障恢复策略是检查 点，在主节点正常工作时设置检查点，当发生错误时恢复到之前正常状态下的检查 点即可实现故障恢复。常用的恢复策略还有针对正常工作的主节点进行主动备用和 被动备用两种，主动备用即主节点的备用节点和主节点同时接受上级节点的数据， 因此一旦主节点失效，备用节点可以保证和主节点相同的状态进入工作。被动备用 则是由备用节点和主节点定期进行通信从而达到同步，因此由于同步之后的一段时 间主节点的状态发生改变，但是还没有来得及进行下一次同步就失效了，此时备用 节点和主节点处于不同的状态，但是相对于主动备用，该策略消耗资源更少，不失 为一个良好选择。每种策略各有优势和不足，在不同系统中也都有所应用，应当根 绝实际需求选择适当的恢复策略来达到最优解。3.6语义在保证高容错性的问题上，面对分布式流处理系统，不得不提的就是语义问 题，输入到系统的语义可以被分为四种，分别是无保障、至多处理一次、至少处理 一次以及精确处理一次。面对不同的语义，在容错度上有不同的要求。无保障，顾名思义，这里不做讨论。至多处理一次，可以使用推送的方式， 当节点恢复时，则不再进行该语义的语句的执行，保证这个语句不会被多次执行。 至少处理一次则正相反，这种语义的语句数据需要在系统中进行持久化存储，一旦 处理失败恢复回来，要重新进行处理，尽管牺牲了效率，但是保证了正确性。精确 处理一次，是最严格的要求，带来的代价也最大，成熟的做法是给每个该类型的语 句一个ID，将ID和对应的语句的执行状态持久化存储到磁盘介质中，当节点恢复 需要重发数据时，通过磁盘中ID的情况来决定怎么做，从而避免了未处理或多次 处理等情况的发生。3.7存储问题存储问题同样是系统层级的需要考虑的问题。传统的分布式系统架构，例如 大名鼎鼎的Hadoop，是将待处理的数据存储在基于磁盘的HDFS中，一次读取后进 行处理，中间数据也存储在磁盘上。这么做可以达到较高的吞吐量，但是在追求低 延迟的分布式流处理中是难以接受的，面向磁盘的I/O将会消耗大量的时间，将中 间数据存储在磁盘上更是极大的增加处理延迟，应当尽可能避免。很多使用场景下，分布式流处理系统面对的都会是不断产生的数据，因此系 统的输入数据如何存储并不重要，主要影响系统延迟的是系统的中间数据的存储方 式。和传统的磁盘存储不同，分布式流处理系统通常将中间数据存放在内存中以减 少延迟，存储的数据一般包括局部处理结果和节点状态。获得较好的性能的同时也 促生了两个问题，首先，内存的共享性。程序的内存是某一个进程独有的，而分布 式系统是基于多个节点的，这些节点往往分布在不同的实体机上，同时为了保证效 率，因此，多数分布式流处理系统不会分享工作节点的内存状态。这也进一步导致 了难以从全局角度对工作节点进行掌控的问题，尤其是当节点失效时，存储在其内 存中的数据将会丢失，可能会对节点的恢复产生较大的影响。常见的方案中，难以 做到效率和稳定性兼顾，只能进一步进行割舍。3.8节点间通信问题同时，节点间的通信也是分布式系统的常见问题，分布式系统的节点间通信 普遍依赖网络，而即使是最高速的网络也难以和机器总线媲美，考虑过了数据在内 存中可能产生的潜在问题之后，不得不继续面对数据在网络传输过程中产生的一系 列问题，使得不得不牺牲一部分效率为这部分网络传输增加保障机制。综合考虑节点内存的易丢失性和网络传输中的可能产生的问题，一些分布式 流处理系统提供了节点数据的备份机制，尽管会导致延迟增加，但是保障系统的正 确运行无疑是更重要的，如果