一文讀懂資料平臺建設的演進歷程

來源：資料驅動智慧

什麼應該作為我們資料平臺建設的指標？雖然在某些情況下，處理的資料量可能是一個有效的指標，但它可能並不全面。例如，處理數TB的資料並不一定意味著機器學習的整合。讓我們探討資料平臺評估的潛在階段，以得出有意義的結論，並確定過渡到更高開發水平所需的標準。

級別 0

在資料平臺演進的初始階段，我認為是 0 級，透過直接訪問交易系統並從中查詢資料來生成報告。Excel、Power BI、帆軟報表或類似應用程式等工具用於以表格或圖表的形式收集和呈現資料。雖然這種方法能夠快速訪問資料，但它存在與資料結構、源效能和延遲變化相關的問題。報告過程往往很慢，特別是當需要手動資料操作來提取必要的資訊時。

級別 1

在此階段，報表和應用程式都在努力解決與每天使用事務系統中資料的大量分析查詢相關的效能問題。作為處理方法，IT 部門決定是時候遷移到另一個環境了。

要解決效能挑戰，有多種選擇。可以投資購買新伺服器、建立虛擬機器 （VM） 或利用 Azure、AWS 或 GCP 等雲提供商提供的服務。是選擇具有手動安裝的資料庫引擎的 VM，還是選擇與資料庫引擎捆綁在一起的無伺服器服務，取決於特定要求。

此階段的主要目標是從事務資料庫中提取資料，並將其儲存在單獨的資料庫或檔案中。這種提取有助於緩解與繁重的分析查詢相關的問題，否則這些問題可能會阻礙關鍵系統，例如財務管理系統、CRM 或事務系統本身。

資料提取可以以原始形式執行，也可以透過資料複製過程執行。IT 部門在促進資料傳輸到指定計算機方面發揮著至關重要的作用。時機是關鍵;資料提取通常在事務系統中活動較少的時期進行。資料位於計算機上後，可以在 Excel 或 Power BI 等工具中重新整理預定義的報表。

級別 2

在第 2 級，組織正在與不一致的資料和資料質量問題作鬥爭，而分析團隊難以滿足對臨時報告的高需求加劇了這些問題。由於需要詳細的業務知識來分析原始應用程式資料，並且歷史資料可能無法一致地儲存，因此在組織內共享收集的資料具有挑戰性。

為了應對這些挑戰，組織決定透過建立資料倉儲向前邁出重要一步。資料倉儲的主要目標是為資料分析建立統一和整合的源，確保具有相同名稱的度量值傳達一致的含義。資料倉儲的內容被設計為易於理解，訪問的特點是效能快。該設計具有適應性和靈活性，可在不中斷現有資料的情況下適應新資料來源的新增。

資料倉儲是決策的基礎，確保它包含正確的資料來支援明智的選擇。這種轉換需要升級環境，並考慮在公有云或本地伺服器之間進行選擇以及選擇適當的資料倉儲引擎。公有云的熱門選項包括 AWS Redshift、BigQuery、Databricks、Microsoft Synapse 和 Snowflake。本地選擇可能包括 Microsoft SQL Server、Oracle 和 PostgreSQL。引擎的選擇取決於資料量、資料團隊的專業知識和特定用例等因素。

除了選擇資料倉儲引擎之外，選擇資料建模方法（例如 Kimball、Inmon 或 Data Vault）也至關重要。完善的資料模型對於適應新的資料來源、進行資料分析和利用商業智慧工具至關重要。另一個關鍵方面是工具的選擇和 ELT/ETL 流程的開發，以整合資料來源、清理和豐富資料、填充資料模型以及提高資料質量。可以使用 Python 或 Scala 等程式語言，並且有現成的工具，例如 SSIS、Informatica、Talend、Nifi、Fivetran、Matillion 等。

這些步驟可以集中對資料進行操作，從而在資料倉儲中建立“單一事實位置”。資料倉儲到位後，可以開始與高階使用者共享資料，從而促進更可靠的報表和儀表板的開發。

但是，當使用新的資料平臺時，將遇到與資料治理相關的新挑戰。可能會出現一些問題，例如在哪裡查詢用於特定報告目的的資料、誰可以訪問敏感資料以及如何遮蔽敏感資料、如何管理授權以及如何整合來自 ERP、CRM 和外部來源等系統的資料。

解決方案的成熟度將需要實施資料管理工具，包括資料目錄、主資料管理、資料分類和資料沿襲。

• 資料目錄：包含後設資料的儲存庫，其中包含用於資料管理和搜尋功能的工具，可幫助分析師和其他資料使用者查詢特定資料。

• 主資料管理 （MDM）：旨在從內部和外部資料來源為客戶、商品和業務實體建立主記錄，確保一致性和可靠性。

