如何看待Kafka KSQL，其有哪些好的適用場景？

官方介紹:https://www.confluent.io/blog/ksql-open-source-streaming-sql-for-apache-kafka/

Github地址

https://github.com/confluentinc/ksql

謝邀

說下我對KSQL的淺見~ KSQL的運行方式是以運行SQL語句的方式執行Kafka Streams以查詢和分析業務數據。

我們對數據進行處理的一般做法是外部系統經connector =&> 消息隊列 =&> 數據處理引擎 =&> KV存儲/資料庫/ =&> Dashboard展示/SQL查詢。這一流程中的每一環我們都能想起一些響噹噹的名字。Kafka也是從0.10開始向上下游擴展，即開放了Kafka Connect介面意在涉足外部系統與Kafka的數據集成服務領域，又實現了Kafka Streams旨在提供輕量級的數據流式處理功能。不過數據處理完畢之後必然要將處理結果放入第三方存儲供後續展示或業務分析之用，不論是放入KV存儲、HDFS或資料庫。很多公司的數據分析師的主要工作可能就是從這些資料庫中查詢SQL來做數據分析，而這些數據分析師IT技術一般，通常只會寫SQL，讓他們自己寫代碼查HBASE是很困難的。故業界開源了像Hive、Kylin這樣的系統來降低這些分析人員的門檻。

對於一般常規性的分析指標（比如轉化率、各種漏斗等）由於其計算方法是固定的，故IT人員通常把它們做成報表直接呈現出來，這種需求我們使用Java版的Streams API寫程序即可實現，完全不需要使用KSQL這樣的工具。但問題在於分析師經常要做頭腦風暴的，今天想出一個點子也許就要馬上寫SQL獲取計算結果來驗證，也就是說他們的查詢大多是隨機的(ad-hoc)。事實上，針對這種ad-hoc查詢，很多框架應對起來都是很吃力的，即便如Kylin這樣按照「以空間換時間」的理念提前算好cube也不敢保證ad-hoc查詢的數據100%地落入cube中。如果要支持這種隨機的ad-hoc查詢，KSQL就是比較好的工具，他可以讓分析師們以SQL的方式立刻實現他們的查詢邏輯，而底層的流處理邏輯則由KSQL自動完成。我想這是KSQL最實際的使用場景。

另外一個重要的優勢是，KSQL是做流處理的，它處理的是無限數據集合(unbounded data set)，這是它和一般資料庫(對資料庫表的查詢通常是有限數據集)的一個典型區別，因此對比於批處理，流處理具有優勢的地方KSQL也都具備。