2019獨(dú)角獸企業(yè)重金招聘Python工程師標(biāo)準(zhǔn)>>>

摘要：?隨著MaxCompute（ODPS）2.0的上線，新增的非結(jié)構(gòu)化數(shù)據(jù)處理框架也推出一系列的介紹文章，包括 MaxCompute上如何訪問OSS數(shù)據(jù), 基本功能用法和整體介紹，側(cè)重介紹讀取OSS數(shù)據(jù)進(jìn)行計(jì)算處理； 本文：MaxCompute(ODPS)上處理非結(jié)構(gòu)化數(shù)據(jù)的Best Practice。

隨著MaxCompute（ODPS）2.0的上線，新增的非結(jié)構(gòu)化數(shù)據(jù)處理框架也推出一系列的介紹文章，包括

1、MaxCompute上如何訪問OSS數(shù)據(jù), 基本功能用法和整體介紹，側(cè)重介紹讀取OSS數(shù)據(jù)進(jìn)行計(jì)算處理；

2、MaxCompute上處理非結(jié)構(gòu)化數(shù)據(jù)的Best Practice。 基于非結(jié)構(gòu)化框架實(shí)現(xiàn)原理，提供一些最佳實(shí)踐總結(jié)；

3、MaxCompute訪問TableStore(OTS) 數(shù)據(jù), 著重介紹通過非結(jié)構(gòu)化框架來訪問計(jì)算KV（TableStore/OTS）數(shù)據(jù)；

4、MaxCompute到OSS的非結(jié)構(gòu)化數(shù)據(jù)輸出（及圖像處理實(shí)例）：介紹了非結(jié)構(gòu)化輸出功能，并通過圖像處理等范例，說明怎樣通過MaxCompute的計(jì)算能力，打通整個(gè)OSS -> MaxCompute -> OSS的數(shù)據(jù)處理閉環(huán)；

5、如何在MaxCompute上處理存儲(chǔ)在OSS上的開源格式數(shù)據(jù), 介紹對于存儲(chǔ)在OSS上的常見開源數(shù)據(jù)（ORC, PARQUET, AVRO等）格式，如何通過非結(jié)構(gòu)化框架進(jìn)行處理。

本文是這系列中的第【2】篇。

?前言

隨著MaxCompute（原ODPS）非結(jié)構(gòu)化數(shù)據(jù)處理框架的推出，在SQL線上打通了MaxCompute與OSS數(shù)據(jù)之間的計(jì)算數(shù)據(jù)連接生態(tài)，我們看到了視頻，圖像，音頻以及基因，氣象等各種各種各樣數(shù)據(jù)在MaxCompute平臺(tái)上實(shí)現(xiàn)了與傳統(tǒng)結(jié)構(gòu)化數(shù)據(jù)的無縫融合。之前我們提供了在MaxCompute非結(jié)構(gòu)化框架處理OSS上數(shù)據(jù)的整體介紹，在基本功能實(shí)現(xiàn)后，我們收到用戶許多關(guān)于優(yōu)化和怎樣最好的使用非結(jié)構(gòu)化功能的問題。 這里通過分析非結(jié)構(gòu)化框架底層的一些實(shí)現(xiàn)原理以及我們看到的一些使用場景，提供一些關(guān)于Best Practice的總結(jié)，方便大家更有效的在MaxCompute中處理各種數(shù)據(jù)。

1. 數(shù)據(jù)在OSS上的存儲(chǔ)

1.1 OSS LOCATION 的選擇

MaxCompute通過在EXTERNAL TABLE上的LOCATION cluase來指定需要處理的OSS數(shù)據(jù)地址【注：本文假設(shè)用戶對于非結(jié)構(gòu)化框架，包括EXTERNABLE TABLE， StorageHanlder等的定義等都有比較好的了解，相關(guān)細(xì)節(jié)這里不再具體說明。 有疑問可以先參考之前的基本功能介紹】。其中LOCATION將指向一個(gè)OSS的一個(gè)目錄（或者更準(zhǔn)確的說，是一個(gè)以‘/’結(jié)尾的地址），其中LOCATION為標(biāo)準(zhǔn)URI格式：

LOCATION 'oss://${endpoint}/${bucket}/${userPath}/'

