MaxCompute Tunnel 技術(shù)原理及開(kāi)發(fā)實(shí)戰(zhàn)是怎樣的

這篇文章給大家介紹MaxCompute Tunnel 技術(shù)原理及開(kāi)發(fā)實(shí)戰(zhàn)是怎樣的，內(nèi)容非常詳細(xì)，感興趣的小伙伴們可以參考借鑒，希望對(duì)大家能有所幫助。

一、MaxCompute Tunnel技術(shù)原理

上圖是架構(gòu)圖，可以看到對(duì)外的服務(wù)提供了一個(gè)統(tǒng)一的SDK，然后集成到所有的外部服務(wù)里。在服務(wù)端，提供的服務(wù)可以大概分為API層和執(zhí)行層。API層有兩個(gè)集群 Frontend集群會(huì)負(fù)責(zé)控制流的介入，Tunnel集群負(fù)責(zé)數(shù)據(jù)。在執(zhí)行層分為控制集群和計(jì)算集群，控制集群會(huì)負(fù)責(zé)資源管控，meta的管理，和權(quán)限管理這些功能，計(jì)算集群就負(fù)責(zé)實(shí)際的計(jì)算和存儲(chǔ)。

可以看到，Tunnel是屬于API層的一個(gè)組件，專(zhuān)門(mén)負(fù)責(zé)數(shù)據(jù)的上傳和下載。為什么這么做, 是因?yàn)檫@是一個(gè)大數(shù)據(jù)的系統(tǒng)，所以在MaxCompute上跑一個(gè)SQL其實(shí)就發(fā)了一條控制指令。由于目標(biāo)的場(chǎng)景是一個(gè)大數(shù)據(jù)量的查詢(xún)，比如說(shuō)十億條這種量級(jí)的，這是一個(gè)規(guī)模比較大的操作，如果在這個(gè)場(chǎng)景下想做數(shù)據(jù)的同步，就不能像MySQL傳統(tǒng)輸入一樣通過(guò)insert into，因?yàn)閕nsert into走控制集群這個(gè)鏈路是非常浪費(fèi)資源的，同時(shí)也會(huì)有一些限制。一次一行的效率特別低，因此設(shè)計(jì)了分開(kāi)的控制流和數(shù)據(jù)流。

Tunnel集群負(fù)責(zé)的功能是在SDK層提供了Tunnel的API，讓用戶(hù)可以通過(guò)一個(gè)結(jié)構(gòu)化的方式去訪(fǎng)問(wèn)數(shù)據(jù)。另外，Tunnel是對(duì)外放出來(lái)的唯一的數(shù)據(jù)接口，會(huì)對(duì)用戶(hù)寫(xiě)進(jìn)來(lái)的數(shù)據(jù)做格式檢查和權(quán)限校驗(yàn)，控制數(shù)據(jù)安全。同時(shí)會(huì)保證用戶(hù)通過(guò)Tunnel寫(xiě)出來(lái)的數(shù)據(jù)用SQL可讀，不用擔(dān)心比如SQL讀不了寫(xiě)進(jìn)來(lái)的數(shù)據(jù)，或者寫(xiě)的數(shù)據(jù)和SQL讀出來(lái)的值有差異。

另外一點(diǎn)，Tunnel是直接訪(fǎng)問(wèn)存儲(chǔ)層的，MaxCompute在底層的存儲(chǔ)是一個(gè)分布式文件系統(tǒng)，Tunnel是直接訪(fǎng)問(wèn)這個(gè)文件系統(tǒng)的，這樣在性能上就有了保證。也就是說(shuō)，Tunnel在理想情況下是可以保證單并發(fā)達(dá)到10兆每秒的吞吐能力，通過(guò)假并發(fā)也是可以水平擴(kuò)展整個(gè)吞吐能力。

二、MaxCompute Tunnel豐富的生態(tài)

MaxCompute有非常豐富的生態(tài)，推薦首先要看一下有什么工具，或者有哪些服務(wù)可以做，建議優(yōu)先使用一些成熟的服務(wù)，盡量不要自己先寫(xiě)代碼。

官方的SDK有Java SDK和Python SDK。

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

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

