Data Lakehouse (湖倉一體) 到底是什麼

語言: CN / TW / HK

背景

資料湖(Data Lake),湖倉一體(Data Lakehouse)儼然已經成為了大資料領域最為火熱的流行詞,在接受這些流行詞洗禮的時候,身為技術人員我們往往會發出這樣的疑問,這是一種新的技術嗎,還是僅僅只是概念上的翻新(新瓶裝舊酒)呢?它到底解決了什麼問題,擁有什麼樣新的特性呢?它的現狀是什麼,還存在什麼問題呢?

what-is-a-data-lakehouse
如果想及時瞭解Spark、Hadoop或者HBase相關的文章,歡迎關注微信公眾號: iteblog_hadoop

帶著這些問題,今天就從筆者的理解,為大家揭開 Data Lakehouse 的神祕面紗,來探一探其技術的本質到底是什麼?

Data Lakehouse(湖倉一體)是新出現的一種資料架構,它同時吸收了資料倉庫和資料湖的優勢,資料分析師和資料科學家可以在同一個資料儲存中對資料進行操作,同時它也能為公司進行資料治理帶來更多的便利性。那麼何為Data Lakehouse呢,它具備些什麼特性呢?

本文參考自 https://www.xplenty.com/glossary/what-is-a-data-lakehouse/ 和 https://databricks.com/blog/2020/01/30/what-is-a-data-lakehouse.html。

Data Lakehouse具備什麼特性?

一直以來,我們都在使用兩種資料儲存方式來架構資料:

  • 資料倉庫數倉這樣的一種資料儲存架構,它主要儲存的是以關係型資料庫組織起來的結構化資料。資料通過轉換、整合以及清理,並匯入到目標表中。在數倉中,資料儲存的結構與其定義的schema是強匹配的。
  • 資料湖:資料湖這樣的一種資料儲存結構,它可以儲存任何型別的資料,包括像圖片、文件這樣的非結構化資料。資料湖通常更大,其儲存成本也更為廉價。儲存其中的資料不需要滿足特定的schema,資料湖也不會嘗試去將特定的schema施行其上。相反的是,資料的擁有者通常會在讀取資料的時候解析schema(schema-on-read),當處理相應的資料時,將轉換施加其上。

現在許多的公司往往同時會搭建數倉、資料湖這兩種儲存架構,一個大的數倉和多個小的資料湖。這樣,資料在這兩種儲存中就會有一定的冗餘。

Data Lakehouse的出現試圖去融合數倉和資料湖這兩者之間的差異,通過將數倉構建在資料湖上,使得儲存變得更為廉價和彈性,同時lakehouse能夠有效地提升資料質量,減小資料冗餘。在lakehouse的構建中,ETL起了非常重要的作用,它能夠將未經規整的資料湖層資料轉換成數倉層結構化的資料。Data Lakehouse概念是由Databricks在此文[1]中提出的,在提出概念的同時,也列出瞭如下一些特性:

  • 事務支援:Lakehouse可以處理多條不同的資料管道。這意味著它可以在不破壞資料完整性的前提下支援併發的讀寫事務。
  • Schemas:數倉會在所有儲存其上的資料上施加Schema,而資料湖則不會。Lakehouse的架構可以根據應用的需求為絕大多數的資料施加schema,使其標準化。
  • 報表以及分析應用的支援:報表和分析應用都可以使用這一儲存架構。Lakehouse裡面所儲存的資料經過了清理和整合的過程,它可以用來加速分析。同時相比於數倉,它能夠儲存更多的資料,資料的時效性也會更高,能顯著提升報表的質量。
  • 資料型別擴充套件:數倉僅可以支援結構化資料,而Lakehouse的結構可以支援更多不同型別的資料,包括檔案、視訊、音訊和系統日誌。
  • 端到端的流式支援:Lakehouse可以支援流式分析,從而能夠滿足實時報表的需求,實時報表在現在越來越多的企業中重要性在逐漸提高。
  • 計算儲存分離:我們往往使用低成本硬體和叢集化架構來實現資料湖,這樣的架構提供了非常廉價的分離式儲存。Lakehouse是構建在資料湖之上的,因此自然也採用了存算分離的架構,資料儲存在一個叢集中,而在另一個叢集中進行處理。
  • 開放性:Lakehouse在其構建中通常會使Iceberg,Hudi,Delta Lake等構建元件,首先這些元件是開源開放的,其次這些元件採用了Parquet,ORC這樣開放相容的儲存格式作為下層的資料儲存格式,因此不同的引擎,不同的語言都可以在Lakehouse上進行操作。

