MaxCompute(原ODPS）的概念

大數據計算服務(MaxCompute，原名ODPS)是一種快速、完全托管的PB/EB級數據倉庫解決方案，具備萬臺服務器擴展能力和跨地域容災能力，是阿裏巴巴內部核心大數據平臺，支撐每日百萬級作業規模。MaxCompute向用戶提供了完善的數據導入方案以及多種經典的分布式計算模型，能夠更快速的解決用戶海量數據計算問題，有效降低企業成本，並保障數據安全。

官方文檔鏈接

優勢

用戶不必關心分布式計算細節，從而達到分析大數據的目的。

應用場景

大型互聯網企業的數據倉庫和BI分析、網站的日誌分析、電子商務網站的交易分析、用戶特征和興趣挖掘等。

MaxCompute（原ODPS）的架構

MaxCompute由四部分組成，分別是客戶端 (ODPS Client)、接入層 (ODPS Front End)、邏輯層 (ODPS Server) 及存儲與計算層 (Apsara Core)。

ODPS的客戶端有以下幾種形式:

1.Web：ODPS以 RESTful API的方式提供離線數據處理服務；

2.ODPS SDK：對ODPS RESTful API的封裝，目前有Java等版本的實現；

ODPS CLT (Command Line Tool)：運行在Window/Linux下的客戶端工具，通過CLT可以提交命令完成Project管理、DDL、DML等操作；

3.ODPS IDE：ODPS提供了上層可視化ETL/BI工具，即“采雲間”，用戶可以基於采雲間完成數據同步、任務調度、報表生成等常見操作。

ODPS接入層提供HTTP服務、Cache、Load Balance，用戶認證和服務層面的訪問控制。

1.邏輯層又稱作控制層，是ODPS的核心部分。實現用戶空間和對象的管理、命令的解析與執行邏輯、數據對象的訪問控制與授權等功能。在邏輯層有Worker、Scheduler和Executor三個角色：

2.Worker處理所有RESTful請求，包括用戶空間（project）管理操作、資源（resource）管理操作、作業管理等，對於SQL DML、MR、DT等啟動Fuxi任務的作業，會提交Scheduler進一步處理；

3.Scheduler負責instance的調度，包括將instance分解為task、對等待提交的task進行排序、以及向計算集群的Fuxi master詢問資源占用情況以進行流控（Fuxi slot滿的時候，停止響應Executor的task申請）；

4.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元數據、安全體系等。

MaxCompute處理流程

下面將以一個完整的SQL語句為例，介紹提交後經過MaxCompute處理的全流程：

提交作業:

1.通過console提交一個SQL語句。

2.調用SDK計算配置信息中的簽名。

3.發送 RESTful 請求給HTTP服務器。

4.HTTP 服務器發送請求到雲賬號服務器做用戶認證。

5.認證通過後，請求就會以 Kuafu通信協議方式發送給 Worker。

6.Worker判斷該請求作業是否需要啟動Fuxi Job。如果不需要，本地執行並返回結果。

7.如果需要，則生成一個 instance， 發送給 Scheduler。

8.Scheduler把instance信息註冊到 OTS，將其狀態置成 Running。

9.Scheduler 把 instance 添加到 instance 隊列。

10.Worker把 Instance ID返回給客戶端。

運行作業：

1.Scheduler會把instance拆成多個Task，並生成任務流DAG圖。

2.把可運行的Task 放入到優先級隊列TaskPool中。

3.Scheduler 有一個後臺線程定時對TaskPool 中的任務進行排序。

4.Scheduler 有一個後臺線程定時查詢計算集群的資源狀況。

5.Executor在資源未滿的情況下，輪詢TaskPool，請求Task。

6.Scheduler判斷計算資源。若集群有資源，就將該Task發給Executor。

7.Executor調用SQL Parse Planner，生成SQL Plan。

8.Executor 將 SQL Plan 轉換成計算層的 FuXi Job 描述文件。

9.Executor 將該描述文件提交給計算層運行，並查詢 Task 執行狀態。

10.Task 執行完成後，Executor更新 OTS 中的 Task信息，並匯報給 Scheudler。

11.Schduler 判斷 instance 結束，更新 OTS 中 instance 信息，置為 Terminated。

查詢狀態：

客戶端接收到返回的 Instance ID 後，可以通過 Instance ID 來查詢作業狀態：

1.客戶端會發送另一個 REST 的請求，查詢作業狀態。

2.HTTP 服務器根據配置信息，去雲賬號服務器做用戶認證。

3.用戶認證通過後，把查詢的請求發送給 Worker。

4.Worker 根據 InstanceID 去 OTS 中查詢該作業的執行狀態。

5.Worker 將查詢到的執行狀態返回給客戶端。

這裏主要說下計算層的MR Job和SQL Job，因為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 執行狀態。

MaxCompute生態圈

ODPS提供了數據上傳下載通道，SQL及MapReduce等多種計算分析服務，並且提供了完善的安全解決方案，其功能組件（綠色虛線部分）以及周邊組件（藍色標識）。

具體功能組件的作用，請參考官方文檔。

MaxCompute計算集群分布

首先整個ODPS計算資源被分成多個集群，每個project可以配置多個集群，但是只能默認跑在其配置的默認集群（默認集群只有一個）上面，除非手動切換。

每個集群會被分成多個quota，一般某個project會跑在某個集群上的quota上的，每個quota有固定的計算資源配額，你的project也會有固定的至少獲取到的資源，最大獲取到的資源就是所在quota的配額，不一定能獲取到最大的配額，因為某個quota是多個project共享的。

Logview分析

當某個任務跑的比較慢，我們可以根據其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，這樣不僅占用資源太多，而且還會影響別人的任務運行。優化固然很難，但是也要慢慢走下去。

以後會分享更多的優化方案。

原文鏈接

閱讀更多幹貨好文，請關註掃描以下二維碼：

阿裏雲大數據MaxCompute計算資源分布以及LogView分析優化