雖然該領域的公司數量在不斷增加，但可以看到，其中有幾個類別的產品出現了整合跡象。MLOps 趨向于端到端，Notebook 正在進入編排領域，而編排正在轉向數據譜系和可觀察性。與此同時，我們看到，開放式表格式進入了元存儲功能。而在治理層，安全和權限管理工具進入目錄領域，反之亦然。

自我們分享“2021 年數據工程現狀”已經過了一年。從去年 5 月我們發布那篇文章以來，數據領域并沒有多少變化。事實上，我們曾在內部討論過 2022 年還要不要做一次更新。

開玩笑的。這一年還是很值得說的。所以，我們再次回來，對數據工程的現狀做下更新和分享。

這一年有什么變化呢？

過去一年的主要主題是整合（consolidation）。一些公司擴大了他們的業務范圍，進入了新的類別，也有一些公司的出現僅僅是為了取代數據工程棧中一些現有的工具。

讓我們來看看更新后的數據工程地圖，今年的分辨率更高。

01?數據采集

這一層包括流技術和 SaaS 服務，提供從業務系統到數據存儲的管道。

這方面值得一提的進展是 Airbyte 的戲劇性崛起。Airbyte 成立于 2020 年，在這年年底才轉向其當前的產品。Airbyte 是一個開源項目，目前有超過 15000 家公司在使用。其社區有超過 600 名貢獻者。在采用和社區方面，如此指數級的增長非常罕見。

Airbyte 剛剛推出了他們的商業產品，并通過收購 Grouparoo（一個反向 ETL 連接器開源項目）擴展到反向 ETL（一個在數據工程現狀地圖中沒有涉及的類別）。我們認為，反向 ETL 是一個與 ETL 有很大差別的產品，因為它需要將數據集成到業務系統中，幫助用戶完成該系統中的工作流。

我們很想知道事情的結果如何。

02 數據湖

2021 年，我們將數據倉庫和湖倉（lakehouse）作為數據湖層的一部分。但今年，我們決定保留數據湖這個類別，僅指用作數據湖的對象存儲技術。我們將所有的數據倉庫和湖倉移至分析引擎類別。

為什么？如今，數據工程師處理的大多數架構都很復雜，足以同時包括對象存儲和分析引擎。因此，你要么只需要一個分析數據庫（這種情況沒有數據湖，只有一個作為分析引擎的數據倉庫），要么兩者都要。而當兩者都需要時，你通常會在對象存儲上執行一些分析，在分析引擎上執行另一些分析。這就是為什么它們需要很容易搭配使用。

這種依賴關系發生在不同的層。大型數據集會托管在對象存儲中，而工件和服務層數據集將存儲在分析引擎和數據庫中。在我們知道的架構中，沒有看到一個征服另一個的情況。

我們看到，在現實中，這些解決方案是并存的。這種架構產生的背后有多種原因，但其中一個肯定是成本考慮。在 Snowflake 或 BigQuery 中查詢大量的數據是很昂貴的。因此，與其讓分析數據庫管理整個湖，不如在對象存儲中管理一切它可以管理的東西，在它上面執行計算更便宜，而將所有必須由分析引擎管理的東西交給分析引擎。

我們認為，湖倉是一個分析引擎（盡管在 Databricks 中，它既包括數據湖，也包括分析引擎）。這個架構的特點是使用 Spark SQL 的優化版本在 Delta 表格式上創建一個分析引擎。這提供了人們希望從分析引擎獲得的性能和成本。

同樣的規則適用于 Iceberg 上的 Dremio，或支持將 Iceberg 作為數據庫外部表的 Snowflake。

03 元數據管理

在元數據領域發生了很多事情！元數據的兩個層次——這一層和圖表頂部的組織層——正成為許多組織的關注點。

回顧我們作為可擴展數據從業者所面臨的挑戰，在過去十年中，我們一直在圍繞存儲和計算機進行創新——所有這些都是為了確保它們支持數據的擴展。

如今，我們面臨的主要是可管理性問題，我們可以通過生成和管理元數據來解決這些問題。這一層涉及元數據的不同方面，讓我們逐個看下。

1、開放式表格式

我們看到，在過去的一年里，開放式表格式取得了有趣的進步。它們正在成為數據湖中保存結構化數據的標準。

一年之前，Delta Lake 是一個 Databricks 項目，它有一個商業化產品叫 Delta。然后在今年，Onehouse 公司商業化了 Apache Hudi，Tabular 公司商業化了 Apache Iceberg。這兩家公司都是由這些開源項目的創建者創立的。

因此，整個領域從開源變成了完全由商業實體支撐。這讓人不禁會問，既然背后有商業利益，其他參與者對開源項目還能有多大影響。

