MaxCompute（原ODPS）任務優化之列裁剪轉自kaiding

最近因為幾個odps任務節點扣分嚴重，計算健康度一度堕落至85分的紅線以下，上了一次黑榜，立馬開始了艱苦的優化之旅。剛剛前幾天搞定了兩個<code>openmr</code>的<code>列裁剪</code>優化，略作記錄。

列裁剪，即針對<code>openmr</code>任務<code>map</code>階段的輸入，如果隻使用了其中的某幾列，則裁剪掉不需要使用的列，隻指定需要使用的列。這樣做的好處也就很明顯了，減少網絡i/o，提升<code>map</code>計算效率等等。其實從使用上來看或許叫做輸入列指定更顧名思義一些。

這裡貼一個本次重點做了列裁剪的節點，在列裁剪優化之前的<code>logview</code>(由于系統隻保留最近幾天的日志，是以這裡就不貼連結了)，這裡就貼部分内容吧，具體檢視路徑為：

1. 在待優化節點右鍵<code>檢視運作日志</code>

2. 找到<code>logview</code>輕點打開

3. <code>odps tasks</code>-&gt;<code>detail</code>

4. <code>main content</code>-&gt;<code>jsonsummary</code>

其中某一路輸入的相關統計資料如下：

ok，沒錯，<code>input_col_total_num</code>和<code>input_col_used_num</code>兩個字段的資料就是我們此次優化需要關注的要點。可以看到這張輸入表在map階段總共輸入了14896列（這裡的意思不是說輸入表有1萬多列，而是map個數乘以表的列數得到的map階段總的輸入列數），但是實際使用了3724列（同理），使用率非常低，扣分就是從這裡開始的。。。

其實回到<code>fuxijobs</code>點選<code>m1_u13</code>，然後在列出的任意一個<code>fuxinstance</code>中點選<code>debug</code>可以看到這個<code>map</code>任務中的統計資料：

從這個<code>map</code>統計資料可以看到，輸入表共輸入8列，但實際使用了2列，即使用率隻有1/4而已，浪費嚴重。

如果你使用的是<code>java sdk</code>，那麼可以在指定輸入表的同時指定輸入列，如下：

如果你的mr任務輸入表确定而不變，則可以參數化進行設定，如下：

第二種方式我沒有用過，目前隻是實踐了第一種方式，而這種方式的靈活性在于，如果你是通過配置檔案來表達輸入表和輸入列時，可以實作<code>隻改配置而不改代碼</code>。

由于目前提供的sdk不支援使用列索引來做<code>列裁剪</code>（個人覺得應該封裝一下），如果因為曆史原因，隻在輸入表的自定義配置檔案中指定了輸入表的列索引也沒關系（如果配置檔案比較大，輸入表有幾十個，我想你也不希望去重新找每張表列索引對應的列名），可以通過擷取<code>table</code>的<code>tableschema</code>，然後通過下标來擷取到列名，簡單看下代碼：

這裡有一個注意點就是，如果優化前在<code>map</code>任務中是通過輸入表的列索引去擷取記錄值的話，需要同步做相應修改。這是因為指定了輸入列之後，實際在<code>map</code>階段的輸入表列數比原輸入表要少，你可以了解為在<code>map</code>階段是一張全新的表，此時列索引應該使用這張經過裁剪後的新表的列索引，是以使用原來的列索引可能會取不到值或者取到錯誤列的值。建議在使用時需要使用列名來通路或者通過新的列索引來擷取記錄值。

其實我上面貼的<code>logview</code>中的内容就是因為我在<code>map</code>階段使用了原輸入表的列索引來通路，導緻了使用率反而降低了。比如表<code>wc_in</code>一共有0-9共10列，你隻需要讀索引為7、8、9這三列，但是你在進行了列裁剪優化之後，實際在<code>map</code>階段的輸入表隻有0、1、2這三個索引對應的值，此時如果你還是使用原來的列索引去讀的話就讀不到資料，導緻該表的輸入列使用率從原來的30%變成了0%。

是以在完成了列裁剪優化之後務必檢查<code>map</code>階段讀取<code>record</code>的方式：

1. 如果是使用列索引的務必改成列名，

2. 或者如果不友善擷取列名的，在<code>setup</code>階段讀取配置檔案建立列索引的映射來解決該問題。

歡迎加入“數加·maxcompute購買咨詢”釘釘群（群号： 11782920）進行咨詢，群二維碼如下：