大資料計算服務(maxcompute，原名odps)是一種快速、完全托管的pb/eb級資料倉庫解決方案，具備萬台伺服器擴充能力和跨地域容災能力，是阿裡巴巴内部核心大資料平台，支撐每日百萬級作業規模。maxcompute向使用者提供了完善的資料導入方案以及多種經典的分布式計算模型，能夠更快速的解決使用者海量資料計算問題，有效降低企業成本，并保障資料安全。(官方文檔有這裡就不多做介紹了)
<a href="https://help.aliyun.com/document_detail/34524.html?spm=5176.product27797.6.540.ppztts" target="_blank">官方文檔連結</a>
使用者不必關心分布式計算細節，進而達到分析大資料的目的。
大型網際網路企業的資料倉庫和bi分析、網站的日志分析、電子商務網站的交易分析、使用者特征和興趣挖掘等。
maxcompute由四部分組成，分别是用戶端 (odps client)、接入層 (odps front end)、邏輯層 (odps server) 及存儲與計算層 (apsara core)。
odps的用戶端有以下幾種形式:
web：odps以 restful api的方式提供離線資料處理服務；
odps sdk：對odps restful api的封裝，目前有java等版本的實作；
odps clt (command line tool)：運作在window/linux下的用戶端工具，通過clt可以送出指令完成project管理、ddl、dml等操作；
odps ide：odps提供了上層可視化etl/bi工具，即“采雲間”，使用者可以基于采雲間完成資料同步、任務排程、報表生成等常見操作。
odps接入層提供http服務、cache、load balance，使用者認證和服務層面的通路控制。
邏輯層又稱作控制層，是odps的核心部分。實作使用者空間和對象的管理、指令的解析與執行邏輯、資料對象的通路控制與授權等功能。在邏輯層有worker、scheduler和executor三個角色：
worker處理所有restful請求，包括使用者空間（project）管理操作、資源（resource）管理操作、作業管理等，對于sql dml、mr、dt等啟動fuxi任務的作業，會送出scheduler進一步處理；
scheduler負責instance的排程，包括将instance分解為task、對等待送出的task進行排序、以及向計算叢集的fuxi master詢問資源占用情況以進行流控（fuxi slot滿的時候，停止響應executor的task申請）；
executor負責啟動sql/ mr task，向計算叢集的fuxi master送出fuxi任務，并監控這些任務的運作。
計算層就是飛天核心（apsara core),運作在和控制層互相獨立的計算叢集上。包括pangu（分布式檔案系統）、fuxi（資源排程系統）、nuwa/zk（naming服務）、shennong（監控子產品）等。odps中的中繼資料存儲在阿裡雲計算的另一個開放服務ots（open table service，開放結構化資料服務）中，中繼資料内容主要包括使用者空間中繼資料、table/partition schema、acl、job中繼資料、安全體系等。
下面将以一個完整的sql語句為例，介紹送出後經過maxcompute處理的全流程：
通過console送出一個sql語句。
調用sdk計算配置資訊中的簽名。
發送 restful 請求給http伺服器。
http 伺服器發送請求到雲賬号伺服器做使用者認證。
認證通過後，請求就會以 kuafu通信協定方式發送給 worker。
worker判斷該請求作業是否需要啟動fuxi job。如果不需要，本地執行并傳回結果。
如果需要，則生成一個 instance， 發送給 scheduler。
scheduler把instance資訊注冊到 ots，将其狀态置成 running。
scheduler 把 instance 添加到 instance 隊列。
worker把 instance id傳回給用戶端。
scheduler會把instance拆成多個task，并生成任務流dag圖。
把可運作的task 放入到優先級隊列taskpool中。
scheduler 有一個背景線程定時對taskpool 中的任務進行排序。
scheduler 有一個背景線程定時查詢計算叢集的資源狀況。
executor在資源未滿的情況下，輪詢taskpool，請求task。
scheduler判斷計算資源。若叢集有資源，就将該task發給executor。
executor調用sql parse planner，生成sql plan。
executor 将 sql plan 轉換成計算層的 fuxi job 描述檔案。
executor 将該描述檔案送出給計算層運作，并查詢 task 執行狀态。
task 執行完成後，executor更新 ots 中的 task資訊，并彙報給 scheudler。
schduler 判斷 instance 結束，更新 ots 中 instance 資訊，置為 terminated。
用戶端接收到傳回的 instance id 後，可以通過 instance id 來查詢作業狀态：
用戶端會發送另一個 rest 的請求，查詢作業狀态。
http 伺服器根據配置資訊，去雲賬号伺服器做使用者認證。
使用者認證通過後，把查詢的請求發送給 worker。
worker 根據 instanceid 去 ots 中查詢該作業的執行狀态。
worker 将查詢到的執行狀态傳回給用戶端。
<b>這裡主要說下計算層的mr job和sql job</b>，因為odps有對外提供mapreduce程式設計接口，來通路odps上的資料，其中mr job就是用來跑那些任務的。而sql job主要用來跑通過用戶端接受的sql查詢請求的任務。
邏輯層裡主要有二個隊列，一個是instance隊列，一個是task隊列，scheduler負責instance的排程，負責将instance分解成task放入到task隊列，重點是：task隊列是按照優先級排序的，負責排序的就是scheduler發起的一個背景線程。executor在資源未滿的情況下，輪詢taskpool，請求task，executor調用sql parse planner，生成sql plan，然後将sql plan轉換成計算層的 fuxi job 描述檔案，最終将該描述檔案送出給計算層運作，并查詢 task 執行狀态。
odps提供了資料上傳下載下傳通道，sql及mapreduce等多種計算分析服務，并且提供了完善的安全解決方案，其功能元件（綠色虛線部分）以及周邊元件（藍色辨別）。
首先整個odps計算資源被分成多個叢集，每個project可以配置多個叢集，但是隻能預設跑在其配置的預設叢集（預設叢集隻有一個）上面，除非手動切換。
每個叢集會被分成多個quota，一般某個project會跑在某個叢集上的quota上的，每個quota有固定的計算資源配額，你的project也會有固定的至少擷取到的資源，最大擷取到的資源就是所在quota的配額，不一定能擷取到最大的配額，因為某個quota是多個project共享的。
當某個任務跑的比較慢，我們可以根據其logview來發現問題，進行優化，下面給大家分享如何對logview進行分析，下面我們來看根據某個logview的分析步驟：
點選圓形的sql，就可以看到實際執行的sql，點選diagnosis就可以看到對sql執行的診斷，是否資源充足，是否有長尾情況，是否有資料傾斜情況。
還可以看到任務運作的開始時間，結束時間，運作時間，點選detail就可以看到這個任務執行詳情，包括有向無環圖，mapper和reducer或join節點具體的運作記錄。 下面是點選detail之後，出現的畫面，也是我們重點要分析的地方，如下圖所示：
我們可以看到左邊是整個執行個體所包含的任務運作的有向無環圖，一共有三個task，右邊包括具體的三個task的詳細資訊，還有summary，你可以看到每個task的input和output的記錄數，還可以看到每個task開啟了幾個instance進行運作。
點選每個fuxi job就可以在下面看到每個job詳情：具體如下圖所示：
從上面可以看到，m1_stg1這個job一共起了46個instance來跑任務，這個job的開始時間在上面個紅色的框框裡，每個instance的開始和起始時間在下面的框框裡，每個instance實際運作時間就是下面latency時間，機關是s，最右邊的框框裡顯示的是這個job下面的所有instance裡面的最小最大和平均運作時間，如果說差異比較大，可能會有長尾或者資料不均勻所緻，我們要根據這些資訊進行分析，該如何去優化這個job。
具體的優化過程以後會給大家具體講解，下面先給大家展示一個例子，由于小表和大表進行join所造成的長尾問題的解決方案以及效果：
-優化方案：
我們将join的二個小表，使用mapjoin的方式進行優化，将每個小表的内容load到每個mapper節點的記憶體中，這個速度可以大大優化，但是對小表的大小是有限制的，如果太小，可以設定每個mapper的memery的大小，但是這些都不是萬能的，當資源不足時，可能會造成資源等待。是以優化方案要根據自己sql以及涉及到的資料量進行優化，任何優化方法都不是萬能的。
-優化前：
-優化後：
希望大家在跑sql任務的時候，多看看自己的logview，不要太蠻力的去跑sql，這樣不僅占用資源太多，而且還會影響别人的任務運作。優化固然很難，但是也要慢慢走下去。
以後會分享更多的優化方案。