Apache Hudi 背後商業公司Onehouse宣佈2500萬美元A輪融資

就在一年前，我們釋出了 Onehouse——一種開放的、完全託管的、雲原生的lakehouse服務——以從根本上縮短最先進的資料湖的價值實現時間。Onehouse 提供在開放格式之上構建和運營資料湖所需的核心資料基礎設施服務，讓原本艱鉅的旅程變得輕鬆。

自推出以來，我們與幾位早期使用者合作，將我們的產品願景變為現實，併為他們的生產資料湖提供動力。我們的目標是在 lakehouse 技術之上提供雲資料倉儲堆疊的易用性和自動化，反過來也為使用者提供急需的成本效益和效能優勢。作為這一旅程的重要里程碑，我很高興地宣佈由 Addition 和 Greylock 合作伙伴領投的 2500 萬美元 A 輪融資。我很榮幸 Jerry Chen (Greylock) 和 Aaron Schildkrout (Addition) 加入我們的董事會。

在此期間，我們還與 100 多家組織就其資料湖和資料倉儲挑戰進行了接觸。在下面的部分中，我們分享了它們如何幫助塑造我們的路線圖，以及行業趨勢和我們對雲資料基礎架構的長期願景。

Lakehouse架構站穩腳跟

早在 2021 年，我們採訪過的大多陣列織都對新的 Lakehouse 技術感到好奇。然而，從許多方面來說，2022 年是 lakehouse 取得突破的一年，我們與之交談的幾乎所有組織都在積極評估這一轉變。作為一個在 lakehouse 技術被稱為“lakehouse”之前就一直在研究它的人，看到該類別令人難以置信的增長和勢頭，我感到無比興奮。Apache Hudi 去年的參與度創下歷史新高，因為大大小小的公司都使用該平臺來構建他們的資料湖。現在幾乎所有主要的雲倉庫和雲資料湖引擎都整合了三大 Lakehouse 儲存專案。Ahana、Dremio 和 Starburst 等許多供應商都圍繞 Lakehouse 重新命名了他們的整個雲產品。

總而言之，Gartner 仍然正確地將 Lakehouses 置於炒作週期的頂峰，在沒有完全提煉出技術可以或不能支援的工作負載的情況下，人們對此持樂觀態度。在 Onehouse，我們有一個團隊一直在運營可以說是地球上最大的交易資料湖。我們想從最初的 Hadoop EDW 願景的缺點中吸取教訓，其中的欣快和樂觀最終未能交付快速採用該技術所需的成熟、易於使用的軟體服務。我們正在接近 lakehouse 不可避免的平臺化，基於我們來之不易的經驗，我們將重點關注必要的自動化、卓越運營和技術創新。

垂直整合是錯誤的選擇

幾乎一致的是，使用者對從一個垂直技術堆疊轉移到另一個垂直技術堆疊持謹慎態度。這些使用者中的許多人在幾年前才從本地資料倉儲遷移到雲資料倉儲，現在正面臨一些關鍵的業務問題。隨著資料量和管道數量的增加，成本也在激增。當這些組織希望開始他們的資料科學工作時，他們還需要不同開放資料格式和程式設計訪問的資料，這在這些倉庫中很難實現。最後，即使使用基於開放格式構建的替代技術堆疊，也擔心會因各種專有服務而被鎖定。在管理底層資料時，大多數引擎供應商只關注自己引擎的工作負載或資料格式。這讓使用者只能自己照顧自己，導致分析癱瘓或代價高昂的資料遷移。我們已經生活在一個不斷髮展的多引擎世界中，使用者正在為傳統分析、流處理、資料科學、機器學習和人工智慧選擇不同的引擎。現在查詢 Apache Parquet/Orc 的最流行引擎與五年前不同。Onehouse 認為正確的以使用者為中心的方法是為資料引入不同的引擎，而不是相反。Onehouse 支援將不同的引擎橫向整合到一個管理良好的公共雲資料儲存中，這樣就可以執行一次標準服務，如資料攝取、資料叢集、索引和 GDPR 刪除，並跨多個引擎使用。事實上，我們可以透過明智地將工作負載從雲倉庫中移出並減少使用高成本的專有託管服務來直接解決上面提到的一些成本問題。今天，我們透過宣佈 Onetable[3] 功能在 Apache Hudi、Delta Lake 或 Iceberg 之間無縫互操作來解鎖 Databricks 或 Snowflake 等供應商內部的專有效能最佳化，從而加倍兌現我們解鎖這個多引擎生態系統的承諾。我們的後續工作將強調哪些引擎最適合哪些工作負載以及原因。

