写在阿里Blink正式开源之际

阿里最近要正式将内部Blink开源，搞Blink 的大牛也在 AI 前线公众号上推了文章，介绍Blink的优势重磅！阿里Blink正式开源，重要优化点解读 ， 首先 spark 君对于每秒处理多少数据量，单个作业处理数据量超过400T 这些标榜不是特别在意，因为这涉及到使用了多少资源，处理时长以及使用姿势，不说清楚就是无意义的。spark君比较在意的是文中提到的Blink的一些重要的feature，大致看有 5 个方面

• Hive的兼容性，Blink：为了打通元数据，我们重构了 Flink catalog 的实现，并且增加了两种 catalog，一个是基于内存存储的 FlinkInMemoryCatalog，另外一个是能够桥接 Hive metaStore 的 HiveCatalog。有了这个 HiveCatalog，Flink 作业就能读取 Hive 的 metaData，  spark君：这个功能怎么看怎么像从 spark 这边抄过来的，至少是借鉴，我们都知道，spark 定义了ExternalCatalog 用来管理操作数据库表或者注册函数等，然后分为 InMemoryCatalog 和HiveExternalCatalog ，连名字都差不多，到底是谁抄谁呢，spark君在平时使用中，感觉 spark sql 除了 像 hive 中带有buckets的table 等极少数几个操作不支持，spark 君敢说 Spark SQL支持绝大部分的Hive特征。
•  SQL/TableAPI的优化，Blink: 我们对 SQL engine 的架构做了较大的调整。提出了全新的 Query Processor（QP）， 它包括了一个优化层（Query Optimizer）和一个算子层（Query Executor）。这样一来，流计算和批计算的在这两层大部分的设计工作就能做到尽可能地复用,   spark 君：这个就对应 spark sql 里面的逻辑优化和物理执行两个流程吧，这个在这里就不用多说了吧，spark君一直孜孜不倦的给小伙伴们普及 spark逻辑优化和物理优化都做了什么，感觉spark在这块都优化的不能再优化了。至于说到 流批复用，我就默默提一下 structured streaming ,  完全架构在 spark sql 之上，一张无限流动的大表。看文章中重点强调的 BinaryRow 和  codegen 优化方式，这都是 spark 玩了很久很久的东西了，不了解的小伙伴，需要多看看相关的，后续spark君会专门抽文章介绍。
• 更好的runtime支持，Blink: 首先 Blink 引入了 Pluggable Shuffle Architecture，开发者可以根据不同的计算模型或者新硬件的需要实现不同的 shuffle 策略进行适配。此外 Blink 还引入新的调度架构，容许开发者根据计算模型自身的特点定制不同调度器。说道这个，spark君表示我对 spark 官方最佩服的一点就是源码里面体现出来的高度工程抽象能力，高内聚，低耦合，面向变化和接口编程，早早就支持调度全家桶了（standalone， yarn， mesos， k8s  spark2.3 之后也是原生的哦）。
• Zeppelin for Flink，  zeppelin 就是个脚手架和大杂烩，spark也早早的入坑了，这个是小功能，就不说了。 
• Flink Web， Blink 这次介绍出来的多种指标展示维度，看着不错，其实我对 spark 的界面是有些不满意的，特别是 针对 structured streaming 的指标展示，还是比较弱。

下面是 一位 spark 大牛的文章，里面很多观点和我的一致，在这里转发给大家看下：

前言

今天朋友圈有篇【阿里技术】发的文章，说Blink的性能如何强悍，功能现在也已经比较完善。譬如：

Blink 在 TPC-DS 上和 Spark 相比有着非常明显的性能优势，而且这种性能优势随着数据量的增加而变得越来越大。在实际的场景这种优势已经超过 Spark 三倍，在流计算性能上我们也取得了类似的提升。我们线上的很多典型作业，性能是原来的 3 到 5 倍。在有数据倾斜的场景，以及若干比较有挑战的 TPC-H query，流计算性能甚至得到了数十倍的提升。

什么时候可以享受这波红利

