444
數加MaxCompute計算資源分布以及LogView分析優化
大數據計算服務(MaxCompute，原名ODPS)是一種快速、完全托管的PB/EB級數據倉庫解決方案，具備萬台服務器擴展能力和跨地域容災能力，是阿裏巴巴內部核心大數據平台，支撐每日百萬級作業規模。MaxCompute向用戶提供了完善的數據導入方案以及多種經典的分布式計算模型，能夠更快速的解決用戶海量數據計算問題，有效降低企業成本，並保障數據安全。(官方文檔有這裏就不多做介紹了)
官方文檔鏈接
用戶不必關心分布式計算細節，從而達到分析大數據的目的。
大型互聯網企業的數據倉庫和BI分析、網站的日誌分析、電子商務網站的交易分析、用戶特征和興趣挖掘等。
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元數據、安全體係等。
下麵將以一個完整的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 執行狀態。
ODPS提供了數據上傳下載通道，SQL及MapReduce等多種計算分析服務，並且提供了完善的安全解決方案，其功能組件（綠色虛線部分）以及周邊組件（藍色標識）。
具體功能組件的作用，請參考官方文檔。
- 首先整個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，這樣不僅占用資源太多，而且還會影響別人的任務運行。優化固然很難，但是也要慢慢走下去。
以後會分享更多的優化方案。
最後更新：2017-05-10 21:32:24