消除混亂：數據倉庫與數據湖與數據湖屋

各行各業的 CIO 都在努力利用數據蔓延，面臨嚴峻挑戰。 其中之一是存儲所有企業數據以提供強大的數據分析。

傳統上存在兩種數據存儲解決方案：數據倉庫和數據湖。

數據倉庫主要存儲來自操作和事務系統的轉換後的結構化數據，並用於對這些歷史數據進行快速復雜的查詢。

數據湖充當轉儲，存儲各種數據，包括半結構化和非結構化數據。 它們支持高級分析，例如用於實時數據處理或機器學習的流式分析。

從歷史上看，數據倉庫的推出成本很高，因為除了維護它們的技能外，您還需要為存儲空間和計算資源付費。 隨著存儲成本的下降，數據倉庫變得更便宜。 一些人認為數據湖（傳統上是一種更具成本效益的替代方案）現在已經死了。 一些人認為數據湖仍然很流行。 與此同時，其他人正在談論一種新的混合數據存儲解決方案——數據湖庫。

他們每個人都有什麼關係？ 讓我們仔細看看。

本博客探討了數據倉庫、數據湖和數據湖庫、流行的技術堆棧和用例之間的主要區別。 它還提供了為您的公司選擇正確解決方案的提示，儘管這很棘手。

什麼是數據倉庫？

數據倉庫旨在存儲結構化、精選的數據，將數據集組織在表和列中。 用戶可以輕鬆地使用這些數據來進行傳統的商業智能、儀表板和報告。

數據倉庫架構

三層架構是設計數據倉庫最常用的方法。 它包括：

• 底層：數據倉庫的暫存區和數據庫服務器，用於從各種來源加載數據。 提取、轉換和加載 (ETL) 過程是將數據推送到數據倉庫的傳統方法
• 中間層：用於在線分析處理 (OLAP) 的服務器，可將數據重組為多維格式以進行快速計算
• 頂層：用於處理數據的 API 和前端工具

圖 1：數據倉庫參考架構

應該提到數據倉庫的其他三個重要組件：數據集市、操作數據存儲和元數據。 數據集市屬於底層。 它們存儲數據倉庫數據的子集，服務於各個業務線。

運營數據存儲充當存儲庫，為基於簡單查詢的運營報告提供組織最新數據的快照。 它們可以用作數據源和數據倉庫之間的中間層。

還有元數據——描述數據倉庫數據的數據——存儲在專用存儲庫中，也位於底層。

數據倉庫的演變和技術

數據倉庫已經存在了幾十年。

傳統上，數據倉庫託管在本地，這意味著公司必須購買所有硬件並在本地部署軟件，無論是付費系統還是開源系統。 他們還需要一個完整的 IT 團隊來維護數據倉庫。 從好的方面來說，傳統數據倉庫帶來了（並且今天仍然如此）快速的洞察時間，沒有延遲問題，完全控制數據以及 100% 的隱私，並最大限度地降低了安全風險。

隨著雲的普及，許多組織現在選擇遷移到所有數據都存儲在雲中的雲數據倉庫解決方案。 它也使用某種類型的集成查詢引擎在雲中進行分析。

市場上有各種成熟的雲數據倉庫解決方案。 每個提供商都提供其獨特的倉庫功能和不同的定價模型。 例如，Amazon Redshift 被組織為一個傳統的數據倉庫。 雪花也是如此。 Microsoft Azure 是一個 SQL 數據倉庫，而 Google BigQuery 基於無服務器架構，本質上是軟件即服務 (SaaS)，而不是基礎設施或平台即服務，例如 Amazon Redshift。

著名的本地數據倉庫解決方案包括 IBM Db2、Oracle 自治數據庫、IBM Netezza、Teradata Vantage、SAP HANA 和 Exasol。 它們也可以在雲上使用。

基於雲的數據倉庫顯然更便宜，因為不需要購買或推出物理服務器。 用戶只需為需要的存儲空間和計算能力付費。 雲解決方案也更容易擴展或與其他服務集成。

數據倉庫以最高的數據質量和快速的洞察力服務於高度特定的業務需求，將長期存在。

