解读 2018：13 家开源框架谁能统一流计算？

2018 年接近尾声，I我策划了“解读 2018”年终技术盘点系列文章，希望能够给读者清晰地梳理出重要技术领域在这一年来的发展和变化。本文是实时流计算 2018 年终盘点，作者对实时流计算技术的发展现状进行了深入剖析，并对当前大火的各个主流实时流计算框架做了全面、客观的对比，同时对未来流计算可能的发展方向进行预测和展望。

今年实时流计算技术为何这么火

今年除了正在热火落地的 AI 技术，实时流计算技术也开始步入主流，各大厂都在不遗余力地试用新的流计算框架，升级替换 Storm 这类旧系统。上半年 P2P 狂想曲的骤然破灭，让企业开始正视价值投资。互联网下半场已然开始，线上能够榨钱的不多了，所以，技术和资本开始赋能线下，如拼多多这类奇思妙想剑走偏锋实在不多。

而物联网这个早期热炒的领域连接线上线下，如今已积累的足够。物联网卡包年资费降到百元以下，NB-IoT 技术的兴起在畜牧业、新农业、城市管理方面都凸显极大价值。各大厂都在血拼智能城市、智慧工厂、智慧医疗、车联网等实体领域。但，这些跟实时流计算有几毛钱的关系？

上述领域有一个共同的特点，那就是实时性。城市车流快速移动、工厂流水线不等人、医院在排号、叫的外卖在快跑，打车、点餐、网购等等，人们无法忍受长时间等待，等待意味着订单流失。所以，毫秒级、亚秒级大数据分析就凸显极大价值。流计算框架和批计算几乎同时起步，只不过流计算现在能挖掘更大的利益价值，才会火起来。

整理了一份2018年合适程序员学习的大数据的学习资料需要的加群QQ群：834325294 注明CSDN既可免费获取

实时流计算框架一览

目前首选的流计算引擎主要是 Flink 和 Spark，第二梯队 Kafka、Pulsar，小众的有 Storm、JStorm、nifi、samza 等。下面逐一简单介绍下每个系统优缺点。

Flink 和 Spark是分布式流计算的首选，下文会单独对二者做对比分析。

Storm、JStorm、Heron：较早的流计算平台。相对于 MapReduce，Storm 为流计算而生，是早期分布式流计算框架首选。但 Storm 充其量是个半成品，ack 机制并不优雅，exactly-once 恰好一次的可靠性语义不能保证。不丢数据、不重复数据、不丢也不重地恰好送达，是不同可靠性层次。Clojure 提供的 LISP 方言反人类语法，学习成本极为陡峭。后来阿里中间件团队另起炉灶开发了 JStorm。JStorm 在架构设计理念上比 Storm 好些，吞吐、可靠性、易用性都有大幅提升，容器化跟上了大势。遗憾的是，阿里还有 Blink（Flink 改进版），一山不容二虎，JStorm 团队拥抱变化，项目基本上停滞了。另起炉灶的还有 twitter 团队，搞了个 Heron，据说在 twitter 内部替换了 Storm，也经过了大规模业务验证。但是，Heron 明显不那么活跃，乏善可陈。值得一提的是，Heron 的存储用了 twitter 开源的另一个框架 DistributedLog。

DistributedLog、Bookkeeper、Pulsar、Pravega：大家写 Spark Streaming 作业时，一定对里面 kafka 接收到数据后，先保存到 WAL（write ahead log）的代码不陌生。DistributedLog 就是一个分布式的 WAL（write ahead log）框架，提供毫秒级时延，保存多份数据确保数据可靠性和一致性，优化了读写性能。又能跑在 Mesos 和 Yarn 上，同时提供了多租户能力，这跟公有云的多租户和企业多租户特性契合。Bookeeper 就是对 DistributedLog 的再次封装，提供了高层 API 和新的特性。而 Pulsar 则是自己重点做计算和前端数据接入，赶上了 serverless 潮流，提供轻量级的 function 用于流计算，而存储交给了 DistributedLog。Pulsar 在流计算方面有新意，但也只是对 Flink 和 Spark 这类重量级框架的补充。笔者认为，Pulsar 如果能在 IoT 场景做到舍我其谁，或许还有机会。 Pravega 是 Dell 收购的团队，做流存储，内部也是使用 Bookeeper，主要用于 IoT 场景。四者关系大致如此。

Beam、Gearpump、Edgent：巨头的布局。三个项目都进入 Apache 基金会了。Beam 是 Google 的，Gearpump 是 Intel 的，Edgent 是 IBM 的，三巨头提前对流计算做出了布局。Gearpump 是以 Akka 为核心的分布式轻量级流计算，Akka stream 和 Akka ht