Lakehouse的概念最早是由Databricks所提出的,而其他的類似的產品有Azure Synapse Analytics。Lakehouse技術仍然在發展中,因此上面所述的這些特性也會被不斷的修訂和改進。

Data lakehouse解決了什麼問題

那說完了Data Lakehouse的特性,它到底解決了什麼問題呢?

這些年來,在許多的公司裡,數倉和資料湖一直並存且各自發展著,也沒有遇到過太過嚴重的問題。但是仍有一些領域有值得進步的空間,比如:

  • 資料重複性:如果一個組織同時維護了一個數據湖和多個數倉,這無疑會帶來資料冗餘。在最好的情況下,這僅僅只會帶來資料處理的不高效,但是在最差的情況下,它會導致資料不一致的情況出現。Data Lakehouse統一了一切,它去除了資料的重複性,真正做到了Single Version of Truth。
  • 高儲存成本:數倉和資料湖都是為了降低資料儲存的成本。數倉往往是通過降低冗餘,以及整合異構的資料來源來做到降低成本。而資料湖則往往使用大資料檔案系統(譬如Hadoop HDFS)和Spark在廉價的硬體上儲存計算資料。而最為廉價的方式是結合這些技術來降低成本,這就是現在Lakehouse架構的目標。
  • 報表和分析應用之間的差異:報表分析師們通常傾向於使用整合後的資料,比如數倉或是資料集市。而資料科學家則更傾向於同資料湖打交道,使用各種分析技術來處理未經加工的資料。在一個組織內,往往這兩個團隊之間沒有太多的交集,但實際上他們之間的工作又有一定的重複和矛盾。而當使用Data Lakehouse後,兩個團隊可以在同一資料架構上進行工作,避免不必要的重複。
  • 資料停滯(Data stagnation):在資料湖中,資料停滯是一個最為嚴重的問題,如果資料一直無人治理,那將很快變為資料沼澤。我們往往輕易的將資料丟入湖中,但缺乏有效的治理,長此以往,資料的時效性變得越來越難追溯。Lakehouse的引入,對於海量資料進行catalog,能夠更有效地幫助提升分析資料的時效性。
  • 潛在不相容性帶來的風險:資料分析仍是一門興起的技術,新的工具和技術每年仍在不停地出現中。一些技術可能只和資料湖相容,而另一些則又可能只和數倉相容。Lakehouse靈活的架構意味著公司可以為未來做兩方面的準備。

Data Lakehouse存在的問題 現有的Lakehouse架構仍存在著一些問題,其中最為顯著的是:

  • 大一統的架構:Lakehouse大一統的架構有許多的優點,但也會引入一些問題。通常,大一統的架構缺乏靈活性,難於維護,同時難以滿足所有使用者的需求,架構師通常更傾向於使用多模的架構,為不同的場景定製不同的正規化。
  • 並非現有架構上本質的改進:現在對於Lakehouse是否真的能夠帶來額外的價值仍存在疑問。同時,也有不同的意見 - 將現有的數倉、資料湖結構與合適的工具結合 - 是否會帶來類似的效率呢?
  • 技術尚未成熟:Lakehouse技術當前尚未成熟,在達到上文所提的能力之前仍有較長的路要走。

本文原文:Data Lakehouse (湖倉一體) 到底是什麼

本部落格文章除特別宣告,全部都是原創!
轉載本文請加上:轉載自過往記憶(https://www.iteblog.com/)
本文連結: 【Data Lakehouse (湖倉一體) 到底是什麼】(https://www.iteblog.com/archives/9905.html)

喜歡 (1) 分享 (0)