还要等待一段时间。要想享受Blink的加持，大家可能还要等待一段时间，因为除了功能合并，还有代码质量。代码质量理论上应该是没有原生flink好的。这个需要时间，不是靠人力就能搞定的。

一点忧思

阿里收购Flink母公司，然后马上发通告，说blink要合并进flink了，之前还是商量口吻。显然，这对于社区来说，是一个非常不友好的感觉。我猜测，社区部分优秀的人才（包括母公司）肯定会有人走的。开源项目对于PR的质量除了功能，更多的是架构，代码质量等等的考量。

那和Spark的对比怎么样？

Spark 和 Flink不在一个level级别战斗。Spark 从诞生没多久开始，就朝着AI方向发展，包括内置的mllib,深度学习后也马上抓住机遇，在2.2.x之后发力，DB公司开发了一套生态辅助系统，比如Spark deep Learning,Tensorframes, GraphFrames等等，另外还有众多第三方框架的加持。2.3-2.4在商业版本里则已经集成了如horovod等分布式深度学习框架，所以说，2.2.x之后，Spark的主战场早就已经是AI,而 Flink依然停留在流，批战场。

Flink,Spark性能好对机器学习有啥影响

有人会问，机器学习对性能不是很在乎么？现在flink性能据说那么好？到底有多好，这是一家之言，但是 在这些框架里
性能在AI方面不是很重要，因为他们对AI重在集成，而不是自己实现。这就意味着瓶颈是在数据交换以及AI框架自身之上。模型构件好进行预测，也是对应的AI框架自己去加载，提供预测接口，其他只是wrap一层而已。

盛夏即将发布的3.0则对AI更加友好，包括CPU/GPU的管理，K8s backend， 数据交换(Spark – AI框架)的提速，内部Barrier API 的等进一步的完，显然让Spark在AI领域进一步保持优势

 和AI集成的基础，Spark以有所沉淀

和AI集成的好坏，取决于Java/Scala语言和Python语言的互通的质量。Spark 在1.6之前就已经支持Python,经过这么多年的优化，已经有了很好的经验，最新的arrow引入让速度更是成两位数的提升。

Flink 盛夏之下的喧闹

这次关于bink 合并进flink的通告不是由社区主导发送，而是阿里技术发送，显然有喧宾夺主的意味，会加大他们（母公司和阿里巴巴）融合的难度。极端点，Flink可能就由一个社区项目变成一个公司产品。阿里开源了那么多东西，有几个达到了真正的国际影响力，并且处于持续的发展之中的？公司加持对于社区而言，短期是利好，但是如果干预多了，长期就不被看好了。

Presto是facebook开源的并且运作，一切以满足公司需求为最高优先级，虽然presto很优秀，但是社区没有主导权，极大的限制了他的发展，终于发生了分裂（大家可以自己搜搜）。

最后加一句

不要再拿Spark streaming 和Flink比了，请拿Structured streaming 以及Continue Processing 来和Flink比。为啥国内还在拿Spark Streaming 和Flink比？

因为惯性使然，structured streaming 新引入了一堆概念，并且限制也比较多，spark streaming大家把之前该遇到的问题都遇到了，而且也有一定的积累，要切换就没那么容易了。加上flink有阿里加持，宣传势头很大,可能有的直接就从，spark streaming 切到flink去了。

大家都在看

▼

spark sql源码系列:

是时候学习真正的spark技术了丨从0到1认识 spark sql丨spark sql 源码剖析 PushDownPredicate丨spark sql 源码剖析 OptimizeIn 篇

structured streaming 系列:

structured streaming 原理剖析丨structured streaming 碰上kafka丨structured streaming 是如何搞定乱序时间的

spark streaming 系列:

spark streaming 读取kafka各种姿势详解丨spark streaming流式计算中的困境与解决之道

spark core 系列:

彻底搞懂spark shuffle过程（1）丨彻底搞懂spark shuffle过程（2）丨spark内存管理-Tungsten框架探秘

spark 机器学习系列

关注【spark技术分享】

一起撸spark源码，一起玩spark最佳实践

原文始发于微信公众号（spark技术分享）：写在阿里Blink正式开源之际