• 資料分類：根據敏感度將資料分組，例如 PII、PHI 資料和財務資料，定義重要性級別。

• 資料沿襲：說明透過 ETL 過程從源的資料流，有助於錯誤調查、增強理解和支援資料分類。

級別 3

在處理大量資料、實時資料和各種來源的組織中，傳統的資料倉儲可能不足以用於分析目的。資料倉儲通常需要耗時的資料建模、架構定義（寫入時架構）和結構化資料。此外，龐大的資料量可能成為某些資料倉儲引擎的限制因素。這帶來了挑戰，尤其是當市場要求迅速採取行動以保持領先於競爭對手時。

幸運的是，資料湖的引入解決了這些挑戰。資料湖可以以低成本高效儲存大量資料，包括非結構化資料。與傳統的資料倉儲不同，資料湖採用讀取時模式方法，允許在沒有預定義模式定義的情況下儲存資料。為了處理這些資料，通常使用 Apache Spark，在計算叢集上處理大規模資料處理。

雖然現代資料湖可能仍需要資料清理和檔案格式統一，但這些任務通常比與完整 ETL（提取、轉換、載入）過程相關的活動勞動密集型要少。這種靈活性支援快速加入和分析新資料來源。

在此設定中，資料工程團隊負責引入、清理和擴充資料湖中的資料。隨後，資料科學團隊可以分析這些資料以提取重要的業務資訊，從而幫助做出明智的決策或推出新產品。資料湖的另一個顯著特點是它在組織內的集中化，促進了資料孤島的打破，促進了資料民主化，並減少了大型組織中資料解決方案的重複。

在這個不斷髮展的資料平臺中，需要注意的是，資料湖不會取代資料倉儲;相反，兩者可以共存，在雙層體系結構中相互補充。資料湖擅長透過讀取模式方法儲存大量多樣化的非結構化資料，從而促進新資料來源的快速載入和分析。同時，資料倉儲對於儲存聚合和建模資料仍然至關重要。這些來自資料倉儲的結構化資料可以與商業智慧工具無縫整合，為分析目的提供全面的解決方案。資料湖和資料倉儲之間的共生關係增強了組織處理各種資料型別的能力，並滿足實時和結構化分析需求。

雙層架構的另一種方法是湖倉一體，其中資料模型直接在資料湖上構建，而無需為資料倉儲提供額外的引擎。

這種高階體系結構的一個組成部分是合併流分析，這需要採用 Apache Kafka 等新工具或 Azure 事件中心、Azure 流分析、GCP 資料流、Pub/Sub 和 Amazon Kinesis 等公有云原生解決方案。流分析提供了資料和流程的實時視角，使組織能夠實時監控活動並快速響應，與傳統的批處理系統相比，傳統的批處理系統每天“重新整理”一次或幾次資料。

透過實現流式處理，可以建立從事務系統實時傳輸更改的流程。例如，在一家金融公司中，這可以在幾秒鐘內對可疑交易做出快速響應。這種過程有助於建立“變更資料捕獲”（CDC）過程，從事務系統資料庫流式傳輸更改。

另一種途徑是利用物聯網 （IoT） 流程，可用於從各種環境（例如工廠）中的感測器收集資訊。這種方法可以檢測意外事件，如裝置故障和環境變化，如溫度波動或管道洩漏。

級別 4

在資料平臺演進的第 4 級，我們利用最先進的技術，突出特點是使用資料湖或湖倉一體以現代格式儲存大量資料集，如 Delta Lake、Iceberg、Apache Hudi 或 Parquet。這些格式使資料工程師能夠以高度壓縮的列格式儲存資料，支援分析查詢、事務和各種合併/更新/刪除操作（不包括 Parquet）。這些格式的採用代表了資料儲存效率的重大進步。

此外，我們的平臺擅長透過流媒體技術分析來自不同來源的實時資料饋送。在報告中提供實時見解的同時，我們還開始利用機器學習 （ML） 模型的強大功能。這些模型在檢測異常、預測裝置故障、識別欺詐活動、預測銷售趨勢和對客戶進行分類方面發揮著至關重要的作用。

在這個高階水平上，決策不僅僅是依靠當前的數字;我們整合了從機器學習模型得出的預測。這種變革性的方法不僅使我們能夠應對當前的情況，而且能夠根據預測分析主動進行規劃。

機器學習模型

機器學習模型有多種型別，每種型別都是為特定任務而設計的：

• 分類：用於模式識別，它可以標記客戶端型別、影像和文件類別等實體。

• 迴歸：研究自變數（特徵）和因變數（結果）之間的關係，通常用於固定價格預測、銷售預測和類似應用。

• 聚類：將相似的資料點分組到叢集或未標記的組中，有利於異常檢測和市場細分等任務。

• 時間序列：基於時序資料預測未來數值，適用於預測銷售、需求、呼叫、Web流量等場景。

