前言
丑话说在前面，笔者无意于撩拨 Flink 和 Spark 两个群体的矛盾，社区间取长补短也好，互相抄袭也好，都不是个事，关键在于用户群体的收益。
在各种会上，经常会被问到 Spark 和 Flink 的区别，如何取舍？
下面从数据模型、运行时架构、调度、时延和吞吐、反压、状态存储、SQL 扩展性、生态、适用场景等方面来逐一分析。
1. 数据模型
Spark 的数据模型
Spark 最早采用 RDD 模型，达到比 MapReduce 计算快 100 倍的显著优势，对 Hadoop 生态大幅升级换代。RDD 弹性数据集是分割为固定大小的批数据，RDD 提供了丰富的底层 API 对数据集做操作。为持续降低使用门槛，Spark 社区开始开发高阶 API：DataFrame/DataSet，Spark SQL 作为统一的 API，掩盖了底层，同时针对性地做 SQL 逻辑优化和物理优化，非堆存储优化也大幅提升了性能。
Spark Streaming 里的 DStream 和 RDD 模型类似，把一个实时进来的无限数据分割为一个个小批数据集合 DStream，定时器定时通知处理系统去处理这些微批数据。劣势非常明显，API 少、难胜任复杂的流计算业务，调大吞吐量而不触发背压是个体力活。不支持乱序处理，把前面的 Kafka topic 设置为 1 个分区，鸡贼式缓解乱序问题。Spark Streaming 仅适合简单的流处理，会被 Structured Streaming 完全替代。
Spark Structured Streaming 提供了微批和流式两个处理引擎。微批的 API 虽不如 Flink 丰富，窗口、消息时间、trigger、watermarker、流表 join、流流 join 这些常用的能力都具备了。时延仍然保持最小 100 毫秒。当前处在试验阶段的流式引擎，提供了 1 毫秒的时延，但不能保证 exactly-once 语义，支持 at-least-once 语义。同时，微批作业打了快照，作业改为流式模式重启作业是不兼容的。这一点不如 Flink 做的完美。
综上，Spark Streaming 和 Structured Streaming 是用批计算的思路做流计算。其实，用流计算的思路开发批计算才是最优雅的。 对 Spark 来讲，大换血不大可能，只有局部优化。其实，Spark 里 core、streaming、structured streaming、graphx 四个模块，是四种实现思路，通过上层 SQL 统一显得不纯粹和谐。
Flink 的数据模型
Flink 采用 Dataflow 模型，和 Lambda 模式不同。Dataflow 是纯粹的节点组成的一个图，图中的节点可以执行批计算，也可以是流计算，也可以是机器学习算法，流数据在节点之间流动，被节点上的处理函数实时 apply 处理，节点之间是用 netty 连接起来，两个 netty 之间 keepalive，网络 buffer 是自然反压的关键。经过逻辑优化和物理优化，Dataflow 的逻辑关系和运行时的物理拓扑相差不大。这是纯粹的流式设计，时延和吞吐理论上是最优的。
Flink 在流批计算上没有包袱，一开始就走在对的路上。
2.运行时架构
Spark 运行时架构
批计算是把 DAG 划分为不同 stage，DAG 节点之间有血缘关系，在运行期间一个 stage 的 task 任务列表执行完毕，销毁再去执行下一个 stage；Spark Streaming 则是对持续流入的数据划分一个批次，定时去执行批次的数据运算。Structured Streaming 将无限输入流保存在状态存储中，对流数据做微批或实时的计算，跟 Dataflow 模型比较像。
Flink 运行时架构
Flink 有统一的 runtime，在此之上可以是 Batch API、Stream API、ML、Graph、CEP 等，DAG 中的节点上执行上述模块的功能函数，DAG 会一步步转化成 ExecutionGraph，即物理可执行的图，最终交给调度系统。节点中的逻辑在资源池中的 task 上被 apply 执行，task 和 Spark 中的 task 类似，都对应线程池中的一个线程。
在流计算的运行时架构方面，Flink 明显更为统一且优雅一些。
3.时延和吞吐
两家测试的 Yahoo benchmark，各说各好。benchmark 鸡肋不可信，笔者测试的结果，Flink 和 Spark 的吞吐和时延都比较接近。
4.反压
Flink 中，上游的算子消费流入到网络 buffer 的数据，如果下游算子处理能力不够，则阻塞网络 buffer，这样也就写不进数据，那么上游算子发现无法写入，则逐级把压力向上传递，直到数据源，这种自然反压的方式非常合理。Spark Streaming 是设置反压的吞吐量，到达阈值就开始限流，从批计算上来看是合理的。
5.状态存储
Flink 提供文件、内存、RocksDB 三种状态存储，可以对运行中的状态数据异步持久化。打快照的机制是给 source 节点的下一个节点发一条特殊的 savepoint 或 checkpoint 消息，这条消息在每个算子之间流动，通过协调者机制对齐多个并行度的算子中的状态数据，把状态数据异步持久化。
Flink 打快照的方式，是笔者见过最为优雅的一个。Flink 支持局部恢复快照，作业快照数据保存后，修改作业，DAG 变化，启动作业恢复快照，新作业中未变化的算子的状态仍旧可以恢复。而且 Flink 也支持增量快照，面对内存超大状态数据，增量无疑能降低网络和磁盘开销。
Spark 的快照 API 是 RDD 基础能力，定时开启快照后，会对同一时刻整个内存数据持久化。Spark 一般面向大数据集计算，内存数据较大，快照不宜太频繁，会增加集群计算量。
6. SQL 扩展性
Flink 要依赖 Apache Calcite 项目的 Stream SQL API，而 Spark 则完全掌握在自己手里，性能优化做的更足。大数据领域有一个共识：SQL 是一等公民，SQL 是用户界面。SQL 的逻辑优化和物理优化，如 Cost based optimizer 可以在下层充分优化。UDX 在 SQL 之上可以支持在线机器学习 StreamingML、流式图计算、流式规则引擎等。由于 SQL 遍地，很难有一个统一的 SQL 引擎适配所有框架，一个个 SQL-like 烟囱同样增加使用者的学习成本。
7.生态和适用场景
这两个方面 Spark 更有优势。
Spark 在各大厂实践多年，跟 HBase、Kafka、AWS OBS 磨合多年，已经成为大数据计算框架的事实标准，但也有来自 TensorFlow 的压力。14 年在生产环境上跑机器学习算法，大多会选择 Spark，当时我们团队还提了个 ParameterServer 的 PR，社区跟进慢也就放弃了。社区为赶造 SQL，错过了 AI 最佳切入时机。这两年 Spark+AI 势头正劲，Matei 教授的论文 Weld 想通过 monad 把批、流、图、ML、TensorFlow 等多个系统粘合起来，统一底层优化，想法很赞；处于 beta 阶段的 MLFlow 项目，把 ML 的生命周期全部管理起来，这些都是 Spark 新的突破点。
反观 Flink 社区，对周边的大数据存储框架支持较好，但在 FlinkML 和 Gelly 图计算方面投入极匮乏，16 年给社区提 PS 和流式机器学习，没一点进展。笔者在华为云这两年多时间，选择了 Flink 作为流计算平台核心，索性在 Flink 基础之上开发了 StreamingML、Streaming Time GeoSpatial、CEP SQL 这些高级特性，等社区搞，黄花菜都凉了。
企业和开发者对大数据 AI 框架的选择，是很重的技术投资，选错了损失会很大。不仅要看框架本身，还要看背后的公司。
Spark 后面是 Databricks，Databricks 背靠伯克利分校，Matei、Reynold Xin、孟祥瑞等高手如云。Databricks Platform 选择 Azure，14 年 DB 就用改造 notebook 所见即所得的大数据开发平台，前瞻性强，同时对 AWS 又有很好的支持。商业和技术上都是无可挑剔的。
Flink 后面是 DataArtisans，今年也推出了 data Artisans Platform，笔者感觉没太大新意，对公有云私有云没有很好的支持。DataArtisans 是德国公司，团队二三十人，勤勉活跃在 Flink 社区，商业上或许势力不足。
开源项目后面的商业公司若不在，项目本身必然走向灭亡，纯粹靠分散的发烧友的力量无法支撑一个成功的开源项目。Databricks 估值 1.4 亿美元，DataArtisans 估值 600 万美元，23 倍的差距。DataArtisans 的风险在于变现能力，因为盘子小所以有很大风险被端盘子，好在 Flink 有个好的 Dataflow 底子。这也是每个开源项目的难题，既要商业支撑开销，又要中立发展。
8.对比小结
| 对比项目 | Spark | Flink | 评分 |
|---|---|---|---|
| 数据模型 | RDD/DataFrame/DataSet, 批流 | DataFlow，流批 | Spark 4分；Flink 5分 |
| 运行时架构 | lambda架构 | DataFlow，优雅 | Spark 4分；Flink 5分 |
| 资源调度 | 支持yarn/mesos/k8s/standalone | 支持yarn/mesos/k8s/standalone | Spark 5分；Flink 4分 |
| 可靠的状态存储 | 多种可靠存储 | 多种存储，快照轻量灵活优雅 | Spark 4分；Flink 5分 |
| 时延和吞吐 | 高吞吐，时延毫秒和秒 | 高吞吐，时延毫秒 | Spark 4分；Flink 5分 |
| 反压 | 支持 | 支持，更优 | Spark 4分；Flink 5分 |
| SQL | 批流SQL | 流批SQL | Spark 5分；Flink 5分 |
| 生态 | 丰富，公有云支持更丰富 | 丰富 | Spark 5分；Flink 4分 |
| 商业能力 | 强，估值高 | 低，估值低，有风险 | Spark 5分；Flink 4分 |
| 合计 | Spark 40分；Flink 40分 |
Flink 和 Spark 在流计算方面各有优缺点，分值等同。Flink 在流批计算方面已经成熟，Spark 还有很大提升空间，此消彼长，未来不好说。
9.总结和展望
实时流计算技术已经成熟，大家可以放心使用。目前的问题在于应用场景推广，提升企业对云厂商的信任度，广泛应用流计算创造价值。而流计算与 AI 的结合，也会是未来可能的方向：
- StreamingML 在线机器学习
- StreamingGraph 在线图计算
- StreamingAI 实时 AI
- 流批合一
- 流存储
- 实时流计算 + 边缘计算、工业 IoT、车联网、智慧城市