Confluent公司于2017年11月宣布KSQL进化到1.0版本，标志着KSQL已经可以被正式用于生产环境。自那时起，整个Kafka发展的重心都偏向于KSQL——这一点可以从Confluent官方博客中KSQL出现的频率之高看出端倪。鉴于最近周围有很多小伙伴都在讨论KSQL，我突然想起了去年9月份Apache Flink“掌门人” Stephan Ewen所写的关于KSQL V.S. Flink SQL的一篇博客，里面很多有意思的观点非常值得品味~~
事情起源于去年8月底Confluent公司的产品经理Michael G. Noll在Twitter上发布了一条消息：
大概的意思是KSQL和Flink SQL一个关键的区别在于：KSQL是纯SQL语言的扩展，你不需要使用Java或Scala写程序的方式来实现，而反观上图右边的Flink SQL，用户必须手动编写一些代码与之结合使用。这样来看，使用KSQL要比Flink SQL简单得多。
发完这条Twitter之后，Flink掌门人Stephan Ewen立刻做出了回应：
“如果这就是你说的KSQL相对于Flink SQL的最大优势，那么看看我下面的这20行代码，它已经‘修复’了你说的这个问题。。。。”
两人的”针锋相对“实在有些意思，特别是Stephan Ewen于第二天在Flink官方博客上发布了一篇博文，里面详细对比了KSQL与Flink SQL的区别，更人觉得有下面让我们来看一看。（值得一提的是，Ewen对比的KSQL还是1.0之前的Demo版本，里面的很多内容在今天看来也许已经过时了。。。）
首先，Ewen正面承认了Flink SQL确实是Java/Scala + SQL的嵌入式混搭方式，而KSQL则是SQL-like Only，即纯SQL的方式。这种区别会有这么大的关注令Ewen始料未及，并且他给出了两种实现方式各自的应用场景。Ewen认为：纯SQL最适合于ad hoc查询以及数据分析之用，而嵌入式的SQL语句方式则主要用于数据管道。Flink社区之所以选择第二种方式主要是因为它主要满足了早期Flink SQL用户的场景。另外这种方式还无缝支持类型检查以及与Flink 其他API的天然适配。当然，纯SQL的方式也是非常有用的，Flink已有也必然会支持。事实上， Ewen已经实现了一个简单的wrapper实现了在Flink中使用纯SQL。
第二，从线上部署情况来看，Ewen坦言Flink SQL已经成功应用于很多大公司，如Uber、阿里巴巴以及华为，但KSQL依然还在Demo阶段(至少在去年9月份)。用户如果要立刻在线上环境部署并使用streaming SQL，那么显然Flink SQL是更好的选择。
第三，Flink SQL底层是统一化的批处理和流处理机制——事实上Flink将批处理仅仅当做是流处理的一种特殊情况来实现，故我们可以安全地认为Flink SQL同时支持批处理和流式处理，而KSQL目前还不支持批处理，因此对于那些想在静态数据集合或静态数据文件上执行SQL查询的用户可以使用Flink SQL。
第四，Flink SQL使用的标准的SQL语言，而KSQL集成了一组它特有的命令，并非扩展自标准SQL语言。如果SQL的通用度对用户来说很重要的话，那么应该使用Flink SQL。
第五，Flink SQL本身支持UDF、常用的聚合函数以及join，但目前KSQL尚未提供诸如UDF等功能。
第六，虽然也成立了Data Artisans公司用于企业级的Flink部署，但Flink SQL本质上依然还是由Apache Flink社区来开发，特别是有像Uber、阿里巴巴以及华为这样的大公司参与。反观KSQL，它已经不再由Apache Kafka社区维护，而是由Confluent公司完全独立管理，故开发的活跃度上可能无法与Flink SQL相比。
可以想见，Ewen在这篇文章中力推Flink SQL。我十分期待KSQL 1.0发布之后Confluent如何回应：）