2024 年數(shù)據(jù)工程：對數(shù)據(jù)湖和服務(wù)層的預(yù)測

2024-01-31 09:15:25

數(shù)據(jù)環(huán)境在 2023 年發(fā)生了重大變化，為數(shù)據(jù)工程團(tuán)隊(duì)帶來了新的機(jī)遇（和潛在挑戰(zhàn)）。今年，我們將在分析、OLAP、數(shù)據(jù)工程和服務(wù)層領(lǐng)域看到以下內(nèi)容，這將為團(tuán)隊(duì)提供更好的協(xié)議和更多工具選擇。

（MeSSrro/Shutterstock）

數(shù)據(jù)湖預(yù)測

從 Hadoop 繼續(xù)前進(jìn)： 2023 年，DuckDB （C++）、Polars （Rust）和 Apache Arrow （Go、Rust、Javascript 等）等工具變得非常流行，將 JVM 和 C/Python 在分析領(lǐng)域的完全主導(dǎo)地位出現(xiàn)裂縫。

我們預(yù)測，JVM之外的創(chuàng)新步伐將會加快，這將現(xiàn)有的基于Hadoop的架構(gòu)送入傳統(tǒng)抽屜當(dāng)中。

雖然大多數(shù)公司已經(jīng)沒有直接使用Hadoop，但目前的大部分技術(shù)仍然建立在Hadoop的腳本之上：Apache Spark完全依賴Hadoop的I/O實(shí)現(xiàn)來訪問其底層數(shù)據(jù)。許多湖倉一體架構(gòu)要么基于 Apache Hive 樣式，要么更直接地基于 Hive 元存儲及其接口，以在其存儲層之上創(chuàng)建表格抽象。

雖然Hadoop和Hive本身并沒有問題，但它們已經(jīng)不再代表最先進(jìn)的技術(shù)。這次，它們完全基于JVM。JVM現(xiàn)在的性能令人難以置信，當(dāng)然如果想從沒有變得更快的CPU中獲得絕對最好的選擇，這仍然不太可能。

此外，Apache Hive通過抽象出Hadoop的底層分布式特性，并在分布式文件系統(tǒng)之上暴露熟悉的SQL（-ish）表抽象，這標(biāo)志著大數(shù)據(jù)處理向前邁出了一大步。由此可以看到，它已經(jīng)開始顯示年齡和局限性：缺乏事務(wù)性和并發(fā)性控制，缺乏元數(shù)據(jù)和數(shù)據(jù)之間的分離。以及我們在 15+ 年中學(xué)到的其他經(jīng)驗(yàn)教訓(xùn)。

今年，我們將看到 Apache Spark 從根源上繼續(xù)前進(jìn)：Databricks 已經(jīng)有一個無 JVM 的 Apache Spark （Photon）實(shí)現(xiàn)，而新的表格式（如 Apache Iceberg）也通過實(shí)現(xiàn)表目錄的開放規(guī)范，以及為 I/O 層提供更現(xiàn)代的方法，并從集體 Hive 根源中走出來。

元商店之戰(zhàn)

隨著 Hive 即成為過去，以及 Delta Lake 和 Iceberg 等 Open Table 格式變得無處不在，任何數(shù)據(jù)架構(gòu)中的核心組件也正在被取代——“元存儲”。對象存儲或文件系統(tǒng)上的文件與它們所表示的表格和實(shí)體之間的間接層。雖然表格格式是開放的，但它們的元存儲似乎越來越專有和鎖定。

Databricks 正在積極推動用戶使用其 Unity Catalog，AWS 擁有 Glue，Snowflake 也有自己的目錄實(shí)現(xiàn)。這些是不可互操作的，并且在許多方面成為希望利用新表格格式提供開放性的用戶鎖定供應(yīng)商的一種手段。我們預(yù)測，在某個時候，鐘擺會擺回去——因?yàn)橛脩魧⒊叩臉?biāo)準(zhǔn)化和靈活性方向發(fā)展。

大數(shù)據(jù)工程作為一種實(shí)踐將走向成熟

隨著分析和數(shù)據(jù)工程變得越來越普遍，大量的技術(shù)正在快速增長，最佳實(shí)踐也開始出現(xiàn)。

2023 年，我們看到促進(jìn)結(jié)構(gòu)化開發(fā)-測試-發(fā)布數(shù)據(jù)工程方法的工具變得更加主流。DBT非常受歡迎和成熟。從Great Expectations、Monte Carlo和其他質(zhì)量和可觀測性平臺等工具的成功來看，可觀測性和監(jiān)控現(xiàn)在也被視為不僅僅是錦上添花。lakeFS 提倡對數(shù)據(jù)本身進(jìn)行版本控制，以允許類似 git 的分支和合并，從而構(gòu)建健壯的、可重復(fù)的開發(fā)-測試-發(fā)布管道。

