解讀 EventBridge Transform,數據轉換和處理的靈活能力

阿里雲 EventBridge 提供了強大而靈活的事件總線服務,它可以連接應用程序、阿里云云服務和阿里雲 Serverless 服務來快速構建 EDA(Event-driven Architectures)事件驅動架構,驅動應用與應用,應用與雲的連接。除此之外,它還可以作爲流式的數據管道,在不同的數據倉庫和數據處理或分析程序之間快速構建 ETL 系統。

本文將從以下幾個方面展開對阿里雲 EventBridge Transform 能力的介紹:

1)首先介紹 ETL 基本概念;

2)接着介紹 T(Transform)的能力;

3)最後探討 EventBridge Transform 能力及落地場景。

1. 什麼是 ETL?

ETL 表示的是數據提取(Extract)、轉換(Transform)和加載(Load)的過程,是數據集成的核心任務。三個步驟的主要作用如下:

1.1 提取

從數據源中提取數據,數據源可以是各種數據存儲系統,比如消息隊列、數據庫等。

1.2 轉換

對提取的數據進行轉換操作,比如數據富化、數據清洗、數據聚合、數據拆分、格式轉換等。

1.3 加載

將經過轉換後的數據加載到目標服務中,比如數據倉庫、數據湖、BI 系統等。ETL 應用廣泛,它可以幫助企業管理和利用數據,實現數據驅動的決策和業務轉型。

2. T(Transform)的能力

2.1 Transform 應用場景

ETL 中的 T(Transform)可以對提取的數據進行轉換操作,它具體的使用場景如下:

2.1.1 數據富化

調用外部服務獲取額外信息豐富原始數據,提高數據的完整度和可應用性。

2.1.2 數據清洗

對原始數據進行清洗或驗證,去除重複、缺失或者不準確的數據,確保數據的質量和準確性,或者對數據中的信息進行脫敏,確保 數據的安全性。

2.1.3 數據聚合

將多條原始數據進行合併,形成一個統一的數據視圖,便於後續的快速分析和查詢。

2.1.4 數據拆分

將單條原始數據根據業務需求拆分爲多條數據。

2.1.5 數據格式轉換

將上游數據轉換爲目標服務可接受的格式,比如將 Base64、Avro、PB 等格式的原始數據統一轉換爲 json 格式。

通過 Transform,可以將原始數據轉化爲一致性、準確性和安全性兼具的高質量數據,爲後續的數據分析等操作提供可靠的基礎。

2.2 業界 Transform 架構概述

目前業界的 Transform 能力,常見的做法有以下幾類:

2.2.1 內置開箱即用的簡單且輕量的 Transform 能力

數據清洗:去除數據中的敏感字段、處理噪音數據等。

數據格式轉換:將數據中的指定字段轉換爲特定格式。

2.2.2 內置 Custom Transform 能力

用戶可自定義 Transform 的邏輯。這種常見的做法是:用戶根據 Custom Transform 的接口規範,實現接口並將實現的代碼打成 jar 包,之後在系統導入該 jar 包即可使用自己編寫的 Transform 邏輯。

2.2.3 Remote Custom Transform 能力

通過 Remote 調用的方式調用外部系統對數據進行 Transform。

上述 1、2 兩種做法,由於其 Transform 與系統邏輯高度耦合,共享計算資源,並不太適合在 Transform 中進行重量級計算,僅適合應用在一些輕量、簡單的業務場景。更優的做法是 Remote Custom Transform,它解耦了 Transform 業務邏輯與數據通路,更具靈活性。

2.3 阿里雲 EventBridge Transform 設計

阿里雲 EventBridge 通過集成阿里雲函數計算實現了 Custom Transform 能力,通過 Remote 調用的方式將 Transform 業務邏輯與數據通路解耦。提高了 Transform 的靈活性,降低計算資源的擠兌風險。

2.3.1 鏈路架構

使用阿里雲的函數計算進行 Transform 時,EventBridge 的整體鏈路如圖所示。

  • EventBridge 從 Source 側提取數據。
  • 提取的數據,先經過攢批(window)邏輯的處理,達到攢批條件後,數據將以批的方式交由下一步處理。過濾(Filter)會遍歷每一條數據,判斷是否要丟棄該條數據。過濾完成後,數據將仍以批的方式交由下一步處理。轉換(Transform)階段會調用函數計算,將數據交由用戶編寫的函數代碼進行處理,Transform 階段會等待函數執行完成並接收其返回的處理結果。
  • EventBridge 將 Transform 處理後的數據加載到 Sink 側。
 

下文在此基礎之上繼續探討鏈路中涉及的幾個關鍵問題:

2.3.2 攢批問題

攢批可以批量聚合多條數據,在達到攢批條件後再將數據批量推送給下一步進行處理。EventBridge 將攢批能力置於 Transform 之前,通過攢批能力提升了數據的處理效率和吞吐量,並且顯著降低 Transform 調用函數計算的次數。

EventBridge 從數量和時間兩個條件來控制攢批的行爲,只要達到其中一個條件時就會觸發批量推送。

批量推送條數:單次可聚合的最大數據條數。

批零推送間隔:聚合的間隔時間,系統每到間隔時間會將已聚合的數據批量推送給下一步。

