MaxCompute Tunnel 技術原理及開發實戰是怎樣的

這篇文章給大家介紹MaxCompute Tunnel 技術原理及開發實戰是怎樣的，內容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

一、MaxCompute Tunnel技術原理

上圖是架構圖，可以看到對外的服務提供了一個統一的SDK，然后集成到所有的外部服務里。在服務端，提供的服務可以大概分為API層和執行層。API層有兩個集群 Frontend集群會負責控制流的介入，Tunnel集群負責數據。在執行層分為控制集群和計算集群，控制集群會負責資源管控，meta的管理，和權限管理這些功能，計算集群就負責實際的計算和存儲。

可以看到，Tunnel是屬于API層的一個組件，專門負責數據的上傳和下載。為什么這么做, 是因為這是一個大數據的系統，所以在MaxCompute上跑一個SQL其實就發了一條控制指令。由于目標的場景是一個大數據量的查詢，比如說十億條這種量級的，這是一個規模比較大的操作，如果在這個場景下想做數據的同步，就不能像MySQL傳統輸入一樣通過insert into，因為insert into走控制集群這個鏈路是非常浪費資源的，同時也會有一些限制。一次一行的效率特別低，因此設計了分開的控制流和數據流。

Tunnel集群負責的功能是在SDK層提供了Tunnel的API，讓用戶可以通過一個結構化的方式去訪問數據。另外，Tunnel是對外放出來的唯一的數據接口，會對用戶寫進來的數據做格式檢查和權限校驗，控制數據安全。同時會保證用戶通過Tunnel寫出來的數據用SQL可讀，不用擔心比如SQL讀不了寫進來的數據，或者寫的數據和SQL讀出來的值有差異。

另外一點，Tunnel是直接訪問存儲層的，MaxCompute在底層的存儲是一個分布式文件系統，Tunnel是直接訪問這個文件系統的，這樣在性能上就有了保證。也就是說，Tunnel在理想情況下是可以保證單并發達到10兆每秒的吞吐能力，通過假并發也是可以水平擴展整個吞吐能力。

二、MaxCompute Tunnel豐富的生態

MaxCompute有非常豐富的生態，推薦首先要看一下有什么工具，或者有哪些服務可以做，建議優先使用一些成熟的服務，盡量不要自己先寫代碼。

官方的SDK有Java SDK和Python SDK。

另外，官方還提供了三種工具。MaxCompute客戶端是一個命令行工具，在數據同步這方面支持用戶把一個本地文件上傳到MaxCompute里面，也可以通過下載一張表到一個本地文件上。MaxCompute Studio是一個idea插件，它也支持文件上傳下載這樣的方式。MMA2.0遷移工具是最近推出的一個工具，可以幫助用戶把數據從現有的大數據系統里遷移到MaxCompute上，這些工具都是基于SDK開發的，都是通過SDK傳輸。

除了工具以外，MaxCompute在第三方服務上也是集成的，比如云上的數據通道圖，SLS（阿里云的日志服務），DataHub（數據通道），他們都是原生就支持MaxCompute投遞的，Kafka也是有官方的插件。

流計算方面，Blink，Spark也都是有MaxCompute同步插件的。數據同步服務方面，DataWorks的數據同步，實時同步和離線同步，都是支持MaxCompute同步的。

總結一下，如果有數據同步的需求，最好先看一下現有的服務是不是可以滿足需求。如果覺得都滿足不了，想要自己開發的話，可以看一下SDK是可以有哪些功能，和使用上的一些注意事項。

三、Tunnel功能簡介

上圖是Tunnel總體功能的表格。現在有兩套API，分批量數據通道和流式數據通道。

批量數據通道目標的場景單并發的吞吐量很大，這種理想的場景是傳量大的數據，一次一批，QPS和并發都不能特別高，但是單并發的吞吐量可以做得很大，這個在API上也有一些優化。

流式數據通道是新提供的一種服務，因為現在的上游服務大多數都是一些流式服務灌進來的，也就是說單并發可能流量沒有那么大，但是都是比較細碎的數據，這種情況如果用批量數據通道會遇到很多限制。最明顯的就是小文件問題，用批量數據通道寫特別碎的數據進來會產生大量的碎片文件，跑SQL查詢就會非常慢，用Tunnel下載也會非常慢。針對這種場景平臺提供了流式數據通道服務，通過流式數據上來可以寫得特別碎，一行寫一次也可以，不需要擔心小文件的問題，也不用擔心并發的問題，并發可以無限多。流式數據通道是不限并發的，但是批量是限并發的。