流計(jì)算方面，Blink，Spark也都是有MaxCompute同步插件的。數(shù)據(jù)同步服務(wù)方面，DataWorks的數(shù)據(jù)同步，實(shí)時(shí)同步和離線(xiàn)同步，都是支持MaxCompute同步的。

總結(jié)一下，如果有數(shù)據(jù)同步的需求，最好先看一下現(xiàn)有的服務(wù)是不是可以滿(mǎn)足需求。如果覺(jué)得都滿(mǎn)足不了，想要自己開(kāi)發(fā)的話(huà)，可以看一下SDK是可以有哪些功能，和使用上的一些注意事項(xiàng)。

三、Tunnel功能簡(jiǎn)介

上圖是Tunnel總體功能的表格?，F(xiàn)在有兩套API，分批量數(shù)據(jù)通道和流式數(shù)據(jù)通道。

批量數(shù)據(jù)通道目標(biāo)的場(chǎng)景單并發(fā)的吞吐量很大，這種理想的場(chǎng)景是傳量大的數(shù)據(jù)，一次一批，QPS和并發(fā)都不能特別高，但是單并發(fā)的吞吐量可以做得很大，這個(gè)在API上也有一些優(yōu)化。

流式數(shù)據(jù)通道是新提供的一種服務(wù)，因?yàn)楝F(xiàn)在的上游服務(wù)大多數(shù)都是一些流式服務(wù)灌進(jìn)來(lái)的，也就是說(shuō)單并發(fā)可能流量沒(méi)有那么大，但是都是比較細(xì)碎的數(shù)據(jù)，這種情況如果用批量數(shù)據(jù)通道會(huì)遇到很多限制。最明顯的就是小文件問(wèn)題，用批量數(shù)據(jù)通道寫(xiě)特別碎的數(shù)據(jù)進(jìn)來(lái)會(huì)產(chǎn)生大量的碎片文件，跑SQL查詢(xún)就會(huì)非常慢，用Tunnel下載也會(huì)非常慢。針對(duì)這種場(chǎng)景平臺(tái)提供了流式數(shù)據(jù)通道服務(wù)，通過(guò)流式數(shù)據(jù)上來(lái)可以寫(xiě)得特別碎，一行寫(xiě)一次也可以，不需要擔(dān)心小文件的問(wèn)題，也不用擔(dān)心并發(fā)的問(wèn)題，并發(fā)可以無(wú)限多。流式數(shù)據(jù)通道是不限并發(fā)的，但是批量是限并發(fā)的。

從表格中可以看到，通過(guò)Tunnel是可以訪(fǎng)問(wèn)這幾種資源的：普通表，Hash Clustered表，Range Clustered表和Transactional表，最后是查詢(xún)結(jié)果，這些都是可以下載的；普通表兩種上傳都支持；Hash Clustered表和Range Clustered表并不適合Tunnel去寫(xiě)，因?yàn)閿?shù)據(jù)在存儲(chǔ)上需要做一個(gè)系統(tǒng)，而且會(huì)排序，而Tunnel集群規(guī)模沒(méi)有計(jì)算機(jī)集群那么大，沒(méi)有這個(gè)能力去做排序。因此，這種表一般經(jīng)典的用法就是先寫(xiě)一張普通表，然后通過(guò)SQL做一個(gè)insert overwrite，生成一張Hash Clustered表或者Range Clustered表。

流式上傳在架構(gòu)上做了升級(jí)，有一個(gè)異步處理的機(jī)制，會(huì)把用戶(hù)寫(xiě)進(jìn)來(lái)的數(shù)據(jù)在后臺(tái)進(jìn)行加工，所以后面會(huì)支持Hash Clustered表。

Transactional表是說(shuō)，MaxCompute的普通表是不支持update或者delete的，系統(tǒng)最近在SQL上支持了這個(gè)語(yǔ)法，就是用戶(hù)可以u(píng)pdate，也可以delete，也可以支持transaction。批量上傳的API現(xiàn)在是支持Transactional表，但是只支持append，也稱(chēng)為insert into，它是不能從Tunnel的API上去update的。流式的也正在規(guī)劃中，后續(xù)可能會(huì)連update也一起完成。批量的可能不會(huì)做update這個(gè)功能，但是批量的現(xiàn)在就可以append這種Transactional表。

