KSQL與Flink SQL的比較

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行代碼，它已經『修復』了你說的這個問題。。。。」

兩人的」針鋒相對「實在有些意思，特別是Stephen 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如何回應：）

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！