Hazelcast 发布开源流处理引擎 Jet

  • Ben Evans
  • 谢丽

2017 年 2 月 14 日

话题:Java语言 & 开发架构

Hazelcast 主要以开源缓存和内存数据网格技术(通常称为 Hazelcast IMDG,或者只是 Hazelcast)为人所熟知。然而过去的两年中,他们一直致力于一个新的、重要的开源项目 Hazelcast Jet,近日,他们宣布了这项新技术的一个主要版本。

InfoQ 与 Hazelcast 首席执行官 Greg Luck 和 Jet 核心团队工程师 Marko Topolnik 取得了联系,进一步了解此次发布的激动人心之处。

InfoQ:据介绍,Jet 是流处理领域的巨大改进。您能解释下为什么吗?

Luck:Jet 的主要目标是让运算速度快的大数据成为应用程序基础设施的一部分。类似 Spark 和 Hadoop 这样的技术过多地干扰了应用程序开发人员架构和思考。我们希望 Jet 可以为开发人员提供工具,让他们专注于问题本身,而不是应用程序管道构建。

Jet 还提供了突破性的性能——我们有 Jet 和其他引擎的横向性能对比数据——全都是基于配备旋转磁盘的 10 节点集群测得——性能数据说明了一切。

InfoQ:您能介绍下你们在 Jet 研发过程中所做的架构及技术决策吗?与当前市场中已有的一些同类产品——尤其是 Apache Spark——相比,它有什么与众不同之处吗?

Topolnik:我们决定,以“多任务处理(cooperative multithreading)”作为核心执行引擎建模的原则,也就是人们常说的“绿色线程”。这就是说,我们不是让操作系统调度我们的工作,而是有多少 CPU 内核可用就启动多少线程,运行任何东西都是这样。我们的基本处理单元,我们称之为 tasklet,每次被调用时都会做一点工作实现与执行引擎的协作,然后就回归本身的处理工作。由于我们使用了具有智能批处理功能的有界并发队列,所以这种工作模式来得很自然:每个 tasklet 调用处理已经在队列中的数据。

我们为什么认为这是一个好方法呢?首先,上下文切换的成本几乎为零。从一个 tasklet 切换到下一个 tasklet 几乎不需要任何逻辑。其次,我们获得了 CPU 内核亲和性的效果:tasklet 不会在线程之间跳来跳去,每个工作线程都极有可能固定在一个内核上。这意味着 CPU 缓存命中率会很高。最后,通过检查输入 / 输出队列,我们就可以立即知道哪个 tasklet 已经准备好了运行。如果我们使用本地线程,我们就必须使用阻塞队列,而这种队列采用相对重量级的 wait/notify 机制,我们必须受操作系统支配,必须由它决定什么时候运行我们的任务。

第二个重要的决策是在所有地方都使用单生产者 / 单消费者的并发队列。为了将 N 个上游 tasklet 和 M 个下游 tasklet 连接起来,我们需要 NxM 个队列;不过,这让我们可以在两端都使用速度极快的无等待算法。我们甚至不需要写入内存,因为我们使用了 lazySet,它只需要在 CPU 的存储缓冲区上将数据项加入队列。在消费者端,在将整个队列存入线程本地存储后,我们只需要一个 lazySet。

Luck:当然,这些想法受了 Martin Thompson 及其创立的 Mechanical Sympathy 的直接影响。

InfoQ:Hazelcast IMDG 已经有了一个相当巧妙 & 直观的划分方法。Jet 对此有什么改进?除了简单地“将 Runnable 发送给一个特定的数据划分”之外,在其他什么场景下可以看到大幅的改善?

Topolnik:将 Runnable 发送给一个划分类似于单个 DAG 顶点的工作。Jet 的优势在于,它能够让顶点转换其读到的数据,生成不属于同一个划分的数据项,然后重新组织并发送给下游顶点,再次正确划分。由于任何类型的 map-reduce 操作的 reduce 单元都必须观察到所有具有相同键的数据项,所以这是至关重要的。为了最小化网络流量,Jet 可以首先减少本地成员生成的数据切片,然后针对每个键只发送一个数据项给远程成员,而后者会将这些部分结果合并。

Luck:我们也有一个 java.util.stream 的分布式版本,它可以很好地与 Jet 架构配合,因为我们将源和汇作为 Jet 的核心部分。在未来版本中,我们还会将 Map-with-Predicate 作为一个源加入进来,让筛选和“场投影(field projection)”充当 Jet 的流数据源。

InfoQ:您认为,在什么特殊的行业或场景中,Jet 会产生特别的影响或者特别成功?

Luck:我们认为,Jet 对 IoT、金融服务、支付处理、欺诈及其他大量使用 CEP(复杂事件处理)的行业都将十分有利。我们觉得,对于 Jet 而言,关键是,当你在一个业务上下文中执行 DAG 运算时,它能发挥多大的作用,而不仅仅是作为分析工具的一部分。

InfoQ:对于 Jet,你们会遵循和 IMDG 一样的产品策略吗?也就是说,开源,但需要付费获得支持及高级功能。

Luck:还不一定。从今天(2 月 8 日)开始,我们将为 Jet 提供专业的支持,和 IMDG 一样。Jet 将可以很好地与 IMDG 结合,因此,我们预计,在 Jet 推出之后,IMDG 的应用会增加,但是,Jet 没有哪一部分是闭源的,将来也不会有。今年晚些时候,我们可能会增加管理监控作为付费特性,虽然那比较明确,但一切都还未定。

我们目前关注的不是将用 Jet 赚钱——我们只是想让它成为一个遵循 Apache 2 许可协议的、成功的开源项目。

InfoQ:Jet 的路线图是什么样的?

Luck:现在发布的是 0.3 版本,之后我们计划每个月发布一次。

我们还计划在两周之后发布 0.3.1——只是稍微整理下几个错过 0.3 版本的部分。特别地,0.3.1 版本将和 IMDG 3.8 一起发布,而且还会增加 Jet 集群(甚至于已经在运行的任务)弹性扩展功能。

0.4 版本应该会包含大量的性能方面的工作。虽然 Jet 的性能已经非常出众,但我们会对 0.4 做进一步的改进。我们还将增加 JCache 支持以及将 IMDG 监听器作为一个真正的流源。当前版本已经支持 IMDG,但是作为一个批处理源,所以,我们还希望增加真正的流支持。

我们已经支持 Kafka 和 HDFS,但还需要做一些性能工作及更多的文档,让它们进入到一等支持状态。

我们还有一些其他的特性,包括一个 DAG 可视化工具,我们希望将其作为一个 Eclipse 及 IntelliJ 插件发布。

我们希望先向社区推出 Jet,然后听听社区的声音——那样一来,一旦 Jet 确定下来,路线图在很大程度上将是社区驱动的。

查看英文原文:Hazelcast release Jet, open-source stream processing engine

Java语言 & 开发架构