478      阿裏雲

圖模型開發和調試__圖模型_大數據計算服務-阿裏雲

ODPS沒有為用戶提供Graph開發插件，但用戶仍然可以基於Eclipse開發ODPS Graph程序，建議的開發流程是：

• 編寫Graph代碼，使用本地調試進行基本的測試；
• 進行集群調試，驗證結果；

開發示例

本節以SSSP 算法為例講述如何用Eclipse開發和調試Graph程序。下麵是開發SSSP的步驟：

1. 創建Java工程，例如：graph_examples；

2. 將ODPS客戶端lib目錄下的jar包加到Eclipse工程的Build Path裏。一個配置好的Eclipse工程如下圖所示。

3. 開發ODPS Graph程序，實際開發過程中，常常會先拷貝一個例子(例如SSSP)，然後再做修改。在本示例中，我們僅修改了package路徑為：package com.aliyun.odps.graph.example。
4. 編譯打包，在Eclipse環境中，右鍵點擊源代碼目錄(圖中的src目錄)，Export -> Java -> JAR file 生成JAR包，選擇目標jar包的保存路徑，例如：D:odpscltodps-graph-example-sssp.jar；
5. 使用ODPS客戶端運行SSSP，相關操作參考快速開始之運行Graph。

Eclipse 配置截圖：

注意：

• 相關的開發步驟請參考Graph開發插件介紹.

本地調試

ODPS GRAPH支持本地調試模式，可以使用Eclipse進行斷點調試。斷點調試步驟如下：

• 下載一個odps-graph-local的maven包。
• 選擇Eclipse工程，右鍵點擊GRAPH作業主程序(包含main函數)文件，配置其運行參數(Run As -> Run Configurations…)，如下圖。
• 在Arguments tab頁中，設置Program arguments 參數為“1 sssp_in sssp_out”，作為主程序的輸入參數；
• 在Arguments tab頁中，設置VM arguments參數為:-Dodps.runner.mode=local -Dodps.project.name=<project.name> -Dodps.end.point=<end.point>-Dodps.access.id=<access.id> -Dodps.access.key=<access.key>

• 對於本地模式(即odps.end.point參數不指定)，需要在warehouse創建sssp_in，sssp_out表，為輸入表 sssp_in 添加數據，輸入數據如下。關於warehouse的介紹請參考MapReduce本地運行 部分；

1,"2:2,3:1,4:4"
2,"1:2,3:2,4:1"
3,"1:1,2:2,5:1"
4,"1:4,2:1,5:1"
5,"3:1,4:1"

• 點擊Run按鈕即可本地跑SSSP；

其中：參數設置可參考ODPS客戶端中conf/odps_config.ini的設置，上述是幾個常用參數，其他參數也說明如下：

• odps.runner.mode：取值為local，本地調試功能必須指定；
• odps.project.name：指定當前project，必須指定；
• odps.end.point：指定當前odps服務的地址，可以不指定，如果不指定，隻從warehouse讀取表或資源的meta和數據，不存在則拋異常，如果指定，會先從warehouse讀取，不存在時會遠程連接odps讀取；
• odps.access.id：連接odps服務的id，隻在指定odps.end.point時有效；
• odps.access.key：連接odps服務的key，隻在指定odps.end.point時有效；
• odps.cache.resources：指定使用的資源列表，效果與jar命令的“-resources”相同；
• odps.local.warehouse： 本地warehouse路徑，不指定時默認為./warehouse；

在 Eclipse 中本地跑 SSSP的調試輸出信息如下：

Counters: 3
         com.aliyun.odps.graph.local.COUNTER
                 TASK_INPUT_BYTE=211
                 TASK_INPUT_RECORD=5
                 TASK_OUTPUT_BYTE=161
                 TASK_OUTPUT_RECORD=5
 graph task finish

注意：在上麵的示例中，需要本地warehouse下有sssp_in及sssp_out表。sssp_in及sssp_out的詳細信息請參考快速開始之運行Graph中的介紹。

本地作業臨時目錄

每運行一次本地調試，都會在 Eclipse 工程目錄下新建一個臨時目錄，見下圖：

一個本地運行的GRAPH作業臨時目錄包括以下幾個目錄和文件：

• counters - 存放作業運行的一些計數信息；
• inputs - 存放作業的輸入數據，優先取自本地的 warehouse，如果本地沒有，會通過 ODPS SDK 從服務端讀取(如果設置了 odps.end.point)，默認一個 input 隻讀10 條數據，可以通過 -Dodps.mapred.local.record.limit 參數進行修改，但是也不能超過1萬條記錄；
• outputs - 存放作業的輸出數據，如果本地warehouse中存在輸出表，outputs裏的結果數據在作業執行完後會覆蓋本地warehouse中對應的表；
• resources - 存放作業使用的資源，與輸入類似，優先取自本地的warehouse，如果本地沒有，會通過ODPS SDK從服務端讀取(如果設置了 odps.end.point)；
• job.xml - 作業配置
• superstep - 存放每一輪迭代的消息持久化信息。

  注意：

  • 如果需要本地調試時輸出詳細日誌，需要在 src 目錄下放一個 log4j 的配置文件：log4j.properties_odps_graph_cluster_debug。

集群調試

在通過本地的調試之後，可以提交作業到集群進行測試，通常步驟：

