資料湖+資料倉儲 = 資料湖庫架構
傳統OLAP和OLTP是分離,資料是從業務資料儲存庫中提取,然後將其儲存在資料湖中,下一步就是進行ETL資料提取轉換和分析,然後,將這些資料的關鍵子集轉移到資料倉儲中,以生成用於決策的業務洞察力。這樣做的問題有:
- 可維護性差:由於存在資料湖和資料倉儲兩個系統,公司需要維護多個系統並促進同步,這使得系統複雜且難以長期維護。
- 缺乏一致性:公司可能經常發現難以保持其資料湖和資料倉儲架構的一致性。這不僅是一件代價高昂的事情,而且團隊還需要對兩個系統之間的 ETL/ELT 資料採用持續的資料工程策略。每個步驟都可能引入影響整體資料質量的故障和不需要的錯誤。
- 不斷變化的資料集:儲存在資料倉儲中的資料可能不如資料湖中的資料那麼最新,這取決於資料管道的時間表和頻率。
- 供應商鎖定:將大量資料轉移到集中式 EDW 對公司而言變得非常具有挑戰性,不僅因為執行此類任務所需的時間和資源,還因為這種架構建立了一個導致供應商鎖定的閉環。此外,儲存在倉庫中的資料也更難與組織內的所有資料終端使用者共享。
- 資料治理:雖然資料湖中的資料大多采用不同的基於檔案的格式,但資料倉儲主要採用資料庫格式,這增加了資料治理和沿襲的複雜性。
- 高階分析限制: PyTorch 和 TensorFlow 等高階機器學習應用程式與資料倉儲不完全相容。這些應用程式是需要從資料質量並不受控制的資料湖中獲取高質量資料的。
資料湖庫=資料倉儲+資料湖
資料湖庫(data lakehouse)解決了資料湖和資料倉儲架構的這些典型限制。
資料湖庫本質上是融合了兩全其美的下一代雲資料湖和倉儲架構。它是一種用於管理所有資料格式(結構化、半結構化或非結構化)以及支援多種資料工作負載(資料倉儲、BI、AI/ML 和流)的架構方法。資料湖庫以新的開放系統架構為基礎,允許資料團隊通過類似於資料倉儲的智慧資料管理功能在類似於資料湖中使用的低成本儲存平臺上實施資料結構。好處:
- 通過簡化模式交付資料質量:資料湖庫具有雙層架構,其中倉庫層嵌入在資料湖強制模式之上,該模式提供資料質量和控制,並協調更快的 BI 和報告。
- 減少資料漂移:資料湖庫架構減少了對多個資料副本的需求,並顯著減少了與資料漂移相關的挑戰。
- 更快的查詢:更快的互動式查詢與真正的資料民主化相結合,有助於做出更明智的決策。該架構允許資料科學家、工程師和分析師快速訪問所需的資料。這導致更快的洞察時間週期。
- 有效管理:通過實施資料湖庫架構,公司可以幫助其資料團隊節省大量時間和精力,因為它在儲存和處理資料以及提供業務洞察力方面需要更少的時間和資源。事實上,通過資料湖庫建立的單一資料管理平臺也可以減輕顯著的管理負擔。
- 無縫資料治理:資料湖庫用作單一來源,從而允許資料團隊嵌入高階功能,例如審計日誌和訪問控制。
- 有效的資料訪問和資料安全:資料湖庫為資料團隊提供了跨管道維護正確的訪問控制和加密以確保資料完整性的選項。此外,在資料湖庫模型中,資料團隊不需要管理所有資料副本的安全性,這使得安全管理變得更加容易和具有成本效益。
- 資料冗餘的可能性低:資料湖庫架構減少了在實施資料湖和資料倉儲的過程中對多個資料副本的需求,從而減少了資料漂移。
- 高可擴充套件性:資料湖庫提供資料和後設資料的高可擴充套件性。這使公司能夠以快速的洞察週期執行關鍵分析專案。
新興的資料湖庫模式產品
Azure Databricks Lakehouse 和Snowflake是公司可用於其資料管理計劃的兩個領先的 Lakehouse 平臺。
- Databricks:
資料湖上的資料處理引擎,新增了資料湖庫功能。
Databricks 本質上是一個 Apache Spark 驅動的資料處理工具,它為資料團隊提供了具有自動可擴充套件計算能力的敏捷程式設計環境。公司只需為使用中的計算資源付費。Databricks 平臺最適合在需要準備和攝取資料的管道早期階段進行資料處理。公司還可以利用它來準備資料以進行轉換和豐富,但在處理用於報告的資料方面存在不足。
在過去幾年中,Databricks 一直專注於圍繞傳統資料倉儲構建功能。該平臺帶有內建的 DQL 查詢介面和直觀的視覺化功能。除此之外,Databricks 還帶有一個類似於資料庫的表結構,該資料庫專門以 Delta 檔案格式開發。這種格式用於將資料庫功能新增到資料湖中。該格式允許通過 ACID 事務和模式進行資料版本控制。
Azure Databricks Lakehouse 的主要特點
- 自帶即用型 spark 環境,無需配置
- 嵌入式開源 Delta Lake 技術,用作附加儲存層
- 通過在 Delta 表中合併較小的檔案來提供更好的效能
- Delta 表中的 ACID 功能有助於確保完整的資料安全性
- 具有多種語言選項,例如 Scala、Python、R、Java 和 SQL
- 平臺支援使用筆記本式編碼進行互動式資料分析
- 提供與 Blob 儲存、Azure 資料工廠和 Azure DevOps 等其他雲平臺服務的無縫整合選項
- 提供開源庫支援
- Snowflake
雲資料倉儲擴充套件以解決資料湖功能。
與 Databricks 不同,Snowflake 幾年前通過提供高度可擴充套件和分散式的計算能力改變了資料倉儲空間。該平臺通過在資料倉儲生態系統中分離儲存和處理能力來實現這一點。這是 Snowflake 在資料湖空間中擴充套件解決方案時採用的方法之一。
多年來,Snowflake 一直在逐步擴充套件其 ELT 功能,允許公司與平臺一起執行其 ELT 流程。例如,一些公司利用 Snowflake Streams 和 Tasks 在 Snowflake 中完成 SQL 任務,而另一些公司則使用 Snowflake 進行“dbt”。
Snowflake 資料湖庫的主要特點
- 帶有內建的匯出和查詢工具
- 該平臺可以與Metabase、Tableau、PowerBI等BI工具無縫對接
- 平臺支援JSON格式查詢和輸出資料
- 為半結構化資料提供安全和壓縮的儲存選項
- 可與 Amazon S3 等物件儲存輕鬆連線
- 具有精細的安全性,可提供最大的資料完整性
- 查詢的大小沒有明顯的限制
- 存在標準 SQL 方言和強大的函式庫
- 附帶虛擬倉庫,允許資料團隊根據要求對工作負載進行分離和分類
- 促進安全的資料共享和與其他雲技術的簡單整合
Dremio 和 Firebolt
資料湖上的 SQL Lakehouse 引擎,除了 Snowflake 和 Databricks,Dremio 和 Firebolt 等資料湖庫工具也推出了高階查詢功能。例如,Dremio 的 SQL Lakehouse 平臺能夠直接在任何資料湖儲存上提供高效能儀表板和直觀分析,從而消除對資料倉儲的需求。同樣,Firebolt 具有高階索引功能,可幫助資料團隊將資料訪問縮小到比分割槽更小的資料範圍。
雲資料湖和倉庫的演變
資料湖庫是對雲資料湖和倉儲架構的演變,它為資料團隊提供了利用兩全其美的機會,同時減輕所有歷史資料管理的弱點。如果做得好,資料湖庫計劃可以釋放資料並使公司能夠以所需的方式和所需的速度使用它。
展望未來,隨著雲資料倉儲和資料湖架構的融合,公司可能很快就會找到結合所有資料湖庫工具的所有功能的供應商。在構建和管理資料管道時,這可能會帶來無窮無盡的機會。
相關文章
- 資料湖 vs 資料倉儲 vs 資料庫資料庫
- 資料湖 VS 資料倉儲之爭?阿里提出大資料架構新概念:湖倉一體阿里大資料架構
- 讀資料湖倉04資料架構與資料工程架構
- 讀資料湖倉08資料架構的演化架構
- 資料湖 vs 倉庫 vs 資料庫資料庫
- 資料湖會取代資料倉儲嗎?
- 談談資料湖和資料倉儲
- 萬字詳解資料倉儲、資料湖、資料中臺和湖倉一體
- 關於資料湖、資料倉儲的想法
- 資料倉儲被淘汰了?都怪資料湖
- 資料倉儲、資料湖與湖倉一體的區別與聯絡
- 資料湖和中央資料倉儲的設計
- 資料湖--架構師如何助力“湖加速”?架構
- 資料倉儲、資料集市、資料湖,你的企業更適合哪種資料管理架構?架構
- 資料網格將替代資料倉儲或資料湖?- thenewstack
- 讀資料湖倉06資料整合
- 讀資料湖倉02資料抽象抽象
- 資料湖是下一代資料倉儲?
- 資料湖架構,為什麼需要“湖加速”?架構
- 通用資料湖倉一體架構正當時架構
- 一文讀懂:本地資料湖丨資料倉儲丨雲資料湖的利與弊
- 通俗語言解釋資料倉儲、資料湖、資料中臺
- 資料湖是誰?那資料倉儲又算什麼?
- 讀資料湖倉01讓資料可信
- 資料倉儲 vs 資料湖 vs 湖倉一體:如何基於自身資料策略,選擇最合適的資料管理方案?
- 奈學:資料湖和資料倉儲的區別有哪些?
- 讀資料湖倉07描述性資料
- 銀行大資料新玩法,構建“一湖兩庫”金融資料湖大資料
- 資料湖架構及概念簡介架構
- 資料湖
- 資料倉儲、資料集市、資料湖、資料中臺到底有什麼區別?
- 有了資料湖,資料倉儲究竟能不能被取代?
- 一文讀懂選擇資料湖還是資料倉儲
- 讀資料湖倉05資料需要的層次
- 讀資料湖倉03不同型別的資料型別
- 大資料湖倉一體架構對分散式儲存有哪些技術需求?大資料架構分散式
- 資料湖中加熱資料?
- 阿里云云原生資料湖分析DLA重磅釋出-資料湖管理,助力企業一站式管理OSS資料湖儲存資料阿里