查詢(xún)結(jié)果就是說(shuō)，如果跑一個(gè)SQL，在odpscmd客戶(hù)端或者DataWorks上對(duì)查詢(xún)結(jié)果有1萬(wàn)條的限制。但是這個(gè)查詢(xún)結(jié)果可以通過(guò)Tunnel下載，就不受條數(shù)限制，可以下載完整的查詢(xún)結(jié)果到本地。

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

四、SDK的使用方式

1）基本配置

如果想開(kāi)發(fā)的話(huà)有哪些東西需要配置，不管上傳、下載，還是流式上傳，這些配置都是一樣的。首先需要?jiǎng)?chuàng)建一個(gè)ODPS對(duì)象和一個(gè)Table Tunnel對(duì)象。如果想用SDK跑SQL，要?jiǎng)?chuàng)建ODPS；TableTunnel是Tunnel入口的一個(gè)類(lèi)，所有的功能都是從這個(gè)類(lèi)發(fā)起的。

然后看具體的配置項(xiàng)，圖中左側(cè)列舉的是比較關(guān)鍵的幾個(gè)。Access ID和Access Key就是賬號(hào)信息，阿里云通過(guò)這個(gè)來(lái)表示一個(gè)賬號(hào)。

ODPS Endpoint是服務(wù)的一個(gè)入口，現(xiàn)在在公共云上應(yīng)該有21個(gè)region，包括金融云和政務(wù)云，中國(guó)有7個(gè)，海外有14個(gè)。每個(gè)region的endpoint是不一樣的，使用時(shí)需要找到自己購(gòu)買(mǎi)的region服務(wù)，并正確填寫(xiě)endpoint進(jìn)去。

Tunnel Endpoint是可選的，如果不填，系統(tǒng)會(huì)通過(guò)所填的ODPS endpoint自動(dòng)路由到對(duì)應(yīng)的Tunnel endpoint上。在公共云上的網(wǎng)絡(luò)環(huán)境比較復(fù)雜，分公網(wǎng)域名和內(nèi)網(wǎng)域名，內(nèi)網(wǎng)域名還分經(jīng)典網(wǎng)絡(luò)和VBC，也許會(huì)有路由的endpoint網(wǎng)絡(luò)不通這種場(chǎng)景，這個(gè)時(shí)候平臺(tái)提供了一個(gè)接口，用戶(hù)可以把能訪(fǎng)問(wèn)的Tunnel endpoint填進(jìn)來(lái)，這樣就會(huì)優(yōu)先用所填的Tunnel endpoint而不會(huì)用路由的，但99%的情況下是不用填。

Default project這個(gè)參數(shù)是在彈內(nèi)經(jīng)常用的。 MaxCompute的權(quán)限管理非常豐富，比如如果在公共云上有多個(gè)project，想要控制數(shù)據(jù)在跨project流動(dòng)的話(huà)，就可以通過(guò)這個(gè)參數(shù)來(lái)配置。ODPS里設(shè)置的Default Project可以理解為是原project，下面的create Stream Session里面又有一個(gè)project，即要訪(fǎng)問(wèn)數(shù)據(jù)所在的project。如果這兩個(gè)project不一樣，系統(tǒng)會(huì)檢查這個(gè)權(quán)限，用戶(hù)是否可以訪(fǎng)問(wèn)目標(biāo)project的數(shù)據(jù)。如果跑SQL，它也會(huì)根據(jù)原project來(lái)控制資源的使用。如果只有一個(gè)，這兩個(gè)填成一樣的就可以。

一般來(lái)說(shuō)，Access ID，Access Key, 和ODPS Endpoint是必選的，Tunnel Endpoint可選，Default project如果只有一個(gè)只填一個(gè)就行了。

2）具體的上傳接口

接下來(lái)展示具體的上傳接口。首先看批量上傳。

【批量上傳】

上圖中可以看到，批量上傳的流程是先創(chuàng)建一個(gè)upload session (第31行),然后open writer，用writer去寫(xiě)數(shù)據(jù)，然后close，再u(mài)pload session加commit。