數據倉庫用例

數據倉庫提供對 PB 和 PB 歷史數據的高速和高性能分析。

它們基本上是為 BI 類型的查詢而設計的。 例如，數據倉庫可能會給出關於特定時間段內的銷售額（按地區或部門分組）以及銷售額同比變動的答案。 數據倉庫的關鍵用例是：

• 交易報告以提供業務績效的圖片
• 臨時分析/報告，為獨立和“一次性”業務挑戰提供答案
• 數據挖掘從數據中提取有用的知識和隱藏模式，以解決複雜的現實問題
• 通過數據可視化動態呈現
• 向下鑽取以查看數據的層次維度以獲取詳細信息

將結構化業務數據放在運營數據庫之外的一個易於訪問的位置，對於任何數據成熟的公司來說都非常重要。

但是，傳統的數據倉庫不支持大數據技術。

它們還成批更新，一次性定期處理所有來源的記錄，這意味著數據在匯總進行分析時可能會變得陳舊。 數據湖似乎解決了這些限制。 有一個權衡。 讓我們探索一下。

什麼是數據湖？

數據湖大多以原始形式收集未經提煉的原始數據。 數據湖和數據倉庫之間的另一個關鍵區別是，數據湖存儲這些數據而不將其安排到任何稱為模式的邏輯關係中。 然而，這就是他們實現更複雜分析的方式。

數據湖提取 (i) 來自 ERP、CRM 或 SCM 等業務應用程序的交易數據，(ii) .csv 和 .txt 格式的文檔，(iii) XML、JSON 和 AVRO 格式等半結構化數據， (iv) 設備日誌和物聯網傳感器，以及 (v) 圖像、音頻、二進製文件、PDF 文件。

數據湖架構

數據湖使用扁平架構進行數據存儲。 其關鍵組成部分是：

• 採集到湖中的所有數據的青銅區域。 數據按原樣存儲用於批處理模式或作為流式工作負載的聚合數據集
• 根據業務需求過濾和豐富數據以供探索的銀區
• 黃金區域存儲精心策劃的結構良好的數據，用於應用 BI 工具和 ML 算法。 該區域通常具有為傳統數據倉庫和數據集市提供數據的運營數據存儲
• 沙箱，可以在其中試驗數據以進行假設驗證和測試。 它既可以作為 Hadoop 或其他 NoSQL 技術的完全獨立的數據庫來實現，也可以作為黃金區的一部分來實現。

圖 2：數據湖參考架構

數據湖本身並不包含分析功能。 沒有它們，它們只會存儲本身無用的原始數據。 因此，組織在數據湖之上構建數據倉庫或利用其他工具來使用數據。

為了確保數據湖不會變成數據沼澤，重要的是要有一個有效的數據管理策略，在數據湖設計中包含內置的數據治理和元數據管理。 在理想的世界中，數據湖中的數據應該被編目、索引、驗證，並且易於數據用戶使用。 不過這種情況很少見，許多數據湖項目都失敗了。 這是可以避免的：無論數據團隊的成熟度如何，安裝至少必要的控制措施以強制執行數據驗證和質量是至關重要的。

數據湖演進與技術

2000 年代初大數據的興起為組織帶來了巨大的機遇和巨大的挑戰。 業務需要新技術來分析這些龐大、混亂且快速增長的數據集，以捕捉大數據對業務的影響。

2008 年，Apache Hadoop 提出了一種創新的開源技術，用於大規模收集和處理非結構化數據，為大數據分析和數據湖鋪平了道路。 不久之後，Apache Spark 出現了。 它更容易使用。 此外，它還提供了構建和訓練 ML 模型、使用 SQL 查詢結構化數據以及處理實時數據的功能。

