在當今數(shù)據(jù)驅(qū)動的世界中，企業(yè)必須適應數(shù)據(jù)管理、分析和利用方式的快速變化。傳統(tǒng)的集中式系統(tǒng)和整體架構雖然在歷史上已經(jīng)足夠，但已不再足以滿足需要更快、實時訪問數(shù)據(jù)洞察的組織不斷增長的需求。該領域的一個革命性框架是事件驅(qū)動的數(shù)據(jù)網(wǎng)格架構，當與 AWS 服務相結(jié)合時，它成為解決復雜數(shù)據(jù)管理挑戰(zhàn)的強大解決方案。

數(shù)據(jù)困境

許多組織在依賴過時的數(shù)據(jù)架構時面臨著重大挑戰(zhàn)。這些挑戰(zhàn)包括：

集中式、整體式且與領域無關的數(shù)據(jù)湖

集中式數(shù)據(jù)湖是所有數(shù)據(jù)的單一存儲位置，使其易于管理和訪問，但如果擴展不當，可能會導致性能問題。單一數(shù)據(jù)湖將所有數(shù)據(jù)處理流程合并到一個集成系統(tǒng)中，這簡化了設置，但可能難以擴展和維護。與領域無關的數(shù)據(jù)湖旨在存儲來自任何行業(yè)或來源的數(shù)據(jù)，提供靈活性和廣泛的適用性，但管理起來可能很復雜，并且針對特定用途的優(yōu)化程度較低。

傳統(tǒng)架構故障壓力點

集中式數(shù)據(jù)架構

在傳統(tǒng)的數(shù)據(jù)系統(tǒng)中，可能會出現(xiàn)幾個問題。數(shù)據(jù)生產(chǎn)者可能會發(fā)送大量數(shù)據(jù)或有錯誤的數(shù)據(jù)，從而在下游產(chǎn)生問題。隨著數(shù)據(jù)復雜性的增加以及系統(tǒng)來源的多樣化，集中式數(shù)據(jù)平臺可能難以處理不斷增長的負載，從而導致崩潰和性能下降。對快速實驗的需求增加可能會使系統(tǒng)不堪重負，從而難以快速適應和測試新想法。數(shù)據(jù)響應時間可能成為一個挑戰(zhàn)，導致訪問和使用數(shù)據(jù)的延遲，從而影響決策和整體效率。

運營數(shù)據(jù)環(huán)境和分析數(shù)據(jù)環(huán)境之間的差異

在軟件架構中，孤立的所有權、不明確的數(shù)據(jù)使用、緊密耦合的數(shù)據(jù)管道和固有的限制等問題可能會導致嚴重的問題。當不同的團隊孤立工作時，就會出現(xiàn)孤立的所有權，從而導致協(xié)調(diào)問題和效率低下。對如何使用或共享數(shù)據(jù)缺乏清晰的了解可能會導致重復工作和不一致的結(jié)果。耦合數(shù)據(jù)管道(組件之間過于依賴)使得系統(tǒng)難以適應或擴展，從而導致延遲。最后，系統(tǒng)的固有限制可能會減慢新功能和更新的交付速度，從而阻礙整體進展。解決這些壓力點對于提高開發(fā)流程的效率和響應速度至關重要。

大數(shù)據(jù)的挑戰(zhàn)

在線分析處理 (OLAP) 系統(tǒng)以一種使分析人員更容易探索數(shù)據(jù)不同方面的方式組織數(shù)據(jù)。為了回答查詢，這些系統(tǒng)必須將操作數(shù)據(jù)轉(zhuǎn)換為適合分析和處理大量數(shù)據(jù)的格式。傳統(tǒng)數(shù)據(jù)倉庫使用ETL(提取、轉(zhuǎn)換、加載)流程來管理此過程。大數(shù)據(jù)技術，例如Apache Hadoop，通過解決擴展問題和開源改進了數(shù)據(jù)倉庫，這使得任何公司只要能夠管理基礎設施就可以使用它。 Hadoop 引入了一種新方法，允許使用非結(jié)構化或半結(jié)構化數(shù)據(jù)，而不是預先強制執(zhí)行嚴格的模式。這種靈活性可以在沒有預定義模式的情況下寫入數(shù)據(jù)，并在稍后的查詢過程中進行結(jié)構化，使數(shù)據(jù)工程師可以更輕松地處理和集成數(shù)據(jù)。采用 Hadoop 通常意味著組建一個獨立的數(shù)據(jù)團隊：數(shù)據(jù)工程師負責數(shù)據(jù)提取，數(shù)據(jù)科學家負責清理和重組，數(shù)據(jù)分析師負責分析。由于數(shù)據(jù)團隊和應用程序開發(fā)人員之間的溝通有限，這種設置有時會導致問題，通常是為了防止影響生產(chǎn)系統(tǒng)。