若要部署機器學習過程，通常涉及以下步驟：

1. 定義用例：與業務使用者協作，確定模型應預測或識別的內容。

2. 獲取資料：確定資料來源並將資料引入資料湖或湖倉一體。

3. 準備資料： 瀏覽和清理資料，根據模型的要求對其進行轉換。

4. 訓練模型：選擇演算法和超引數，然後評估結果。

5. 部署模型：利用經過訓練的模型生成請求的結果。

可以使用開源庫和本地或公有云基礎架構來訓練模型。例如，在 Python 中，可以使用 Pandas、Scikit-Learn、PyTorch 和 TensorFlow 等工具。Azure 機器學習、BigQuery ML、Vertex AI、Amazon SageMaker 和 Redshift ML 等公有云服務也是有價值的選擇。此外，機器學習模型可以 docker 化並託管在公有云中。若要編排 ML 流程，可以使用 Azure 資料工廠、Airflow、Prefect、GCP 工作流和 AWS Step Functions 等工具。

AI 服務和生成式 AI

利用公有云服務可以訪問現成的 AI 服務，這些服務具有具有可定製 API 的預訓練模型。這些服務的示例涵蓋各個領域，包括用於對話、搜尋、監控、翻譯、語音和視覺的自然語言處理。利用這些服務，企業能夠開發尖端產品，實現各種流程的自動化和增強。例如，語音到文字的轉換可用於分析客戶問題，視覺服務可用於分析影像。

傳統的 AI 解決方案專注於理解和推薦資訊，而新一代生成式 AI 則更進一步，能夠建立全新的內容。生成式 AI 建立在大型語言模型 （LLM） 等技術之上，這些技術基於大量文字資料進行訓練，不僅可以生成文字，還可以生成影像、影片和音訊。截至撰寫本文時，著名的生成式 AI 模型包括 Chat GPT、OpenAI、Gemini、Bard 和 Duet AI。這些服務可以用作內建幫助或整合到應用程式中。在內建幫助的上下文中，它們可以增強各種任務，例如支援在 BigQuery 中編寫查詢、在 Visual Studio Code 中幫助建立程式碼或改進營銷材料。

級別 5

雖然我們可能還沒有達到第 5 級，但人工智慧領域的持續創新，尤其是生成式人工智慧，將影響資料平臺的發展。隨著進展的持續，我預見到一種情況，即很大一部分任務和分析將毫不費力地參與人工智慧。使用者可能會提出有關各類資料的問題，獲得及時和有見地的答案。這種演變有望大大改善組織內部對資訊的訪問。唯一的問題是：我們可以在多大程度上突破人工智慧利用的界限，相關成本是多少？人工智慧能力和成本效益的交集可能會定義這一變革之旅的邊界。

資料網格和資料編織

在分析平臺的不斷髮展中，考慮新興的架構趨勢至關重要，特別要注意資料網格和資料編織等概念。Zhamak Dehghani 於 2019 年推出的 Data Mesh 提出了一種去中心化的資料平臺模型，其中面向領域的團隊負責交付、維護和確保各自資料產品的質量。這個想法是促進領域團隊之間的協作，提高開發速度，讓團隊專注於他們的專業領域。雖然一些出版物認為資料網格代表了新一代的資料平臺，但必須承認其去中心化的性質可能更適合擁有多個資料團隊的大型組織。相比之下，在單個資料團隊處理所有報告需求的中型或小型組織中，它可能不那麼有效。

另一方面，Fabric 強調與資料平臺相關的活動的集中化，包括資料攝取、ETL、報告和資料治理。這種集中式方法旨在解決與資料孤島相關的挑戰，促進資料共享並加強協作。但是，必須注意的是，集中式模型可能會在交付中引入瓶頸，尤其是在組織經歷快速增長時。

對於考慮這兩個概念的組織來說，仔細評估每個概念的利弊至關重要。選擇最符合組織特定需求和挑戰的方法非常重要，而不是盲目追隨最新趨勢。

小結

資料平臺的開發涉及各種指標的組合，包括架構方法、資料治理、可擴充套件性、實時資料處理、大資料處理、高階分析等。我們在資料平臺開發的不同階段的旅程表明，從簡單的解決方案開始，逐步新增新元件或高階分析（如 ML 和 AI）使我們能夠適應和滿足不斷變化的業務需求。

在資料平臺開發領域，透過資料和技術的利用來實現測量。如果僅依賴一個事務系統進行查詢，則正處於此旅程的初始階段。但是，整合 ML 和 AI 會讓處於領先地位，使能夠滿足更復雜的業務需求並超越競爭對手。當然，可能性程度與組織的規模和發展密切相關。邁向更高層次不僅涉及技術的實施，還涉及在公司內部培養“資料素養”。