原文連接html
看到標題,可能有用戶要問:OSS不是用來存圖片、視頻、及文件的嗎,還能夠在上面建表、數倉?計算效率和經濟性表現怎麼樣?apache
本文先給出基本結論:安全
對象存儲(Object Storage Service,簡稱OSS)是基於阿里雲飛天分佈式系統的海量、安全和高可靠的雲存儲服務,是一種面向互聯網的大規模、通用存儲,提供RESTful API,具有容量和處理的彈性擴展能力。網絡
既然能夠把攝像頭推流接到OSS,建表屬於小Case了。而且2016年在亦龍大神的幫助下,Hadoop社區在官方版本中支持OSS,開啓了阿里雲存儲與開源融合的新里程碑。架構
今天爲了下降OSS上建表的門檻,日誌服務(原SLS)LogHub能夠支持OSS上表的實時寫入(表類型包括TextFile,列存儲Parquet),支持壓縮及數據Partition配置。在計算引擎端,咱們已經和阿里雲(MaxCompute、E-MapReduce)和主流開源計算引擎(Presto等)打通,無縫使用多種計算引擎熱插拔對接。app
既然能夠把數據表直接建在HDFS、MaxCompute(原ODPS)上,選擇OSS來存儲表數據又是爲何呢?分佈式
在2009年作大規模計算的核心詞是「Locality」:讓計算儘可能靠近數據以提高效率。當時一個公認的模型是:構建一個足夠大的資源池,把數據和計算融合在裏面發揮規模效應。ide
但最近幾年以來,生態和環境都悄然發生了一些變化:oop
從這些變化使得咱們發現:性能
經過一款機型通吃存儲+計算方案,已經演變成存儲+計算各自服務化,經過高速網絡進行鏈接的趨勢
這種方式可使得存儲、計算不用再被」機型「,」機櫃「,」電力「等方案束縛,在各自最擅長的領域進行創新。從業界對於」分層「的工做中,咱們也看到了這類的嘗試:
Netflix是AWS創新表明,特別是他們的大數據業務。根據2016 Re:Invent上Slides描述,Netflix天天新增500 Billion條日誌(數據量500 TB)、存量數倉規模 60PB、天天會對其中3PB數據作計算。
在Slides中Netflix談到:從2014年開始就決定開始摒棄各類系統隔閡,底層使用了統一存儲S3,之上構建各類計算引擎系統。事實證實Netflix這一步走得正確,海量的存儲與計算能力使得商業的創新獲得了充分釋放,成爲AWS上使人引覺得傲的學習榜樣。
受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的目錄設置,對大規模(百萬級別以上)文件作合理劃分,並與計算引擎配合拿到更高的計算效率。LogHub投遞OSS存儲支持Hive-style分區目錄,將數據按照日期存儲,能夠設置多維分區。
舉個例子,咱們有一個應用叫my-app,爲應用建立一個dw項目 my-dw,在項目中建立了一組表,以其中一個表my-table做爲例子:表中的數據以時間(天)做爲partition(例如date='20170330' 表明當天的數據目錄)。
整個數倉的層級結構能夠映射爲OSS的一個訪問路徑:
OSS 是提供實時數據讀寫「最便宜」存儲產品之一,對於100GB日誌數據:
咱們能夠將數據以一種通用的協議存儲(例如textfile,sequence file或parquet等),目前OSS上數據支持以下計算引擎:
以上計算引擎和存儲之間都是熱插拔,能夠方便地在不一樣大小的測試、生產數據集上進行切換組合。
對比與傳統數倉方案,數據存儲於OSS,計算實現了Schema on Read,使得數據分析的自由度獲得了很大提高。
除了支持多種計算引擎外,OSS 自己還有Geo-Replication功能,能夠在不一樣Region間準實時進行同步,不把雞蛋放在一個籃子裏,以進一步提高重要數據的安全性。
OSS從API上看起來不像HDFS類存儲這麼細,性能並不必定好?
這裏以一個Map-Reduce做業舉例,在做業的執行過程當中,OSS會在3個地方被用到:
可見,對於Ad-Hoc Query類場景,OSS在使用模式上均可以徹底勝任。
直接將日誌以準實時方式寫入OSS,支持JSON、Parquet格式,投遞規則配置以下:
數據在OSS存儲以下:
2017-04-18 11:50:39 513.75KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_11_00/log_1492487434507106535_1670221.snappy.parquet 2017-04-18 11:56:01 517.36KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_11_00/log_1492487754196771821_1670280.snappy.parquet 2017-04-18 12:01:31 537.03KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_12_00/log_1492488089710991745_1670335.snappy.parquet 2017-04-18 12:06:54 512.95KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_12_00/log_1492488410774368293_1670389.snappy.parquet 2017-04-18 12:22:55 512.95KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_12_00/log_1492489370787863606_1670558.snappy.parquet 2017-04-18 12:34:21 261.69KB oss://oss-shipper-shenzhen-test/tfs_access_log/updatetime=2017_04_18_12_00/log_1492490057002827204_1670672.snappy.parquet object list number is: 5451 totalsize is: real:195677878828, format:182.24GB
經過LogHub寫入優點:數據接入LogHub多種選擇,全託管歸檔服務,準實時投遞,支持異常重試,STS受權。瞭解OSS投遞請參考文檔。
使用OSS 各類SDK或API寫入,徹底自主的寫入方式,參考文檔。