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

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

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

優(yōu)勢
用戶不必關(guān)心分布式計算細節(jié)，從而達到分析大數(shù)據(jù)的目的。

應用場景
大型互聯(lián)網(wǎng)企業(yè)的數(shù)據(jù)倉庫和BI分析、網(wǎng)站的日志分析、電子商務網(wǎng)站的交易分析、用戶特征和興趣挖掘等。

MaxCompute（原ODPS）的架構(gòu)

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

ODPS的客戶端有以下幾種形式:
Web：ODPS以 RESTful API的方式提供離線數(shù)據(jù)處理服務；
ODPS SDK：對ODPS RESTful API的封裝，目前有Java等版本的實現(xiàn)；
ODPS CLT (Command Line Tool)：運行在Window/Linux下的客戶端工具，通過CLT可以提交命令完成Project管理、DDL、DML等操作；
ODPS IDE：ODPS提供了上層可視化ETL/BI工具，即“采云間”，用戶可以基于采云間完成數(shù)據(jù)同步、任務調(diào)度、報表生成等常見操作。
ODPS接入層提供HTTP服務、Cache、Load Balance，用戶認證和服務層面的訪問控制。

邏輯層又稱作控制層，是ODPS的核心部分。實現(xiàn)用戶空間和對象的管理、命令的解析與執(zhí)行邏輯、數(shù)據(jù)對象的訪問控制與授權(quán)等功能。在邏輯層有Worker、Scheduler和Executor三個角色：
Worker處理所有RESTful請求，包括用戶空間（project）管理操作、資源（resource）管理操作、作業(yè)管理等，對于SQL DML、MR、DT等啟動Fuxi任務的作業(yè)，會提交Scheduler進一步處理；

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

Executor負責啟動SQL/ MR task，向計算集群的Fuxi master提交Fuxi任務，并監(jiān)控這些任務的運行。

計算層就是飛天內(nèi)核（Apsara Core),運行在和控制層相互獨立的計算集群上。包括Pangu（分布式文件系統(tǒng)）、Fuxi（資源調(diào)度系統(tǒng)）、Nuwa/ZK（Naming服務）、Shennong（監(jiān)控模塊）等。ODPS中的元數(shù)據(jù)存儲在阿里云計算的另一個開放服務OTS（Open Table Service，開放結(jié)構(gòu)化數(shù)據(jù)服務）中，元數(shù)據(jù)內(nèi)容主要包括用戶空間元數(shù)據(jù)、Table/Partition Schema、ACL、Job元數(shù)據(jù)、安全體系等。

MaxCompute處理流程

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

提交作業(yè):
通過console提交一個SQL語句。
調(diào)用SDK計算配置信息中的簽名。
發(fā)送 RESTful 請求給HTTP服務器。
HTTP 服務器發(fā)送請求到云賬號服務器做用戶認證。
認證通過后，請求就會以 Kuafu通信協(xié)議方式發(fā)送給 Worker。
Worker判斷該請求作業(yè)是否需要啟動Fuxi Job。如果不需要，本地執(zhí)行并返回結(jié)果。
如果需要，則生成一個 instance， 發(fā)送給 Scheduler。
Scheduler把instance信息注冊到 OTS，將其狀態(tài)置成 Running。
Scheduler 把 instance 添加到 instance 隊列。
Worker把 Instance ID返回給客戶端。

運行作業(yè)：
Scheduler會把instance拆成多個Task，并生成任務流DAG圖。
把可運行的Task 放入到優(yōu)先級隊列TaskPool中。
Scheduler 有一個后臺線程定時對TaskPool 中的任務進行排序。
Scheduler 有一個后臺線程定時查詢計算集群的資源狀況。
Executor在資源未滿的情況下，輪詢TaskPool，請求Task。
Scheduler判斷計算資源。若集群有資源，就將該Task發(fā)給Executor。
Executor調(diào)用SQL Parse Planner，生成SQL Plan。
Executor 將 SQL Plan 轉(zhuǎn)換成計算層的 FuXi Job 描述文件。
Executor 將該描述文件提交給計算層運行，并查詢 Task 執(zhí)行狀態(tài)。
Task 執(zhí)行完成后，Executor更新 OTS 中的 Task信息，并匯報給 Scheudler。
Schduler 判斷 instance 結(jié)束，更新 OTS 中 instance 信息，置為 Terminated。

查詢狀態(tài)：
客戶端接收到返回的 Instance ID 后，可以通過 Instance ID 來查詢作業(yè)狀態(tài)：

客戶端會發(fā)送另一個 REST 的請求，查詢作業(yè)狀態(tài)。
HTTP 服務器根據(jù)配置信息，去云賬號服務器做用戶認證。
用戶認證通過后，把查詢的請求發(fā)送給 Worker。
Worker 根據(jù) InstanceID 去 OTS 中查詢該作業(yè)的執(zhí)行狀態(tài)。
Worker 將查詢到的執(zhí)行狀態(tài)返回給客戶端。

