基於 MaxCompute 的實時數據處理實踐

本文轉載自查看原文 2021-09-08 16:01 125 數據

簡介： MaxCompute 通過流式數據高性能寫入和秒級別查詢能力(查詢加速)，提供EB級雲原生數倉近實時分析能力；高效的實現對變化中的數據進行快速分析及決策輔助。當前Demo基於近實時交互式BI分析/決策輔助場景，實現指標卡近實時BI分析、近實時市場監測、近實時趨勢分析、近實時銷量拆分功能。

本文作者隆志強阿里雲智能高級產品專家

一、產品功能介紹

基於查詢加速的數倉架構

當前比較盛行的實時數倉，基本都是基於Flink來做的。今天分享的內容不是把 MaxCompute 定義為一個實時數倉，我們講的是基於當前數據的實時處理流程，在MaxCompute中是怎么去做支持的，怎么在 MaxCompute 中做實時數據的接入、查詢、應用。開源的實時數倉是基於Flink來做的，Flink本質是實時計算，支持流批一體，所以比較實時的場景都是基於Flink+Kafka+存儲來做的。本次分享主要不是講計算環節，本次主要講解基於BinLog、Flink、Spark Streaming的實時流數據是怎么寫入到 MaxCompute 中的。

通過實時流通道，實時寫入MaxCompute，寫入即可見，這是 MaxCompute 的產品特點。目前市場的數倉產品寫入查詢絕大多數都有延時存在， MaxCompute 是做到了高QPS的實時寫入，寫入即可查。可以通過查詢加速(MCQA)實時查詢寫入進 MaxCompute 的數據。對接到BI工具，即席查詢可以實時訪問到實時寫入的數據。

Binlog寫到到MaxCompute，是通過DataX，支持增刪改查的合並，后續在產品功能迭代中，MaxCompute會支持upsert，支持業務數據庫數據的新增、修改、刪除。Flink數據計算完之后寫入到 MaxCompute 時，直接使用Streaming Tunnel插件寫入MaxCompute中，這個過程不需要做代碼開發，Kafka也支持了插件。

實時寫入目前沒有做寫入數據的計算處理環節，只是快速的把現在流式數據包括消息服務的數據，直接通過Streaming Tunnel服務寫入到MaxCompute中。當前Streaming Tunnel支持了主流消息服務，如Kafka、Flink，做了插件支持。以及Streaming Tunnel SDK，當前只支持Java SDK。可以通過Streaming Tunnel SDK做一些應用讀取之后的邏輯處理，再調取Streaming Tunnel SDK寫入到MaxCompute中。寫入MaxCompute之后，目前主要的處理環節是針對寫入的數據，進行直讀查詢，也可以把寫入的數據關聯到MaxCompute中的離線數據，做聯合查詢分析。在查的過程中，如果是通過SDK或者JDBC接入時，可以打開查詢加速（MCQA)功能。如果是通過web console或DataWorks，是默認開啟查詢加速（MCQA）功能。當前主要是BI分析工具和第三方應用層分析工具，通過SDK或JDBC鏈接MaxCompute時，是可以打開查詢加速（MCQA）功能，這樣可以做到接近秒級查詢實時寫入的數據。

整體來看，現在的場景主要是數據的實時流式寫入，寫入之后可以結合離線數據，做聯合分析查詢，通過查詢加速（MCQA）功能。在數據進入MaxCompute后，是沒有做計算的，只是做查詢服務。這是目前基於MaxCompute實時數據處理場景。

流式數據寫入功能介紹

當前流式數據寫入功能已經在中國區商業化發布。當前此功能是免費使用。

功能特定

支持高並發、高QPS（Queries-per-second）場景下流式數據寫入，寫入即可見。
提供流式語義API：通過流式服務的API可以方便的開發出分布式數據同步服務。
支持自動創建分區：解決數據同步服務並發創建分區導致的並發搶鎖問題。
支持增量數據異步聚合（Merge）：提升數據存儲效率。
支持增量數據異步zorder by排序功能，zorder by詳情請參見插入或覆寫數據（INSERT INTO | INSERT OVERWRITE）。

性能優勢

更優化的數據存儲結構，解決高QPS寫入導致的碎片文件問題。
數據鏈路與元數據訪問完全隔離，解決高並發寫入場景下元數據訪問導致的搶鎖延遲和報錯問題。
提供了增量數據異步處理機制，可以在使用過程中無感知情況下對新寫入的增量數據做進一步處理，已經支持的功能包括：

數據聚合（Merge）：提升存儲效率。
zorder by排序：提升存儲、查詢效率。

流式數據寫入-技術架構

Stream API無狀態並發數據實時可見

技術架構分為三個部分：數據通道、流計算數據同步、自研應用。

當前數據通道支持的有Datahub、Kafka、TT、SLS

流計算數據同步支持的有Blink、Spark、DTS、DataX、kepler/DD

數據寫入MaxCompute中，在計算集群前會有Tunnel集群存在，提供Stream Tnnel服務來完成從客戶端到Tunnel服務端數據的寫入。寫入過程是一個文件最佳的過程，最后會有一個文件的合並。這個過程是消耗了數據通道過程中的計算資源服務，但這一消耗是免費的。

查詢加速功能介紹

實現數據實時寫入與基於查詢加速的交互式分析

目前查詢加速功能可以支持日常查詢80%-90%的場景。查詢加速功能的語法與MaxCompute內置語法完全一致。

MaxCompute查詢加速 – 針對實時性要求高的查詢作業，全鏈路加快 MaxCompute 查詢執行速度

使用MaxComputeSQL語法和引擎，針對近實時場景進行優化
系統自動進行查詢優化選擇，同時支持用戶選擇延時優先還是吞吐優先的執行方式
針對近實時場景使用不同的資源調度策略：latencybased
針對低延時要求的場景進行全鏈路優化：獨立執行資源池；多層次的數據和metaCaching；交互協議優化

收益

簡化架構，查詢加速與海量分析自適應的一體化方案
對比普通離線模式快幾倍甚至數十倍
結合MaxCompute流式上傳能力，支持近實時分析
支持多種接入方式，易集成
支持自動識別離線任務中的短查詢，后付費模式是默認開啟。預付費當前支持為使用包年包月資源的實例下SQL掃描量在10 GB以內的查詢作業提供免費查詢加速服務。
低成本，免運維，高彈性

查詢加速-技術架構

自適應執行引擎、多層次緩存機制

當SQL提交到MaxCompute計算引擎時，會分為兩個模式，離線作業(吞吐量優化）和短查詢(延遲優化）。兩個模式從技術底層來說，查詢加速作業做了執行計划的縮減和優化，計算資源是預拉起資源，是向量化執行，會基於內存/網絡shuffle以及多層次的緩存機制。相比於離線作業的代碼生產到磁盤shuffle，再進行資源排隊申請。查詢加速會進行識別作業，如果符合條件，則直接進入預拉起資源。在數據緩存部分，基於Pangu分布式文件系統，對表跟字段會有一個緩存機制。