1. 配置ODPS客戶端；
2. 使用“add jar /path/work.jar -f;”命令更新jar包；
3. 使用jar命令運行作業，查看運行日誌和結果數據，如下所示；

注意：

• 集群運行Graph的詳細介紹可以參考快速開始之運行Graph。

性能調優

下麵主要從 ODPS Graph 框架角度介紹常見性能優化的幾個方麵：

作業參數配置

對性能有所影響的 GraphJob 配置項包括：

• setSplitSize(long) // 輸入表切分大小，單位MB，大於0，默認64；
• setNumWorkers(int) // 設置作業worker數量，範圍：[1, 1000]， 默認值-1, worker數由作業輸入字節數和split size決定；
• setWorkerCPU(int) // Map CPU資源，100為1cpu核，[50，800]之間，默認200；
• setWorkerMemory(int) // Map 內存資源，單位MB，[256M，12G]之間，默認4096M；
• setMaxIteration(int) // 設置最大迭代次數，默認 -1，小於或等於 0 時表示最大迭代次數不作為作業終止條件；
• setJobPriority(int) // 設置作業優先級，範圍：[0, 9]，默認9，數值越大優先級越小。

通常情況下：

1. 可以考慮使用setNumWorkers方法增加 worker 數目；
2. 可以考慮使用setSplitSize方法減少切分大小，提高作業載入數據速度；
3. 加大 worker 的 cpu 或內存；
4. 設置最大迭代次數，有些應用如果結果精度要求不高，可以考慮減少迭代次數，盡快結束；

接口 setNumWorkers 與 setSplitSize 配合使用，可以提高數據的載入速度。假設 setNumWorkers 為 workerNum, setSplitSize 為 splitSize, 總輸入字節數為 inputSize, 則輸入被切分後的塊數 splitNum = inputSize / splitSize，workerNum 和 splitNum 之間的關係：

1. 若 splitNum == workerNum，每個 worker 負責載入一個 split；
2. 若 splitNum > workerNum，每個 worker 負責載入一個或多個 split；
3. 若 splitNum < workerNum, 每個 worker 負責載入零個或一個 split。

因此，應調節 workerNum 和 splitSize，在滿足前兩種情況時，數據載入比較快。迭代階段隻調節 workerNum 即可。 如果設置 runtime partitioning 為 false，則建議直接使用 setSplitSize 控製 worker 數量，或者保證滿足前兩種情況，在出現第三種情況時，部分 worker 上點數會為0. 可以在 jar 命令前使用set odps.graph.split.size=<m>; set odps.graph.worker.num=<n>; 與 setNumWorkers 和 setSplitSize 等效。另外一種常見的性能問題：數據傾斜，反應到 Counters 就是某些 worker 處理的點或邊數量遠遠超過其他 worker。數據傾斜的原因通常是某些 key 對應的點、邊，或者消息的數量遠遠超出其他 key，這些 key 被分到少量的 worker 處理，從而導致這些 worker 相對於其他運行時間長很多，解決方法：

• 可以試試 Combiner，把這些 key 對應點的消息進行本地聚合，減少消息發生；
• 改進業務邏輯。

運用Combiner

開發人員可定義 Combiner 來減少存儲消息的內存和網絡數據流量，縮短作業的執行時間。細節見 SDK中Combiner的介紹。

減少數據輸入量

數據量大時，讀取磁盤中的數據可能耗費一部分處理時間，因此，減少需要讀取的數據字節數可以提高總體的吞吐量，從而提高作業性能。可供選擇的方法有如下幾種：

• 減少輸入數據量：對某些決策性質的應用，處理數據采樣後子集所得到的結果隻可能影響結果的精度，而並不會影響整體的準確性，因此可以考慮先對數據進行特定采樣後再導入輸入表中進行處理
• 避免讀取用不到的字段：ODPS Graph 框架的 TableInfo 類支持讀取指定的列(以列名數組方式傳入)，而非整個表或表分區，這樣也可以減少輸入的數據量，提高作業性能

內置jar包

下麵這些 jar 包會默認加載到運行 GRAPH 程序的 JVM 中，用戶可以不必上傳這些資源，也不必在命令行的 -libjars 帶上這些 jar 包：

• commons-codec-1.3.jar
• commons-io-2.0.1.jar
• commons-lang-2.5.jar
• commons-logging-1.0.4.jar
• commons-logging-api-1.0.4.jar
• guava-14.0.jar
• json.jar
• log4j-1.2.15.jar
• slf4j-api-1.4.3.jar
• slf4j-log4j12-1.4.3.jar
• xmlenc-0.52.jar

注意：

• 在起 JVM 的CLASSPATH 裏，上述內置 jar 包會放在用戶 jar 包的前麵，所以可能產生版本衝突，例如：用戶的程序中使用了 commons-codec-1.5.jar 某個類的函數，但是這個函數不在 commons-codec-1.3.jar 中，這時隻能看 1.3 版本裏是否有滿足你需求的實現，或者等待ODPS升級新版本。

最後更新：2016-07-24 16:35:49

  上一篇： 圖模型功能介紹__圖模型_大數據計算服務-阿裏雲

  下一篇： 單源最短距離__示例程序_圖模型_大數據計算服務-阿裏雲