[ATC 17] StreamBox: 面向多核机器上的针对Records的无序到达的实时流处理系统

        今天要讲的文章ATC 2017年的一篇文章，StreamBox: Modern Stream Processing on a Multicore Machine。本文主要想解决的问题就是：高速大量的实时流数据主要是由IOT、Data Centers、Humans产生，它需要快速实时流处理系统。然而由于数据的到达是无序的，因为这些记录通过不同的网络路径传播，并且records上的计算以不同的速率执行。所以如何对这种 无序到达的数据进行高效的处理？是当今实时流处理系统一个重要挑战，所以作者提出了StreamBox，利用窗口机制和如今多核体系架构的硬件，对这种无序到达的数据进行高效的处理。

1.BackGround

        高速大量的实时流数据主要是由IOT、Data Centers、Humans产生，它需要快速实时数据流处理。Pipeline 将处理无界的数据流进入到Epoch 这样一个时序的处理单元中。Pipeline 将会执行多个Transform操作，每个Transform都是一个单独的计算。在数据被处理完成之后，Pipeline将会发出输出结果给用户。

        为什么这样的实时流处理时很难的呢？因为数据是无序的到达的，因为这些记录通过不同的网络路径传播，并且records上的计算以不同的速率执行。并且如今的硬件资源都含有大量的CPU 核数，这样可以提供高性能的计算。他们不得不利用数据并行、流水线并行、内存本访问本地化

2. Prior Work

        先前的工作 都是在epoch内部进行无限的处理，在这个图片中。Transform0含有三个epochs,但是在同一时刻只有一个epoch 被处理。接下来，随着时间的进行，当这个epoch准备好之后，Transform0到Transform1之间有两个epoch在同一时刻运行。然后接下来Transform0到Transform2之间，会有三个epoch在同一时刻运行。在这种设计下，同一时刻每个Transform只有一个epoch被处理。 StreamBox就是这样一种设计。它通过epoch来处理无序tuple，并且它能够并行地处理所有Transform的epoch。

        StreamBox就是这样一种设计。它通过epoch来处理无序tuple，并且它能够并行地处理所有Transform的epoch。

        相比之前的工作和StreamBox进行对比，StreamBox是一个High Pipeline 并且数据并行的实时流处理系统，因为它能够并行地处理所有Transform的epoch。

        作者比较了StreamBox和现有存在的实时流处理系统在多核机器上，StreamBox 可以达到很高的系统吞吐量比现有的实时流处理系统。

3. StreamBox Introduction

        在此介绍之前，为了去处理实时流数据，作者定义了Transform。Transform是一个消耗流数据并且能够产生流数据的一种计算结构。许多Transform构成了一个DAG图就叫做一个Pipeline。

        无界的数量流包括持续到来的输入，每个Stream Records包括数据和产生数据的event time。event time 就是数据的生产时间。由于这些记录通过不同的网络路径传播，并且record上的计算以不同的速率执行，这些记录的到达时间是无序的。

        实时流数据持续不断的到来，窗口是一个临时的处理数据的范围。窗口将无限的数据沿着时间边界切割成有限的片段。我们的数据将会前往相应的窗口范围根据它们的eventTime。Transform可以基于Windonw进行计算操作。

        数据将会前往相应的窗口范围根据它们的eventTime。正如之前提到的那样，Records 意味着会以无序的形式持续不断的到来，比如举个列子。1:09比1:11事件提早发生，但是1:09比1:11推迟到来。这个时候1:11需要进入到一个window中，但是这里有两个windows。分别是1:05-1:10和1:00-1:05。因此问题就是什么时候这个窗口执行完成，系统如何知道属于这个window的所有的记录已经到来了。特别的是在这个例子中，系统如何知道1:09将要接下来会到达。

        因此系统必须通知输入已经完成，这就是watermark。Watermark就是由Stream Souce生成的，用来指示输入已经完成。WaterMark X指所有比X时间小的输入数据（含有evetnTime）都已经到达了。比如说WaterMark 1:05 意味着比1:05时间小的输入数据都已经到达了，因此这个窗口就可以关闭了。

        接下来我们来看如何去使用watermark来处理无序的数据。这个情况下，当1:08到达的时候，它将会去相应的window。当1:11到达，它将会去另外一个window。然后当1:09到达的时候，它将会去先前的那个window。此时，系统发现了一个watermark 1：10。系统知道比1：10小的输入数据都已经到达了。因此它就可以关闭这个window，Transform就可以进行基于窗口的计算。

 

        事件流由watermark分开进入到Epoch中，每个Epoch是一组在两个Watermark之间的记录集合。并且一个窗口可能会穿越多个Epoch。