從表格中可以看到，通過Tunnel是可以訪問這幾種資源的：普通表，Hash Clustered表，Range Clustered表和Transactional表，最后是查詢結果，這些都是可以下載的；普通表兩種上傳都支持；Hash Clustered表和Range Clustered表并不適合Tunnel去寫，因為數據在存儲上需要做一個系統，而且會排序，而Tunnel集群規模沒有計算機集群那么大，沒有這個能力去做排序。因此，這種表一般經典的用法就是先寫一張普通表，然后通過SQL做一個insert overwrite，生成一張Hash Clustered表或者Range Clustered表。

流式上傳在架構上做了升級，有一個異步處理的機制，會把用戶寫進來的數據在后臺進行加工，所以后面會支持Hash Clustered表。

Transactional表是說，MaxCompute的普通表是不支持update或者delete的，系統最近在SQL上支持了這個語法，就是用戶可以update，也可以delete，也可以支持transaction。批量上傳的API現在是支持Transactional表，但是只支持append，也稱為insert into，它是不能從Tunnel的API上去update的。流式的也正在規劃中，后續可能會連update也一起完成。批量的可能不會做update這個功能，但是批量的現在就可以append這種Transactional表。

查詢結果就是說，如果跑一個SQL，在odpscmd客戶端或者DataWorks上對查詢結果有1萬條的限制。但是這個查詢結果可以通過Tunnel下載，就不受條數限制，可以下載完整的查詢結果到本地。

總而言之，如果使用SDK的話，就可以做到表格里的這些功能。

四、SDK的使用方式

1）基本配置

如果想開發的話有哪些東西需要配置，不管上傳、下載，還是流式上傳，這些配置都是一樣的。首先需要創建一個ODPS對象和一個Table Tunnel對象。如果想用SDK跑SQL，要創建ODPS；TableTunnel是Tunnel入口的一個類，所有的功能都是從這個類發起的。

然后看具體的配置項，圖中左側列舉的是比較關鍵的幾個。Access ID和Access Key就是賬號信息，阿里云通過這個來表示一個賬號。

ODPS Endpoint是服務的一個入口，現在在公共云上應該有21個region，包括金融云和政務云，中國有7個，海外有14個。每個region的endpoint是不一樣的，使用時需要找到自己購買的region服務，并正確填寫endpoint進去。

Tunnel Endpoint是可選的，如果不填，系統會通過所填的ODPS endpoint自動路由到對應的Tunnel endpoint上。在公共云上的網絡環境比較復雜，分公網域名和內網域名，內網域名還分經典網絡和VBC，也許會有路由的endpoint網絡不通這種場景，這個時候平臺提供了一個接口，用戶可以把能訪問的Tunnel endpoint填進來，這樣就會優先用所填的Tunnel endpoint而不會用路由的，但99%的情況下是不用填。

Default project這個參數是在彈內經常用的。 MaxCompute的權限管理非常豐富，比如如果在公共云上有多個project，想要控制數據在跨project流動的話，就可以通過這個參數來配置。ODPS里設置的Default Project可以理解為是原project，下面的create Stream Session里面又有一個project，即要訪問數據所在的project。如果這兩個project不一樣，系統會檢查這個權限，用戶是否可以訪問目標project的數據。如果跑SQL，它也會根據原project來控制資源的使用。如果只有一個，這兩個填成一樣的就可以。

一般來說，Access ID，Access Key, 和ODPS Endpoint是必選的，Tunnel Endpoint可選，Default project如果只有一個只填一個就行了。

2）具體的上傳接口

接下來展示具體的上傳接口。首先看批量上傳。

【批量上傳】

上圖中可以看到，批量上傳的流程是先創建一個upload session (第31行),然后open writer，用writer去寫數據，然后close，再upload session加commit。

Upload session可以理解為是一個會話的對象，類似于transaction的概念。這次上傳是以upload session為單位的，即最終upload session commit成功了這些數據才是可見的。在一個upload session內部可以open多個writer，并且多個writer可以并發上傳，但是writer是有狀態的，需要給它指定一個不重復的block ID，避免產生覆蓋。Upload session也是有狀態的，沒有commit就不可見； 如果commit成功了，這個session就結束了，暫時就不能再去open writer。Writer的實現原理是open一個writer請求，系統會發一個HTP請求到服務端，然后保持這個長鏈接，寫數據時平臺會實時地把數據寫到服務端，writer是寫一個臨時目錄。根據這個機制可以看到，如果writer或者close失敗了，就相當于這個長連接斷了。所以writer和close這兩個接口是不能重試的，如果writer中間有任何階段失敗了，就需要重新寫。

除了正常的commit之外，MaxCompute還支持讓用戶檢查數據正確性。比如用戶open了五個writer，commit的時候可以把這五個ID當成例子上傳確認。如果檢查到服務端與這個例子不一致，commit就會報錯。