Upload session可以理解為是一個(gè)會(huì)話(huà)的對(duì)象，類(lèi)似于transaction的概念。這次上傳是以u(píng)pload session為單位的，即最終upload session commit成功了這些數(shù)據(jù)才是可見(jiàn)的。在一個(gè)upload session內(nèi)部可以open多個(gè)writer，并且多個(gè)writer可以并發(fā)上傳，但是writer是有狀態(tài)的，需要給它指定一個(gè)不重復(fù)的block ID，避免產(chǎn)生覆蓋。Upload session也是有狀態(tài)的，沒(méi)有commit就不可見(jiàn)； 如果commit成功了，這個(gè)session就結(jié)束了，暫時(shí)就不能再去open writer。Writer的實(shí)現(xiàn)原理是open一個(gè)writer請(qǐng)求，系統(tǒng)會(huì)發(fā)一個(gè)HTP請(qǐng)求到服務(wù)端，然后保持這個(gè)長(zhǎng)鏈接，寫(xiě)數(shù)據(jù)時(shí)平臺(tái)會(huì)實(shí)時(shí)地把數(shù)據(jù)寫(xiě)到服務(wù)端，writer是寫(xiě)一個(gè)臨時(shí)目錄。根據(jù)這個(gè)機(jī)制可以看到，如果writer或者close失敗了，就相當(dāng)于這個(gè)長(zhǎng)連接斷了。所以writer和close這兩個(gè)接口是不能重試的，如果writer中間有任何階段失敗了，就需要重新寫(xiě)。

除了正常的commit之外，MaxCompute還支持讓用戶(hù)檢查數(shù)據(jù)正確性。比如用戶(hù)open了五個(gè)writer，commit的時(shí)候可以把這五個(gè)ID當(dāng)成例子上傳確認(rèn)。如果檢查到服務(wù)端與這個(gè)例子不一致，commit就會(huì)報(bào)錯(cuò)。

總結(jié)一下，基本的功能點(diǎn)有：

批量上傳是有狀態(tài)并發(fā)；

commit成功后數(shù)據(jù)才可見(jiàn)；

支持insertOverwrite, 也支持InsertInto語(yǔ)義。

Insert overwrite指commit的時(shí)候支持使用某個(gè)upload session的數(shù)據(jù)直接overwrite掉一整個(gè)分區(qū)或者一張表，類(lèi)似SQL的Insert和Overwrite的功能。

這個(gè)功能也有使用限制。

第一，一個(gè)upload session不能超過(guò)2萬(wàn)個(gè)Block。

第二，Block ID會(huì)導(dǎo)致數(shù)據(jù)覆蓋。

第三，upload session 24小時(shí)過(guò)期，因?yàn)閣riter數(shù)據(jù)是寫(xiě)在存儲(chǔ)的臨時(shí)目錄的，臨時(shí)數(shù)據(jù)有回收周期，超過(guò)24小時(shí)， writer寫(xiě)過(guò)的數(shù)據(jù)就有可能被回收掉，這個(gè)就限制了upload session的生命周期。

第四，如果open了一個(gè)writer但是不寫(xiě)數(shù)據(jù)，就相當(dāng)于占了一個(gè)空閑鏈接，服務(wù)端會(huì)把這個(gè)鏈接直接斷掉。

【流式上傳】

接下來(lái)看一下流式上傳的接口。前文中有提到，流式上傳是在API上做了簡(jiǎn)化，還去掉了并發(fā)的限制和時(shí)間的限制。

圖中可以看到，接口是CreateStreamUploadSession，寫(xiě)數(shù)據(jù)的從writer改成了RecordPack。所謂的pack其實(shí)相當(dāng)于一個(gè)內(nèi)存里的buffer，可以用pack.append(record)，比如判斷size只需要判斷這個(gè)buffer足夠大或者條數(shù)足夠多，然后再flush就可以了（42到44行）。Pack并不是寫(xiě)網(wǎng)絡(luò)的，而是寫(xiě)內(nèi)存的。因此，不同于writer，flush是可以重試的，因?yàn)閿?shù)據(jù)都在內(nèi)存里。并且Pack也沒(méi)有狀態(tài)，不需要關(guān)心writer的Block ID等等。另外，因?yàn)閒lush成功后數(shù)據(jù)就可見(jiàn)了，所以session也沒(méi)有commit這種狀態(tài)。因此，如果要開(kāi)發(fā)分布式服務(wù)，這個(gè)相比批量上傳就簡(jiǎn)化很多，沒(méi)有太多的限制，只需要確保本機(jī)內(nèi)存是否夠大就好了。

