資料膨脹最佳化 -

本文為您介紹產生資料膨脹的原因及處理措施。

問題現象

在Logview中查看Fuxi Task的輸出資料量比輸入資料量大很多。輸入、輸出資料量可以通過Fuxi Task的I/O Record和I/O Bytes屬性擷取。

如下圖所示，輸入資料量為1 GB，經過處理後輸出數量變為1 TB。在一個Instance下處理1 TB的資料，運行效率會大大降低。

產生該問題的可能原因及對應的處理措施如下。

產生原因	描述	處理措施
代碼存在缺陷	代碼缺陷，例如：代碼中的`join`條件有誤，寫為了笛卡爾積。 UDTF不合理，輸出資料量遠大於輸入資料量。	修正代碼。
彙總操作引起的資料膨脹	大多數彙總操作是具備遞迴性的，會對中間結果進行合并（MERGE）。通常中間結果資料量不大，而且大多數彙總操作的計算複雜度比較低，即使資料量不小，也能較快完成。所以通常情況下，彙總操作的問題不大。但某些彙總操作，例如`collect_list`、`median`，需要把全量中間資料都保留下來，在配合其他彙總用法時，可能會產生資料膨脹，例如：在`select`中使用彙總操作，並按照不同維度做去重（DISTINCT），每一次去重都會使資料膨脹。使用`grouping sets`、`cube`、`rollup`，中間資料可能會擴充很多倍。	避免使用彙總的特殊用法。
`join`操作引起的資料膨脹	例如，對兩個表執行`join`操作，左表是人口資料，資料量很大。右表是張維表，記錄每種性別對應的一些資訊。雖然只有兩種性別，但是每種性別都包含數百行資料。如果直接按照性別執行`join`，可能會讓左表資料膨脹數百倍。	對右表的行做彙總操作後，再與左表執行`join`操作，即可規避資料膨脹問題。