摘要： MaxCompute(原ODPS）的概念 海量數據處理平臺，服務于批量結構化數據的存儲和計算，提供海量數據倉庫的解決方案以及針對大數據的分析建模服務.(官方文檔有這里就不多做介紹了)官方文檔鏈接 優勢 用戶不必關心分布式計算細節，從而達到分析大數據的目的。

點此查看原文：http://click.aliyun.com/m/41383/

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

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

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

MaxCompute（原ODPS）的架構

odps.structure.pngMaxCompute由四部分組成，分別是客戶端 (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元數據、安全體系等。

MaxCompute處理流程

下面將以一個完整的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 將查詢到的執行狀態返回給客戶端。

這里主要說下計算層的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分析优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。