資料倉儲演變與資料湖倉架構

隨著資料量的爆炸性增長和資料型別的多樣化，傳統資料倉儲在處理非結構化和半結構化資料方面逐漸顯現不足。大資料技術的興起，特別是Hadoop和Spark等分散式處理框架，為處理海量資料提供了新的解決方案。然而，本地佈署Hadoop叢集的成本和複雜性也促使企業尋求更有效率的資料管理方式。雲端技術的發展為資料管理帶來了新的契機，雲端資料倉儲服務如Amazon Redshift、Snowflake等，提供了彈性擴充套件、高效能和低成本的優勢。雲端物件儲存的普及也催生了資料湖架構，允許儲存各種格式和結構的資料。為了整合資料湖和資料倉儲的優勢，資料湖倉架構應運而生，提供更快速、更靈活的資料分析能力。資料管道方面，ETL和ELT兩種方式各有優劣，企業需要根據自身需求選擇合適的方案。

資料管理架構的演變：從資料倉儲到資料湖倉

在過去的25年中，資料倉儲技術不斷進化，以支援日益增長的結構化資料。然而，現代數位平台（如行動和網頁應用程式、感測器、物聯網裝置、社群媒體和音視訊媒體平台）產生了大量的半結構化和非結構化資料。這些平台以高速率產生大量資料，其規模遠超傳統結構化資料來源。

傳統資料倉儲的侷限性

傳統資料倉儲擅長儲存和管理來自傳統來源的平面結構化資料，將其組織成關係型綱要（relational schema）。然而，它們在處理大量高速率的半結構化和非結構化資料方面表現不佳。隨著這些新型資料來源的重要性日益增加，組織需要更先進的技術來深入分析這些資料。

大資料處理技術的崛起

在2010年代初期，新的大資料處理技術開始流行。Hadoop，一個用於在電腦叢集上處理大型資料集的開源框架，成為處理大資料的主流方式。這些叢集包含數百台機器，配備有可容納數萬TB資料的磁碟卷，並由Hadoop分散式檔案系統（HDFS）進行管理。

許多組織在其資料中心佈署了Hadoop發行版，例如Cloudera、Hortonworks、MapR和IBM。這些Hadoop套件包括叢集管理工具，以及預先組態和整合的開源分散式資料處理框架，如MapReduce、Hive、Spark和Presto。像Apache Spark這樣的分散式資料處理框架能夠處理各種結構化、半結構化和非結構化資料，並透過在叢集中的數千台機器上分散處理，提供極高的吞吐量。

雲端資料管理的興起

隨著組織越來越多地採用公有雲基礎設施，他們開始利用雲端資料倉儲服務，如Amazon Redshift、Snowflake、Google BigQuery和Azure Synapse。這些服務提供了無需前期投資、PB級擴充套件、高效能、彈性容量擴充套件、可變成本和基礎設施管理的自由。

與此同時，雲端物件儲存（如Amazon S3）變得越來越流行，能夠以遠低於本地儲存的成本儲存數百PB的資料，並支援儲存來自任何來源、格式或結構的資料。這些雲端物件儲存服務也提供了與數百種雲端原生和第三方資料處理及分析工具的原生整合。

資料湖架構的出現

組織開始採用資料湖架構，這是一種新的整合分析資料管理方法。資料湖架構使得組織能夠在一個集中的、可高度擴充套件的儲存函式庫中匯集各種大小和型別（結構化、半結構化、非結構化）的資料，從而建立單一真相來源。

內容解密：

什麼是資料湖？ 資料湖是一個集中式的儲存函式庫，能夠儲存各種原始資料，無論其格式或結構如何。它使得組織能夠將不同來源的資料匯集在一起，從而更容易進行深入分析。
為什麼採用資料湖架構？ 採用資料湖架構可以幫助組織克服傳統資料倉儲和大資料叢集所面臨的挑戰，例如資料孤島和資料移動的困難，從而實作單一真相來源。

從資料湖到資料湖倉

最近，雲端供應商開始在其分析服務中新增支援資料湖倉架構的能力。資料湖倉架構旨在原生整合資料湖和資料倉儲的最佳功能，包括快速攝取任何型別的資料、儲存和處理PB級非結構化、半結構化和結構化資料、支援ACID交易、低延遲資料存取，以及使用各種工具（包括SQL、Spark、機器學習框架和商業智慧工具）消費資料。

