Kafka的作者Neha Narkhede在Confluent上發表了一篇博文，介紹了Kafka新引入的KSQL引擎——一個基于流的SQL。推出KSQL是為了降低流式處理的門檻，為處理Kafka數據提供簡單而完整的可交互式SQL接口。KSQL目前可以支持多種流式操作，包括聚合（aggregate）、連接（join）、時間窗口（window）、會話（session），等等。
與傳統SQL的主要區別
KSQL與關系型數據庫中的SQL還是有很大不同的。傳統的SQL都是即時的一次性操作，不管是查詢還是更新都是在當前的數據集上進行。而KSQL則不同，KSQL的查詢和更新是持續進行的，而且數據集可以源源不斷地增加。KSQL所做的其實是轉換操作，也就是流式處理。
KSQL的適用場景
1.實時監控
一方面，可以通過KSQL自定義業務層面的度量指標，這些指標可以實時獲得。底層的度量指標無法告訴我們應用程序的實際行為，所以基于應用程序生成的原始事件來自定義度量指標可以更好地了解應用程序的運行狀況。另一方面，可以通過KSQL為應用程序定義某種標準，用于檢查應用程序在生產環境中的行為是否達到預期。
2.安全檢測
KSQL把事件流轉換成包含數值的時間序列數據，然后通過可視化工具把這些數據展示在UI上，這樣就可以檢測到很多威脅安全的行為，比如欺詐、入侵，等等。KSQL為此提供了一種實時、簡單而完備的方案。
3.在線數據集成
大部分的數據處理都會經歷ETL（Extract——Transform——Load）這樣的過程，而這樣的系統通常都是通過定時的批次作業來完成數據處理的，但批次作業所帶來的延時在很多時候是無法被接受的。而通過使用KSQL和Kafka連接器，可以將批次數據集成轉變成在線數據集成。比如，通過流與表的連接，可以用存儲在數據表里的元數據來填充事件流里的數據，或者在將數據傳輸到其他系統之前過濾掉數據里的敏感信息。
4.應用開發
對于復雜的應用來說，使用Kafka的原生Streams API或許會更合適。不過，對于簡單的應用來說，或者對于不喜歡Java編程的人來說，KSQL會是更好的選擇。
KSQL的核心抽象
KSQL是基于Kafka的Streams API進行構建的，所以它的兩個核心概念是流（Stream）和表（Table）。流是沒有邊界的結構化數據，數據可以被源源不斷地添加到流當中，但流中已有的數據是不會發生變化的，即不會被修改也不會被刪除。表就是流的視圖，或者說它代表了可變數據的集合。它與傳統的數據庫表類似，只不過具備了一些流式語義，比如時間窗口，而且表中的數據是可變的。KSQL將流和表集成在一起，允許將代表當前狀態的表與代表當前發生事件的流連接在一起。
KSQL架構
KSQL是一個獨立運行的服務器，多個KSQL服務器可以組成集群，可以動態地添加服務器實例。集群具有容錯機制，如果一個服務器失效，其他服務器就會接管它的工作。KSQL命令行客戶端通過REST API向集群發起查詢操作，可以查看流和表的信息、查詢數據以及查看查詢狀態。因為是基于Streams API構建的，所以KSQL也沿襲了Streams API的彈性、狀態管理和容錯能力，同時也具備了僅一次（exactly once）語義。KSQL服務器內嵌了這些特性，并增加了一個分布式SQL引擎、用于提升查詢性能的自動字節碼生成機制，以及用于執行查詢和管理的REST API。
Kafka+KSQL要顛覆傳統數據庫
傳統關系型數據庫以表為核心，日志只不過是實現手段。而在以事件為中心的世界里，情況卻恰好相反。日志成為了核心，而表幾乎是以日志為基礎，新的事件不斷被添加到日志里，表的狀態也因此發生變化。將Kafka作為中心日志，配置KSQL這個引擎，我們就可以創建出我們想要的物化視圖，而且視圖也會持續不斷地得到更新。
KSQL的未來
KSQL目前還處于開發者預覽階段，作者還在收集社區的反饋。未來計劃增加更多的特性，包括支持更豐富的SQL語法，讓KSQL成為生產就緒的系統。
這里有KSQL的快速入門指南和一個演示程序。可以在Slack的#KSQL頻道上向作者提供反饋信息，或者如果發現Bug，可以在GitHub上提出來。
京公網安備 11010502049343號