利用 AWS 的事件驅動資料網格架構應對現代資料挑戰

背景

在當今資料驅動的世界中，企業必須適應資料管理、分析和利用方式的快速變化。傳統的集中式系統和單片式架構雖然在歷史上已經足夠，但已無法滿足企業日益增長的需求，因為企業需要更快地實時獲取資料見解。事件驅動資料網格架構是這一領域的革命性框架，與 AWS 服務結合後，它將成為應對複雜資料管理挑戰的強大解決方案。

資料困境

許多組織在依賴過時的資料架構時都面臨著巨大的挑戰。這些挑戰包括

集中式、單片式和領域無關的資料湖
集中式資料湖是所有資料的單一儲存位置，易於管理和訪問，但如果擴充套件不當，可能會導致效能問題。單體資料湖將所有資料處理流程整合到一個整合系統中，簡化了設定，但可能難以擴充套件和維護。與領域無關的資料湖旨在儲存來自任何行業或來源的資料，具有靈活性和廣泛的適用性，但管理起來可能比較複雜，對特定用途的最佳化程度也較低。

傳統架構故障壓力點

在傳統資料系統中，可能會出現一些問題。資料生產者可能會傳送大量資料或有錯誤的資料，從而給下游帶來問題。隨著資料複雜性的增加和系統中資料來源的多樣化，集中式資料平臺可能難以應對不斷增長的負載，導致系統崩潰和效能緩慢。快速實驗需求的增加可能會使系統不堪重負，難以快速適應和測試新想法。資料響應時間可能會成為一個挑戰，導致訪問和使用資料的延遲，從而影響決策和整體效率。

業務資料與分析資料之間的差異
在軟體架構中，孤島式所有權、不明確的資料使用、緊密耦合的資料管道以及固有的侷限性等問題都可能導致重大問題。當不同團隊各自為政時，就會出現各自為政的情況，從而導致協調問題和效率低下。對如何使用或共享資料缺乏清晰的認識，會導致工作重複和結果不一致。耦合的資料管道，即元件之間過於依賴，會使系統難以調整或擴充套件，從而導致延誤。最後，系統固有的侷限性會減緩新功能和更新的交付，阻礙整體進展。解決這些壓力點對於提高開發流程的效率和響應速度至關重要。

大資料帶來的挑戰

線上分析處理 (OLAP) 系統組織資料的方式使分析人員更容易探索資料的不同方面。為了回答查詢，這些系統必須將運算元據轉換為適合分析和處理大量資料的格式。傳統的資料倉儲使用 ETL（提取、轉換、載入）流程來管理這些資料。Apache Hadoop 等大資料技術透過解決擴充套件問題和開放原始碼改進了資料倉儲，只要能夠管理基礎設施，任何公司都可以使用。Hadoop 引入了一種新方法，允許使用非結構化或半結構化資料，而不是預先執行嚴格的模式。這種靈活性使資料工程師更容易處理和整合資料，因為資料可以在沒有預定義模式的情況下寫入，並在以後的查詢過程中進行結構化。採用 Hadoop 通常意味著組建一個獨立的資料團隊：資料工程師負責資料提取，資料科學家負責資料清理和重組，資料分析師負責資料分析。由於資料團隊與應用開發人員之間的溝通有限，這種設定有時會導致問題，通常是為了防止影響生產系統。

問題 1：資料模型邊界問題
用於分析的資料與其原始結構密切相關，這對於複雜且經常更新的模型來說是個問題。資料模型的更改會影響所有使用者，使他們容易受到這些更改的影響，尤其是當模型涉及許多表時。

問題 2：不良資料，忽視問題的代價
錯誤資料通常不會被注意到，直到它在模式中產生問題，導致錯誤資料型別等問題。由於驗證通常會推遲到流程的最後階段，因此不良資料會在管道中傳播，導致昂貴的修復費用和不一致的解決方案。不良資料會導致重大業務損失，例如造成數百萬美元損失的計費錯誤。研究表明，不良資料每年會給企業造成數萬億的損失，浪費知識工作者和資料科學家的大量時間。

問題 3：缺乏單一所有權
應用程式開發人員是源資料模型方面的專家，但他們通常不會將這些資訊傳達給其他團隊。他們的責任往往止於應用程式和資料庫邊界。資料工程師負責管理資料提取和移動，但他們通常是被動工作，對資料來源的控制有限。資料分析師與開發人員相距甚遠，他們在接收資料時面臨挑戰，從而導致協調問題，並需要單獨的解決方案。

