玩大資料的第一件事情是将資料上傳到maxcompute，那麼資料是通過哪些途徑進入maxcompute中的呢？
如上圖所示，maxcompute/streamcompute是提供給使用者用來計算大資料的平台，一般來說，它們本身不直接産生實際的業務資料，業務資料是來自于資料庫rds、app logs以及iot等終端裝置，兩者之間需要橋梁進行連接配接。
從上圖中間可以看到：資料可以通過tunnel元件進入maxcompute，tunnel是一個非常注意吞吐量同時又盡可能追求資料嚴格一緻的輸入輸出接口；在這條通道上再往前延伸，還有開源軟體sqoop、kettle以及阿裡巴巴自研的開源軟體datax。事實上，在公司内部所有資料的傳輸、導入到maxcompute或者說最後計算完的結果再回流到資料庫中，這種對前台資料庫沖擊不大的情況都在使用datax。為了實時傳輸資料，滿足流計算的訴求，阿裡雲提供了dathub元件，它是一個偏重于實時的增量資料通道，在此基礎上，對于ecs上的文本日志支援了業界著名的logstash、flume、fluentd三個開源軟體。
如何将資料庫中的資料拖進maxcompute中呢？首先能想到的方法是在資料庫中執行select語句，将結果集通過tunnel寫入maxcompute，這是一個容易上手又友善容錯的方式。但這種方式對于資料量較大并且需要長期運作的情況不一定非常合适。一方面在阿裡的實踐過程中發現執行select語句會對資料庫産生查詢壓力，當資料量非常龐大時，可能會導緻前台業務因為資料庫增大而産生響應能力上的降低；其次執行sql語句會碰到各種各樣的情況，例如想用時間過濾前一天的增量，但是在時間字段上因為曆史原因沒有索引，這在專有雲案例中經常發生。對于這種情況，我們嘗試解析mysql的binlog，将其binlog以一種流式的方式源源不斷地、實時地傳遞到dathub上，然後該資料再通過dathub再寫入maxcompute，在maxcompute上再進行資料的合并等操作，還原出前一天的增量資料。
目前，在公共雲，dathub和官方的資料傳輸産品dts已經打通，能夠無縫完成rds上的資料庫實時變更增量并寫入dathub中，進一步push到maxcompute中；另一方面，所有進入dathub的實時資料都可以被流計算無縫使用，做一些時效性更好的計算作業。
資料上雲核心問題
資料上雲的核心問題包括四點：
（1）資料要能上傳，它主要面臨兩個痛點包：一是前台存儲多樣化，包括rdbms、nosql、logs等，每多一種類型，需要對應地識别其協定，解析schema，甚至是無schema的類型還需要按照業務邏輯轉變成二維表的格式；二是傳輸需求多變，例如在傳輸的過程中需要将字元串轉變成id，将圖檔變成url位址等，很難将其抽象成一個标準的模型。
阿裡雲為應對該問題，提供了tunnel和datahub的官方api和sdk作為兜底，保障了在阿裡雲生态工具跟不上的情況下，開發者依舊有方法将資料上傳到雲端。
（2）資料的高效傳輸，資料傳輸中最典型的問題就是帶寬，尤其是長途傳輸，長途帶寬上的稍微波動都對傳輸效率起到很大的影響；第二個問題是資料庫dump開銷大，影響到核心業務的運轉。
傳輸問題對應的解決方案一是盡量規避長途傳輸、長途帶寬對效率的影響，在tunnel通道中，支援壓縮協定，可以在用戶端進行壓縮，然後再大包送出，進而提升吞吐量；第二點采用dts這類基于增量日志的實時上傳方式，拉長傳輸時間，并且支援斷點續傳，降低某特定時刻對帶寬的需求。
（3）資料的正确性，首先maxcompute是一個強schema的資料庫，從oralce到maxcompute傳導資料時，在字段類型的映射上或浮點數的操作上一定會存在精度誤差，那麼精度誤差如何處理？第二點是正确性無法避開的timeout重傳導緻的資料重複。
tunnel提供兩階段送出的功能，先write後commit，提供了資料嚴格一緻的可能性；相反地，datahub流式傳輸無法實作兩階段送出，這是由于要考慮效率和吞吐量導緻。
（4）安全是使用雲計算必須面臨的問題，資料存儲是否可靠以及會不會第三方被嗅探。
maxcompute采用pangu的三副本存儲，本身提供了非常高的可靠性。另一方面，maxcompute預設不同使用者之間的資料完全隔離， 并且在傳輸過程中全部采用https協定，使得資料被第三方嗅探到的可能降到最低。
下面來具體看一下tunnel和datahub。
<b>批量、曆史資料通道tunnel</b>
tunnel是針對曆史資料的批量資料通道，它的典型特征是支援大包傳輸，write&commit兩階段送出，最大可能性保證資料一緻。使用者可以使用odpscmd指令對資料進行上傳、下載下傳等操作。
datax是阿裡開源的一款工具，可以适配常見的資料源，包括關系資料庫、文本檔案等，這是一款單機的軟體，适用于中小資料量的傳輸。使用datax傳輸資料到odps時，在ecs機器或一台實體機器上部署好datax，此機器要能夠同時連通資料源與maxcompute(原odps)服務。sqoop可以并行起多個任務導出資料，相比datax可以取得更好的性能。
<b>實時、增量資料通道datahub</b>
datahub是實時、增量資料通道，目的是為支援流計算和實時資料。在程式設計友好性上，datahub要優于tunnel，解決了tunnel的小包效率問題，并且能夠容忍少量的資料重複。
datahub摒棄了兩階段送出的方式，使用時不停地寫入資料即可，技術特征是面向高吞吐，是以在datahub上并沒有提供嚴格一緻的語義支援；在阿裡集團内部，datahub每天有數百tb資料壓縮後寫入，pb級别的資料消費。消費的資料之是以是寫入資料的數倍是因為一份資料會被多方使用，例如一份資料進入maxcompute進行離線加工，另一份甚至多份用于實時處理，給使用者提供更實時的資料。
在datahub通道上，要盡可能保障資料低延遲，目前，理論上資料庫中的使用者訂單可以做到毫秒級流入流計算或maxcompute中；在阿裡的實際生産經驗中，為了平衡延時和吞吐，在絕大數情況下，前台訂單流入後端計算平台的總時間在1s-2s左右，但這種時效性已經能夠滿足絕大多數業務需求。
datahub和流計算産品緊密結合，可以在流計算中非常友善的重複使用多份資料；datahub是基于topic/shard（s）模型，每個主題(topic)的資料流吞吐能力可以動态擴充和減少，最高可達到每主題256000 records/s的吞吐量。
源頭資料庫到datahub資料庫之間可以通過dts、oracle goldengate連接配接；app logs到datahub之間可以通過logstash、fluentd等開源軟體連接配接。
maxcompute生态思路
上述提到的資料上傳是整個maccompute生态的一部分，maxcompute整體思路如上圖所示：最底層是maxcompute restful api（tunnel&datahub）；在中間層（黃色部分）提供了java、rodps、pyodps、ruby/php（社群貢獻）等語言的sdk，這兩層是兜底方案，當上層提供的元件無法滿足需求時，開發者依舊有方式将資料傳到計算平台上；最上層是生态的思路，包括官方大資料dataide、intellij idea plugin（maxcompute studio）、jupyter notebook、導入導出子產品等。
<b>rodps</b>
rodps提供了一種橋接的方式，使得可以在r語言環境中無縫的使用maxcompute(原odps)裡面的資料、計算資源，類似于開源社群的rhive和rhadoop的功能；r語言開發者可以在r語言中直接執行maxcompute sql，并将結果集轉換為rdata.frame，便于進一步研究。rodps很适合在maxcompute中預先完成計算，縮小結果集再進行單機分析的場景。
未來rodps将緻力于将本地算法和資料處理運作在分布式系統上面，緻力于讓使用者無縫遷移r社群的開源包，提供類似于sparkr那樣的強大的能力。
<b>pyodps</b>
pyodps 是odps的python版本的sdk， 它提供了對maxcompute對象的基本操作，在python中運作maxcompute sql語句的需求促進了pyodps的出現；與rodps類似，在python中也可以做maxcompute dataframe，甚至maxcompute結果的dataframe還可以和pandas dataframe進行join操作；除此之外，通過pyodps還為開發者提供了基于第三方軟體（如jupyter notebook）連接配接到maxcompute中進行互動式資料分析的能力。