同時(shí)系統(tǒng)還支持了內(nèi)存的復(fù)用，即flush過(guò)以后的pack是可以復(fù)用的。系統(tǒng)會(huì)把上次寫(xiě)滿(mǎn)的內(nèi)存留住，避免產(chǎn)生GC。流式上傳只支持InsertInto，因?yàn)樵贏PI上沒(méi)有另外的接口，所以InsertOverwrite語(yǔ)義現(xiàn)在是不支持的。另外，流式服務(wù)是支持異步數(shù)據(jù)處理的，也就是除了保證用戶(hù)通過(guò)流式寫(xiě)上來(lái)的數(shù)據(jù)可讀之外，服務(wù)端還有一個(gè)機(jī)制能識(shí)別出來(lái)新寫(xiě)進(jìn)來(lái)的數(shù)據(jù)和存量數(shù)據(jù)，可以對(duì)新寫(xiě)出來(lái)的數(shù)據(jù)做一些異步的處理，比如zorder by排序和墨紙。

ZorderBy排序是指一種數(shù)據(jù)的組織方式，可以把存在MaxCompute的數(shù)據(jù)按某些規(guī)則重新組織一遍，這樣查詢(xún)的時(shí)候效率會(huì)非常高。墨紙是指支持把數(shù)據(jù)在后端重新寫(xiě)一遍，把一些很碎的數(shù)據(jù)重新組織成存儲(chǔ)數(shù)據(jù)存儲(chǔ)效率較高的數(shù)據(jù)文件。在這個(gè)基礎(chǔ)上還可以做一些排序和其他的處理，后續(xù)會(huì)再加更多的功能。

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

【批量下載】

接下來(lái)介紹批量下載的接口。

圖中可以看到，TableTunnel創(chuàng)建了一個(gè)叫downloadSession的對(duì)象?？梢缘玫絩ecord Count，指一個(gè)分區(qū)或者一張表的總行數(shù)。下面是open reader，可以和批量上傳對(duì)應(yīng)起來(lái): reader和writer; uploadSession和downloadSession。Openreader是按record來(lái)區(qū)分的，比如有1000行，可以分十個(gè)100行并發(fā)下載。Download支持列裁剪，也就是可以下載其中幾列。下載查詢(xún)結(jié)果就把TableTunnel入口類(lèi)改成InstanceTunnel，odps也是一樣，53行就不是project, table了，是一個(gè)InstanceID。

使用限制方面，和批量上傳類(lèi)似，DownloadSession限制也是24小時(shí)，因?yàn)樗灿信R時(shí)文件。同樣空閑鏈接120秒超時(shí)，另外還有Project級(jí)別并發(fā)限流，性能受碎片文件影響。

五、最佳實(shí)踐

如果并發(fā)很高，不推薦走批量接口，因?yàn)椴l(fā)限流是project級(jí)別的，如果上傳或者下載的限額打滿(mǎn)，整個(gè)project的批量上傳都會(huì)失敗。

這種接口推薦把并發(fā)降下來(lái)，然后充分利用并發(fā)約10兆每秒的吞吐能力。流式因?yàn)榧軜?gòu)上的原因，是不受并發(fā)限制的。QPS不建議批量上傳，因?yàn)樗槠募膯?wèn)題，不建議用特別高的QPS來(lái)用批量的接口寫(xiě)數(shù)據(jù)。 如果QPS和并發(fā)都不高，使用這三種方式都不會(huì)很受限制。

另外有幾個(gè)場(chǎng)景，transaction現(xiàn)在支持批量上傳，流式上傳后續(xù)會(huì)跟進(jìn)。目前流式上傳不支持Insert Overwrite，可能后面也不一定會(huì)開(kāi)發(fā)，因?yàn)檫@個(gè)場(chǎng)景明顯是一個(gè)批量的語(yǔ)義。

關(guān)于MaxCompute Tunnel 技術(shù)原理及開(kāi)發(fā)實(shí)戰(zhàn)是怎樣的就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，可以學(xué)到更多知識(shí)。如果覺(jué)得文章不錯(cuò)，可以把它分享出去讓更多的人看到。