數(shù)據(jù)管理向數(shù)據(jù)湖的轉(zhuǎn)變確實(shí)是必然的，也是一次全平臺(tái)的變革。
數(shù)據(jù)湖將成為管理大量原始、非結(jié)構(gòu)化和半結(jié)構(gòu)化數(shù)據(jù)的基礎(chǔ)。它可以將歷史數(shù)據(jù)存儲(chǔ)為單一事實(shí)來源，這對(duì)于在不同部門和團(tuán)隊(duì)之間保持?jǐn)?shù)據(jù)一致性、完整性和可信度是至關(guān)重要的。
通過集成Apache Spark、Trino或ClickHouse等計(jì)算引擎，data lake變?yōu)閐ata lakehouse。這不僅有助于存儲(chǔ)大量數(shù)據(jù)，而且有助于高效處理數(shù)據(jù)。
Apache Kafka是一種廣泛使用的事件流平臺(tái)，幾乎所有的公司都在使用。起初，Kafka一直被作為數(shù)據(jù)管道來進(jìn)行實(shí)現(xiàn)，隨著其持久化能力與可靠性，它也被視為現(xiàn)代數(shù)據(jù)技術(shù)中的“新興的數(shù)據(jù)存儲(chǔ)庫(kù)”。
許多數(shù)據(jù)工程師使用 Kafka 保存最近讀取的數(shù)據(jù)，通常持續(xù) 7 天到一個(gè)月，然后再將這些數(shù)據(jù)傳輸?shù)綌?shù)據(jù)湖中。
在印象中“事件流平臺(tái)是針對(duì)實(shí)時(shí)數(shù)據(jù)的，而數(shù)據(jù)湖是針對(duì)歷史數(shù)據(jù)的”。然而，隨著數(shù)據(jù)組件的發(fā)展，越來越多的表明 Kafka 正在演變成一種新形式的數(shù)據(jù)湖。
一、為什么說Kafka是數(shù)據(jù)湖？
數(shù)據(jù)湖是一個(gè)集中式存儲(chǔ)庫(kù)，允許您存儲(chǔ)任意規(guī)模的所有結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)。與以結(jié)構(gòu)化和有組織的方式存儲(chǔ)數(shù)據(jù)的數(shù)據(jù)倉(cāng)庫(kù)不同，數(shù)據(jù)湖以原始、本機(jī)格式保留數(shù)據(jù)，通常采用扁平架構(gòu)。
目前流行的數(shù)據(jù)湖管理框架有三種，即Apache Iceberg、Apache Hudi和Delta Lake。雖然這些系統(tǒng)都有其獨(dú)特的功能和優(yōu)勢(shì)，但這三個(gè)系統(tǒng)都被廣泛用于大規(guī)模存儲(chǔ)和管理歷史數(shù)據(jù)。
它們的設(shè)計(jì)和功能使處理大量數(shù)據(jù)變得更加容易，并且它們與 Apache Spark、Flink 等流行計(jì)算引擎的集成功能使它們適合各種大數(shù)據(jù)應(yīng)用程序和分析用例。
Kafka 擁有所有數(shù)據(jù)湖屬性
Kafka 本質(zhì)上非常適合作為數(shù)據(jù)湖。在討論 Kafka 是否是數(shù)據(jù)湖的新形式之前，我們首先檢查一下 Kafka 是否具備成為數(shù)據(jù)湖所需的所有屬性。
ACID屬性：正如 Martin Kleppmann 在 2018 年舊金山 Kafka 峰會(huì)主題演講“ Kafka 是數(shù)據(jù)庫(kù)嗎？”中強(qiáng)調(diào)的那樣。，Kafka 已經(jīng)發(fā)展到包含所有類似數(shù)據(jù)庫(kù)的屬性，特別是原子性、一致性、隔離性和持久性 (ACID)。雖然許多人使用 Kafka 只存儲(chǔ)最近的數(shù)據(jù)，但 Kafka 實(shí)際上具有無限保留性，類似于現(xiàn)代數(shù)據(jù)湖。這種功能使 Kafka 成為存儲(chǔ)大量數(shù)據(jù)的有吸引力的選擇。
分層存儲(chǔ)：人們猶豫是否使用 Kafka 存儲(chǔ)長(zhǎng)期數(shù)據(jù)的一個(gè)關(guān)鍵原因是認(rèn)為 Kafka 是基于高性能機(jī)器的，其使用價(jià)格昂貴。但這已經(jīng)是曾經(jīng)的事實(shí)，Kafka 的經(jīng)典設(shè)計(jì)需要將數(shù)據(jù)存儲(chǔ)在計(jì)算實(shí)例中，這可能比對(duì)象存儲(chǔ)或HDFS存儲(chǔ)昂貴得多。然而，這種情況已經(jīng)改變。Confluence 構(gòu)建的最新版本 Kafka以及Redpanda和Apache Pulsar等其他流行的事件流平臺(tái)都采用了分層存儲(chǔ)，將冷數(shù)據(jù)存儲(chǔ)在廉價(jià)的對(duì)象存儲(chǔ)中，從而降低了成本并使得持久數(shù)據(jù)成為可能。這種新設(shè)計(jì)使 Kafka 適合以低成本存儲(chǔ)大量數(shù)據(jù)，而無需擔(dān)心可擴(kuò)展性。
存儲(chǔ)實(shí)時(shí)數(shù)據(jù)：雖然許多人使用數(shù)據(jù)湖來存儲(chǔ)歷史數(shù)據(jù)，但現(xiàn)代數(shù)據(jù)湖正在不斷發(fā)展并變得越來越實(shí)時(shí)，例如越來越多的人使用數(shù)據(jù)湖來支持流批一體的能力。這種演變是自然的，因?yàn)楝F(xiàn)代應(yīng)用程序和設(shè)備可以連續(xù)生成大量數(shù)據(jù)。因此，數(shù)據(jù)湖正在實(shí)施優(yōu)化以允許實(shí)時(shí)提取數(shù)據(jù)。作為一個(gè)事件流平臺(tái)，Kafka 本質(zhì)上支持實(shí)時(shí)數(shù)據(jù)攝取。其架構(gòu)非常適合存儲(chǔ)快速移動(dòng)的實(shí)時(shí)數(shù)據(jù)和緩慢移動(dòng)的歷史數(shù)據(jù)。
存儲(chǔ)不同類型的數(shù)據(jù)：Kafka 可以處理多種數(shù)據(jù)類型，從關(guān)系數(shù)據(jù)等結(jié)構(gòu)化數(shù)據(jù)，到 JSON 和 Avro 等半結(jié)構(gòu)化數(shù)據(jù)，甚至文本文檔、圖像和視頻等非結(jié)構(gòu)化數(shù)據(jù)（盡管不常見）。這種多功能性在當(dāng)今多樣化的數(shù)據(jù)環(huán)境中至關(guān)重要，它使 Kafka 能夠充當(dāng)組織所有數(shù)據(jù)的集中存儲(chǔ)庫(kù)，從而降低管理多個(gè)存儲(chǔ)解決方案的復(fù)雜性和開銷。
二、Kafka適合成為新的數(shù)據(jù)湖嗎？
Kafka 擁有數(shù)據(jù)湖的所有屬性，但 Kafka 是否有潛力成為生產(chǎn)中的新數(shù)據(jù)湖？
這里有支持這個(gè)觀點(diǎn)的理由：
作為Data Source：許多業(yè)務(wù)直接將數(shù)據(jù)提取到 Kafka 中，然后再將其傳輸?shù)綌?shù)據(jù)倉(cāng)庫(kù)或其他存儲(chǔ)系統(tǒng)中。如果使用Kafka作為永久保留數(shù)據(jù)的數(shù)據(jù)湖，就消除了在不同系統(tǒng)之間重新定位數(shù)據(jù)的必要性。消除數(shù)據(jù)移動(dòng)不僅可以降低成本，還可以最大限度地減少數(shù)據(jù)不一致和丟失的可能性。
單一事實(shí)來源：利用 Kafka 作為數(shù)據(jù)湖意味著它可以作為整個(gè)組織真正的單一事實(shí)來源。數(shù)據(jù)不一致的發(fā)生是因?yàn)槿藗冝D(zhuǎn)換數(shù)據(jù)。但如果我們使用數(shù)據(jù)源作為數(shù)據(jù)目的地，那么我們就不會(huì)遇到任何數(shù)據(jù)不一致的問題。此外，這種方法通過減少需要維護(hù)、同步和集成的系統(tǒng)數(shù)量，顯著簡(jiǎn)化了數(shù)據(jù)架構(gòu)，從而使基礎(chǔ)設(shè)施更易于管理、更不易出錯(cuò)且更具成本效益。
豐富的生態(tài)系統(tǒng)：Kafka 擁有非常豐富且強(qiáng)大的生態(tài)系統(tǒng)，用于從各種數(shù)據(jù)源獲取數(shù)據(jù)，并且大多數(shù)計(jì)算引擎可以輕松使用來自 Kafka 的數(shù)據(jù)。這種靈活性極大地促進(jìn)了 Kafka 與現(xiàn)有系統(tǒng)和工作流程的集成，從而減少了采用 Kafka 作為數(shù)據(jù)湖所需的工作量和復(fù)雜性。此外，Kafka 的功能不僅僅限于數(shù)據(jù)攝取和存儲(chǔ)。它還本身提供輕量級(jí)流處理功能（通過Kafka Streams），這意味著數(shù)據(jù)可以在攝取時(shí)實(shí)時(shí)處理。對(duì)于需要實(shí)時(shí)分析和決策能力的組織來說，這是一個(gè)顯著的優(yōu)勢(shì)。
三、Kafka能取代現(xiàn)有的數(shù)據(jù)湖組件嗎？
首先我的答案是否定的，至少在不久的將來不會(huì)。
盡管 Kafka 能夠存儲(chǔ)實(shí)時(shí)和歷史數(shù)據(jù)，但這并不意味著它將取代廣泛使用的數(shù)據(jù)湖管理組件，如 Apache Iceberg、Apache Hudi 和 Delta Lake。
這些數(shù)據(jù)湖管理框架針對(duì)大規(guī)模數(shù)據(jù)存儲(chǔ)進(jìn)行了優(yōu)化，同時(shí)保持了 ACID 屬性。從功能上來說，Kafka 尚未整合關(guān)鍵功能，例如用于壓縮的數(shù)據(jù)類型感知、對(duì)查詢下推的支持以及對(duì)更新和插入的支持，對(duì)列式數(shù)據(jù)的支持，這使得它在提供歷史數(shù)據(jù)方面的吸引力較低。
近期可能采用的架構(gòu)是利用Kafka作為統(tǒng)一的讀寫接口，將熱數(shù)據(jù)和溫?cái)?shù)據(jù)存儲(chǔ)在Kafka中。然后，冷數(shù)據(jù)可以在用戶不知情的情況下透明地從 Kafka 逐步過渡到 Iceberg/Hudi/Delta。
這種方法利用了 Kafka 和現(xiàn)有數(shù)據(jù)湖的優(yōu)勢(shì)。用戶可以直接調(diào)用Kafka API繼續(xù)讀寫數(shù)據(jù)，無需考慮底層結(jié)構(gòu)和數(shù)據(jù)格式。這意味著底層數(shù)據(jù)轉(zhuǎn)換和存儲(chǔ)機(jī)制的復(fù)雜性被從最終用戶手中抽象出來，簡(jiǎn)化了他們與系統(tǒng)的交互。
四、使用 Kafka 構(gòu)建流數(shù)據(jù) Lakehouse
Lakehouse融合了數(shù)據(jù)湖和數(shù)據(jù)倉(cāng)庫(kù)功能，它提供了一個(gè)統(tǒng)一的平臺(tái)，可以處理大量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，并支持高級(jí)分析和機(jī)器學(xué)習(xí)。
隨著Kafka演變成一個(gè)新的數(shù)據(jù)湖，本質(zhì)上可以構(gòu)建一個(gè)可以存儲(chǔ)和處理實(shí)時(shí)數(shù)據(jù)和歷史數(shù)據(jù)的“流式的Lakehouse”。
在 Kafka 之上構(gòu)建流數(shù)據(jù) Lakehouse 至少需要兩個(gè)關(guān)鍵組件：
流處理系統(tǒng)。第一個(gè)基本組件是流處理系統(tǒng)，例如Apache Flink，Spark Streaming。這些系統(tǒng)旨在處理存儲(chǔ)在 Kafka 中的實(shí)時(shí)數(shù)據(jù)流，使企業(yè)能夠通過分析生成的數(shù)據(jù)來做出更快、更明智的決策。
實(shí)時(shí)分析引擎。第二個(gè)關(guān)鍵組件是實(shí)時(shí)分析引擎，例如 Apache Spark、Trino 或 ClickHouse。這些引擎旨在分析處理后的數(shù)據(jù)、提供見解并促進(jìn)決策。它們能夠以低延遲處理大量數(shù)據(jù)，這使得它們非常適合基于 Kafka 構(gòu)建的流數(shù)據(jù) Lakehouse 架構(gòu)。
通過將 Kafka 與強(qiáng)大的流處理系統(tǒng)和強(qiáng)大的實(shí)時(shí)分析引擎相結(jié)合，企業(yè)可以創(chuàng)建能夠處理現(xiàn)代數(shù)據(jù)處理和分析需求的流數(shù)據(jù) Lakehouse 架構(gòu)。
該架構(gòu)使組織能夠最大限度地發(fā)揮數(shù)據(jù)的價(jià)值，提供實(shí)時(shí)洞察，從而推動(dòng)更好的決策并創(chuàng)造競(jìng)爭(zhēng)優(yōu)勢(shì)。
五、Kafka成為真正數(shù)據(jù)湖還需提供的能力
雖然 Kafka 非常強(qiáng)大且用途廣泛，但如果 Kafka 真正演變成一個(gè)數(shù)據(jù)湖，那么還有一些需要改進(jìn)的地方。
壓縮的數(shù)據(jù)類型感知。目前，Kafka 將數(shù)據(jù)視為字節(jié)數(shù)組，不知道數(shù)據(jù)的實(shí)際結(jié)構(gòu)和類型。這種意識(shí)的缺乏意味著 Kafka 執(zhí)行的壓縮是通用的，并且不如理解數(shù)據(jù)結(jié)構(gòu)時(shí)的效率高。如果 Kafka 能夠了解它正在處理的數(shù)據(jù)類型，它就可以更有效地執(zhí)行數(shù)據(jù)壓縮。這一改進(jìn)將通過最大限度地減少需要傳輸和處理的數(shù)據(jù)量來降低存儲(chǔ)需求并優(yōu)化分析查詢的性能。
支持查詢下推。查詢下推是一種將查詢的部分內(nèi)容（例如過濾器）下推到存儲(chǔ)層的技術(shù)，從而實(shí)現(xiàn)更高效的數(shù)據(jù)檢索和處理。目前，Kafka不支持查詢下推，這意味著所有數(shù)據(jù)都需要加載到內(nèi)存中并進(jìn)行處理，即使只需要一小部分?jǐn)?shù)據(jù)。如果 Kafka 能夠支持查詢下推，那么它將通過減少需要加載到內(nèi)存和處理的數(shù)據(jù)量來提高分析查詢的性能。
支持更新和刪除。目前，Kafka 被設(shè)計(jì)為僅追加日志，雖然有處理更新和刪除的解決方法，但它們并不像傳統(tǒng)數(shù)據(jù)庫(kù)那樣簡(jiǎn)單和高效。如果Kafka能夠原生支持更新和刪除操作，那么數(shù)據(jù)維護(hù)將會(huì)變得更加簡(jiǎn)單和高效。它還將使 Kafka 成為一個(gè)更完整、更通用的數(shù)據(jù)存儲(chǔ)解決方案，從而提高其作為數(shù)據(jù)湖的適用性。對(duì)于許多組織來說，這一新增功能將改變游戲規(guī)則，簡(jiǎn)化其數(shù)據(jù)架構(gòu)并減少與數(shù)據(jù)維護(hù)相關(guān)的開銷。
結(jié)論
如果Kafka完成了數(shù)據(jù)湖能力的支持，那么對(duì)于整個(gè)數(shù)據(jù)產(chǎn)品來說就是一次整合和變革，將根本性縮短現(xiàn)有的數(shù)據(jù)處理鏈路，同時(shí)可以統(tǒng)一數(shù)據(jù)源，減少數(shù)據(jù)產(chǎn)品間的轉(zhuǎn)換適配等成本。
Kafka天生的“流式底子”能力，也正代表了現(xiàn)代數(shù)據(jù)架構(gòu)的轉(zhuǎn)變，加上流處理系統(tǒng)和實(shí)時(shí)分析引擎，使其成為構(gòu)建流式湖倉(cāng)一體架構(gòu)的堅(jiān)實(shí)基礎(chǔ)。此外，它對(duì)數(shù)據(jù)持久化的支持、以及作為單一事實(shí)來源的能力和豐富的生態(tài)系統(tǒng)進(jìn)一步鞏固了其作為可行的數(shù)據(jù)湖選項(xiàng)的地位。
我是希望數(shù)據(jù)下層組件們最好能夠統(tǒng)一下，不同特定領(lǐng)域數(shù)據(jù)存儲(chǔ)數(shù)據(jù)引擎事實(shí)上本身是有很多共通點(diǎn)的。當(dāng)前不同數(shù)據(jù)組件間數(shù)據(jù)的共享已然成為很大的成本項(xiàng)，也造成了體驗(yàn)感差的問題。最后讓我們看看Kafka和其他事件流平臺(tái)在不久的將的發(fā)展，是否可以實(shí)現(xiàn)簡(jiǎn)單統(tǒng)一的數(shù)據(jù)源平臺(tái)框架。