由于這三個開源項目都屬于 Apache/Linux 基金會，所以對社區而言風險很低。這似乎并不能平息這三個項目的創建者和粉絲之間的激烈爭論，圍繞誰“真正”開源以及誰提供了最好的解決方案。Netflix 很快就會把這個故事作為電視劇的絕佳素材。

2、Metastore 的未來仍不明朗……

我們看到，Hive Metastore 被從架構中移除，開放式表格式或許可以替代它。并不是所有的組織都充分利用了 Metastore 的能力，如果他們唯一的用例是虛擬化表，那么開放式表格式和以它為基礎構建的商業產品提供了一個很好的選擇。Metastore 的其他用例還沒有更好的替代解決方案。

3、Git For Data

Git For Data 的概念在社區中日漸流行。dbt 鼓勵分析師在不同版本的數據（開發、過渡和生產）上使用最佳實踐，但不支持在數據湖中創建和維護這些數據集。

數據運營團隊越來越需要提供跨組織的數據版本控制，以管理隨著時間推移做過不同修訂的數據集。對一個數據集進行不同修訂的例子有：重新計算，這是算法和 ML 模型所必需的，或者是來自運營系統的回填，這在 BI 中經常發生，或者是遵循 GDPR 被遺忘權規定而刪除一個子集。

這一趨勢從 LakeFS 及其社區的急劇增長可以明顯看出來，我親眼目睹了這一點。LakeFS 同時提供了結構化和非結構化數據操作服務，在兩者都存在的情況下大放光彩。

遺憾的是，關于 Dremio 的 Nessie 項目的使用情況，很難找到公開數據。有趣的是，它還提供了一個名為 Arctic 的免費服務。這可能是為了與 Tabular 競爭而做出的戰略決定。

04 數據計算

為了更好地反映生態系統現狀，我們今年對計算層做了一些修改。首先，我們完全刪除了虛擬化這個類別。它目前似乎還沒有流行開來。

然后我們把計算引擎分成兩類：分布式計算和分析引擎。它們之間的主要區別在于這些工具對其存儲層的要求。

分布式計算包括對存儲沒有要求的計算引擎，而分析引擎類別包含有要求的計算引擎（無論是否分布式）。

1、分布式計算

一般的分布式計算引擎允許工程師分發任意 SQL 或任何其他代碼。當然，它們可能對編程語言有要求，但它們會在（通常是）聯合數據上進行普遍分發。這可能是跨許多格式和數據源的數據。

分布式計算類別中新增了兩個有趣的補充：Ray 和 Dask。

Ray 是一個開源項目，允許工程師擴展任何計算密集型的 Python 工作負載，主要用于機器學習。Dask 也是一個基于 Pandas 的分布式 Python 引擎。

你可能認為，Spark 將是統治這個領域的分布式引擎，看不到任何競爭。因此，見證新技術在這一類別中的崛起還是相當令人興奮的。

2、分析引擎

分析引擎類別包括所有的數據倉庫，如 Snowflake、BigQuery、Redshift、Firebolt 以及老好的 PostgreSQL。它還包含像 Databricks lakehouse、Dremio 或 Apache Pinot 這樣的湖倉。所有這些工具都有自己支持的數據格式，為的是使查詢引擎提供更好的性能。

由于所有的分析引擎都使用數據湖作為深層存儲或存儲，所以值得一提的是，Snowflake 現在支持將 Apache Iceberg 作為外部表格式之一，可以由 Snowflake 直接從湖中讀取。

05 數據編排和可觀察性

這是今年新增加的一層，但由現有的類別組成。編排工具去年是元數據層的一部分，但我們把它移到了它真正屬于的計算引擎層——它主要是跨計算引擎和數據源編排管道。

與此同時，我們看到，可觀察性工具在 2021 年有了很大的發展，可以支持更多的數據源（產生于任何計算引擎）。

1、數據編排

關于數據編排，有什么引人注目的事情發生嗎？Airflow 仍然是最大的開源產品。從加入云計算行列至今，Astronomer 多年來一直以它為基礎。現在，Astronomer 直接與云供應商在托管 Airflow 領域展開了競爭。

Astronomer 另一個非常有趣的舉動是收購了提供數據譜系的 Datakin。這讓人不禁要問——當一個編排工具具備了數據譜系能力時會發生什么？

理論上，這可以幫助數據團隊構建更安全、更有彈性的管道。了解哪些數據集依賴于缺失、損壞或低質量的數據，將邏輯（由編排工具管理）和它們的輸出（由譜系工具管理）聯系起來，影響分析將變得相當容易。這是否會成為編排生態系統的一個組成部分，還有待觀察。

2、可觀察性