?對于數(shù)據(jù)安全比較敏感的場景，比如在多用戶場景或者公共云上，則推薦采用上述方式，不再LOCATION上使用AK，而是通過STS/RAM體系事先進(jìn)行鑒權(quán)（參見基本功能介紹）。

LOCATION的選擇有幾點(diǎn)要注意：

• 不允許使用oss的root bucket作為LOCATION, 也就是說${userPath}不可以為空，這個(gè)要求源自O(shè)SS對root bucket下存放內(nèi)容的一些限制。
• LOCATION不能指向一個(gè)單獨(dú)文件，也就是說，類似oss://oss-cn-hangzhou.aliyuncs.com/mybucket/directory/data.csv?這種LOCATION是無效的。 如果只有一個(gè)文件要處理，則應(yīng)該提供該文件的父目錄。

1.2 數(shù)據(jù)文件的存儲(chǔ)和處理：小文件和大文件

在分布式計(jì)算系統(tǒng)中，文件的大小對于整個(gè)系統(tǒng)的運(yùn)行效率，性能等都有比較大的相關(guān)性。 這里對MaxCompute對非結(jié)構(gòu)化數(shù)據(jù)的相關(guān)處理機(jī)制做一個(gè)介紹，并分析幾種有代表性的場景（e.g., 小文件和大文件），總結(jié)了幾個(gè)針對MaxCompute計(jì)算場景中，比較好的OSS文件存儲(chǔ)建議。

• 小文件：通常小文件往往伴隨著超大的文件數(shù)目，這對于分布式計(jì)算系統(tǒng)來說，有兩個(gè)問題：

• 大的文件數(shù)，會(huì)導(dǎo)致在進(jìn)行文件分片時(shí), 獲取文件宏信息的overhead較大，導(dǎo)致planning和分片比較耗時(shí)，比如一個(gè)100萬個(gè)文件的oss LOCATION, planning的耗時(shí)可能在分鐘以上的量級。
• 打開每個(gè)OSS文件是有ovehead的，碎片化的小文件會(huì)帶來額外的讀取開銷。 比如從OSS讀取1000個(gè)10KB大小的文件，相比讀取一個(gè)10MB的的文件，耗時(shí)可能在10倍以上。 對大量小文件的訪問將帶來整個(gè)分布式系統(tǒng)更多的網(wǎng)絡(luò)開銷，降低實(shí)際上有效的IO throughput。

所以總體上不推薦在一個(gè)OSS目錄中存放過多的文件。 可以從另一個(gè)方面，考慮將Externable Table做partition，盡量在partition的子粒度上進(jìn)行數(shù)據(jù)處理。 另外，在適用的場景下，可以考慮使用tar文件，比如把多個(gè)圖像文件打在一個(gè)tar文件中再保存到OSS上面。 如果是文本文件，MaxCompute的built-in StorageHandler (比如com.aliyun.odps.CsvStorageHandler或者com.aliyun.odps.TsvStorageHandler) 是能自動(dòng)從tar文件中讀取數(shù)據(jù)的。 如果用戶自己定義的StorageHandler/Extractor，也可以在用戶代碼中使用Java中的tar處理類，比如直接使用Apache common 的TarArchiveInputStream來訪問。

• 大文件：與小文件相對的，是另外一個(gè)極端： 超大文件。 分布式系統(tǒng)的精髓是分而治之的思想：對數(shù)據(jù)進(jìn)行分片，通過并發(fā)處理多個(gè)分片來加快海量數(shù)據(jù)的處理。 在極限情況下，如果海量數(shù)據(jù)存在一個(gè)無法被切割處理的單個(gè)文件中，那并發(fā)度就被降成為1，這樣子的“分布式系統(tǒng)”就失去了意義。 即使沒有那么極端，多個(gè)超大文件（比如每個(gè)幾十GB），對分布式系統(tǒng)也是不友好的：大的文件處理可能需要單獨(dú)占用大量系統(tǒng)資源，給資源調(diào)度帶來困難，另外還容易造成長尾，失敗重跑代價(jià)過高等問題。 所以從MaxCompute處理計(jì)算的角度，也不推薦在OSS上使用超大文件保存數(shù)據(jù)。