4. StreamBox Desgin

        目前现有的实时流处理系统都是在分布式系统中进行优化。它们忽视了高效的多核机器，并且他们假设一台机器无法有效的处理实时流处理数据。

        然而，现代硬件的进步使单个多核机器成为一个有吸引力的流媒体平台。 这些进步包括：（i）显着提高入口速率的高吞吐量I / O，例如远程直接存储器存取（RDMA）和10Gb以太网; （ii）TB级别的内存存储，可以保存大量的流处理中的状态以及（iii）大量的计算CPU核数。本文旨在最大限度地提高数据流吞吐量并最大限度地减少现代多核硬件的延迟，从而减少流处理系统所需的机器数量。作者的目标就是设计一个高效的实时流处理系统为了一个多核的机器。流处理系统在保证正确性的前提下，它还要尽量减少线程之间同步，同时尊重两个Transform之间的依赖性。然后为了达到动态高度并行，它能够在不同的epoch中并行的处理任何记录。并且系统的目标是达到高吞吐量和低延迟。StreamBox弹性地将软件并行性映射到硬件。 它将一组工作线程绑定到核心。 （i）每个线程独立地从一个容器中检索一组记录（一个包），并执行变换，产生新的记录，并将其存储到下游容器中。（ii）为了优化等待时间，它优先处理具有下游输出所需要的当前时间戳的容器。

        但是这里由三个挑战：为了达到正确性，它通过两个不变量来保证watermark的语义。为了达到高吞吐量，它不停顿pipline。例如，当水印处理是一个长时间延迟事件时，StreamBox不会停滞，因为一旦后续记录到达，它就会打开新的容器并开始处理它们。为了达到低延迟的特性，他不会造成空闲的watermark事件处理。并且能够提供一个高度并行化的Pipline进行高度并行化的计算。

        第一个规则就是Transform必须顺序地消费watermark。Transform必须在处理完1：10之后，才能处理1:20的watermark。Transform必须消费一个epoch中的所有记录，然后才能消费epoch的watermark，并且刷新Transform的内部状态，生成新的watermark。

        第二个规则Transform计算必须尊重每个epoch的边界。也就是说一旦一个记录被分配到一个epoch时，这个record永远不会改变相应的epoch，因为这种变化可能会违背watermark的保证。

        作者的解决方案就是使用一个数据结构：级联容器。每个Cascading Container对应一个相应的epoch。它们跟踪SS一个epoch的状态，以及记录和watermark之间的关系。并且它们调度工作线程以消耗watermark和records。

        由于每个Transform操作含有多个Container，所以每个container对应相应的下游container。那么为什么要这样去设计？这是因为记录/水印需要通过这个连接流经Pipeline。

        并且Transform计算必须尊重epoch的边界。也就是说每一个Container的bundles，必须发往相应的下游Contaniner容器进行计算，而不能发往其他的Contaniner，进而造成不必要的计算。

 

        然后就是在container内的所有记录都被处理后，水印将被处理，这个将对应第一个规则，Transform必须顺序的消费watermark。接下来就是watermark必须被顺序的处理，比如watermark 20:00被处理，必须在watermark15:00之前被处理。

            最后就是所有的container中的记录都是并行的处理，所以说StreamBox能够并行的处理所有的Transfomr中的epoch。

        接下来是StreamBox的总体设计，一个Pipeline有多个Transform。并且每个Transform含有多个Container，recodrs/watermarks流动必须通过这些链接。所以为了做到这些，我们需要有一个高度并行的Pipline。

5. Evaluation

        作者通过设计一组应用对StreamBox进行测试，作者发现StreamBox有着很好的吞吐量和可扩展性。

        作者将StreamBox和存在的现有的实时流处理引擎进行比较，发现StreamBox由于多核并行体系架构相比如现有的未批处理引擎有着很好的性能。

        作者发现StreamBox对于处理无序的记录有着很好的吞吐量的性能。

6. Conclusion

        StreamBox通过使用所有CPU内核并行处理任何时期的任何记录实现高吞吐量和低延迟，并且数百万记录每秒吞吐量，与具有数百个CPU核心的群集上的分布式引擎相当。StreamBox几十毫秒的延迟，比其他大型引擎短20倍。