內容解密：

什麼是資料湖倉？ 資料湖倉是一種新的分析架構，能夠結合資料湖和資料倉儲的優勢，提供更快、更靈活的資料分析能力。
為什麼選擇資料湖倉？ 選擇資料湖倉架構可以幫助組織實作更高效、更具成本效益的資料管理，同時支援更廣泛的分析和應用場景。

此圖示說明瞭從傳統資料倉儲到資料湖倉架構的技術演進路徑。

隨著大資料的持續增長和雲端技術的日益成熟，未來資料管理架構將繼續演進，提供更高效、更靈活、更具成本效益的解決方案。組織需要保持對新技術和新趨勢的關注，以便及時調整自己的資料管理策略，從而在瞬息萬變的市場環境中保持競爭優勢。

內容解密：

未來的挑戰與機會 組織需要關注新技術的發展，如人工智慧和機器學習，以進一步提升資料分析的能力。同時，也需要考慮到資料安全和隱私保護的問題。
如何應對未來的變化？ 組織應持續監控技術發展趨勢，並根據自身需求調整資料管理策略，以實作更高效的資料分析和決策支援。

深入理解資料倉儲與資料市集：真相的源泉

企業資料倉儲（Enterprise Data Warehouse, EDW）是核心的資料儲存函式庫，包含結構化、整理過、一致且可信賴的資料資產，這些資產按照良好的模型化結構進行組織。EDW中的資料資產涵蓋了關鍵業務領域的所有相關資訊，透過整合來自以下來源的資料構建而成：

執行業務的應用程式（企業資源規劃系統、客戶關係管理系統、業務線應用程式），這些應用程式支援企業各個關鍵業務領域的運作。
外部資料來源，例如來自合作夥伴和第三方的資料。

企業資料倉儲為業務使用者和決策者提供了一個易於使用、集中的平台，幫助他們查詢和分析經過良好模型化、整合的單一真相版本，涵蓋客戶、產品、銷售、行銷、供應鏈等多個業務主題領域。業務使用者透過分析倉儲中的資料來衡量業務績效、發現當前和歷史業務趨勢、尋找商機以及瞭解客戶行為。

資料倉儲與資料市集的核心概念

在接下來的內容中，我們將透過討論以EDW為中心的典型資料管理架構來檢視資料倉儲的基礎概念，如下圖所示。通常，資料倉儲為中心的架構包括以下幾個部分：

資料倉儲（以及可選的多個主題聚焦的資料市集）
資料倉儲與各個業務領域資料來源之間的整合
資料倉儲與使用倉儲中資料的終端使用者分析工具和系統之間的整合

圖2.1：企業資料倉儲架構

在我們的架構中心是企業資料倉儲，它承載了一系列包含當前和歷史關鍵業務主題領域資料的資產。在左側，我們有源系統和一個ETL（提取、轉換、載入）管線，用於將資料載入倉儲。在右側，我們可以看到多個從資料倉儲消費資料的系統/應用程式。

現代雲原生資料倉儲的優勢

在接下來的幾節中，我們將探討現代雲原生資料倉儲（如Amazon Redshift）如何利用平行處理和欄位儲存來儲存和處理海量資料。Amazon Redshift提供了極高的查詢吞吐量，同時處理大量資料。

分散式儲存與大規模平行處理

在下圖中，我們可以看到Amazon Redshift叢集的底層架構：

圖2.2：Amazon Redshift叢集的MPP架構

如圖所示，Amazon Redshift叢集包含多個計算資源，以及與其相關聯的磁碟儲存。Redshift叢集中有兩種型別的節點：

一個長官節點，負責與客戶端應用程式介面、接收和解析查詢，並協調在計算節點上的查詢執行
多個計算節點，用於儲存倉儲資料並平行執行查詢步驟

每個計算節點都有其獨立的處理器、記憶體和儲存卷，這些資源與叢集中的其他計算節點隔離（這被稱為無分享架構）。資料以分散式方式儲存在計算節點上。透過簡單地向叢集新增更多的計算節點（水平擴充套件），叢集可以輕鬆擴充套件以儲存和處理PB級別的資料。