問題 1：數(shù)據(jù)模型邊界問題

用于分析的數(shù)據(jù)與其原始結(jié)構密切相關，這對于復雜且頻繁更新的模型來說可能會出現(xiàn)問題。數(shù)據(jù)模型的更改會影響所有用戶，使他們?nèi)菀资艿竭@些更改的影響，尤其是當模型涉及許多表時。

問題 2：不良數(shù)據(jù)，忽視問題的代價

不良數(shù)據(jù)通常會被忽視，直到它導致架構出現(xiàn)問題，從而導致數(shù)據(jù)類型不正確等問題。由于驗證通常會延遲到流程結(jié)束，因此不良數(shù)據(jù)可能會通過管道傳播，從而導致昂貴的修復和不一致的解決方案。不良數(shù)據(jù)可能會導致重大業(yè)務損失，例如計費錯誤造成數(shù)百萬美元的損失。研究表明，不良數(shù)據(jù)每年給企業(yè)造成數(shù)萬億美元的損失，浪費了知識工作者和數(shù)據(jù)科學家的大量時間。

問題3：缺乏單一所有權

應用程序開發(fā)人員是源數(shù)據(jù)模型方面的專家，通常不會將此信息傳達給其他團隊。他們的職責通常終止于應用程序和數(shù)據(jù)庫邊界。管理數(shù)據(jù)提取和移動的數(shù)據(jù)工程師通常是被動工作，并且對數(shù)據(jù)源的控制有限。數(shù)據(jù)分析師遠離開發(fā)人員，他們收到的數(shù)據(jù)面臨挑戰(zhàn)，導致協(xié)調(diào)問題和需要單獨的解決方案。

問題 4：自定義數(shù)據(jù)連接

在大型組織中，多個團隊可能使用相同的數(shù)據(jù)，但創(chuàng)建自己的管理流程。這會產(chǎn)生多個數(shù)據(jù)副本，每個副本都獨立管理，從而造成混亂。跟蹤 ETL 作業(yè)并確保數(shù)據(jù)質(zhì)量變得困難，從而導致由于同步問題和數(shù)據(jù)源安全性較低等因素而導致不準確。這種分散的方法浪費了時間、金錢和機會。

數(shù)據(jù)網(wǎng)格通過將數(shù)據(jù)視為具有清晰架構、文檔和標準化訪問的產(chǎn)品來解決這些問題，從而降低不良數(shù)據(jù)風險并提高數(shù)據(jù)準確性和效率。

數(shù)據(jù)網(wǎng)格：現(xiàn)代方法

數(shù)據(jù)網(wǎng)格架構

數(shù)據(jù)網(wǎng)格通過分散所有權并將數(shù)據(jù)視為由自助服務基礎設施支持的產(chǎn)品，重新定義了數(shù)據(jù)管理。這種轉(zhuǎn)變使團隊能夠完全控制其數(shù)據(jù)，同時聯(lián)合治理可確保整個組織的質(zhì)量、合規(guī)性和可擴展性。

簡單來說，它是一個架構框架，旨在通過使用去中心化所有權和分布式方法來解決復雜的數(shù)據(jù)挑戰(zhàn)。它用于集成來自各個業(yè)務領域的數(shù)據(jù)以進行全面的數(shù)據(jù)分析。它還建立在強大的數(shù)據(jù)共享和治理政策之上。

