<p>Hazelcast主要以开源缓存和内存数据网格技术（通常称为Hazelcast IMDG，或者只是Hazelcast）为人所熟知。然而过去的两年中，他们一直致力于一个新的、重要的开源项目Hazelcast Jet，近日，他们宣布了这项新技术的一个主要版本。</p>    <p>InfoQ与Hazelcast首席执行官Greg Luck和Jet核心团队工程师Marko Topolnik取得了联系，进一步了解此次发布的激动人心之处。</p>    <p><strong>InfoQ：据介绍，Jet是流处理领域的巨大改进。您能解释下为什么吗？</strong></p>    <p>Luck：Jet的主要目标是让运算速度快的大数据成为应用程序基础设施的一部分。类似Spark和Hadoop这样的技术过多地干扰了应用程序开发人员架构和思考。我们希望Jet可以为开发人员提供工具，让他们专注于问题本身，而不是应用程序管道构建。</p>    <p>Jet还提供了突破性的性能——我们有Jet和其他引擎的横向性能对比数据——全都是基于配备旋转磁盘的10节点集群测得——性能数据说明了一切。</p>    <p><strong>InfoQ：您能介绍下你们在Jet研发过程中所做的架构及技术决策吗？与当前市场中已有的一些同类产品——尤其是Apache Spark——相比，它有什么与众不同之处吗？</strong></p>    <p>Topolnik：我们决定，以“多任务处理（cooperative multithreading）”作为核心执行引擎建模的原则，也就是人们常说的“绿色线程”。这就是说，我们不是让操作系统调度我们的工作，而是有多少CPU内核可用就启动多少线程，运行任何东西都是这样。我们的基本处理单元，我们称之为tasklet，每次被调用时都会做一点工作实现与执行引擎的协作，然后就回归本身的处理工作。由于我们使用了具有智能批处理功能的有界并发队列，所以这种工作模式来得很自然：每个tasklet调用处理已经在队列中的数据。</p>    <p>我们为什么认为这是一个好方法呢？首先，上下文切换的成本几乎为零。从一个tasklet切换到下一个tasklet几乎不需要任何逻辑。其次，我们获得了CPU内核亲和性的效果：tasklet不会在线程之间跳来跳去，每个工作线程都极有可能固定在一个内核上。这意味着CPU缓存命中率会很高。最后，通过检查输入/输出队列，我们就可以立即知道哪个tasklet已经准备好了运行。如果我们使用本地线程，我们就必须使用阻塞队列，而这种队列采用相对重量级的wait/notify机制，我们必须受操作系统支配，必须由它决定什么时候运行我们的任务。</p>    <p>第二个重要的决策是在所有地方都使用单生产者/单消费者的并发队列。为了将N个上游tasklet和M个下游tasklet连接起来，我们需要NxM个队列；不过，这让我们可以在两端都使用速度极快的无等待算法。我们甚至不需要写入内存，因为我们使用了lazySet，它只需要在CPU的存储缓冲区上将数据项加入队列。在消费者端，在将整个队列存入线程本地存储后，我们只需要一个lazySet。</p>    <p>Luck：当然，这些想法受了Martin Thompson及其创立的Mechanical Sympathy的直接影响。</p>    <p>I<strong>nfoQ：Hazelcast IMDG已经有了一个相当巧妙&直观的划分方法。Jet对此有什么改进？除了简单地“将Runnable发送给一个特定的数据划分”之外，在其他什么场景下可以看到大幅的改善？</strong></p>    <p>Topolnik：将Runnable发送给一个划分类似于单个DAG顶点的工作。Jet的优势在于，它能够让顶点转换其读到的数据，生成不属于同一个划分的数据项，然后重新组织并发送给下游顶点，再次正确划分。由于任何类型的map-reduce操作的reduce单元都必须观察到所有具有相同键的数据项，所以这是至关重要的。为了最小化网络流量，Jet可以首先减少本地成员生成的数据切片，然后针对每个键只发送一个数据项给远程成员，而后者会将这些部分结果合并。</p>    <p>Luck：我们也有一个java.util.stream的分布式版本，它可以很好地与Jet架构配合，因为我们将源和汇作为Jet的核心部分。在未来版本中，我们还会将Map-with-Predicate作为一个源加入进来，让筛选和“场投影（field projection）”充当Jet的流数据源。</p>    <p><strong>InfoQ：您认为，在什么特殊的行业或场景中，Jet会产生特别的影响或者特别成功？</strong></p>    <p>Luck：我们认为，Jet对IoT、金融服务、支付处理、欺诈及其他大量使用CEP（复杂事件处理）的行业都将十分有利。我们觉得，对于Jet而言，关键是，当你在一个业务上下文中执行DAG运算时，它能发挥多大的作用，而不仅仅是作为分析工具的一部分。</p>    <p><strong>InfoQ：对于Jet，你们会遵循和IMDG一样的产品策略吗？也就是说，开源，但需要付费获得支持及高级功能</strong>。</p>    <p>Luck：还不一定。从今天（2月8日）开始，我们将为Jet提供专业的支持，和IMDG一样。Jet将可以很好地与IMDG结合，因此，我们预计，在Jet推出之后，IMDG的应用会增加，但是，Jet没有哪一部分是闭源的，将来也不会有。今年晚些时候，我们可能会增加管理监控作为付费特性，虽然那比较明确，但一切都还未定。</p>    <p>我们目前关注的不是将用Jet赚钱——我们只是想让它成为一个遵循Apache 2许可协议的、成功的开源项目。</p>    <p><strong>InfoQ：Jet的路线图是什么样的？</strong></p>    <p>Luck：现在发布的是0.3版本，之后我们计划每个月发布一次。</p>    <p>我们还计划在两周之后发布0.3.1——只是稍微整理下几个错过0.3版本的部分。特别地，0.3.1版本将和IMDG 3.8一起发布，而且还会增加Jet集群（甚至于已经在运行的任务）弹性扩展功能。</p>    <p>0.4版本应该会包含大量的性能方面的工作。虽然Jet的性能已经非常出众，但我们会对0.4做进一步的改进。我们还将增加JCache支持以及将IMDG监听器作为一个真正的流源。当前版本已经支持IMDG，但是作为一个批处理源，所以，我们还希望增加真正的流支持。</p>    <p>我们已经支持Kafka和HDFS，但还需要做一些性能工作及更多的文档，让它们进入到一等支持状态。</p>    <p>我们还有一些其他的特性，包括一个DAG可视化工具，我们希望将其作为一个Eclipse及IntelliJ插件发布。</p>    <p>我们希望先向社区推出Jet，然后听听社区的声音——那样一来，一旦Jet确定下来，路线图在很大程度上将是社区驱动的。</p>    <p> </p>    <p> </p>    <p>来自：http://www.infoq.com/cn/news/2017/02/HazlecastJetOSS</p>    <p> </p>