這個類別由 Monte Carlo 數據公司創建，也由它主導。Monte Carlo 的頻繁融資表明其產品在市場上被迅速采用。該產品不斷發展，提供了更多的集成（如 Databricks 生態系統），以及額外的可觀察性和根源分析功能。或許正是這種成功推動了這一類別的增長，至少從如今在探索這一領域的公司數量來看是如此。2021 年，有幾家公司成立或打破隱身狀態，最有趣的是 Elementary，又一個來自 YC 的開源項目。

06?數據科學和分析的可用性

這一層是為數據架構（通過前幾層創建）用戶準備的：數據科學家和分析師，他們從數據獲取洞察力。我們把這個類別分成三個子類別：

端到端 MLOps 工具以數據中心化 ML 方法為基礎的工具ML 可觀察性和監控

1、端到端 MLOps 工具

當我著手考察這個領域時，有人告訴我，我應該把這個類別命名為：“準備好失望吧”。雖然這個類別有很棒的工具，但沒有一個是真正的端到端。它們為 ML 過程中的某些步驟提供了很好的解決方案，但對 ML 管道的其他方面缺乏支持。

盡管如此，提供端到端解決方案的方法在 2021 年還是很受歡迎。有幾款面向特定任務的工具走上了這一道路，成為了端到端的產品，如 Comet、Weights & Biases、Clear.ml 和 Iguazio。

2、數據中心化 ML

這個子類別也沒有逃脫端到端的陷阱，但其中列出的工具采用了不同的方法來提供功能。它們以數據及其管理作為任務的中心。

這個領域有兩個新成員 Activeloop 和 Graviti。它們是由經驗豐富的數據從業者構建的，他們了解數據管理對數據操作成功的重要性。在 LakeFS，我們也有這樣的感受。

DagsHub 采取了一種獨特的方法，提供了一個以數據為中心的端到端解決方案，不過是基于開源解決方案。他們在 ML 生命周期的每個階段都很出色，提供了很好的可用性，并且易于集成。在這樣一個混亂的領域里，這是一個可靠的方法，可以得到一個不錯的端到端解決方案，同時也可以取悅用戶。我們正滿心期待地看著這家公司....

3、ML 可觀察性和監控

這個子類別包括專注于模型質量監控和可觀察性的工具。與數據可觀察性類別非常相似，這一領域正在成長并逐步形成良好的發展勢頭。2022 年初，Deepchecks 開放了源代碼，并迅速獲得關注，吸引了不少貢獻者和合作伙伴。

4、Notebooks

在 Notebooks 類別中，我們看到，得益于 Databricks 和 Snowflake 的投資，Hex 得到了更多的關注和驗證。Hex 在其 Notebook 中提供了更多編排能力。Ploomber 也是如此，它的出現為 Jupyter 提供了編排能力。

在過去的一年里，這個面向分析師的工具類別確立了自己的地位，并贏得了一些競爭。dbt 證明了自己是分析師的標準。2021 年，它發布了與可擴展數據工程棧的集成，包括對象存儲、HMS 和 Databricks 的產品。在與生態系統合作的同時，2021 年，Databricks 推出了其“活性表”產品的正式版本，與 dbt 展開了直接競爭。

07 數據目錄、權限和治理

對于這個生態系統，我的感覺是，現在各種規模的公司對數據目錄的需求都很明確。我們將看到，它會成為一種標準。基于開源項目的商業產品顯示出良好的采用水平。

與此同時，企業解決方案的長期供應商，Alation 和 Collibra，繼續擴展他們的產品。而安全和權限管理供應商 BigID 也在試圖提供一個目錄。

Immuta 繼續致力于數據訪問控制，其獨特的技術使它現在可以兼容更多的數據源。為了加速發展，該公司早在 2021 年中期就完成了 9000 萬美元的 D 輪融資。

08?小結

雖然該領域的公司數量在不斷增加，但可以看到，其中有幾個類別的產品出現了整合跡象。

MLOps 趨向于端到端，Notebook 正在進入編排領域，而編排正在轉向數據譜系和可觀察性。與此同時，我們看到，開放式表格式進入了元存儲功能。而在治理層，安全和權限管理工具進入目錄領域，反之亦然......

這些跡象是否預示著市場（仍然）有限，也許是 MLOps 市場有限？這種整合是否反映了由于激烈的競爭而產生的差異化需求（在編排方面可能是這種情況）？還是說這是一個填補空白的機會，像開放式表格或數據中心化 ML 那樣的情況？還是說，這都是因為用戶希望使用更少的工具來做更多的事情？

我打算把這些問題留給讀者，希望能引發對 2022 年數據工程狀況的討論。

2022 年，還有哪些項目正在獲得發展的動力？哪些工具正在成為行業內的事實標準？

關于 lakeFSlakeFS 項目是一項開源技術，為數據湖提供類似 Git 的版本控制接口，并與流行的數據工具和框架無縫集成。我們的使命是最大限度地提高開源數據分析解決方案的可管理性。