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

摘要： 海量數據處理平臺，服務於批量結構化數據的存儲和計算，提供海量數據倉庫的解決方案以及針對大數據的分析建模服務.(官方文檔有這裏就很少作介紹了)官方文檔連接 優點 用戶沒必要關心分佈式計算細節，從而達到分析大數據的目的。

 

MaxCompute(原ODPS）的概念

 

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

 

官方文檔連接

 

優點

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

 

應用場景

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

 

MaxCompute（原ODPS）的架構

 

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

 

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，這樣不只佔用資源太多，並且還會影響別人的任務運行。優化當然很難，可是也要慢慢走下去。

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

 

原文連接