總結一下，基本的功能點有：

批量上傳是有狀態并發；

commit成功后數據才可見；

支持insertOverwrite, 也支持InsertInto語義。

Insert overwrite指commit的時候支持使用某個upload session的數據直接overwrite掉一整個分區或者一張表，類似SQL的Insert和Overwrite的功能。

這個功能也有使用限制。

第一，一個upload session不能超過2萬個Block。

第二，Block ID會導致數據覆蓋。

第三，upload session 24小時過期，因為writer數據是寫在存儲的臨時目錄的，臨時數據有回收周期，超過24小時， writer寫過的數據就有可能被回收掉，這個就限制了upload session的生命周期。

第四，如果open了一個writer但是不寫數據，就相當于占了一個空閑鏈接，服務端會把這個鏈接直接斷掉。

【流式上傳】

接下來看一下流式上傳的接口。前文中有提到，流式上傳是在API上做了簡化，還去掉了并發的限制和時間的限制。

圖中可以看到，接口是CreateStreamUploadSession，寫數據的從writer改成了RecordPack。所謂的pack其實相當于一個內存里的buffer，可以用pack.append(record)，比如判斷size只需要判斷這個buffer足夠大或者條數足夠多，然后再flush就可以了（42到44行）。Pack并不是寫網絡的，而是寫內存的。因此，不同于writer，flush是可以重試的，因為數據都在內存里。并且Pack也沒有狀態，不需要關心writer的Block ID等等。另外，因為flush成功后數據就可見了，所以session也沒有commit這種狀態。因此，如果要開發分布式服務，這個相比批量上傳就簡化很多，沒有太多的限制，只需要確保本機內存是否夠大就好了。

同時系統還支持了內存的復用，即flush過以后的pack是可以復用的。系統會把上次寫滿的內存留住，避免產生GC。流式上傳只支持InsertInto，因為在API上沒有另外的接口，所以InsertOverwrite語義現在是不支持的。另外，流式服務是支持異步數據處理的，也就是除了保證用戶通過流式寫上來的數據可讀之外，服務端還有一個機制能識別出來新寫進來的數據和存量數據，可以對新寫出來的數據做一些異步的處理，比如zorder by排序和墨紙。

ZorderBy排序是指一種數據的組織方式，可以把存在MaxCompute的數據按某些規則重新組織一遍，這樣查詢的時候效率會非常高。墨紙是指支持把數據在后端重新寫一遍，把一些很碎的數據重新組織成存儲數據存儲效率較高的數據文件。在這個基礎上還可以做一些排序和其他的處理，后續會再加更多的功能。

流式上傳也會有一些限制。首先在寫的時候，系統會對這個表加鎖，流式寫的時候其他的操作是不能寫的，比如InsertInto和Insert Overwrite是會失敗的，要把流式停掉之后才能正常寫。另外，DDL有一些延遲，如果要drop table或者rename table的話，可能drop完還能成功寫幾條數據，會有最多60秒的延遲。如果有這種場景，建議先把流式停掉再去drop或者rename。

【批量下載】

接下來介紹批量下載的接口。

圖中可以看到，TableTunnel創建了一個叫downloadSession的對象。可以得到record Count，指一個分區或者一張表的總行數。下面是open reader，可以和批量上傳對應起來: reader和writer; uploadSession和downloadSession。Openreader是按record來區分的，比如有1000行，可以分十個100行并發下載。Download支持列裁剪，也就是可以下載其中幾列。下載查詢結果就把TableTunnel入口類改成InstanceTunnel，odps也是一樣，53行就不是project, table了，是一個InstanceID。

使用限制方面，和批量上傳類似，DownloadSession限制也是24小時，因為它也有臨時文件。同樣空閑鏈接120秒超時，另外還有Project級別并發限流，性能受碎片文件影響。

五、最佳實踐

如果并發很高，不推薦走批量接口，因為并發限流是project級別的，如果上傳或者下載的限額打滿，整個project的批量上傳都會失敗。

這種接口推薦把并發降下來，然后充分利用并發約10兆每秒的吞吐能力。流式因為架構上的原因，是不受并發限制的。QPS不建議批量上傳，因為碎片文件的問題，不建議用特別高的QPS來用批量的接口寫數據。 如果QPS和并發都不高，使用這三種方式都不會很受限制。

另外有幾個場景，transaction現在支持批量上傳，流式上傳后續會跟進。目前流式上傳不支持Insert Overwrite，可能后面也不一定會開發，因為這個場景明顯是一個批量的語義。

關于MaxCompute Tunnel 技術原理及開發實戰是怎樣的就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。