總結(jié)一下， 作為一個(gè)整體上的指導(dǎo)原則，MaxCompute非結(jié)構(gòu)框架推薦如下比較理想的OSS數(shù)據(jù)存儲(chǔ)方案：

數(shù)據(jù)文件根據(jù)應(yīng)用特性，分文件夾存儲(chǔ)，不推薦一個(gè)文件夾中存儲(chǔ)10萬以上個(gè)文件。 可以考慮使用tar打包多個(gè)文件來作為降低物理文件數(shù)目的方法。

比較適中的文件大小以及均勻分布的數(shù)據(jù)文件，能更合理的使用各種系統(tǒng)資源， 從而提高分布式處理效率。 對MaxCompute非結(jié)構(gòu)化框架而言，單個(gè)文件大小在1MB-2GB是比較理想的情況。

1.3 MaxCompute訪問OSS的網(wǎng)絡(luò)連通以及速度

MaxComput和OSS作為獨(dú)立的分布式計(jì)算和存儲(chǔ)服務(wù)，在不同的部署集群上的網(wǎng)絡(luò)連通性有可能影響MaxCompute訪問OSS的數(shù)據(jù)的可達(dá)性。 網(wǎng)絡(luò)的連通性整體服從七網(wǎng)隔離的原則，具體一點(diǎn)來說有幾點(diǎn)：

MaxCompute的公共云集群上的計(jì)算應(yīng)該訪問OSS的外部集群，另外推薦需要訪問的OSS集群與MaxCompute計(jì)算集群在物理上盡量靠近。關(guān)于OSS公共云上的訪問域名以及對應(yīng)數(shù)據(jù)中心可以參考OSS文檔。

在MaxCompute并發(fā)訪問OSS的情況下，一個(gè)需要特別注意的是OSS具有限流機(jī)制，默認(rèn)情況下一個(gè)OSS賬號的訪問流量是限制在5Gb/s，也就是600MB/s左右。 在MaxComput的高并發(fā)度下（比如1000個(gè)以上的計(jì)算節(jié)點(diǎn)），OSS數(shù)據(jù)下載的速度可能將不再受限于單機(jī)網(wǎng)絡(luò)速度，而取決與OSS的總體流量限速。 在這種情況下，完全可能出現(xiàn)單個(gè)計(jì)算節(jié)點(diǎn)的下載速度低于1MB/s。 當(dāng)然OSS的限流是可以特別配置的，如果有超大量的數(shù)據(jù)計(jì)算需求，可以聯(lián)系OSS團(tuán)隊(duì)調(diào)高對應(yīng)賬戶的具體的限流上限。

2. 在用戶自定義StorageHandler/Extractor中對輸入數(shù)據(jù)的處理

除了提供幾個(gè)內(nèi)置的StorageHandler用來處理CSV, TSV以及Apache ORC文件以外，MaxCompute同時(shí)開發(fā)了非結(jié)構(gòu)化Java SDK來方便用戶對數(shù)據(jù)進(jìn)行解析和處理。 通過這樣的方法，擴(kuò)展整個(gè)非結(jié)構(gòu)化數(shù)據(jù)處理的生態(tài)，對接視頻，圖像，音頻，基因，氣象等數(shù)據(jù)處理的能力。 簡單的來說， MaxCompute封裝了分布式系統(tǒng)的細(xì)節(jié)，使用Java?InputStream?的一個(gè)增強(qiáng)子類來將做輸入數(shù)據(jù)與用戶代碼的對接。 這樣的接口設(shè)計(jì)區(qū)別于Hive的SerDe，?RowFormatter等多層封裝，提供了更自然的完全非結(jié)構(gòu)化數(shù)據(jù)入口， 用戶能獲得原始數(shù)據(jù)流，用類似單機(jī)程序相似的邏輯進(jìn)行處理。 當(dāng)然，基于分布式系統(tǒng)的處理原則，還是有一些Best Practice推薦用戶遵守。

2.1 輸入數(shù)據(jù)流的處理模式

