Heron：来自Twitter的新一代流处理引擎应用篇

【导语】 本文对比了Heron和常见的流处理项目，包括Storm、Flink、Spark Streaming和Kafka Streams，归纳了系统选型的要点。此外实践了Heron的一个案例，以及讨论了Heron在这一年开发的新特性。

在今年6月期的“基础篇”中，我们通过学习Heron[1][2][3]的基本概念、整体架构和核心组件等内容，对Heron的设计、运行等方面有了基本的了解。在这一期的“应用篇”中，我们将Heron与其他流行的实时流处理系统（Apache Storm[4][5]、Apache Flink[6]、Apache Spark Streaming[7]和Apache Kafka Streams[8]）进行比较。在此基础上，我们再介绍如何在实际应用中进行系统选型。然后我们将分享一个简单的案例应用。最后我们会介绍在即将完结的2017年里Heron有哪些新的进展。

实时流处理系统比较与选型

当前流行的实时流处理系统主要包括Apache基金会旗下的Apache Storm、Apache Flink、Apache Spark Streaming和Apache Kafka Streams等项目。虽然它们和Heron同属于实时流处理范畴，但是它们也有各自的特点。

Heron对比Storm（包括Trident）

在Twitter内部，Heron替换了Storm，是流处理的标准。

数据模型的区别

Heron兼容Storm的数据模型，或者说Heron兼容Storm的API，但是背后的实现完全不同。所以它们的应用场景是一样的，能用Storm的地方也能用Heron。但是Heron比Storm提供更好的效率，更多的功能，更稳定，更易于维护。

Storm Trident是Storm基础上的项目，提供高级别的API，如同Heron的函数式API。Trident以checkpoint加rollback的方式实现了exactly once；Heron以Chandy和Lamport发明的分布式快照算法实现了effectively once。

应用程序架构的区别

Storm的worker在每个JVM进程中运行多个线程，每个线程中执行多个任务。这些任务的log混在一起，很难调试不同任务的性能。Storm的nimbus无法对worker进行资源隔离，所以多个topology的资源之间互相影响。另外ZooKeeper被用来管理heartbeat，这使得ZooKeeper很容易变成瓶颈。

Heron的每个任务都是单独的JVM进程，方便调试和资源隔离管理，同时节省了整个topology的资源。ZooKeeper在Heron中只存放很少量的数据，heartbeat由tmaster进程管理，对ZooKeeper没有压力。

Heron对比Flink

Flink框架包含批处理和流处理两方面的功能。Flink的核心采用流处理的模式，它的批处理模式通过模拟块数据的的流处理形式得到。

数据模型的区别

Flink在API方面采用declarative的API模式。Heron既提供declarative模式API或者叫做functional API也提供底层compositional模式的API，此外Heron还提供Python[9]和C++[10]的API。

应用程序架构的区别

在运行方面，Flink可以有多种配置，一般情况采用的是多任务多线程在同一个JVM中的混杂模式，不利于调试。Heron采用的是单任务单JVM的模式，利于调试与资源分配。

在资源池方面，Flink和Heron都可以与多种资源池合作，包括Mesos/Aurora、YARN、Kubernetes等。

Heron对比Spark Streaming

Spark Streaming处理tuple的粒度是micro-batch，通常使用半秒到几秒的时间窗口，将这个窗口内的tuple作为一个micro-batch提交给Spark处理。而Heron使用的处理粒度是tuple。由于时间窗口的限制，Spark Streaming的平均响应周期可以认为是半个时间窗口的长度，而Heron就没有这个限制。所以Heron是低延迟，而Spark Streaming是高延迟。

Spark Streaming近期公布了一项提案，计划在下一个版本2.3中加入一个新的模式，新的模式不使用micro-batch来进行计算。

数据模型的区别

语义层面上，Spark Streaming和Heron都实现了exactly once/effectively once。状态层面上，Spark Streaming和Heron都实现了stateful processing。API接口方面，Spark Streaming支持SQL，Heron暂不支持。Spark Streaming和Heron都支持Java、Python接口。需要指出的是，Heron的API是pluggable模式的，除了Java和Python以外，Heron可以支持许多编程语言，比如C++。

应用程序架构的区别

任务分配方面，Spark Streaming对每个任务使用单个线程。一个JVM进程中可能有多个任务的线程在同时运行。Heron对每个任务都是一个单独的heron-instance进程，这样的设计是为了方便调试，因为当一个task失败的时候，只用把这个任务进程拿出来检查就好了，避免了进程中各个任务线程相互影响。

资源池方面，Spark Streaming和Heron都可以运行在YARN和Mesos上。需要指出的是Heron的资源池设计是pluggable interface的模式，可以连接许多资源管理器，比如Aurora等。读者可以查看[11]了解Heron支持的资源池。

Heron对比Kafka Streams

Kafka Streams是一个客户端的程序库。通过这个调用库，应用程序可以读取Kafka中的消息流进行处理。

数据模型的区别</