這里主要說下計算層的MR Job和SQL Job，因為ODPS有對外提供MapReduce編程接口，來訪問ODPS上的數(shù)據(jù)，其中MR Job就是用來跑那些任務的。而SQL Job主要用來跑通過客戶端接受的SQL查詢請求的任務。

邏輯層里主要有二個隊列，一個是instance隊列，一個是Task隊列，Scheduler負責instance的調(diào)度，負責將instance分解成Task放入到Task隊列，重點是：Task隊列是按照優(yōu)先級排序的，負責排序的就是Scheduler發(fā)起的一個后臺線程。Executor在資源未滿的情況下，輪詢TaskPool，請求Task，Executor調(diào)用SQL Parse Planner，生成SQL Plan，然后將SQL Plan轉(zhuǎn)換成計算層的 FuXi Job 描述文件，最終將該描述文件提交給計算層運行，并查詢 Task 執(zhí)行狀態(tài)。

MaxCompute生態(tài)圈

ODPS提供了數(shù)據(jù)上傳下載通道，SQL及MapReduce等多種計算分析服務，并且提供了完善的安全解決方案，其功能組件（綠色虛線部分）以及周邊組件（藍色標識）。
具體功能組件的作用，請參考官方文檔。

MaxCompute計算集群分布

首先整個ODPS計算資源被分成多個集群，每個project可以配置多個集群，但是只能默認跑在其配置的默認集群（默認集群只有一個）上面，除非手動切換。
每個集群會被分成多個quota，一般某個project會跑在某個集群上的quota上的，每個quota有固定的計算資源配額，你的project也會有固定的至少獲取到的資源，最大獲取到的資源就是所在quota的配額，不一定能獲取到最大的配額，因為某個quota是多個project共享的。

Logview分析

當某個任務跑的比較慢，我們可以根據(jù)其logview來發(fā)現(xiàn)問題，進行優(yōu)化，下面給大家分享如何對logview進行分析，下面我們來看根據(jù)某個logview的分析步驟：

點擊圓形的sql，就可以看到實際執(zhí)行的sql，點擊diagnosis就可以看到對sql執(zhí)行的診斷，是否資源充足，是否有長尾情況，是否有數(shù)據(jù)傾斜情況。

還可以看到任務運行的開始時間，結(jié)束時間，運行時間，點擊detail就可以看到這個任務執(zhí)行詳情，包括有向無環(huán)圖，Mapper和Reducer或Join節(jié)點具體的運行記錄。 下面是點擊detail之后，出現(xiàn)的畫面，也是我們重點要分析的地方，如下圖所示：

我們可以看到左邊是整個實例所包含的任務運行的有向無環(huán)圖，一共有三個Task，右邊包括具體的三個Task的詳細信息，還有summary，你可以看到每個Task的input和output的記錄數(shù)，還可以看到每個Task開啟了幾個instance進行運行。

點擊每個Fuxi Job就可以在下面看到每個Job詳情：具體如下圖所示：

從上面可以看到，M1_STG1這個job一共起了46個instance來跑任務，這個job的開始時間在上面?zhèn)€紅色的框框里，每個instance的開始和起始時間在下面的框框里，每個instance實際運行時間就是下面Latency時間，單位是s，最右邊的框框里顯示的是這個job下面的所有instance里面的最小最大和平均運行時間，如果說差異比較大，可能會有長尾或者數(shù)據(jù)不均勻所致，我們要根據(jù)這些信息進行分析，該如何去優(yōu)化這個Job。

優(yōu)化例子

具體的優(yōu)化過程以后會給大家具體講解，下面先給大家展示一個例子，由于小表和大表進行join所造成的長尾問題的解決方案以及效果：

-優(yōu)化方案：
我們將join的二個小表，使用mapjoin的方式進行優(yōu)化，將每個小表的內(nèi)容load到每個mapper節(jié)點的內(nèi)存中，這個速度可以大大優(yōu)化，但是對小表的大小是有限制的，如果太小，可以設(shè)置每個mapper的memery的大小，但是這些都不是萬能的，當資源不足時，可能會造成資源等待。所以優(yōu)化方案要根據(jù)自己sql以及涉及到的數(shù)據(jù)量進行優(yōu)化，任何優(yōu)化方法都不是萬能的。

-優(yōu)化前：

-優(yōu)化后：

后續(xù)

希望大家在跑sql任務的時候，多看看自己的logview，不要太蠻力的去跑sql，這樣不僅占用資源太多，而且還會影響別人的任務運行。優(yōu)化固然很難，但是也要慢慢走下去。

總結(jié)

以上是生活随笔為你收集整理的阿里云大数据MaxCompute计算资源分布以及LogView分析优化的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。