此外，我們現(xiàn)在還看到，從Snowflake和Databricks到初創(chuàng)公司，每個人都在推廣數(shù)據(jù)網(wǎng)格和數(shù)據(jù)產(chǎn)品等模式，以填補(bǔ)圍繞這些模式仍然存在的工具空白。

因此，我們將在 2024 年看到旨在幫助用戶實(shí)現(xiàn)這些目標(biāo)的工具激增。從以數(shù)據(jù)為中心的監(jiān)控和日志記錄到測試工具和更好的 CI/CD 選項(xiàng)，軟件工程實(shí)踐還有很多工作要做，現(xiàn)在是縮小這些差距的正確時機(jī)。

服務(wù)層預(yù)測

云原生應(yīng)用程序?qū)迅蠓蓊~的狀態(tài)轉(zhuǎn)移到對象存儲中： 2023 年底，AWS 宣布了自 2006 年成立以來最大的功能之一，即其核心存儲服務(wù) S3。

該功能“S3 Express One-Zone”允許用戶使用與 S3 提供的相同*標(biāo)準(zhǔn)對象存儲 API，但訪問數(shù)據(jù)的延遲始終如一的堅(jiān)持個位數(shù)毫秒，成本大約是 API 調(diào)用的一半。

這標(biāo)志著一個巨大的變化。到目前為止，對象存儲的用例有些狹窄：雖然它們允許存儲幾乎無限量的數(shù)據(jù)，但即使您只想讀取少量數(shù)據(jù)，您也必須接受更長的訪問時間。

這種權(quán)衡顯然使它們在分析和大數(shù)據(jù)處理中非常受歡迎。因?yàn)樵谶@些領(lǐng)域，延遲通常不如整體吞吐量重要，但這意味著數(shù)據(jù)庫、HPC 和面向用戶的應(yīng)用程序等低延遲系統(tǒng)不能真正依賴它們作為其關(guān)鍵路徑的一部分。

如果他們使用了對象存儲，則通常采用存檔或備份存儲層的形式。如果想要快速訪問，則必須選擇以某種形式附加到實(shí)例的塊存儲設(shè)備，并放棄對象存儲提供的可擴(kuò)展性和持久性優(yōu)勢。我們相信 S3 Express One-Zone 是改變這種狀況的第一步。

S3 是新的磁盤驅(qū)動器，通過一致、低延遲的讀取，現(xiàn)在理論上可以構(gòu)建完全不依賴塊存儲的完全對象存儲支持的數(shù)據(jù)庫。

我們預(yù)測，在2024年，我們將看到更多的可操作數(shù)據(jù)庫開始在實(shí)踐中采用這一概念：允許數(shù)據(jù)庫在完全短暫的計算環(huán)境中運(yùn)行，完全依靠對象存儲來實(shí)現(xiàn)持久性。

（圖片來源：Oz Katz）

業(yè)務(wù)數(shù)據(jù)庫將開始分解

考慮到前面的預(yù)測，我們可以將這種方法更進(jìn)一步：如果我們像標(biāo)準(zhǔn)化 OLAP 一樣標(biāo)準(zhǔn)化 OLTP 的存儲層會怎樣？

數(shù)據(jù)湖的最大承諾之一是能夠?qū)⒋鎯陀嬎惴珠_，以便一種技術(shù)寫入的數(shù)據(jù)可以被另一種技術(shù)讀取。這使開發(fā)人員可以自由選擇最適合其用例的最佳堆棧。但是，有了 Apache Parquet、Delta Lake 和 Apache Iceberg 等技術(shù)，現(xiàn)在這是可行的。

如果我們設(shè)法將用于操作數(shù)據(jù)訪問的格式標(biāo)準(zhǔn)化，會怎么樣？讓我們想象一個鍵/值抽象（可能類似于 LSM sstables？），它允許存儲排序的鍵值對，為對象存儲進(jìn)行最佳布局。

我們可以部署一個無狀態(tài)的RDBMS，在上面提供查詢解析/規(guī)劃/執(zhí)行功能，甚至作為一個按需的lambda函數(shù)。另一個系統(tǒng)可能會使用相同的存儲抽象來存儲用于搜索的反排索引，或者用于存儲酷炫的生成式 AI 應(yīng)用程序的向量相似性索引。

雖然不相信一年后我們會將所有數(shù)據(jù)庫作為 lambda 函數(shù)運(yùn)行，但確實(shí)將看到從“對象存儲作為存檔層”到更多“對象存儲作為記錄系統(tǒng)”的轉(zhuǎn)變，在操作數(shù)據(jù)庫中也會發(fā)生。