問題 4：自定義資料連線
在大型企業中，多個團隊可能使用相同的資料，但卻建立各自的流程來管理這些資料。這就會產生多個資料副本，每個副本都獨立管理，造成混亂。由於同步問題和資料來源不安全等因素，跟蹤 ETL 作業和確保資料質量變得十分困難，從而導致資料不準確。這種分散的方法浪費時間、金錢和機會。

Data Mesh資料網格

可以解決這些問題，它將資料視為一種產品，具有清晰的模式、文件和標準化訪問，從而降低了不良資料風險，提高了資料準確性和效率。Data Mesh 是一種分散式資料架構，旨在解決傳統集中式資料架構面臨的挑戰。它將資料視為一個產品，由不同的團隊負責特定領域的資料治理和管理。

Data Mesh現代方法

資料網格重新定義了資料管理，它將所有權下放，並將資料視為一種產品，由自助式基礎設施提供支援。這種轉變使團隊能夠完全控制其資料，同時聯合治理確保了整個組織的質量、合規性和可擴充套件性。簡單地說，它是一種架構框架，旨在透過使用分散所有權和分散式方法來解決複雜的資料難題。它用於整合來自不同業務領域的資料，以進行全面的資料分析。它還建立在強大的資料共享和治理政策之上。

Data Mesh的目標

資料網格可幫助各種組織大規模地深入瞭解資料，簡而言之，就是處理不斷變化的資料環境、日益增多的資料來源和使用者、所需的各種資料轉換，以及快速適應變化的需求。

資料網格透過分散控制解決了上述所有問題，因此團隊可以管理自己的資料，而無需將資料隔離在不同的部門。這種方法透過分散資料處理和儲存來提高可擴充套件性，有助於避免單一中央系統的執行速度減慢。它允許團隊直接處理自己的資料，減少了因等待中央團隊而造成的延誤，從而加快了洞察力的提高。每個團隊對自己的資料負責，從而提高質量和一致性。透過使用易於理解的資料產品和自助服務工具，資料網格可確保所有團隊都能快速訪問和管理自己的資料，從而提高運營速度和效率，更好地滿足業務需求。

核心原則

• 領域導向：將資料管理責任分配給領域團隊，促進對資料的深入理解和責任感。
• 自服務平臺：提供工具和平臺，支援團隊獨立處理資料，而無需依賴中央資料團隊。
• 資料作為產品：將資料作為產品對待，採用標準化的訪問、版本和模式定義，每個領域團隊將其資料視為產品，關注資料質量、可發現性和易用性。
• 跨域互操作性：確保不同領域的資料能夠有效互動和整合，促進整體資料生態的協同工作。
• 分散的資料所有權： 團隊擁有並管理自己的資料產品，對其質量和可用性負責。
• 聯合治理： 制定政策以維護資料完整性、安全性和合規性，同時仍允許分散所有權。
  

場景應用

• 大規模組織：在大型企業中，各個部門可能會產生大量資料，Data Mesh 允許不同團隊獨立管理資料，避免了傳統架構中的瓶頸。
• 敏捷開發：支援敏捷開發模式，領域團隊可以快速迭代，提供高質量資料產品，滿足快速變化的業務需求。
• 多樣化資料來源：隨著資料來源的多樣化，Data Mesh 提供靈活性，讓團隊能夠根據特定需求選擇和管理資料來源。

實際案例

• 金融行業：某金融機構實施 Data Mesh，將信貸、風險管理、客戶資料等領域的團隊賦權，使他們能夠獨立管理和使用資料，從而提高了決策的速度和準確性。
• 電商平臺：一個大型電商平臺透過 Data Mesh 實現了各個產品線的資料獨立管理，促進了個性化推薦系統的最佳化，提升了使用者體驗。

Data Mesh 透過分散資料管理，提高了資料治理的靈活性和響應速度，適用於需要快速適應變化和處理複雜資料環境的組織。透過將資料視為產品，Data Mesh 鼓勵團隊主動管理資料，提升資料的價值和可用性。

Data Mesh 和 Data Lake 是兩種不同的資料管理理念和架構

架構設計

• Data Mesh：強調分散化和領域導向的資料管理。資料被視為產品，由各個業務領域團隊負責管理和維護。每個團隊獨立處理其領域的資料，促進快速響應和創新。

• Data Lake：通常是一個集中式的儲存系統，用於儲存各種格式的原始資料（結構化、半結構化和非結構化資料）。資料湖的設計目的是將所有資料集中儲存，以便於後續分析和挖掘。

資料治理

• Data Mesh：鼓勵領域團隊對其資料負責，強調自服務和透明性。每個團隊負責確保其資料的質量、可用性和安全性，同時提供清晰的文件和介面，便於其他團隊使用。

• Data Lake：通常由中央資料團隊負責資料治理。資料湖中的資料治理可能會較為複雜，尤其是在資料整合和資料質量管理方面，容易出現“資料孤島”現象。

