看到标題，可能有使用者要問：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等改變計算形态
從這些變化使得我們發現：
通過一款機型通吃存儲+計算方案，已經演變成存儲+計算各自服務化，通過高速網絡進行連接配接的趨勢
這種方式可以使得存儲、計算不用再被”機型“，”機櫃“，”電力“等方案束縛，在各自最擅長的領域進行創新。從業界對于”分層“的工作中，我們也看到了這類的嘗試：
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的一個通路路徑：
my-app 為 oss 上bucket名稱
my-dw 之後則為數倉的項目名（namespace）
my-table是表名
date=20170330是一維分區
oss 是提供實時資料讀寫“最便宜”存儲産品之一，對于100gb日志資料：
使用列存儲編碼（以parquet格式為例），通過snappy壓縮後，存儲資料量在8 gb左右
以oss目前官網價格計算，使用oss存儲一個月費用為 8 * 0.148 = 1.184 元
除此之外，oss有兩種根據通路頻率可任意轉換形态：ia（低頻）、archive（冷備），最低可以降低60%成本。oss 與 ia，archive之間資料模型是一緻的，資料形态可以非常便捷的轉換。
我們可以将資料以一種通用的協定存儲（例如textfile，sequence file或parquet等），目前oss上資料支援如下計算引擎：
開源：spark、presto、druid，pig，hive等
阿裡雲：maxcompute，e-mapreduce、rds-pg、batch compute等
以上計算引擎和存儲之間都是熱插拔，可以友善地在不同大小的測試、生産資料集上進行切換組合。
對比與傳統數倉方案，資料存儲于oss，計算實作了schema on read，使得資料分析的自由度得到了很大提升。
除了支援多種計算引擎外，oss 本身還有geo-replication功能，可以在不同region間準實時進行同步，不把雞蛋放在一個籃子裡，以進一步提升重要資料的安全性。
oss從api上看起來不像hdfs類存儲這麼細，性能并不一定好？
這裡以一個map-reduce作業舉例，在作業的執行過程中，oss會在3個地方被用到：
排程：當查詢送出時，需要根據計算資料範圍 list oss目錄制定plan，确定多少檔案目錄參與計算
運作：每個worker根據plan掃描指定目錄下檔案，讀取并進行自定義計算
結果：當計算完成時，寫入oss（計算中間結果産生的shuffle檔案可以寫在本機以優化性能，部分場景下也可以選擇使用oss）
可見，對于ad-hoc query類場景，oss在使用模式上都可以完全勝任。
loghub（推薦）
資料在oss存儲如下：
oss api/sdk
maxcompute 使用者（odps）：功能内測中。
其它：随時一個get，資料全部拿走。