雲端資料倉儲實作了一種稱為大規模平行處理（Massively Parallel Processing, MPP）的分散式查詢處理架構，以加速對海量資料的查詢。在這種方法中，叢集長官節點將傳入的客戶端查詢編譯成分散式執行計畫。然後，它協調在資料倉儲叢集的多個計算節點上平行執行編譯後的查詢程式碼片段。每個計算節點在其本地儲存的分散式資料集部分上執行分配給它的查詢片段。為了最佳化MPP吞吐量，資料集可能會均勻地分散在各個節點上，以確保最大數量的叢集節點參與平行查詢處理。為了加速分散式MPP連線，大多數常見的連線資料集會根據共同的連線鍵分散在叢集節點上，以便被連線的表格片段最終落在相同的計算節點上。

欄位導向資料儲存與高效資料壓縮

除了提供大規模儲存和叢集運算之外，現代資料倉儲還透過欄位導向儲存和資料壓縮來提升查詢效能。在本文中，我們將探討這是如何工作的，但首先，讓我們瞭解傳統的線上交易處理（Online Transaction Processing, OLTP）資料函式庫如何儲存其資料。

OLTP應用程式通常處理包含表格所有欄位的整個列（例如，讀取/寫入銷售記錄或查詢目錄記錄）。為了服務OLTP應用程式，後端資料函式庫需要高效地讀取和寫入完整的列到磁碟上。為了加速完整列的查詢和更新，OLTP資料函式庫使用列導向佈局將表格列儲存在磁碟上。在列導向實體資料佈局中，給定列的所有欄位值都被放在一起，如下圖所示：

程式碼範例：欄位導向儲存範例

-- 建立一個範例表格
CREATE TABLE sales (
    id INT,
    product_id INT,
    sale_date DATE,
    amount DECIMAL(10, 2)
);

-- 插入一些範例資料
INSERT INTO sales (id, product_id, sale_date, amount)
VALUES (1, 101, '2023-01-01', 100.00),
       (2, 102, '2023-01-02', 200.00),
       (3, 103, '2023-01-03', 300.00);

-- 查詢特定日期的銷售金額總和
SELECT SUM(amount) FROM sales WHERE sale_date = '2023-01-01';

內容解密：

表格建立：CREATE TABLE sales 陳述式定義了一個名為 sales 的表格，包含 id、product_id、sale_date 和 amount 四個欄位。
資料插入：INSERT INTO sales 陳述式向 sales 表格中插入了三條銷售記錄。
查詢操作：SELECT SUM(amount) FROM sales WHERE sale_date = '2023-01-01' 陳述式計算了特定日期（‘2023-01-01’）的銷售金額總和。
欄位導向儲存優勢：在欄位導向儲存中，像 sale_date 和 amount 這樣的欄位是分開儲存的，這使得對特定欄位的查詢（如上述查詢中的 sale_date 和 amount）更加高效，因為只需要讀取相關欄位的資料，而不是整個列。

資料倉儲與資料市集的理解 - 真實資料的源泉

大多數商業使用者針對資料倉儲執行的分析查詢都是為了回答特定的問題，通常涉及對事實表和維度表中有限欄位元組的彙總運算（如總和、平均值、均值等）。這些查詢需要掃描大量資料列，但只需要查詢中關心的有限欄位元。導向列的物理資料佈局更適合分析查詢處理，每個查詢僅需要部分欄位元。

資料儲存佈局的演變

行導向儲存佈局

圖 2.3 – 行導向儲存佈局

在行導向的資料函式庫中，分析查詢需要掃描大量的完整資料列，即使它們只需要這些列中的一小部分欄位元。這導致了不必要的磁碟I/O操作。

列導向儲存佈局

現代資料倉儲使用列導向的物理資料佈局，將一張表的資料分成多個列區塊（row chunks/groups），然後將每個列區塊的資料按照欄位元依次排列，使得同一個欄位元的所有值在物理上連續儲存於磁碟上。

圖 2.4 – 列導向儲存佈局

這種儲存方式使得查詢引擎能夠僅檢索特定查詢所需的欄位元，大大減少了磁碟I/O操作。此外，大多數現代資料倉儲在將資料儲存到磁碟之前會對其進行壓縮。由於列導向儲存使得相同資料型別的欄位元值連續儲存，因此能夠獲得更好的壓縮比率，從而進一步減少磁碟I/O並節省儲存空間。

資料倉儲中的維度建模

資料倉儲中的資料資產通常以關聯式表格的形式儲存，並組織成廣泛使用的維度模型，如星型架構或雪花型架構。這種儲存方式使得檢索和過濾相關資料變得更加容易，同時也使分析查詢處理更加靈活、簡單和高效。

