Apache Hudi是一個開源資料湖管理平臺，用於簡化增量資料處理和資料管道開發，該平臺可以有效地管理業務需求，例如資料生命週期，並提高資料質量。Hudi的一些常見用例是記錄級的插入、更新和刪除、簡化檔案管理和近乎實時的資料訪問以及簡化的CDC資料管道開發。
本期SOFTWARE DAILY我們有幸採訪到了Apache Hudi專案VP Vinoth Chandar。Vinoth是Uber Hudi專案的建立者，他繼續在Apache Software Foundation領導Hudi的發展。在此之前他曾是Confluent的首席工程師，之前是Uber的高階工程師/經理。本期我們將討論構建大型分散式和資料系統。
Q1：今天我們就資料湖、資料倉儲和資料基礎設施進行一場引人入勝的討論。資料湖可以低成本儲存所有資料，然後使用該資料執行操作，由於價格便宜，可以儲存所有資料。資料倉儲是更昂貴的儲存空間，它可能更接近記憶體，並且通常更昂貴，但訪問速度更快。這是我如何看待這兩個抽象的非常粗略的描述。我希望您對這兩個抽象以及這些術語在過去幾年中的演變有何看法？
VC：我認為您對它們的描述幾乎與幾年前一樣，如果稍微倒退一點回到Teradata、Vertica時代，儲存與計算耦合的資料倉儲，他們幾乎都是MPP資料庫，然後到Hadoop時代，帶來了水平可擴充套件的計算能力，然後資料湖和倉庫共存。但是最後我想說大約五年來，資料湖和資料倉儲生態系統都發生了巨大的變化。具體地說，雲數倉現在是黃金時間，它們與以前的倉庫有完全不同的體系結構，它們使儲存和計算分離，然後可以使用雲端儲存來水平擴充套件，這樣它們聽起來就像是資料湖。而如果使用資料湖，那麼會有事務性管理資料的需求，或者具有變更和更新儲存在資料湖中的資料的能力。擺脫了"好吧，讓我們將其視為所有資料的廉價轉儲，轉變成更有意識組織的，大量結構化資料流入資料湖"，然後資料湖技術也開始變得越來越像資料庫/資料倉儲邊界，從我看來那就是我們的方向。
Q2：您對不同的流行資料倉儲（資料湖抽象）看法是什麼？ 我看到的三個主要物件是Snowflake，BigQuery和帶有Delta和Spark的Lakehouse架構。也許還會包括Redshift。也許您可以列舉不同的流行資料倉儲，資料湖抽象以及它們之間的對比。
VC：那麼讓我們從雲資料倉儲開始，實際上我會將Redshift放在前面，我會將Redshift，BigQuery和Snowflake視為雲數倉。它們都有一些非常共同的特徵，如都有很多類似資料庫的引數。實際上它們具有的事務處理能力要遠遠高於您所看到的能力，正如我們在談論資料湖抽象時所看到的，它們都具有一種內部專有格式，不是很開放，並且非常類似於垂直整合系統，包括SQL、檔案格式、執行執行時。他們與BI系統緊密整合，就像常規分析一樣，因此我以類似的方式來看待它們。然後進入資料湖，這是我從2016年左右開始涉足Apache Hudi的背景，包括Databricks的Delta Lake，Netflix的Apache iceberg，三個系統都提供了一個事務層，就像在S3或雲物件儲存之上管理檔案一樣，並且使用開放檔案格式，如Parquet、ORC。這三個專案在內部設計以及解決問題的方式有一些相似之處和不同點。就我個人而言，當Lakehouse出現時，我並不感到驚訝，因為幾年來我們已經在Uber投入生產類似的東西，我知道有幾家大型科技公司已經在做類似的事情，其核心思想是：“讓我們將數倉的原語帶到資料湖，並試圖在資料湖本身上做更多的事情" ，而且我認為Databricks做出了出色的工作，它是業界領先的Spark計算提供商之一，為這種架構模式增加了行業視野，他們在表達這種願景方面也做得很好，這就是我的看法。
Q3：既然您提到Uber，您能給我更多有關Uber的資料倉儲或Uber的資料基礎架構的背景資訊嗎？
VC：我在2014年加入Uber，Uber業務增速非常快，這意味著隨著我們推出更多城市，資料量也在不斷增長。Uber是一家非常實時的公司，我們可以通過構建大量針對資料新鮮度進行優化的系統來節省大量資金。公司、城市運營商，工程師，每個人都可以訪問資料。我們從Vertica開始，但是隨著資料量的增長，我們意識到需要一個資料湖，我們使用Spark將所有初始資料轉儲到資料湖中，然後將原始資料從本地倉庫中移出。但是當真正開始實施時，我們意識到在資料庫和資料湖之間增加了額外一層，這導致上在它們之間增加了很多延遲，這主要是由於所有事情都是大批量完成的， Hadoop世界更喜歡大規模批量操作。這就是Hudi出現的背景，需要支援更新，刪除。我們實際上可以獲取資料庫更改日誌，這給我們帶來了極大的查詢資料新鮮度，而Vertica也為我們提供了良好的查詢效能。我們通過在Hadoop檔案系統抽象之上構建事務層或無伺服器事務層來複制類似的東西，以便它可以與HDFS，S3一起使用，這是面向未來的。並且我們嘗試在將運算元據提取到資料湖中的同時解決更新和刪除問題，可以將批處理工作從大約12、16小時，24小時執行轉變為在30分鐘，15分鐘，5分鐘內完成，實際上可以根據我們的需求調整延遲，因為Hudi可以使用Apache Spark作為執行時，因此它可以非常好地水平擴縮容。
我們解決的第二個問題僅僅是解決更新和刪除問題，但還不夠，因為通常在資料湖體系中會擁有一組原始表，然後使用ETL作業從中構建更多派生表，但所有這些派生表都不瞭解實際更改了哪些資料。例如有一個簡單的ETL作業（正在標準化貨幣換算或某些非常簡單的原始操作），但必須對整個小費表表進行全表掃描，才能真正瞭解發生了什麼變化，所以我們說：“好吧，流處理是如何解決這個問題的"，這就是Hudi內建的兩個基本特性。我們在支援更新，刪除和增量更改流的同時也支援了事務，這就是Hudi誕生的方式，我們在2016年做到了這一點。到2016年底，Hudi已經穩定執行兩年時間，為Uber的所有關鍵業務關鍵資料集提供了動力，已經儲存了幾PB的資料。我們在2017年開源了該專案，進入了Apache孵化器，2018年Apache孵化器中畢業。而且我們一直在與許多在其平臺上採用Hudi的雲提供商一起發展社群，以解決整個行業廣泛存在的相同問題。
Q4：為何當時沒有像現有的資料基礎架構技術那樣解決這些問題？如今這些現有的資料湖、資料倉儲產品已經解決了這些問題嗎？
VC：我們需要事務、更新和刪除等功能，以便我們快速將資料從上游資料庫中提取到倉庫中。但是倉庫不能容納所有資料，您可以執行數十個節點的Arrows群集，但是我們的資料量巨大，以至於無法容納在任何一個叢集中，這是Arrow限制，我們無法進行擴充套件。
總的來說在Hadoop技術棧體系中，當時還沒有成熟的系統能夠攝取資料並真正很好地對其進行管理。Hadoop計劃中的大部分工作都用於構建HDFS，Yarn，Hadoop Spark，Hive Spark，Presto等，實際資料管理或儲存層並未引起太多關注，例如調整檔案大小。使用者可以擴充套件HDFS並通過寫入適當大小的檔案來保持HDFS健康，但沒有庫在整個生態系統中統一實現這一功能，大型公司都試圖構建自己的解決方案，但在不同時間軸上，實際這是一個明顯的問題，也是Hudi的誕生方式。如果拉回到今天，我會說雲倉庫在解決我說過的老式資料倉儲中的資料規模問題方面做得很好，它們的儲存位於S3上而不在本地裝置上，它們確實解決了資料儲存擴充套件問題。但是問題仍然在於它們是專有格式，因此如果今天再次進行操作，我仍會重新構建，因為我們不想將公司的所有原始資料鎖定為一種專有格式，Databricks提出的Lakehouse引起了我的共鳴，因為它們不是通用的，在某種意義上說我們需要一流的公民來支援資料科學和機器學習。然後我們希望資料科學家對分析人員用於報告的相同資料建立模型和分析。如果資料在資料倉儲和資料湖中同時存在，那麼會遇到大量的資料質量問題。從體系結構上講，我認為讓資料更快進入由Apache Hudi之類的功能驅動的原始資料湖仍然有意義，這樣對於您要執行的任何下游處理開銷都很少。然後您選擇要使用哪種工具整理資料（如果需要）以進行分析。還是有很多其他實時分析工具，比如Druid、Clickhouse等。
Q5：Hudi是一個開源專案，這意味著它廣泛適用。這不僅適用於不同規模的公司。為什麼這是一個廣泛適用的問題？
VC：這是一個非常非常好的問題。當我們真正開始建立Hudi時，甚至是在我自己追溯該問題時，我都非常確信這就是我們必須為Uber構建它的方式。人們通常應該採用這種方式，但是並不是那種強制功能可以使人們以某種方式採用這種功能，如果您檢視其中的一些技術，Hudi自2016年左右就已經存在，實際上它帶給我們的是GDPR之類的能力，還有諸如強制功能之類的服務，轉儲到S3或其他儲存上的所有資料，您都需要對其進行管理，需要刪除內容，需要糾正或掩蓋其中的內容，這個場景適用於任何跨國公司，然後這也引起了人們對資料湖的大量關注，這就是我們感到Hudi非常適用的地方。以事務方式更新資料，然後像流資料湖模式（如我所說的那樣）進行攝取的技術正在慢慢流行起來，人們意識到在資料隱私法律中需要適當地管理使用者資料，那麼什麼是正確的架構？看來我需要一個資料湖，現在有了這些工具，我們在該行業上是正確的，而且我認為未來幾年我們將適應各種模式。
Q6：簡單介紹一下您認為理想的資料體系結構。就像什麼理想的使用者體驗可以消除大量的配置和繁瑣的設定工作或維護工作？ 對於在資料平臺之上工作的資料工程師，資料科學團隊來說，什麼是好的理想體驗？
VC：這是另一個奇妙的問題，讓我們從組織的角度來思考這個問題，假設有一家公司已經相當成功了，它擁有數百名員工。然後現在資料管理問題開始出現了，然後可以使用一些整合工具來進行基本的報告分析。但現在如果有兩三個業務職能，一個風險團隊，一個風險欺詐團隊，並且有一個財務團隊，還有一個產品團隊，每個團隊都需要聘請資料工程師，並且對使用者某些操作中的資料感興趣，資料在MySQL，Postgres、Oracle、RDBMS或NoSQL儲存，然後會自然引入Kafka訊息佇列，像事件跟蹤資料一樣，幾乎每個公司都使用類似的方法來跟蹤許多正在進行的活動。因此大多數公司從本質上選擇了一條途徑，即從聘請資料工程師到各個業務職能部門開始，他們精心挑選所需的資料集，他們實際上並沒有像完全集中的資料湖那樣進行構建，因為在組織上通常很難為這種產品提供資金。隨著時間的流逝，最終出現了資料孤島。然後財務團隊成員寫的查詢無法與欺詐團隊中的某人核對資料，然後需要給財務團隊中的某人（而不是欺詐團隊）一個類似的、不同種類的生產資料訪問控制，使得人們抱怨在使用資料湖的痛苦，我認為要解決的首要問題是在原始環境中將大量上游系統複製到資料湖中，這必須在沒有太多轉換的情況下進行，而且它必須非常快地完成操作，這樣您就可以在工作之前不必等待數小時才能收到這些資料了，因此只要您能夠像原始資料流一樣構建它們稱為的原始資料層，然後將其釋放-並在其之上使用一些類似的工具和控制元件訪問控制，那麼它將使您的資料工程師專注於業務功能，如果他們想連線某些表以獲得更好的資料質量也很容易做到，因為他們擁有所有可用的資料。如果您今天看一下Databricks，Databricks是一個Spark執行時，其提供了大量資料科學工具，而且如果您檢視的是Starburst或Presto，HANA Starburst，Presto之類的查詢引擎公司，它們確實非常適合–就像他們擁有良好的BI工具一樣，實際上可以根據用例選擇要使用的查詢引擎，並且可以向資料科學團隊提供資料庫訂閱，當財務團隊執行報表時，就像儀表板一樣。因此可以自由選擇，並且可以實際控制哪些資料，回到我之前說的那樣，此原始原始資料層幾乎沒有增加資料延遲，所有原始資料都非常快地流入資料湖，這就是在公司中進行的任何派生資料計算的起點。您可以隨時從一個雲倉庫轉移到另一個倉庫，也可以像您喜歡的那樣引入或淘汰舊的實時分析引擎。如果需要您將幾乎可以重新計算任何東西，並且此模型具有很大的自由度，我認為這就是我應該朝著的方向發展。
Q7：鑑於您剛剛將其描述的未來，請描述下資料基礎架構部署到該世界需要做些什麼？還是我們需要在基礎設施技術方面取得哪些進步才能實現這一未來？
VC：我認為很多技術已經存在，如果我們現在一步步走，首先我們需要做的事情就是真正捕獲更改資料–這就是類似Debezium這樣的專案做得很棒的地方，越來越多的公司從資料庫提供CDC流，而且隨著這種方式成為主流，採用更加標準化的工具來獲取這些流並將其放入資料湖的表中，我認為這是我們真正需要的。有了Apache Hudi，我們已經朝這個方向邁出了一大步，這就像我們一直在構建Hudi一樣，就像一個平臺，而不是像事務層一樣，或者只解決了這一更新問題，更多的工具和一條更好的途徑來快速地提取和整合資料，我要說的第二部分是如果花一點時間來比較一下雲資料倉儲和資料湖，資料湖中的中央meta儲存可能仍然是Hive Metastore，然後在最近幾年，Hive Metastore有其自身的可擴充套件性問題，它無法跟蹤檔案級別或類似級別的詳細統計資訊，因此我覺得我們需要為了使人們能夠以出色的效能查詢此資料並希望提供出色的可用性，我們需要要麼像Hive Metastore這樣的顯著改進，要麼像Hudi這樣的新型類似系統以及為開源查詢引擎抽象的類似系統，這是我看到的一個技術差距。如果沒有此功能，則您的Presto查詢引擎可能真的非常非常好，但是如果沒有所有統計資料輸入，您將無法獲得與像雲資料倉儲這樣的完全垂直整合的系統一樣的效能，所以這些都是我認為我們需要改進的地方。
我要說的第三點，實際上是Hudi目標的核心，作為一個專案我們要思考的要比我們做的要遠得多，我們必須想一想如何從流處理中學習並讓我們的批處理作業更多，如增量執行無需過多處理，因為任何時候您都會遇到圍繞資料新鮮度或查詢效能的類似瓶頸，這會導致就像我們剛剛討論過的理想資料架構面臨的風險和威脅一樣。從那時起人們開始採用捷徑，並且喜歡在其資料體系結構方面朝著不同的方向發展，我認為這是我們應該建立的三件事。
Q8：回到Apache Hudi，您可以更深入地介紹Hudi的體系結構嗎？
VC：從高層次上講對Hudi最好的描述是它是一個資料湖平臺，而且它有很多平臺元件，它們圍繞某種資料庫核心進行了構建，並針對流處理進行了優化，所以我喜歡將其分解，Hudi是一個庫，沒有長期執行的伺服器，使用者可以使用Spark或Flink向其中寫入資料。Hudi將類似的資料組織在Apache Parquet或Apache Avro檔案中，並且提供了很多後設資料，還跟蹤有關在雲端儲存上對該邏輯資料集進行的寫入和更改的大量後設資料，然後所有查詢引擎（例如Hive，Spark，Presto，Impala，Trino甚至Redshift）都可以直接查詢在Hudi表中寫入的資料。現在如果像Hudi OSI資料層那樣分解Hudi，那麼您就擁有了雲端儲存，此外還有這些開放資料檔案格式，Parque，ORC，Avro檔案格式以及所有內容，Hudi定義了檔案組織的佈局，然後再提供併發控制和事務。然後它提供了一些功能來對資料建立索引，以便您可以進行快速更新刪除，另外Hudi還有一些服務（守護程式）優化儲存佈局，並在使用者高興地只是將資料寫入格式時在後臺重新索引某些內容，壓縮或在後臺執行多項操作，Hudi有很多這樣的服務，它們可以在寫入過程中同步執行或者非同步執行。它們可以像優化所有表的守護程式一樣執行。對於更新操作，可以先增量更新到日誌中，然後再壓縮它們，因此有一個壓縮服務，當然使用者可以改變資料儲存佈局，並重新對資料進行聚類以獲得更好的查詢效能，因此Hudi有一個Clustering服務，然後還有個Clean服務清理和清除舊檔案，所有這些服務彼此協調，這是Hudi的核心設計，而不是像其他系統那樣，Hudi有大量的上層服務，就像有一個提取服務一樣，它可以從Kafka中獲取資料，將其轉換為本質上是流，而不只是在S3上的Hudi表，它可以執行檢查點管理，它可以自己進行恢復。同樣我們擁有一堆不同的非結構化資料格式進行轉化將其提取到Hudi表中；也可以編寫流式的增量ETL管道，僅從上游Hudi表中使用變更流，可以獲得自某個時間點以來已插入或更新的所有記錄。Hudi也可處理重複資料。另外我們提供了一些工具，可以在資料寫入Hudi表時對外提供通知，我們有很多這樣的服務，這就是為什麼我要說我們的原則不是要建立一個資料庫核心，而是要建立一套工具和服務，使人們可以簡單地使用它，然後解決實際問題。
Q9：如果系統可以從Hudi受益但沒有使用Hudi，它們將面臨哪些挑戰呢？
VC：讓我們來一個沒有Hudi的資料湖。包括一個上游資料庫，假設您有一個Cassandra叢集或Dynamo，例如某些資料庫，其中包含一些即將到來的變更流，您有一個Kafka叢集，您的微服務通過該叢集記錄事件。現在您已經擁有了我們想要構建的資料湖體系結構。但是您想構建一組原始表，然後編寫一些ETL並構建一種派生表，如果沒有Hudi，人們通常會這樣做，那就是他們會像Spark作業那樣編寫程式碼，或者使用Kafka Connect或Camel之類的框架或者只是繼續編寫某些內容–就像從Kafka提取一樣，將這些事件寫成類似Avro檔案和行存，這就是您佈置原始資料的方式。然後他們將在幾個小時內批量匯入資料庫，或者可以從這些資料庫中進行更改捕獲，但是他們不知道如何應用它們，因此他們需要對整個表進行批量合併，這會進行資料庫的大量提取，並且它們將像事件的增量式提取那樣進行。而且如果他們想每5分鐘或每1分鐘提取一次Kafka資料，他們就必須做更多的事情來控制檔案大小和所有內容，這導致原始層中資料庫資料的資料新鮮度較差，並且產生有很多小檔案，或者由於它們是基於行的格式，導致分析查詢效能差。同樣編寫ETL的作業也將延遲，通常您使用Hive或Spark編寫一堆ETL，然後構建一組派生資料表，這些匯出的資料表還遭受不良的資料新鮮度的困擾，原始資料的查詢效率也非常非常差，因為您必須應對原始資料格式，並且必須處理許多小檔案，這些檔案通常會降低查詢效能。如果使用Hudi之類的工具，便可以使用Hudi的增量資料流工具，如果某個Kafka叢集中有任何資料，則可以增量、連續攝取，同時可以直接使該表，這意味著即使是資料庫資料，資料延遲也在幾分鐘之內。同時還可以使用Hudi自動調整小檔案功能，以便下游ETL和查詢執行效能更好，因為採用列存格式。
以Uber為例說明，如果每30分鐘提取一次資料，將會寫入10個檔案，這10個檔案中的大多數將包含所有城市的資料，因為這有點像資料到達的方式。但通過類似Hudi Clustering的服務可以重組資料，使屬於給定城市的所有記錄彼此靠近。這樣一來查詢實際上掃描的資料量將大大減少。可以做很多事情來減少查詢成本，提高效率，還可以很好地改善資料的新鮮度，繼續到派生的資料管道，Hudi還可以提供Hudi中每個表的變更流，這意味著可以採用與流處理中相同的概念。同樣您可以像Flink或Spark作業那樣將變更流連線到Hudi表，它也可以作為快照與另一個Hudi表關聯查詢。編寫增量資料管道使得它們處理較少的資料量，這意味著成本較低，並提供了更好的資料新鮮度，這是我想當初在Uber進行的一件令我著迷的事情。通常您沒有機會獲得可以真正降低成本並且在構建資料庫時也可以更快的機會，Hudi為您提供了一個框架，使您可以實際增量地攝取和增量地執行ETL，簡而言之它將為您的資料湖做好準備。
Q10：那麼對於Hudi來說，由Hudi構建的所有東西都被放入記憶體了嗎，還是Hudi完全使用磁碟？
VC：當您查詢Hudi表時，它與查詢Hive表或Presto表沒有什麼不同，或像為Hive表一樣，本質上這些湖引擎所做的就是Hudi所做的。 Hudi就像查詢層的形式一樣，只是像它們查詢的表抽象一樣呈現，Hudi本身會將所有資料儲存在雲端儲存之上，它沒有任何長時間執行的記憶體元件。在執行期間它可能會在給定的事務中快取一些內容，僅此而已。
Q11：那麼應用程式所有者（例如正在查詢的人）還是正在像資料科學家一樣進行最終查詢的人，他們是否需要了Hudi？還是對他們透明？
VC：如果他們正在執行批處理查詢，例如，如果您只是查詢表的快照，那麼它們通常不必真正關心它是Hudi還是Delta Lake或其他任何格式，甚至是Hive，他們通常只是簡單地感興趣："查詢速度更快，資料正確"，就這樣。因此他們不必知道，但是如果您是寫增量ETL的資料工程師，那麼您需要利用非常特定於Hudi的功能，您需要了解Hudi格式是什麼，因此這些人可能會意識到，如果您正在編寫批處理ETL管道，您甚至都不知道它是否是Hudi表，它的行為就像其他任何Hive表一樣。
Q12：當我們結束對話時，我想和您一起探索更多的東西。但是請描述現在Hudi的狀態，它能做什麼？您希望該專案實現的願景是什麼？距離您那個願景有多遠？
VC：廣義上講有很多原因，Hudi是我們2016年分享的願景的體現，"所有批處理都應該是增量的"，通過Hudi，我們在鞏固這一目標方面取得了很大進展。當整合原始資料層的資料時需要以增量的方式進行處理，我們在Hudi中構建了許多出色的軟體堆疊，它們的效能可能非常出色，並且具有許多功能可以使您做到這一點。具體地說我們有一個資料庫核心和一組類似的服務，這些服務都可以水平擴充套件和輕鬆部署。如果您知道如何部署Spark作業和Flink作業，Hudi可以開箱即用。我們將來真正想投資的部分實際上正在釋放真正的端到端增量ETL管道，我們應該能夠編寫非常複雜的ETL管道。批處理非常簡單，它是無狀態的。然而今天的流處理是有狀態的，甚至需要像一套不同的工程師一樣來編寫非常好的流處理程式，因此我們實際上希望降低該標準，然後幫助人們編寫複雜的增量ETL作業，併為該模型增加更多的批處理ETL工作量，就像我們希望該專案達到目標一樣，另一部分是我們需要在專案中解決的另一件事，我們正在逐步進行所有工作，因為我們希望節省成本，並且希望資料新鮮度更高，但是查詢引擎側還有很多空白，雲端儲存系統的一些基本限制可能會影響這些新資料的實時查詢效能，因此這有兩個方面。資料延遲我們可以通過增量ETL和增量攝取來解決，但是互動式和類似實時分析查詢的效能是我們可能需要構建的東西，例如Hudi中的可變快取，列式快取層，它實際上可以吸收大量更新，將其儲存在記憶體中，降低了合併成本，以便人們可以很好地對其進行查詢，現在所有表統計資訊都寫在一個JSON檔案和Avro檔案中，這就像可伸縮性一樣，但是用這種方式計劃查詢可能會花費大量時間。因此我認為一個高效能和高度可伸縮的元儲存，內部有Snowflake或BigQuery或redshift之類的東西，我們需要構建類似的東西，我認為將這兩者放在一起將真正釋放我們的願景，那就是所有資料都應該非常快地到達，並且也應該能夠很快被查詢。