數(shù)據(jù)網(wǎng)格的目標

數(shù)據(jù)網(wǎng)格幫助各種組織獲得對大規(guī)模數(shù)據(jù)的一些有價值的見解;簡而言之，處理不斷變化的數(shù)據(jù)環(huán)境、不斷增長的數(shù)據(jù)源和用戶數(shù)量、所需的各種數(shù)據(jù)轉(zhuǎn)換以及快速適應變化的需求。

數(shù)據(jù)網(wǎng)格通過分散控制解決了上述所有問題，因此團隊可以管理自己的數(shù)據(jù)，而無需將其隔離在不同的部門。這種方法通過分布式數(shù)據(jù)處理和存儲來提高可擴展性，這有助于避免單個中央系統(tǒng)的速度變慢。它允許團隊直接使用自己的數(shù)據(jù)，從而減少因等待中央團隊而造成的延遲，從而加快洞察速度。每個團隊對自己的數(shù)據(jù)負責，這提高了質(zhì)量和一致性。通過使用易于理解的數(shù)據(jù)產(chǎn)品和自助服務工具，數(shù)據(jù)網(wǎng)格確保所有團隊都可以快速訪問和管理其數(shù)據(jù)，從而實現(xiàn)更快、更高效的運營并更好地滿足業(yè)務需求。

數(shù)據(jù)網(wǎng)格的關鍵原理

· 分散的數(shù)據(jù)所有權：團隊擁有并管理他們的數(shù)據(jù)產(chǎn)品，使他們對其質(zhì)量和可用性負責。

· 數(shù)據(jù)作為產(chǎn)品：數(shù)據(jù)被視為具有標準化訪問、版本控制和模式定義的產(chǎn)品，確?？绮块T的一致性和易用性。

· 聯(lián)合治理：制定政策是為了維護數(shù)據(jù)完整性、安全性和合規(guī)性，同時仍然允許分散所有權。

· 自助服務基礎設施：團隊可以訪問可擴展的基礎設施，支持數(shù)據(jù)的攝取、處理和查詢，而不會出現(xiàn)瓶頸或依賴集中式數(shù)據(jù)團隊。

事件如何幫助數(shù)據(jù)網(wǎng)格?

事件允許系統(tǒng)的不同部分實時共享和更新數(shù)據(jù)，從而幫助數(shù)據(jù)網(wǎng)格。當一個區(qū)域發(fā)生變化時，會通過一個事件通知其他區(qū)域，這樣每個人都可以了解最新情況，而無需直接聯(lián)系。這使得系統(tǒng)更加靈活和可擴展，因為它可以處理大量數(shù)據(jù)并輕松適應變化。事件還可以更輕松地跟蹤數(shù)據(jù)的使用和管理方式，并讓每個團隊處理自己的數(shù)據(jù)而不依賴其他團隊。

最后，讓我們看看事件驅(qū)動的數(shù)據(jù)網(wǎng)格架構。

事件驅(qū)動的數(shù)據(jù)網(wǎng)格架構

這種事件驅(qū)動的方法使我們能夠?qū)?shù)據(jù)的生產(chǎn)者與消費者分開，使系統(tǒng)隨著領域隨著時間的推移而發(fā)展而更具可擴展性，而無需對架構進行重大更改。生產(chǎn)者負責生成事件，然后將其發(fā)送到數(shù)據(jù)傳輸系統(tǒng)。流媒體平臺確保這些事件可靠地傳遞。當生產(chǎn)者微服務或數(shù)據(jù)存儲發(fā)布新事件時，它會存儲在特定主題中。這會觸發(fā)消費者端的偵聽器(例如 Lambda 函數(shù)或 Kinesis)來處理事件并根據(jù)需要使用它。

利用 AWS 實現(xiàn)事件驅(qū)動的數(shù)據(jù)網(wǎng)格架構

AWS 提供了一套服務，完美補充了事件驅(qū)動的數(shù)據(jù)網(wǎng)格模型，使組織能夠擴展其數(shù)據(jù)基礎設施、確保實時數(shù)據(jù)交付并維持高水平的治理和安全性。

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