對于輸入數(shù)據(jù)流（InputStream），推薦在獲取數(shù)據(jù)bytes后能直接在內(nèi)存中直接處理。?最理想的情況是，能針對輸入數(shù)據(jù)做流式的“邊讀邊計(jì)算”的處理。 當(dāng)然，對于某些數(shù)據(jù)格式，由于數(shù)據(jù)本身的特性，很難做到完全的流式處理：比如對于某些圖片/音頻數(shù)據(jù)格式，一張文件必須完全讀入才能獲得正確的編碼信息以及其他特性，那這種情況下，在文件本身不是很大的情況下，可以把文件完全讀入本地內(nèi)存，再行處理。 效率比較低的一種方式是把數(shù)據(jù)文件下載到本地，然后再通過FileStream讀取本地文件進(jìn)行處理，這樣的處理模式有兩個(gè)問題：

作為分布式系統(tǒng)，為了實(shí)現(xiàn)資源隔離和保護(hù)計(jì)算節(jié)點(diǎn)的健康度，一般不推薦往本地磁盤寫文件（尤其是大文件）。在MaxCompue計(jì)算系統(tǒng)上，用戶的Java代碼對本地文件近些讀寫操作需要另外申請權(quán)限，或者打開隔離選項(xiàng)（總體計(jì)算性能會(huì)下降）。

數(shù)據(jù)寫入到本地落盤，再讀取，性能上有額外的損耗。

對于比較大的數(shù)據(jù)（比如10GB或更大的文件），運(yùn)算節(jié)點(diǎn)的磁盤空間無法做保證，存在磁盤被寫爆的可能

2.2 三方庫使用

在非結(jié)構(gòu)化數(shù)據(jù)的處理線上，經(jīng)常遇到的一個(gè)需求是把單機(jī)的數(shù)據(jù)處理機(jī)制，通過MaxCompute非結(jié)構(gòu)化數(shù)據(jù)框架，遷移到分布式系統(tǒng)上執(zhí)行。 比如希望同過ffmpeg來直接讀取視頻數(shù)據(jù)，或者希望通過Netcdf-Java來直接處理氣象的netcdf/grib格式數(shù)據(jù)。 而這些三方庫往往有一些共同的特性/局限性，比如

• 可能是基于C/C++，所以需要通過JNI來運(yùn)行native代碼
• 可能是面對單機(jī)實(shí)現(xiàn)，所以數(shù)據(jù)的入口經(jīng)常是一個(gè)本地的文件地址

在這些情況下，非結(jié)構(gòu)化框架均有對應(yīng)的方式來支持。 比如在隔離打開的情況下允許JNI的使用，以及通過權(quán)限審批允許數(shù)據(jù)下載到本機(jī)臨時(shí)文件等等。 從長期來講，MaxCompute框架本身也認(rèn)同使用native C/C++代碼庫，來處理各種特定的數(shù)據(jù)格式，將是無法避免的，所以會(huì)從框架本身安全等方面來解決這個(gè)問題，但是對于讀取數(shù)據(jù)到本地再做處理，從本質(zhì)上是一種比較大的額外消耗，還是推薦通過直接處理輸入數(shù)據(jù)的方式來做，比如改動(dòng)NETCDF-JAVA的實(shí)現(xiàn)，把輸入接口通過FilePath->FileStream改成直接使用InputStream等。

3. 結(jié)語

MaxCompute非結(jié)構(gòu)化框架是隨著MaxCompute2.0推出的新功能，除了處理OSS上面的非結(jié)構(gòu)化數(shù)據(jù)之外，最近也打通了與TableStore(OTS)的數(shù)據(jù)鏈路。 框架本身也還在不斷的發(fā)展和完善，包括和MaxCompute優(yōu)化器以及和整個(gè)UDF框架更緊密的結(jié)合和擴(kuò)展等等。 在這里先從現(xiàn)有系統(tǒng)的實(shí)現(xiàn)和我們收到的一些反饋，總結(jié)提煉了一些處理非結(jié)構(gòu)化數(shù)據(jù)的最佳實(shí)踐，也希望得到更多的反饋，把框架功能做到更優(yōu)。 后繼我們也會(huì)結(jié)合具體的使用場景，比如城市大腦上的離線視頻圖像處理等，來提供一些更具體的使用范例。

原文鏈接

轉(zhuǎn)載于:https://my.oschina.net/u/3735980/blog/1812730

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的MaxCompute(ODPS)上处理非结构化数据的Best Practice的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。