本篇主要透過五個部分介紹MaxCompute Tunnel

MaxCompute Tunnel技術原理MaxCompute Tunnel豐富的生態 Tunnel功能簡介 SDK的使用方式最佳實踐一、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，可能後面也不一定會開發，因為這個場景明顯是一個批次的語義。