譯自Query Apache Kafka with SQL，作者 Stéphane Derosiaux。

 

Apache Kafka 在大型組織中廣泛用於儲存和交換數據，但它有一個大問題：你無法輕鬆查詢這些數據。 必須始終將資料複製到常規資料庫才能對其進行查詢。 這會減慢數據創新，並迫使企業建立可能發生任何事情的管道。

 

使組織中的每個團隊成員都能使用他們想要的解決方案來存取和利用即時數據，是一種變革性策略，它推動了廣泛採用和營運效率。 這不僅賦予了開發人員權力，也賦予了業務分析師、資料科學家和建構數據驅動型文化的決策者權力。

 

Kafka 僅用於串流 ETL 嗎？

Kafka 在 2011 年開源，當時大型資料庫和大數據盛行。 從那時起，我們已經了解了很多關於使用這種新方法在資料移動和轉換時保持資料動態的資訊。

 

如今，Kafka 主要用於將數據可靠地移動到每個人都可以使用的地方。 這可能是一個資料庫、資料倉儲或資料湖，使用者可以對其進行查詢（例如 PostgreSQL、ClickHouse、Elasticsearch 或Snowflake），分析團隊可以使用它，並且可以用來建立儀表板和機器學習模型。 Kafka 通常僅用於其實時功能，且不包含歷史資料－Kafka 中的預設資料保留時間只有幾天，之後資料會自動刪除。

 

Kafka 與串流處理技術（如 Kafka Streams、Apache Spark 或 Apache Flink）結合使用，以進行轉換、過濾資料、使用使用者資料進行豐富，並可能在各種來源之間進行一些聯接。 Kafka 非常適合建立串流擷取、轉換和載入 (ETL)，它可以即時擷取、轉換和將資料載入到另一個地方，這與在計劃的基礎上（每 X 分鐘）定義的傳統批次相反。

 

一切都很好，但 Kafka 有一個很大的缺點：它無法使資料可存取。

 

Kafka 對於查詢來說不是很好

Apache Kafka 通常是組織中所有資料在移入其他應用程式之前創建的地方。 然後所有應用程式透過 Kafka 進行通訊並產生數據。 但不知何故，這些數據對於包括資料科學家、分析師和產品所有者在內的非開發人員來說幾乎無法存取。

 

即使對於開發人員來說，探索和處理資料也不是一件容易的事，因為沒有像SQL這樣的簡單語言來用 Kafka 討論資料。 你通常需要外部工具（如Conduktor）或終端機中的高級命令列工具來查看和分析資料——但這只能做到這一步。

 

並非組織中的每個人都是精通技術的，而組織希望為每個人提供一致的體驗，以便平等地進行交流。 例如，他們希望整個團隊，無論他們對技術有多熟悉，都能夠在無需學習複雜的新工具的情況下開展新專案。

 

在 Kafka 領域，組織依賴資料工程團隊來建立必要的管道和 ETL，以使資料可存取。 這些團隊還使用 Debezium 等變更資料擷取 (CDC) 工具將資料移出 Kafka，這會稀釋資料所有權、安全性和責任。

 

但 Apache Kafka 不是資料庫…是嗎？

正如Martin Kleppmann 在2018 年Kafka 峰會舊金山分會上所討論的那樣：「Kafka 是一個資料庫嗎？」：Kafka 可以透過建立流處理器來實現資料庫的所有原子性、一致性、隔離性和持久性(ACID ) 要求。 Kafka 也完全支援一次性事務，Apache 的KIP-939提議正在出現，以支援兩階段提交 (2PC) 協議，以便與其他資料庫進行分散式事務。

 

有趣的是，Kleppman 得出的結論是“肯定沒有臨時查詢”，而且你必須將資料移到真正的資料庫中才能處理此類問題。 六年後，這是仍然存在的一個警告，並且減慢了所有想要使用 Kafka 的人的速度。

 

處理資料混亂

