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

在羅定等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供網(wǎng)站設(shè)計(jì)制作、成都網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作按需制作,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),成都品牌網(wǎng)站建設(shè),全網(wǎng)營銷推廣,外貿(mào)營銷網(wǎng)站建設(shè),羅定網(wǎng)站建設(shè)費(fèi)用合理。

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

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

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

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

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

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

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

官方的SDK有Java SDK和Python SDK。

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

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

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

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

三、Tunnel功能簡介

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

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

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

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

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

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

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

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

四、SDK的使用方式

1）基本配置

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

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

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

Tunnel Endpoint是可選的，如果不填，系統(tǒng)會通過所填的ODPS endpoint自動路由到對應(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，也許會有路由的endpoint網(wǎng)絡(luò)不通這種場景，這個時候平臺提供了一個接口，用戶可以把能訪問的Tunnel endpoint填進(jìn)來，這樣就會優(yōu)先用所填的Tunnel endpoint而不會用路由的，但99%的情況下是不用填。

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

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

2）具體的上傳接口

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

【批量上傳】

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

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

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

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

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

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

支持insertOverwrite, 也支持InsertInto語義。

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

這個功能也有使用限制。

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

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

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

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

【流式上傳】

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

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

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

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

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

【批量下載】

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

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

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

五、最佳實(shí)踐

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

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

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

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

新聞名稱：MaxComputeTunnel技術(shù)原理及開發(fā)實(shí)戰(zhàn)是怎樣的
文章路徑：http://aaarwkj.com/article20/pjcojo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供靜態(tài)網(wǎng)站、外貿(mào)建站、云服務(wù)器、網(wǎng)站策劃、域名注冊、網(wǎng)站維護(hù)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)