如今，數據湖主要是雲託管存儲庫。 AWS、Azure 和 Google 等所有頂級雲提供商都提供基於雲的數據湖以及具有成本效益的對象存儲服務。 他們的平台帶有各種數據管理服務來自動化部署。 例如，在一種情況下，數據湖可能由數據存儲系統（如 Hadoop 分佈式文件系統 (HDFS) 或 Amazon S3）與雲數據倉庫解決方案（如 Amazon Redshift）集成。 這些組件將與生態系統中的服務分離，這些服務可能包括用於數據處理的 Amazon EMR、提供數據目錄和轉換功能的 Amazon Glue、Amazon Athena 查詢服務或用於構建元數據存儲庫和索引的 Amazon Elasticsearch Service數據。 由於安全、隱私或延遲等常見的雲問題，本地數據湖仍然很常見。

還有一些本地存儲供應商為數據湖提供一些產品，但是他們的數據湖產品並沒有明確定義。 與數據倉庫不同，數據湖背後沒有多年的實際部署。 仍然有很多批評將數據湖概念描述為模糊和不明確。 批評者還認為，在任何組織中，很少有人具備針對原始數據運行探索性工作負載的技能（或對此充滿熱情）。

他們說，需要謹慎對待將數據湖用作所有企業數據的中央存儲庫的想法。 還有一個挑釁性的說法是數據湖的日子已經屈指可數了。 引用了以下原因：

• 數據湖不能按需有效地擴展計算資源（嗯，這是因為它們一開始就不是設計意圖的）
• 數據湖背負著巨大的技術債務，它們的創建主要是由營銷炒作驅動的，而不是技術原因（許多數據倉庫也發生了同樣的情況）
• 隨著雲數據倉庫解決方案的興起，數據湖不再提供顯著的成本效益（成本問題並不那麼簡單，因為很難預測計算成本）

這種批評是任何年輕技術的固有部分。 但是，數據湖確實有明確的用例，例如流式分析。 目前，它們還沒有威脅到數據倉庫。 在某些時候，數據湖甚至勝過數據倉庫，在存儲數據方面提供更廣泛的分析能力、成本效益和靈活性。 然而，隨著數據倉庫技術的成熟，許多人認為現在沒有明顯的贏家。 通常建議同時維護它們，或者……選擇混合架構。 繼續閱讀。

數據湖用例

數據湖的主要思想是讓企業盡快訪問所有來源的所有可用數據。 數據湖不只是描繪昨天發生的事情。 存儲大量數據的數據湖旨在使組織能夠更多地了解當前（使用流式分析）和未來（使用大數據解決方案，包括預測分析和機器學習）。 數據湖的關鍵用例是：

• 為企業數據倉庫提供數據集
• 執行流分析
• 實施機器學習項目
• 使用 Tableau 或 MS Power BI 等歷史悠久的企業 BI 工具構建高級分析圖表
• 構建自定義數據分析解決方案
• 運行根本原因分析，使數據團隊能夠追踪問題的根源

憑藉強大的數據工程技能將原始數據轉移到分析環境中，數據湖可能非常相關。 它們允許團隊對數據進行試驗，以了解它的用途。 這可能涉及構建模型以挖掘數據並嘗試不同的模式以以新的方式查看數據。 數據湖還允許處理從網絡日誌和物聯網傳感器湧入的流數據，不適合傳統的數據倉庫方法。

簡而言之，數據湖使組織能夠挖掘模式、預測變化或發現圍繞新產品或當前流程的潛在商機。 用於不同的業務需求，數據湖和數據倉庫通常是串聯實現的。 在我們轉向下一個數據存儲概念之前，讓我們快速回顧一下數據倉庫和數據湖之間的主要區別。

數據倉庫與數據湖

新的混合架構數據湖庫怎麼樣？

除了營銷之外，關於數據湖庫的關鍵理念是將計算能力引入數據湖。 在架構上，數據湖庫通常包括：

• 存儲層以開放格式（例如 Parquet）存儲數據。 這一層可以稱為數據湖，與計算層分離
• 提供組織倉庫功能的計算層，支持元數據管理、索引、模式實施和 ACID（原子性、一致性、可靠性和持久性）事務
• 用於訪問數據資產的API 層
• 服務層支持各種工作負載，從報告到 BI、數據科學或機器學習。

圖 3：Data Lakehouse 參考架構

被吹捧為結合了兩全其美的解決方案，數據湖屋解決了這兩個問題：