資料處理和訪問

• Data Mesh：支援靈活的資料訪問方式，團隊可以根據業務需求快速釋出和更新資料產品，促進跨團隊協作和資料共享。

• Data Lake：資料處理通常是批處理或流處理的結合，使用者需要一定的技術能力來提取和分析資料，可能需要依賴資料科學家或工程師進行資料準備和分析。

適用場景

• Data Mesh：適合大型、複雜的組織，尤其是在不同業務部門有獨立資料需求和創新能力時。它能夠支援快速變化的業務需求和靈活的團隊結構。

• Data Lake：適合需要集中儲存大量資料的組織，特別是在資料分析和機器學習等應用場景中。它可以作為資料分析和挖掘的基礎。

Databricks 的Data Mesh架構

ConfluentCloud事件資料流

事件如何幫助Data Mesh？

事件允許系統的不同部分實時共享和更新資料，從而幫助實現資料網格。當某一區域發生變化時，事件會通知其他區域，因此每個人都能及時瞭解最新情況，而無需直接連線。這使得系統更加靈活和可擴充套件，因為它可以處理大量資料並輕鬆適應變化。事件還能讓我們更輕鬆地跟蹤資料的使用和管理情況，讓每個團隊都能處理自己的資料，而無需依賴他人。

最後，讓我們來看看事件驅動的Data Mesh架構：

國內基於Kafka案例

透過這種事件驅動方法，我們可以將資料生產者與消費者分離開來，從而使系統隨著領域的不斷髮展更具可擴充套件性，而無需對架構進行重大改動。生產者負責生成事件，然後將事件傳送到在途資料系統。流平臺可確保這些事件的可靠交付。當生產者微服務或資料儲存釋出一個新事件時，它會被儲存到一個特定的主題中。這會觸發消費者端的監聽器（如 Lambda 函式或 Kinesis）來處理事件並根據需要使用它。

利用 AWS 實現事件驅動資料網格架構
AWS 提供的一整套服務完美地補充了事件驅動資料網格模型，使企業能夠擴充套件其資料基礎架構，確保實時資料交付，並保持高水平的治理和安全性。

以下是各種 AWS 服務如何融入此架構：

用於實時事件流的 AWS Kinesis
在事件驅動的資料網格中，實時流是一個關鍵因素。AWS Kinesis 提供了大規模收集、處理和分析實時流資料的能力。

Kinesis 提供多個元件：

Kinesis 資料流： 接收實時事件並與多個消費者併發處理這些事件。
Kinesis Data Firehose： 將事件流直接傳送到 S3、Redshift 或 ElasticSearch，以便進一步處理和分析。
Kinesis 資料分析： 實時處理資料，即時獲得洞察力，實現資料處理管道中的即時反饋迴路。

用於事件處理的 AWS Lambda
AWS Lambda 是資料網格架構中無伺服器事件處理的支柱。它能夠自動擴充套件和處理傳入的資料流，無需伺服器管理、

Lambda 是以下方面的理想選擇：

實時處理 Kinesis 資料流
針對特定事件呼叫 API 閘道器請求
與 DynamoDB、S3 或其他 AWS 服務互動，以儲存、處理或分析資料

用於事件分發的 AWS SNS 和 SQS
AWS Simple Notification Service (SNS) 是主要的事件廣播系統，可在分散式系統間傳送實時通知。AWS Simple Queue Service (SQS) 可確保解耦服務之間的訊息得到可靠傳遞，即使在部分系統故障的情況下也是如此。這些服務允許解耦的微服務在沒有直接依賴關係的情況下進行互動，確保系統保持可擴充套件性和容錯性。

用於實時資料管理的 AWS DynamoDB
在分散式架構中，DynamoDB 提供了一個可擴充套件、低延遲的 NoSQL 資料庫，可實時儲存事件資料，是儲存資料處理管道結果的理想選擇。它支援 “發件箱 ”模式，即應用程式生成的事件儲存在
儲存在 DynamoDB 中，然後由流服務（如 Kinesis 或 Kafka）消費。

聯合資料目錄和 ETL 的 AWS Glue
AWS Glue 提供全面管理的資料目錄和 ETL 服務，對於資料網格中的聯合資料治理至關重要。Glue 可幫助對分散式域中的資料進行編目、準備和轉換，確保整個組織的可發現性、治理和整合。

用於資料湖的 AWS Lake Formation 和 S3
在資料網格架構脫離集中式資料湖的同時，S3 和 AWS Lake Formation 在儲存、保護和編目各個域之間流動的資料、確保長期儲存、治理和合規性方面發揮著至關重要的作用。