用于實時事件流的 AWS Kinesis

在事件驅(qū)動的數(shù)據(jù)網(wǎng)格中，實時流是一個關鍵要素。 AWS Kinesis 提供大規(guī)模收集、處理和分析實時流數(shù)據(jù)的能力。

Kinesis 提供了多個組件：

· Kinesis Data Streams：攝取實時事件并與多個使用者同時處理它們。

· Kinesis Data Firehos e：將事件流直接傳送到 S3、Redshift 或 Elastic 搜索以進行進一步處理和分析。

· Kinesis Data Analytics：實時處理數(shù)據(jù)以動態(tài)獲取見解，從而在數(shù)據(jù)處理管道中實現(xiàn)即時反饋循環(huán)。

用于事件處理的 AWS Lambda

AWS Lambda 是數(shù)據(jù)網(wǎng)格架構中無服務器事件處理的支柱。憑借其自動擴展和處理傳入數(shù)據(jù)流的能力，無需服務器管理，

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

· 實時處理 Kinesis 流

· 調(diào)用API網(wǎng)關請求以響應特定事件

· 與 DynamoDB、S3 或其他 AWS 服務交互以存儲、處理或分析數(shù)據(jù)

用于事件分發(fā)的 AWS SNS 和 SQS

AWS Simple Notification Service (SNS) 充當主要事件廣播系統(tǒng)，跨分布式系統(tǒng)發(fā)送實時通知。 AWS Simple Queue Service (SQS) 確保解耦服務之間的消息可靠傳遞，即使在部分系統(tǒng)發(fā)生故障的情況下也是如此。這些服務允許解耦的微服務在沒有直接依賴的情況下進行交互，從而確保系統(tǒng)保持可擴展性和容錯性。

用于實時數(shù)據(jù)管理的 AWS DynamoDB

在去中心化架構中，DynamoDB 提供可擴展、低延遲的 NoSQL 數(shù)據(jù)庫，可以實時存儲事件數(shù)據(jù)，非常適合存儲數(shù)據(jù)處理管道的結(jié)果。它支持發(fā)件箱模式，其中應用程序生成的事件存儲

在 DynamoDB 中并由流服務(例如 Kinesis 或 Kafka)使用。

用于聯(lián)合數(shù)據(jù)目錄和 ETL 的 AWS Glue

AWS Glue 提供完全托管的數(shù)據(jù)目錄和 ETL 服務，這對于數(shù)據(jù)網(wǎng)格中的聯(lián)合數(shù)據(jù)治理至關重要。 Glue 可幫助編目、準備和轉(zhuǎn)換分布式域中的數(shù)據(jù)，確保整個組織的可發(fā)現(xiàn)性、治理和集成。

適用于數(shù)據(jù)湖的 AWS Lake Formation 和 S3

雖然數(shù)據(jù)網(wǎng)格架構逐漸遠離集中式數(shù)據(jù)湖，但 S3 和 AWS Lake Formation 在存儲、保護和編目不同域之間流動的數(shù)據(jù)方面發(fā)揮著至關重要的作用，從而確保長期存儲、治理和合規(guī)性。

使用 AWS 和 Python 運行事件驅(qū)動的數(shù)據(jù)網(wǎng)格

事件制作者：AWS Kinesis + Python

在此示例中，我們在創(chuàng)建新客戶時使用 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 函數(shù)使用 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']}")

結(jié)論

通過利用 Kinesis、Lambda、DynamoDB 和 Glue 等 AWS 服務，組織可以充分發(fā)揮事件驅(qū)動的數(shù)據(jù)網(wǎng)格架構的潛力。該架構提供敏捷性、可擴展性和實時洞察力，確保組織在當今快速發(fā)展的數(shù)據(jù)環(huán)境中保持競爭力。對于希望在大數(shù)據(jù)和分布式系統(tǒng)時代蓬勃發(fā)展的企業(yè)來說，采用事件驅(qū)動的數(shù)據(jù)網(wǎng)格架構不僅是技術的增強，而且是戰(zhàn)略上的當務之急。