1背景

用戶本地有一份txt或者csv文件，無論是從業(yè)務(wù)數(shù)據(jù)庫導(dǎo)出、還是其他途徑獲取，當(dāng)需要使用螞蟻的大數(shù)據(jù)分析工具進(jìn)行數(shù)據(jù)加工、挖掘和共創(chuàng)應(yīng)用的時(shí)候，首先要將本地文件上傳至ODPS，普通的小文件通過瀏覽器上傳至服務(wù)器，做一層中轉(zhuǎn)便可以實(shí)現(xiàn)，但當(dāng)這份文件非常大到了10GB級(jí)別，我們就需要思考另一種形式的技術(shù)方案了，也就是本文要闡述的方案。

技術(shù)要求主要有以下幾方面：

支持超大數(shù)據(jù)量、10G級(jí)別以上

穩(wěn)定性：除網(wǎng)絡(luò)異常情況100%成功

準(zhǔn)確性：數(shù)據(jù)無丟失，讀寫準(zhǔn)確性100%

效率：1G文件分鐘級(jí)、10G文件小時(shí)級(jí)

體驗(yàn)：實(shí)時(shí)進(jìn)度感知、網(wǎng)絡(luò)異常斷點(diǎn)續(xù)傳、定制字符特殊處理

2文件上傳選型

文件上傳至ODPS基本思路是先文件上傳至某中轉(zhuǎn)區(qū)域存儲(chǔ)，然后同步至ODPS，根據(jù)存儲(chǔ)介質(zhì)可以分為兩類，一類是應(yīng)用服務(wù)器磁盤，另一類類是中間介質(zhì)，OSS作為阿里云推薦的海量、安全低成本云存儲(chǔ)服務(wù)，并且有豐富的API支持，成為中間介質(zhì)的首選。而文件上傳至OSS又分為web直傳和sdk上傳兩種方案，因此上傳方案有如下三種，詳細(xì)優(yōu)缺點(diǎn)對比如下：

螞蟻的文本上傳功能演進(jìn)過程中對第一種、第二種方案均有實(shí)踐，缺點(diǎn)比較明顯，如上表所述，不滿足業(yè)務(wù)需求，因此大文件上傳終極方案是方案三。

3整體方案

以下是方案三的整體過程示意圖。

請求步驟如下：

用戶向應(yīng)用服務(wù)器取到上傳policy和回調(diào)設(shè)置。

應(yīng)用服務(wù)器返回上傳policy和回調(diào)。

用戶直接向OSS發(fā)送文件上傳請求。
等文件數(shù)據(jù)上傳完，OSS給用戶Response前，OSS會(huì)根據(jù)用戶的回調(diào)設(shè)置，請求用戶的服務(wù)器。如果應(yīng)用服務(wù)器返回成功，那么就返回用戶成功，如果應(yīng)用服務(wù)器返回失敗，那么OSS也返回給用戶失敗。這樣確保了用戶上傳成功，應(yīng)用服務(wù)器已經(jīng)收到通知了。

應(yīng)用服務(wù)器給OSS返回。

OSS將應(yīng)用服務(wù)器返回的內(nèi)容返回給用戶。

啟動(dòng)后臺(tái)同步引擎執(zhí)行oss到odps的數(shù)據(jù)同步。

同步實(shí)時(shí)進(jìn)度返回返回給應(yīng)用服務(wù)器，同時(shí)展示給用戶。

4技術(shù)方案

4.1上傳

OSS提供了豐富的SDK，有簡單上傳、表單上傳、斷點(diǎn)續(xù)傳等等，對于超大文件提供的上傳功能建議采用斷點(diǎn)續(xù)傳方式，優(yōu)點(diǎn)是可以對大文件并行分片上傳，利用OSS的并行處理能力，中間暫停也可以從當(dāng)前位置繼續(xù)上傳，網(wǎng)絡(luò)環(huán)境影響可以降到最低。

4.2下載

OSS文件下載同樣也有多種方式，普通下載、流式下載、斷點(diǎn)續(xù)傳下載、范圍下載等等，若直接下載到本地同樣建議斷點(diǎn)續(xù)傳下載，但我們的需求并不僅僅是下載文件本地存儲(chǔ)，而是讀取文件做數(shù)據(jù)從OSS到ODPS的同步，因此不做中間存儲(chǔ)，直接邊讀變寫，一方面采用OSS流式讀取，一方面ODPS tunnel上傳，用多線程讀寫方式提高同步速率。

4.3兩階段數(shù)據(jù)轉(zhuǎn)移