星型架構

圖 2.5 – 銷售資料實體以星型架構組織

在星型架構中，事實表位於中心，儲存了業務主題領域的粒度數值測量/指標（如價格或數量）。周圍的維度表儲存了捕捉事實測量時的上下文資訊。每個維度表本質上提供了上下文實體的屬性，如誰（員工、客戶）、什麼（產品）、在哪裡（商店、城市、州）和何時（銷售日期/時間、季度、年份、工作日）。

商業分析師通常透過不同的維度視角對事實進行切片、切塊和彙總，以產生有關星型架構所代表的業務主題領域的洞察。

雪花型架構

圖 2.6 – 銷售資料實體以雪花型架構組織

雪花型架構透過將每個維度表規範化為多個相關的維度表來解決星型架構中可能出現的資料不一致性和重複問題。這種高度規範化的模型被稱為雪花型架構。

-- 建立事實表
CREATE TABLE Sales (
    SaleID INT PRIMARY KEY,
    ProductID INT,
    CustomerID INT,
    SaleDate DATE,
    Quantity INT,
    Price DECIMAL(10, 2),
    FOREIGN KEY (ProductID) REFERENCES Product(ProductID),
    FOREIGN KEY (CustomerID) REFERENCES Customer(CustomerID)
);

-- 建立維度表
CREATE TABLE Product (
    ProductID INT PRIMARY KEY,
    ProductName VARCHAR(255),
    ProductCategory VARCHAR(255)
);

CREATE TABLE Customer (
    CustomerID INT PRIMARY KEY,
    CustomerName VARCHAR(255),
    City VARCHAR(255),
    State VARCHAR(255)
);

內容解密：

建立事實表：Sales 表儲存了銷售事實的粒度測量，包括銷售ID、產品ID、客戶ID、銷售日期、數量和價格。外部索引鍵約束確保了與維度表的參照完整性。
建立維度表：Product 和 Customer 表分別儲存了產品和客戶的上下文資訊。這些表的設計使得查詢可以根據產品或客戶的不同屬性進行過濾和彙總。
外部索引鍵約束：在 Sales 表中使用外部索引鍵約束來參照 Product 和 Customer 表的主鍵，確保了資料的一致性和參照完整性。

透過這種維度建模方式，資料倉儲能夠支援複雜的分析查詢，並提供快速、靈活的資料檢索能力。星型和雪花型架構根據不同的業務需求和資料特性，提供瞭解決方案以最佳化查詢效能和資料管理。

資料倉儲與資料市集的真實來源

在企業資料倉儲架構中，資料倉儲（Data Warehouse）與資料市集（Data Mart）扮演著至關重要的角色。資料倉儲是一個集中儲存企業所有相關業務領域資料的倉函式庫，具有全面但複雜的結構設計。資料倉儲旨在支援跨領域的分析，以指導戰略性的業務決策。然而，許多組織內部也存在著一些使用者，他們只關心特定的業務線、部門或主題領域。這些使用者傾向於使用結構簡單、僅包含他們感興趣的資料子集的儲存函式庫。因此，組織通常會建立資料市集來滿足這些使用者的需求。

資料市集的角色

資料市集專注於單一業務主題領域（例如行銷、銷售或財務），通常為服務特定部門或業務功能而建立。與企業資料倉儲相比，資料市集往往具有一組反規範化的事實表（denormalized fact tables），結構更加簡單。由於結構簡單、資料量較少，資料市集的建立速度更快，使用者更容易理解和使用。資料市集可以透過以下兩種方式建立：

自上而下（Top-down）：從現有的資料倉儲中提取相關的業務主題資料。
自下而上（Bottom-up）：直接從與特定業務領域相關的執行業務應用程式中取得資料。

資料倉儲與資料市集的比較

無論是資料倉儲還是資料市集，都提供了來自多個來源的整合資料檢視，但它們在儲存資料的範圍上有所不同。資料倉儲為整個企業提供了一個中央資料儲存，涵蓋了所有業務領域。資料市集則服務於特定的部門或業務功能，提供與該業務功能相關的主題領域的整合檢視。

將資料饋送到倉儲 - ETL 與 ELT 管道

要將資料匯入倉儲（以及可選的資料市集），組織通常會建立資料管道（data pipelines），這些管道負責以下任務：

