摘要：還可以看到任務(wù)運(yùn)行的開始時(shí)間，結(jié)束時(shí)間，運(yùn)行時(shí)間，點(diǎn)擊就可以看到這個(gè)任務(wù)執(zhí)行詳情，包括有向無(wú)環(huán)圖，和或節(jié)點(diǎn)具體的運(yùn)行記錄。

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

點(diǎn)此查看原文：http://click.aliyun.com/m/41383/

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

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

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

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

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

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

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

Scheduler負(fù)責(zé)instance的調(diào)度，包括將instance分解為task、對(duì)等待提交的task進(jìn)行排序、以及向計(jì)算集群的Fuxi master詢問(wèn)資源占用情況以進(jìn)行流控（Fuxi slot滿的時(shí)候，停止響應(yīng)Executor的task申請(qǐng)）；

Executor負(fù)責(zé)啟動(dòng)SQL/ MR task，向計(jì)算集群的Fuxi master提交Fuxi任務(wù)，并監(jiān)控這些任務(wù)的運(yùn)行。

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

MaxCompute處理流程

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

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

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

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

客戶端會(huì)發(fā)送另一個(gè) REST 的請(qǐng)求，查詢作業(yè)狀態(tài)。
HTTP 服務(wù)器根據(jù)配置信息，去云賬號(hào)服務(wù)器做用戶認(rèn)證。
用戶認(rèn)證通過(guò)后，把查詢的請(qǐng)求發(fā)送給 Worker。
Worker 根據(jù) InstanceID 去 OTS 中查詢?cè)撟鳂I(yè)的執(zhí)行狀態(tài)。
Worker 將查詢到的執(zhí)行狀態(tài)返回給客戶端。

這里主要說(shuō)下計(jì)算層的MR Job和SQL Job，因?yàn)镺DPS有對(duì)外提供MapReduce編程接口，來(lái)訪問(wèn)ODPS上的數(shù)據(jù)，其中MR Job就是用來(lái)跑那些任務(wù)的。而SQL Job主要用來(lái)跑通過(guò)客戶端接受的SQL查詢請(qǐng)求的任務(wù)。

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

MaxCompute生態(tài)圈

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

MaxCompute計(jì)算集群分布

首先整個(gè)ODPS計(jì)算資源被分成多個(gè)集群，每個(gè)project可以配置多個(gè)集群，但是只能默認(rèn)跑在其配置的默認(rèn)集群（默認(rèn)集群只有一個(gè)）上面，除非手動(dòng)切換。
每個(gè)集群會(huì)被分成多個(gè)quota，一般某個(gè)project會(huì)跑在某個(gè)集群上的quota上的，每個(gè)quota有固定的計(jì)算資源配額，你的project也會(huì)有固定的至少獲取到的資源，最大獲取到的資源就是所在quota的配額，不一定能獲取到最大的配額，因?yàn)槟硞€(gè)quota是多個(gè)project共享的。

Logview分析

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

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

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

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

點(diǎn)擊每個(gè)Fuxi Job就可以在下面看到每個(gè)Job詳情：具體如下圖所示：

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

優(yōu)化例子

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

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

-優(yōu)化前：

-優(yōu)化后：

后續(xù)

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