Kafka猛然醒來，突然變成了資料庫

02-03

有時候，資料庫就像一堆蠟板，可以堆疊和歸整來進行更新；而如今，有時候資料庫更像一條河流，形狀取決於流經的地域，但是資料庫在不斷變化和流動，而這種流動恰恰比其他任何因素更加定義了驅動業務發展的信息。沒有時間使資料庫持久化、整理並查詢資料庫。

在這種情況下，將資料庫徑直嵌入到該數據流中有其道理，這也正是Confluent所做的，這家公司使Apache Kafka實現了商業化，而Apache Kafka是由商務社交網路LinkedIn創建，在2011年初開源的一種分散式消息隊列架構。眾所周知，Kafka最初是一種數據流服務，將數據傳送到諸如Hadoop之類的系統，但是它本身正在逐漸成為一個平台。實際上，KSQL數據流資料庫正是將Kafka轉變成一種正宗平台的那個缺失的環節，也是Confluent的聯合創始人尼哈·納克赫德（Neha Narkhede）長期想要搞的技術，他當初幫助開發了Kafka及相關的Samza數據流處理框架，這種框架在LinkedIn將Kafka和Hadoop混合起來。

我們生活在一個完全顛倒的世界，資料庫正試圖添加數據流函數，而數據流伺服器正變成資料庫。許多現代應用系統以消息傳送為中心（比如金融服務應用已存在了幾十年），尤其是需要為數百萬、數千萬甚至數十億用戶確保高性能的那些應用系統，然後數據流服務和資料庫服務依託於這些應用。

KSQL覆蓋在Kafka上面有其道理，但這並不意味著因此很容易將源源不斷的數據流轉換到外觀感覺如同傳統的SQL驅動型關係資料庫的資料庫。納克赫德告訴IT外媒The Next Platform，SQL介面的主要目的是，為使用基於Kafka的數據流服務降低准入門檻，這就好比Hadoop上的SQL覆蓋層旨在讓普通的SQL用戶更容易充分利用在Hadoop上運行的數據湖，而過去不得不編寫MapReduce腳本，以便對它提出問題。

Kafka本身是結合Scala和Java編寫而成的，Kafka Streams數據流處理器好比Spark Streaming、Flink及類似系統，將其表覆蓋內容存儲到分散式RocksDB數據存儲系統中。（RocksDB是一種低級存儲引擎（http://rocksdb.org/），處於谷歌Spanner數據存儲系統的CockroachDB克隆版的核心，RocksDB本身源自Google開源、受到谷歌的BigTable和Spanner資料庫服務啟發的LevelDB鍵/值存儲引擎。）RocksDB數據存儲區在伺服器集群上加以分片和分布，這恰恰為Kafka賦予了帶寬和彈性。Samza將Hadoop的YARN作業調度程序和數據複製功能與Kafka（因而現在的KSQL）整合成一個應用程序框架。

編者註：當然了，如果哪天早上Kafka醒來，發現已變成了CockroachDB，那將會有趣得多。

KSQL是完全用Java編寫的，這是Confluent從頭開始創建的一種分散式實時SQL引擎，如今該公司開源該SQL引擎（採用Apache 2.0許可證），這與LinkedIn當初開源Kafka如出一轍。KSQL覆蓋層支持各種數據流函數，比如開窗聚合以便流式傳送表連接，目前正處於開發者預覽版狀態。納克赫德表示，Confluent想在接下來的四到六個月，徵集Kafka社區的反饋意見，看看如何才能最好地調整或改動，然後將其商用、用於生產環境。KSQL還沒有準備好迎來黃金時段。

對於剛接觸數據流的人來說，一個顯而易見的問題是：為什麼將資料庫放到數據流層。

納克赫德解釋道：「大多數關係資料庫用於對存儲的數據執行按需查找和修改這類操作。KSQL目前還不是旨在執行查詢――它很快會支持這種功能，而是旨在執行連續查詢；從某種意義上來說，它正在徹底顛覆資料庫。關係資料庫擁有事務日誌，這是系統的數據源或真相源（source of truth），而它擁有從該日誌派生而來的表，表是最重要的構件。如果使用Kafka和KSQL，日誌是最重要的構件，表是派生視圖，並存儲在RocksDB中，對這些表所作的更新可建模成數據流。KSQL就是位於Kafka數據流表上面的介面，你可以將數據作為數據流來讀取（每個更新獨立於所有其他更新），也可以作為表來讀取（每個更新可能是對進入到數據流的上一個更新的更新）。一旦你有了數據流表，可以將它們連接起來，或者對它們執行聚合操作，或者在將來某個時候查詢這些表。這樣的好處是，表實際上與傳統資料庫中的表全然不同，原因就在於每當新的事件到達數據流，表不斷加以更新。數據流進來時，查詢會生成更多事件，或者更新表。」

關係資料庫有一個類似的概念，名為物化視圖（materialized view）：信息發生變化後，物化視圖會自動更新從許多資料庫表的連接和聚合而來的派生表。源表中的數據若有更新，不斷運行的查詢會運行，但是這些數據和派生表必須不斷被寫入到資料庫底層的磁碟存儲設備。KSQL是為一直變化的數據設計的，而不是為很少變化的數據設計的，並不斷流式傳送可實時查詢的物化視圖。

往數據流引擎上添加SQL層的並非只有Confluent這一家。與之競爭的Apache Flink數據流處理框架有一個基於Apache Calcite項目的SQL引擎，該框架脫胎於柏林技術大學、柏林洪堡大學和波茨坦大學哈索普拉特納研究所三方合作的Stratosphere項目。 PipelineDB是一個數據流資料庫層，作為PostgreSQL資料庫和Vertica資料庫的擴展而運行。Spark Streaming是Spark內存資料庫的數據流層，它有自己的DataFrame和SQL層，允許查詢數據流。

嚴格來說，面向Kafka的KSQL資料庫層不符合ANSI SQL標準，這主要是由於流媒體平台所需要的數據流函數不是那些資料庫標準的一部分。關係資料庫以表為中心，Kafka和KSQL以數據流為中心，KSAL資料庫實際上來源於數據流。（就像Facebook創建的HBase資料庫覆蓋層其實來源於Hadoop分散式文件系統。）納克赫德表示，關係資料庫上司空見慣的SQL開窗函數需要大量修改，才能支持數據流。他補充說，在數據流系統上的所有SQL層都是如此。

Kafka Streams和KSQL不需要很龐大的系統。如果一台標準的X86伺服器在兩個插槽上有16個到24個核心，另外搭載合理的內存和磁碟數量，如果輸入輸出需要的話，可能還需要一些快閃記憶體，它就可以勝任重任。對於大多數客戶來說，集群中Kafka節點之間的10 Gbps乙太網結構（Ethernet fabric）就足夠了。這完全取決於數據的性質和使用數據的應用。在延遲很重要的場合，可能需要容量更多的內存和快閃記憶體以及速度更快的網路，甚至可能需要更多的計算，或至少需要速度更快的計算。如果你需要更強大的數據流功能，只需要為Kafka集群添加更多節點。

商業級KSQL的包裝和定價細節還沒有透露，價格不太可能透露。