• 數據倉庫的限制，包括缺乏對依賴結構化和非結構化數據的高級數據分析的支持，以及不將存儲與計算資源分開的傳統數據倉庫的顯著擴展成本
• 數據湖挑戰，包括數據重複、數據質量以及訪問多個系統以執行各種任務或與分析工具實現複雜集成的需求

數據湖庫是數據分析領域的一項新進展。 該概念於 2017 年首次用於 Snowflake 平台。 2019 年，AWS 使用數據湖庫術語來描述其 Amazon Redshift Spectrum 服務，該服務允許其數據倉庫服務 Amazon Redshift 的用戶搜索存儲在 Amazon S3 中的數據。 2020 年，Data Lakehouse 一詞開始廣泛使用，Databricks 將其用於其 Delta Lake 平台。

隨著各行各業的公司都在採用人工智能來改善服務運營、提供創新產品和服務或推動營銷成功，數據湖的未來可能會一片光明。 數據倉庫提供的來自操作系統的結構化數據不適合智能分析，而數據湖則不適用於穩健的治理實踐、安全性或 ACID 合規性。

數據湖與數據湖庫

所以數據倉庫 vs. 數據湖 vs. 數據湖房：選擇哪個

無論您是想從頭開始構建數據存儲解決方案，還是對舊系統進行現代化改造以支持 ML 或提高性能，正確的答案都不容易。 隨著供應商的產品和定價模式迅速發展，關鍵差異、收益和成本仍然存在很多混亂。 此外，即使您有利益相關者的支持，這始終是一個困難的項目。 但是，在選擇數據倉庫、數據湖和數據湖庫時，有一些關鍵的考慮因素。

您應該回答的主要問題是：為什麼。 這裡要記住的一點是，數據倉庫、湖泊和 Lakehouse 之間的主要區別不在於技術。 它們是關於服務於不同的業務需求。 那麼，為什麼您首先需要數據存儲解決方案？ 是用於定期報告、商業智能、實時分析、數據科學還是其他復雜的分析？ 數據一致性或及時性對您的業務需求更重要嗎？ 花一些時間開髮用例。 您的分析需求應該得到很好的定義。 您也應該深入了解您的用戶和技能組合。 一些經驗法則是：

• 如果您有確切的問題並且知道您希望定期獲得哪些分析結果，那麼數據倉庫是一個不錯的選擇。
• 如果您在醫療保健或保險等高度監管的行業，您可能首先需要遵守廣泛的報告規定。 因此，數據倉庫將是更好的選擇。
• 如果您的 KPI 和報告要求可以通過簡單的歷史分析來解決，那麼數據湖或混合解決方案將是多餘的。 改用數據倉庫。
• 如果您的數據團隊正在進行實驗性和探索性分析，請選擇數據湖或混合解決方案。 但是，您需要強大的數據分析技能來處理非結構化數據。
• 如果您是一個想要利用機器學習技術的數據成熟組織，那麼混合解決方案或數據湖將是天作之合。

還要考慮您的預算和時間限制。 數據湖的構建速度肯定比數據倉庫快，而且可能更便宜。 您可能希望逐步實施您的計劃並在擴大規模時添加功能。 如果您想對遺留數據存儲系統進行現代化改造，那麼您應該再次詢問為什麼需要它。 是不是太慢了？ 或者它不允許您在更大的數據集上運行查詢？ 是否缺少某些數據？ 您想提取不同類型的分析嗎？ 您的組織在遺留系統上花費了大量資金，因此您肯定需要一個強大的業務案例來放棄它。 也將其與投資回報率聯繫起來。 數據存儲架構仍在成熟中。 無法確定它們將如何發展。 但是，無論您將採取哪條道路，識別常見的陷阱並充分利用已有的技術是很有用的。

我們希望這篇文章已經消除了一些關於數據倉庫、數據湖和數據湖庫的困惑。 如果您仍有疑問或需要頂級技術技能或建議來構建您的數據存儲解決方案，請聯繫 ITRex。 他們會幫助你。

最初於 2022 年 2 月 23 日在 https://itrexgroup.com 上發布。