從來源系統中提取資料。
透過驗證、清理、標準化和整理源資料來轉換它。
將轉換後的源資料載入到企業資料倉儲結構中，以及可選的資料市集。

在這些管道中，第一步是從來源系統中提取資料，但後續兩步可以採用轉換-載入（Transform-Load）或載入-轉換（Load-Transform）的順序。

現代組織的資料倉儲通常需要從多樣化的來源中取得資料，例如ERP和CRM應用程式資料函式庫、儲存在網路附加儲存（NAS）陣列上的檔案、SaaS應用程式以及外部合作夥伴應用程式。用於實作ETL和ELT管道中的提取步驟的元件通常需要連線到這些來源，並處理多樣化的資料格式（包括關聯式表格、平面檔案和連續的記錄流）。

決定是建立ETL（Extract-Transform-Load）還是ELT（Extract-Load-Transform）資料管道取決於以下因素：

所需的資料轉換的複雜性。
源資料需要在被產生後多快地在資料倉儲中可用於分析。

ETL 管道

ETL管道首先從各種來源提取資料，並將其儲存在暫存區域（staging area，一個位於倉儲外的系統）。然後，在暫存資料上執行轉換操作，以驗證、清理、標準化、結構化並將其轉換為適合載入到資料倉儲（以及可選的資料市集）的形式。然後，將暫存區域中的轉換後的資料載入到倉儲的維度結構中。當以下條件成立時，通常會使用ETL方法建立資料管道：

來源資料函式庫技術和格式與資料倉儲不同。
資料量較小到中等。
資料轉換複雜且需要大量計算資源。

ETL 管道範例程式碼

-- 從來源系統提取資料
CREATE TABLE Staging_Data AS
SELECT *
FROM Source_System_Data;

-- 在暫存區域進行轉換操作
CREATE TABLE Transformed_Data AS
SELECT 
    column1,
    CASE 
        WHEN column2 > 0 THEN 'Positive'
        ELSE 'Negative'
    END AS column2_transformed,
    column3
FROM Staging_Data;

-- 將轉換後的資料載入到資料倉儲
INSERT INTO Data_Warehouse_Table
SELECT *
FROM Transformed_Data;

內容解密：

提取階段：首先，我們從來源系統提取所需的資料，並將其儲存在一個名為Staging_Data的暫存表格中。
轉換階段：接著，我們對Staging_Data中的資料進行必要的轉換。在這個例子中，我們使用了一個CASE陳述式來根據column2的值建立一個新的欄位column2_transformed。這種轉換邏輯可以根據實際需求進行擴充套件和修改，以滿足特定的業務規則或資料品質要求。
載入階段：最後，我們將轉換後的資料從Transformed_Data表格載入到最終的Data_Warehouse_Table中，完成整個ETL流程。

ELT 管道

另一方面，ELT管道從各種來源提取資料（通常是高度結構化的資料），並將其以原始形式（匹配來源系統的資料結構）載入到資料倉儲內的暫存區域。然後，使用支援資料倉儲的資料函式庫引擎對暫存資料執行轉換操作，使其準備好被使用。

ELT 管道範例程式碼

-- 從來源系統提取並載入資料到暫存表格
CREATE TABLE Staging_Table AS
SELECT *
FROM Source_System_Data;

-- 在資料倉儲內進行轉換操作
CREATE TABLE Transformed_Table AS
SELECT 
    column1,
    column2,
    CASE 
        WHEN column3 > 100 THEN 'High'
        ELSE 'Low'
    END AS column3_category
FROM Staging_Table;

-- 將最終結果儲存到目標表格
INSERT INTO Target_Table
SELECT *
FROM Transformed_Table;

內容解密：

提取和載入階段：首先，我們直接從來源系統提取資料，並將其載入到資料倉儲內的Staging_Table中，保持原始的資料結構。
轉換階段：接著，利用資料倉儲強大的處理能力，我們對Staging_Table中的資料進行轉換。這裡，我們建立了一個新的欄位column3_category，根據column3的值進行分類別。同樣，這個階段可以根據需求加入更複雜的轉換邏輯。
結果儲存階段：最後，將轉換後的結果儲存到Target_Table中，供後續分析和報告使用。

玄貓 BlackCat

技術愛好者，專注於分享程式開發、雲端技術與 AI 應用的心得體會。