資料湖需要簡單，而不僅僅是高效

我們遇到的許多使用者都非常精明，並且完全瞭解圍繞垂直雲倉儲資料堆疊與更分散、更靈活的資料湖架構的所有權衡[4]。他們只是開始使用雲倉庫，因為它是一項完全託管的服務，可以減輕他們資料團隊的運營負擔。他們的想法是，在足夠大的規模下，他們可以透過經驗豐富的資料工程師來擴充套件他們的資料團隊，這些資料工程師可以使用 Apache Hudi 等技術構建他們的lakehouse。然而資料具有巨大的慣性，成功執行公司範圍內的資料遷移的現實證明是一項艱鉅的多年專案。

儘管去年全世界都對生成式人工智慧著迷，但基本的資料湖基礎設施仍然是手動的。我們公司最重要的創始目標之一就是改變這種現狀。我們每天都在挑戰自己，構建產品和技術，只需輕鬆點選幾下，即可在幾分鐘內啟動並執行資料湖。然後使用者應該能夠將各種查詢引擎連線到他們的資料湖，執行工作負載評估並在幾天後上線。當我們的第一個使用者能夠在幾天內上線時，我們感到非常驚喜，其中有一個複雜的用例，例如近實時 CDC 到 AWS 上的資料湖。最後，透過 Apache Hudi 的綜合資料服務集，甚至非 Onehouse 使用者也可以獲得這些好處。展望未來，我們希望做出更多貢獻，使 Onehouse/Apache Hudi 成為使用者雲資料之旅的第一站。

批次資料處理有更好的選擇

雖然使用開放表格式來擴充套件大型不可變表的後設資料的想法在去年獲得了很多關注，但這僅僅觸及了像 Apache Hudi 這樣的技術可以帶來多大變革的皮毛。2016 年在Uber建立該專案的最初動機[5]圍繞著一個大膽的新願景，即取代湖/倉庫上的批處理資料，這需要資料湖上更快的可變性。當時由於陷入批處理資料處理，我們 Uber 的夢想是將可變事務資料流近乎實時地增量處理到資料湖。如今，Apache Hudi 使用者可以在任何雲提供商上使用幾條命令輕鬆完成此操作[6]。Hudi 透過圍繞索引、合併讀取儲存格式、非同步表服務、可擴充套件後設資料、非阻塞併發控制以及對變更資料捕獲的內建支援進行創新來實現這一目標，這些問題最佳化了所有需要可變性的用例。在過去的一年裡，我們彙總了經過同行評審的全面比較[7]，這些比較提出了這些設計選擇和技術差異化因素，並表明幾家大型企業正在 Hudi 上執行高階增量處理工作負載。我們也為 Onehouse 帶來了相同的增量處理魔力，使用者可以在其中以完全增量的方式構建各層架構[8]，幾乎不需要任何程式碼，避免了任何資料重新計算。在市場供應商和行業專家做出 2023 年預測之際，我們也想發表自己的看法。我們預測 Lakehouse 技術將遵循 Lindy 效應[9]，繪製出與主要關聯式資料庫類似的路徑，該效應表明一項技術存在的時間越長，它在未來出現的可能性就越大。Onehouse 旨在透過對 Apache Hudi 專案和產品創新的持續貢獻來進一步推進增量處理願景。我們打算在今年晚些時候就此分享更多資訊。

向前

在我們開啟公司生活的新篇章之際，我要衷心感謝我們所有早期的設計合作伙伴、使用者和客戶的支援和反饋。我還要感謝我們這個規模雖小但才華橫溢的團隊，感謝他們的奉獻精神和辛勤工作。最後感謝 Apache Hudi 社群的持續合作和推動開源資料湖平臺的創新。

可以毫不誇張地說，Onehouse 的成功可能會對行業產生深遠影響，我們最終可以將資料儲存和管理與運算元據的不同計算引擎分離，讓我們永遠擺脫資料鎖定。我們將以誠意和我們的首要原則來實現這一願景，向前。