利用 AWS 和 Python 實現事件驅動資料網格

事件生產者： AWS Kinesis + Python
在本示例中，當建立新客戶時，我們使用 AWS Kinesis 對事件進行流式處理：

import boto3
import json

kinesis = boto3.client('kinesis')

def send_event(event):
kinesis.put_record(
StreamName="CustomerStream",
Data=json.dumps(event),
PartitionKey=event['customer_id']
)

def create_customer_event(customer_id, name):
event = {
'event_type': 'CustomerCreated',
'customer_id': customer_id,
'name': name
}
send_event(event)

# Simulate a new customer creation
create_customer_event('123', 'ABC XYZ')

事件處理： AWS Lambda + Python

此 Lambda 函式消耗 Kinesis 事件並對其進行實時處理

import json
import boto3

dynamodb = boto3.resource('dynamodb')
table = dynamodb.Table('CustomerData')

def lambda_handler(event, context):
for record in event['Records']:
payload = json.loads(record['kinesis']['data'])
if payload['event_type'] == 'CustomerCreated':
process_customer_created(payload)

def process_customer_created(event):
table.put_item(
Item={
'customer_id': event['customer_id'],
'name': event['name']
}
)
print(f"Stored customer data: {event['customer_id']} - {event['name']}")

AWS DataZone架構

data.all

如果您瞭解開源並想要構建和管理自己的解決方案，請考慮使用諸如 data.all 之類的開源框架。Data.all 是一個現代資料市場，支援不同使用者之間的協作。Data.all 簡化了資料發現、共享和精細的資料訪問管理，而構建者則使用資料和 AWS 分析服務組合。下圖顯示了基於 data.all 的資料網格參考架構

架構圖包含以下元件：

1. 資料生產者在 data.all 前端提供的目錄中釋出資料產品。data.all 的前端和後端託管在中央治理賬戶中。
2. 資料使用者（使用者）使用其單點登入或 Amazon Cognito 憑證登入 data.all 前端。他們可以瀏覽目錄並搜尋自己感興趣的資料產品。他們可以篩選搜尋結果。
3. 屬於消費者團隊的資料使用者找到他們感興趣的資料產品後，他們可以請求訪問資料。Data.all 有一個內建的訪問管理工作流程，資料所有者可以使用該工作流程來審查和批准訪問請求。
4. 消費者團隊可以利用這些資料來增強他們的 AI/ML、分析和報告以及 ETL 用例。

基於DataMesh實時同步場景

資料血緣

結論

透過利用 Kinesis、Lambda、DynamoDB 和 Glue 等 AWS 服務，企業可以充分發揮事件驅動資料網格架構的潛力。這種架構具有敏捷性、可擴充套件性和實時洞察力，可確保企業在當今快速發展的資料環境中保持競爭力。對於希望在大資料和分散式系統時代蓬勃發展的企業來說，採用事件驅動資料網格架構不僅是技術上的提升。

---

今天先到這兒，希望對雲原生，技術領導力， 企業管理，系統架構設計與評估，團隊管理, 專案管理, 產品管理，資訊保安，團隊建設 有參考作用 , 您可能感興趣的文章:
構建創業公司突擊小團隊
國際化環境下系統架構演化
微服務架構設計
影片直播平臺的系統架構演化
微服務與Docker介紹
Docker與CI持續整合/CD
網際網路電商購物車架構演變案例
網際網路業務場景下訊息佇列架構
網際網路高效研發團隊管理演進之一
訊息系統架構設計演進
網際網路電商搜尋架構演化之一
企業資訊化與軟體工程的迷思
企業專案化管理介紹
軟體專案成功之要素
人際溝通風格介紹一
精益IT組織與分享式領導
學習型組織與企業
企業創新文化與等級觀念
組織目標與個人目標
初創公司人才招聘與管理
人才公司環境與企業文化
企業文化、團隊文化與知識共享
高效能的團隊建設
專案管理溝通計劃
構建高效的研發與自動化運維
某大型電商雲平臺實踐
網際網路資料庫架構設計思路
IT基礎架構規劃方案一(網路系統規劃)
餐飲行業解決方案之客戶分析流程
餐飲行業解決方案之採購戰略制定與實施流程
餐飲行業解決方案之業務設計流程
供應鏈需求調研CheckList
企業應用之效能實時度量系統演變

如有想了解更多軟體設計與架構, 系統IT,企業資訊化, 團隊管理 資訊，請關注我的微信訂閱號：

作者：Petter Liu
出處：http://www.cnblogs.com/wintersun/
本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連線，否則保留追究法律責任的權利。 該文章也同時釋出在我的獨立部落格中-Petter Liu Blog。