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相比。
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相比。