天天看點

存儲與計算分離:OSS建構表 + 計算引擎對接

看到标題,可能有使用者要問:oss不是用來存圖檔、視訊、及檔案的嗎,還可以在上面建表、數倉?計算效率和經濟性表現怎麼樣?

本文先給出基本結論:

oss是什麼?

基于oss是否可以建立資料表?

既然可以把攝像頭推流接到oss,建表屬于小case了。并且2016年在亦龍大神的幫助下,hadoop社群在官方版本中支援oss,開啟了阿裡雲存儲與開源融合的新裡程碑。

oss上建表是否易用?

今天為了降低oss上建表的門檻,日志服務(原sls)loghub可以支援oss上表的實時寫入(表類型包括textfile,列存儲parquet),支援壓縮及資料partition配置。在計算引擎端,我們已經和阿裡雲(maxcompute、e-mapreduce)和主流開源計算引擎(presto等)打通,無縫使用多種計算引擎熱插拔對接。

既然可以把資料表直接建在hdfs、maxcompute(原odps)上,選擇oss來存儲表資料又是為什麼呢?

在2009年做大規模計算的核心詞是“locality”:讓計算盡量靠近資料以提升效率。當時一個公認的模型是:建構一個足夠大的資源池,把資料和計算融合在裡面發揮規模效應。

但最近幾年以來,生态和環境都悄然發生了一些變化:

計算模式:全量資料計算模式,逐漸被impala、presto等更高效計算模式趕上

存儲格式:orc/parquet/kudu等列存、索引技術誕生,使得計算不需要scan大塊資料

網絡架構:25g網絡開始上線,fpga等技術也加快了網絡體驗

存儲媒體:ssd、aliflash、3d x-point 大量混合技術使得存儲可以“既快又猛”

計算平台:gpu、fgpa、甚至是未來的tpu等改變計算形态

從這些變化使得我們發現:

通過一款機型通吃存儲+計算方案,已經演變成存儲+計算各自服務化,通過高速網絡進行連接配接的趨勢
存儲與計算分離:OSS建構表 + 計算引擎對接

這種方式可以使得存儲、計算不用再被”機型“,”機櫃“,”電力“等方案束縛,在各自最擅長的領域進行創新。從業界對于”分層“的工作中,我們也看到了這類的嘗試:

netflix是aws創新代表,特别是他們的大資料業務。根據2016 re:invent上slides描述,netflix每天新增500 billion條日志(資料量500 tb)、存量數倉規模 60pb、每天會對其中3pb資料做計算。

在slides中netflix談到:從2014年開始就決定開始摒棄各種系統隔閡,底層使用了統一存儲s3,之上建構各種計算引擎系統。事實證明netflix這一步走得正确,海量的存儲與計算能力使得商業的創新得到了充分釋放,成為aws上令人引以為傲的學習榜樣。

存儲與計算分離:OSS建構表 + 計算引擎對接

受netflix啟發,aws 在2016 re:invent 上推出了一款新的計算産品athena:該産品将presto服務化提供基于各種存儲類服務的 ad-hoc query能力。

aws athena利用多個可用區(availability zones)中的計算資源執行查詢,并将s3用作底層資料存儲系統,由于資料備援地存儲在多個地點和每個地點的多個裝置中,服務具備很高的可用性和可靠性。

google開源了level db,而facebook通過改造成rocksdb使它上升到新高度。rocksdb除了對lsm模型的多個優化外,另一個非常吸引人的地方在對存儲媒體、計算層适配得非常友好,可以充分發揮計算和存儲的性能。底層的媒體與存儲對上層api透明熱插拔,是在軟體設計層面存儲+計算分離的一個優美案例。

存儲與計算分離:OSS建構表 + 計算引擎對接

對于資料倉庫來說最重要一點是海量存儲,能為計算分析提供大資料吞吐支援。在這個點上oss是非常合适的。

結合oss的目錄設定,對大規模(百萬級别以上)檔案做合理劃分,并與計算引擎配合拿到更高的計算效率。loghub投遞oss存儲支援hive-style分區目錄,将資料按照日期存儲,可以設定多元分區。

舉個例子,我們有一個應用叫my-app,為應用建立一個dw項目 my-dw,在項目中建立了一組表,以其中一個表my-table作為例子:表中的資料以時間(天)作為partition(例如date='20170330' 代表當天的資料目錄)。

整個數倉的層級結構可以映射為oss的一個通路路徑:

my-app 為 oss 上bucket名稱

my-dw 之後則為數倉的項目名(namespace)

my-table是表名

date=20170330是一維分區

存儲與計算分離:OSS建構表 + 計算引擎對接

oss 是提供實時資料讀寫“最便宜”存儲産品之一,對于100gb日志資料:

使用列存儲編碼(以parquet格式為例),通過snappy壓縮後,存儲資料量在8 gb左右

以oss目前官網價格計算,使用oss存儲一個月費用為 8 * 0.148 = 1.184 元

除此之外,oss有兩種根據通路頻率可任意轉換形态:ia(低頻)、archive(冷備),最低可以降低60%成本。oss 與 ia,archive之間資料模型是一緻的,資料形态可以非常便捷的轉換。

存儲與計算分離:OSS建構表 + 計算引擎對接

我們可以将資料以一種通用的協定存儲(例如textfile,sequence file或parquet等),目前oss上資料支援如下計算引擎:

開源:spark、presto、druid,pig,hive等

阿裡雲:maxcompute,e-mapreduce、rds-pg、batch compute等

以上計算引擎和存儲之間都是熱插拔,可以友善地在不同大小的測試、生産資料集上進行切換組合。

對比與傳統數倉方案,資料存儲于oss,計算實作了schema on read,使得資料分析的自由度得到了很大提升。

存儲與計算分離:OSS建構表 + 計算引擎對接

除了支援多種計算引擎外,oss 本身還有geo-replication功能,可以在不同region間準實時進行同步,不把雞蛋放在一個籃子裡,以進一步提升重要資料的安全性。

oss從api上看起來不像hdfs類存儲這麼細,性能并不一定好?

這裡以一個map-reduce作業舉例,在作業的執行過程中,oss會在3個地方被用到:

排程:當查詢送出時,需要根據計算資料範圍 list oss目錄制定plan,确定多少檔案目錄參與計算

運作:每個worker根據plan掃描指定目錄下檔案,讀取并進行自定義計算

結果:當計算完成時,寫入oss(計算中間結果産生的shuffle檔案可以寫在本機以優化性能,部分場景下也可以選擇使用oss)

存儲與計算分離:OSS建構表 + 計算引擎對接

可見,對于ad-hoc query類場景,oss在使用模式上都可以完全勝任。

loghub(推薦)

存儲與計算分離:OSS建構表 + 計算引擎對接

資料在oss存儲如下:

oss api/sdk

maxcompute 使用者(odps):功能内測中。

其它:随時一個get,資料全部拿走。