2.3.3 高可用問題

Transform 處理數據時可能出現異常,爲避免異常導致數據丟失或影響鏈路的穩定性和可用性等。Transform 複用了 EventBridge 的重試、死信、容錯等機制。

  • 重試機制
    由於網絡異常、系統 crash 等原因導致 Transform 處理異常時,EventBridge 會按照用戶選擇的重試策略進行重試,目前支持退避重試、指數衰減重試兩種方式。
  • 死信隊列當數據超過重試次數後仍未 Transform 成功時,會變成死信數據。如果不希望死信數據被丟棄,用戶可以配置死信隊列,所有的死信數據會被 EventBridge 投遞到死信隊列中,目前 EventBridge 支持 Kafka、RocketMQ、MNS 作爲死信隊列的目標端。
  • 容錯策略
    當 Transform 發生錯誤時,EventBridge 提供了以下兩種處理方式:
    • 允許異常容錯:當 Transform 異常發生時不會阻塞執行,會繼續處理後續的數據。但是,EventBridge 會重試發生異常的數據,在超出重試策略後根據配置將數據投遞至死信隊列或直接丟棄。
    • 禁止容錯:不允許錯誤,當 Transform 異常發生且超過重試策略配置時會阻塞執行。

2.3.4 費用問題

函數計算的調用和函數的執行會產生一定費用,包含函數調用、資源使用(CPU、Mem 等)和公網出流量三部分的費用。爲減少函數計算產生的費用,函數計算定向減免了來自 EventBridge 的函數調用次數費用,即 EventBridge 觸發函數計算產生的函數調用次數不再計入費用賬單[3,4]。

2.4 產品交互

目前可在 EventBridge 的事件流中體驗 Transform 能力,如圖所示。

 

對於阿里雲函數計算來說,我們提供了兩種方式:

2.4.1 新建函數模板

可在提供的模板之上,直接創建函數。產品層面提供了簡易的 IDE,便於用戶編寫和調試代碼。

 

2.4.2 綁定現有函數

支持綁定用戶已有的函數。更詳細的使用可參考 Transform 幫助文檔,見附錄[4]。

2.5 Transform 優勢

2.5.1 Serverless Transform 特性

EventBridge Transform 基於 Serverless 函數計算構建,可享受 Serverless 服務免運維、資源彈性伸縮、按量付費等特性,具體如下:

  • 彈性:百毫秒內級別的伸縮,可滿足波峯波谷、Burst、持續穩定等多樣化的負載場景。
  • 免運維:用戶無需關心和運維 Transform 運行環境及資源。
  • 按量付費:用戶只需支付函數運行所產生的費用,更重要的是 EventBridge 調用函數所產生的調用次數費用將不計費。
  • 靈活性:UDF 的方式可滿足實際業務中複雜、個性化的需求。
  • 多語言支持支持:go、python、java、nodejs 等主流語言,可選擇熟悉或適合的語言實現 Custom Transform 邏輯。
  • 架構解耦:Remote Transform 的架構將 Transform 業務邏輯和系統邏輯結解耦,資源隔離,避免產生資源爭搶等問題。
  • 模版支持:產品層面提供了多種 Transform 函數模板,避免用戶從零開始。
  • 攢批提效:通過攢批,函數的入參爲批量的消息,大幅提升了消息的處理效率和吞吐。

3. 客戶場景案例介紹

3.1 數據格式轉換+架構升級

消息(MNS)->Transform->消息(RocketMQ)

客戶面臨架構升級問題,希望將系統依賴的 MNS 升級爲 RocketMQ,但系統架構複雜,依賴 MNS 邏輯較多,且牽涉研發人員較多,預計全部升級架構需持續幾個月時間。爲保證架構升級過程中產生的數據一致性問題,客戶使用 EventBridge 將舊架構的 MNS 消息實時同步到新架構的 RocketMQ 實例中,來保證數據在一致性。同時爲了適配新架構中的消息設計,客戶使用 FC Transform 先將舊消息轉換爲目標格式,再投遞至 RocketMQ 中。

3.2 數據清洗+數據轉儲

消息(RocketMQ)->Transform->OSS

客戶會將用戶產生的視頻數據投遞到 RocketMQ 中,這些數據用戶是可以查看的。爲此客戶選擇 OSS 來進行文件存儲,滿足這種寫多讀少、低成本存儲數據的場景。但是,視頻數據中包含了若干敏感信息,爲此客戶使用 FC Transform 對視頻中的敏感數據做清除後,再將視頻投遞到 OSS 中。

4. 總結與展望

EventBridge Transform 通過集成函數計算,滿足了實際業務中複雜、個性化的需求。其彈性伸縮、免運維、按量付費的特性深受客戶青睞。未來 Transform 會通過集成更多的服務(阿里雲工作流、HTTP Destination 等)解鎖更多的業務場景,滿足多樣化需求。

相關鏈接:

[1] EventBridge-事件流-事件內容轉換

[2] EventBridge-事件流產品首頁

[3] 定向減免消息類產品和雲工作流的函數調用次數費用

[4] 函數計算計費項降價通知

原文鏈接

本文爲阿里雲原創內容,未經允許不得轉載。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章