在考慮數據平台時,考慮所有可用的服務和架構選項可能有點困難。
企業數據平台通常由數據倉庫、數據模型、數據湖和報告組成,每個都有特定的目的和所需的技能集。 相比之下,在過去幾年中出現了一種稱為數據湖庫的新設計。
數據湖和數據倉庫數據管理的多功能性結合在稱為“數據湖庫”的革命性數據存儲架構中。
我們將在這篇文章中深入研究數據湖庫,包括它的組件、特性、架構和其他方面。
什麼是數據湖屋?
顧名思義,數據湖屋是一種將數據湖與數據倉庫相結合,分別解決各自不足的新型數據架構。
本質上,Lakehouse 系統使用廉價的存儲來維護原始形式的大量數據,就像數據湖一樣。 在商店頂部添加元數據層還可以提供數據結構並授權數據管理工具,例如數據倉庫中的那些。
它存儲了他們從整個組織中使用的不同業務應用程序、系統和小工具獲得的大量有組織、半結構化和非結構化數據。
大多數時候,數據湖使用帶有文件應用程序編程接口 (API) 的低成本存儲基礎架構,以開放的通用文件格式存儲數據。
這使得許多團隊可以通過單個系統訪問所有公司數據,以實施各種計劃,例如數據科學、 機器學習和商業智能。
功能
- 低成本存儲。 數據湖庫必須能夠將數據存儲在廉價的對象存儲中,例如 Google雲端 存儲、Azure Blob 存儲、Amazon Simple Storage Service,或者本機使用 ORC 或 Parquet。
- 數據優化能力:數據佈局優化、緩存和索引是數據湖庫必須能夠在保持數據原始格式的同時優化數據的幾個示例。
- 一層事務性元數據:在必要的低成本存儲之上,這實現了對數據倉庫性能至關重要的數據管理功能。
- 支持聲明性 DataFrame API:大多數 AI 工具都可以使用 DataFrame 來檢索原始對象存儲數據。 對聲明性 DataFrame API 的支持增加了動態改進數據表示和結構以響應特定數據科學或 AI 任務的能力。
- 支持 ACID 事務:縮寫詞 ACID 代表原子性、一致性、隔離性和持久性,是定義事務和確保數據一致性和可靠性的關鍵組件。 此類事務以前只能在數據倉庫中進行,但 Lakehouse 提供了將它們與數據湖一起使用的選項 也是。 多條數據流水線,包括並發數據讀寫,解決了後者數據質量低的問題。
數據湖屋的元素
數據湖庫的架構在較高層次上分為兩個主要層。 存儲層的數據攝入由 Lakehouse 平台(即數據湖)控制。
無需將數據加載到數據倉庫或將其轉換為專有格式,處理層就可以直接使用一系列工具查詢存儲層中的數據。
然後,BI 應用程序以及 AI 和 ML 技術可以使用這些數據。 這種設計提供了數據湖的經濟性,但由於任何處理引擎都可以讀取這些數據,因此企業可以自由地使準備好的數據可用於一系列系統的分析。 使用這種方法進行處理和分析,可以提高處理器性能和成本。
由於它支持遵循以下 ACID(原子性、一致性、隔離性和持久性)標準的數據庫事務,該架構還允許多方在系統內同時訪問和寫入數據:
- 原子性 指的是在完成交易時,無論是完整交易還是全部交易都不成功。 如果進程中斷,這有助於避免數據丟失或損壞。
- 一致性 保證交易以可預測的、一致的方式發生。 它通過確保每個數據按照預定規則是合法的來維護數據的完整性。
- 隔離 確保在完成之前,系統中的任何其他事務都不會影響任何事務。 這允許多方同時從同一系統讀取和寫入,而不會相互干擾。
- 耐久度 保證在事務完成後對系統中數據的更改繼續存在,即使在系統發生故障的情況下也是如此。 交易帶來的任何變更都將永久存檔。
數據湖屋架構
Databricks(其 Delta Lake 概念的創新者和設計者)和 AWS 是數據湖庫概念的兩個主要倡導者。 因此,我們將依靠他們的知識和洞察力來描述湖屋的建築佈局。
數據湖庫系統通常有五層:
- 攝取層
- 存儲層
- 元數據層
- API層
- 消費層
攝取層
系統的第一層負責從各種來源收集數據並將其發送到存儲層。 該層可以利用多種協議連接到眾多內部和外部源,包括結合批處理和流式數據處理功能,例如
- NoSQL 數據庫,
- 文件共享
- 客戶關係管理應用程序,
- 網站,
- 物聯網傳感器,
- 社交媒體,
- 軟件即服務 (SaaS) 應用程序,以及
- 關係數據庫管理系統等
此時,可以使用用於數據流的 Apache Kafka 和用於從 RDBMS 和 NoSQL 數據庫導入數據的 Amazon Data Migration Service (Amazon DMS) 等組件。
存儲層
Lakehouse 架構旨在將各種類型的數據作為對象存儲在廉價的對象存儲中,例如 AWS S3。 使用開放文件格式,客戶端工具可以直接從商店讀取這些項目。
這使得許多 API 和消費層組件可以訪問和利用相同的數據。 元數據層存儲結構化和半結構化數據集的模式,以便組件可以在讀取數據時將其應用於數據。
例如,Hadoop 分佈式文件系統 (HDFS) 平台可用於構建雲存儲庫服務,將本地計算和存儲分開。 Lakehouse 非常適合這些服務。
元數據層
元數據層是區分這種設計的數據湖庫的基本組成部分。 它是一個單一目錄,為存儲在湖中的所有項目提供元數據(有關其他數據片段的信息),並允許用戶使用管理功能,例如:
- 由於 ACID 事務,並發事務可以看到數據庫的一致版本;
- 緩存以保存雲對象存儲文件;
- 使用索引添加數據結構索引以加快查詢處理;
- 使用零拷貝克隆來複製數據對象; 和
- 要存儲某些版本的數據等,請使用數據版本控制。
此外,元數據層支持實現模式管理,使用星形/雪花模式等 DW 模式拓撲,並直接在數據湖上提供數據治理和審計能力,增強整個數據管道的完整性。
模式演變和實施的功能包含在模式管理中。 通過拒絕任何不符合表模式的寫入,模式強制使用戶能夠保持數據的完整性和質量。
模式演變允許修改表的當前模式以適應不斷變化的數據。 由於數據湖之上的單一管理界面,還存在訪問控制和審計的可能性。
API層
現在出現了架構的另一個關鍵層,託管了許多 API,所有最終用戶都可以使用這些 API 更快地執行工作並獲得更複雜的統計數據。
使用元數據 API 可以更輕鬆地識別和訪問給定應用程序所需的數據項。
在機器學習庫方面,其中一些,例如 TensorFlow 和 Spark MLlib,可以讀取 Parquet 等開放文件格式並直接訪問元數據層。
同時,DataFrame API 提供了更大的優化機會,使程序員能夠組織和更改分散的數據。
消費層
Power BI、Tableau 和其他工具和應用託管在消費層下。 通過 Lakehouse 設計,客戶端應用程序可以訪問保存在湖中的所有元數據和所有數據。
Lakehouse可供公司內的所有用戶使用,以執行各種 分析操作,包括創建商業智能儀表板和運行 SQL 查詢和機器學習任務。
數據湖屋的優勢
組織可以創建一個數據湖庫來統一他們當前的數據平台並優化他們的整個數據管理流程。 通過拆除連接各種來源的孤島障礙,數據湖庫可以取代對不同解決方案的需求。
與策劃的數據源相比,這種集成產生了更有效的端到端過程。 這有幾個優點:
- 更少的管理:數據湖庫不是從原始數據中提取數據並準備在數據倉庫中使用,而是允許與其鏈接的任何源將其數據可用並組織起來以供使用。
- 提高成本效益:數據湖庫是使用現代基礎設施構建的,將計算和存儲分開,使得在不增加計算能力的情況下擴展存儲變得簡單。 僅使用廉價的數據存儲就可以實現具有成本效益的可擴展性。
- 更好的數據治理:數據湖庫採用標準化的開放架構構建,允許對安全性、指標、基於角色的訪問和其他重要管理組件進行更多控制。 通過統一資源和數據源,它們可以簡化和增強治理。
- 簡化標準:由於在 1980 年代連接受到高度限制,當數據倉庫最初開發時,本地化模式標準經常在企業內部甚至部門內部開發。 數據湖庫利用這樣一個事實,即許多類型的數據現在都具有開放的模式標準,通過攝取具有重疊統一模式的大量數據源來簡化程序。
數據湖屋的缺點
儘管圍繞數據湖庫的所有喧囂,重要的是要記住,這個想法仍然很新。 在完全採用這種新設計之前,請務必權衡缺點。
- 單片結構: 湖屋的全包式設計提供了幾個優點,但也帶來了一些問題。 單體架構通常會導致為所有用戶提供糟糕的服務,並且可能僵化且難以維護。 通常,架構師和設計師喜歡更模塊化的架構,他們可以針對各種用例進行定制。
- 技術還不成熟:最終目標需要大量的機器學習和人工智能。 在湖屋可以按預期運行之前,這些技術必須進一步發展。
- 與現有結構相比沒有顯著進步:對於湖屋實際貢獻多少價值仍然存在相當大的懷疑。 一些批評者認為,湖倉庫設計與適當的自動化設備相結合可以達到相當的效率。
數據湖屋的挑戰
採用數據湖庫技術可能很困難。 由於其組成部分的複雜性,將數據湖庫視為一個包羅萬象的理想結構或“一個萬能的平台”是不正確的。
此外,由於越來越多地採用數據湖,企業將不得不將其當前的數據倉庫遷移到其中,僅依賴於沒有明顯經濟效益的成功承諾。
如果在整個傳輸過程中存在任何延遲問題或中斷,這最終可能會變得昂貴、耗時並且可能不安全。
根據某些明確或暗示將解決方案作為數據湖庫推銷的供應商,業務用戶必須採用高度專業化的技術。 這些可能並不總是與鏈接到系統中心數據湖的其他工具一起使用,從而增加了問題。
此外,在運行關鍵業務工作負載時提供 24/7 分析可能很困難,這需要具有成本效益可擴展性的基礎架構。
結論
近年來最新的數據中心品種是數據湖屋. 它融合了信息技術、開源軟件、 雲計算和分佈式存儲協議。
它使企業能夠從任何位置集中存儲所有類型的數據,從而簡化管理和分析。 Data Lakehouse 是一個非常有趣的概念。
如果任何公司都可以訪問一個像數據倉庫一樣快速高效、同時又像數據湖一樣靈活的一體化數據平台,那麼它就會擁有顯著的競爭優勢。
這個想法仍在發展中,並且仍然相對較新。 因此,可能需要一些時間來確定某些東西是否可以傳播開來。
我們都應該對 Lakehouse 建築的發展方向感到好奇。
發表評論