文件從本地到ODPS可以分為兩個(gè)階段，第一階段前端分片斷點(diǎn)續(xù)傳將本地文件上傳至OSS，第二階段后端流式讀寫將數(shù)據(jù)從OSS同步至ODPS，如下圖所示：

涉及技術(shù)點(diǎn)：

4.3.1前端，js sdk帶STS token 安全上傳

在需要上傳的文件較大時(shí)，可以通過multipartUpload接口進(jìn)行分片上傳。分片上傳的好處是將一個(gè)大請求分成多個(gè)小請求來執(zhí)行，這樣當(dāng)其中一些請求失敗后，不需要重新上傳整個(gè)文件，而只需要上傳失敗的分片就可以了。一般對于大于100MB的文件，建議采用分片上傳的方法，每次進(jìn)行分片上傳都建議重新new一個(gè)新的OSS實(shí)例。

阿里云分片上傳流程主要會(huì)調(diào)用3個(gè)api，包含

InitiateMultipartUpload, 分片任務(wù)初始化接口。

UploadPart,單獨(dú)的分片上傳接口。

CompleteMultipartUpload, 分片上傳完成后任務(wù)完成接口

臨時(shí)訪問憑證是通過阿里云Security Token Service(STS)來實(shí)現(xiàn)授權(quán)的一種方式。其實(shí)現(xiàn)請參見STS Java SDK。臨時(shí)訪問憑證的流程如下：

客戶端向服務(wù)器端發(fā)起獲得授權(quán)的請求。服務(wù)器端先驗(yàn)證客戶端的合法性。如果是合法客戶端，那么服務(wù)器端會(huì)使用自己的AccessKey來向STS發(fā)起一個(gè)請求授權(quán)的請求，具體可以參考訪問控制。

服務(wù)器端獲取臨時(shí)憑證之后返回給客戶端。

客戶端使用獲取的臨時(shí)憑證來發(fā)起向OSS的上傳請求，更詳細(xì)的請求構(gòu)造可以參考臨時(shí)授權(quán)訪問?？蛻舳丝梢跃彺嬖搼{證用來上傳，直到憑證失效再向服務(wù)器端請求新的憑證。

4.3.2后端，多線程流式讀寫

OSS端：如果要下載的文件太大，或者一次性下載耗時(shí)太長，可以多線程流式下載，一次處理部分內(nèi)容，直到完成文件的下載。
ODPS端：tunnel sdk對OSS流式數(shù)據(jù)直接寫入，一次完整的數(shù)據(jù)寫入流程通常包括以下步驟：
先對數(shù)據(jù)進(jìn)行劃分;

為每個(gè)數(shù)據(jù)塊指定 block id，即調(diào)用 openRecordWriter(id);

然后用一個(gè)或多個(gè)線程分別將這些 block 上傳上去, 并在某個(gè) block 上傳失敗以后，需要對整個(gè) block 進(jìn)行重傳;

在所有 block 都上傳以后，向服務(wù)端提供上傳成功的 blockid list 進(jìn)行校驗(yàn)，即調(diào)用 session.commit([1,2,3,…])
而由于服務(wù)端對block管理，連接超時(shí)等的一些限制，上傳過程邏輯變得比較復(fù)雜，為了簡化上傳過程，SDK提供了更高級(jí)的一種RecordWriter——TunnelBufferWriter。

5總結(jié)

實(shí)測結(jié)果顯示，本文的上傳方案實(shí)現(xiàn)了第一節(jié)提出的幾點(diǎn)技術(shù)要求，如下：

支持超大數(shù)據(jù)量、10G級(jí)別以上沒有任何壓力，主要是前端在分片上傳設(shè)置好分片限額即可（最大10000片，每片最大100G），目前設(shè)置每片1M滿足10G需求。

穩(wěn)定性：實(shí)測觀察網(wǎng)絡(luò)異常情況較少，文件內(nèi)容正常情況下100%成功。

準(zhǔn)確性：實(shí)測數(shù)據(jù)無丟失，讀寫準(zhǔn)確性100%。

效率：辦公網(wǎng)帶寬1.5M/s的情況下1G文件分鐘級(jí)、10G文件小時(shí)級(jí)，實(shí)際速度視用戶端的當(dāng)前網(wǎng)絡(luò)帶寬變化。

體驗(yàn)：實(shí)時(shí)進(jìn)度感知、網(wǎng)絡(luò)異常斷點(diǎn)續(xù)傳、定制字符特殊處理等高級(jí)功能可以提升用戶體驗(yàn)。

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評論