組織在 Kafka 和資料庫中擁有大量資料。 數據的品質各不相同。 規則並非處處相同。 沒有人對所有事情都有相同的看法。 很難知道數據在哪裡或真實來源在哪裡。 這就是我們所說的數據混亂。

 

將資料從 Kafka 複製到資料庫會增加一層複雜性。 由於安全模型根本不同，資料的擁有權和安全性變得脆弱，並且可能不一致。 Kafka和資料庫在資料保護方面有不同的方法。 這種不匹配很難修復，尤其是在添加資料屏蔽或字段級加密等要求時。

 

資料外洩事件突顯了生態系統中技能、一致性和成熟度的不足。 例如，法國政府在 3 月發生了一次違規行為，洩漏了多達 4,300 萬人的資料。

 

數據產品的快速成長加劇了組織內的數據版圖的分散性。 這種激增創造了資料孤島，每個孤島各自獨立運行，稀釋統一資料策略的潛力。 資料管道專案的臨時開發在內聚治理框架之外進行，導致組織容易受到不準確性和不一致性的影響。

 

SQL 是否是終局？

SQL 是一款非常著名且流行的程式語言，在TIOBE 指數中排名第 6 位，全球 40% 的開發人員都在使用它——其中有 78% 的人經常在工作中使用 SQL。

 

PostgreSQL是領先的資料庫協議，許多供應商都希望與之相容。 Grafana、Metabase、Tableau、DBeaver 和Apache Superset等工具都可以連接到提供與 PostgreSQL 相容的端點的服務。 擁有為任何主題提供此類端點的 Kafka 平台能夠使用這些工具進行資料視覺化和直接內省。

 

SQL 為建構統一的資料生態系統提供了堅實的基礎，而 Kafka 則作為其核心中的單一事實來源。 PostgreSQL 以其廣泛的兼容性和易於上手而脫穎而出，這要歸功於許多易於接近的供應商。 其開源特性、與開發環境無縫整合以及直接的設定和管理，使其成為可擴展性、多用性、靈活性和健全性的首選資料庫選擇。

 

透過對 Kafka 進行現代化改造以納入 SQL 功能，我們可以大幅減少對資料管道和複製的需求。 它還將帶來整體效率、成本效率、更簡單的治理以及更少的安全故障。

 

這樣做也能讓資料工程師直接融入產品團隊，而不是讓他們孤立在自己的筒倉中，擁有自己的資料路線圖，進而加強開發人員和分析團隊之間的協作。

 

AI 和機器學習 (ML) 的進一步發展

SQL 非常適合即席分析、儀表板或建立資料管道。 但它並非最適合處理資料科學和 AI/ML 所需的大量資料。 這就是 Apache Parquet 和 Apache Iceberg 等技術發揮作用的地方。

 

它們提供了基於列的系統和下推式篩選器最佳化，可有效查詢大量資料。 許多資料科學家喜歡它們，因為它們可以使用 Apache Spark、Pandas、Dask 和 Trino 等工具進行查詢。 這改進了資料可訪問性，並簡化了建立 AI/ML 應用程式的方式。

 

正如我們在對Kafka 峰會倫敦 2024 年的回顧中所分享的，隨著組織尋求以多種格式在 Kafka 中公開數據，Kafka 作為單一事實來源的能力正在成為現實。 Confluent 宣布了TableFlow，它可以將 Apache Kafka 主題無縫地將具體化為 Apache Iceberg 表格，而無需建立和維護資料管道。

 

鋪平解放數據之路

Conduktor 和 Kafka 具有支援即時資料需求的功能，可利用 SQL 處理線上分析處理 (OLAP) 和業務需求。 他們也透過 Parquet 和 Iceberg 等檔案格式來滿足人工智慧/機器學習要求。 透過這些途徑，他們正在為數據真正可訪問並針對各種消費偏好進行優化的那一天鋪平道路。 建立真正的產品資料並消除跨不同資料儲存的技術重複的需求，將導致更有效率和更安全的 data 資料生態系統。