MaxCompute小文件問題優化方案

小文件背景知識
小文件定義
分佈式文件系統按塊Block存放，文件大小比塊大小小的文件（默認塊大小爲64M），叫作小文件。

如何判斷存在小文件數量多的問題
查看文件數量

desc extended + 表名

判斷小文件數量多的標準
一、非分區表，表文件數達到1000個，文件平均大小小於64M
二、分區表: a) 單個分區文件數達到1000個，文件平均大小小於64M，

b) 整個非分區表分區數達到五萬 （系統限制爲6萬）

產生小文件數量多的主要緣由
一、表設計不合理致使：分區多致使文件多，好比按天按小時按業務單元（假若有6個業務單元BU）分區，那麼一年下來，分區數將會達到365246=52560。
二、在使用Tunnel、Datahub、Console等數據集成工具上傳上傳數據時，頻繁Commit，寫入表（表分區）使用不合理致使：每一個分區存在多個文件，文件數達到幾百上千，其中大多數是大小隻有幾 k 的小文件。
三、在使用insert into寫入數據時過，幾條數據就寫入一次，而且頻繁的寫入。
四、Reduce過程當中產生小文件過多。
五、Job執行過程當中生成的各類臨時文件、回收站保留的過時的文件過多。

注意：雖然在MaxCompute系統側會自動作小文件合併的優化，但對於緣由一、二、3須要客戶採用合理的表分區設計和上傳數據的方法才能夠避免。

小文件數量過多產生的影響
MaxCompute處理單個大文件比處理多個小文件更有效率，小文件過多會影響總體的執行性能;小文件過多會給文件系統帶來必定的壓力，且影響空間的有效利用。MaxCompute對單個fuxi Instance能夠處理的小文件數限制爲120個，文件數過多影響fuxi instance數目，影響總體性能。

合併小文件命令
set odps.merge.max.filenumber.per.job=50000; --值默認爲50000個；當分區數大於50000時須要調整，最大可到1000000萬，大於1000000的提交屢次merge
ALTER TABLE 表名[partition] MERGE SMALLFILES;
如何合併小文件
分區表：
若是您的表已是分區表，請檢查您的分區字段是不是可收斂的，若是分區數過多一樣會影響計算性能，建議用日期作分區。
一、按期執行合併小文件命令；
二、若是是按日期建的分區，能夠天天對前一天的分區數據用insert overwrite從新覆蓋寫入。
例如：

insert overwrite table tableA partition (ds='20181220')
select * from tableA where ds='20181220';
非分區表：
若是您的表是非分區表，您能夠按期執行合併小文件命令來優化小文件問題，但強烈建議您設計成分區表：
一、先建立一個新的分區表，建議按日期作分區，合理設置生命週期，以方便進行歷史數據回收；
二、把原非分區表的數據導入新的分區表；（建議先暫停原非分區表的實時寫入業務）
例如：

create table sale_detail_patition like sale_detail;
alter table sale_detail_insert add partition(sale_date='201812120', region='china');
insert overwrite table sale_detail_patition partition (sale_date='20181220', region='china')
select * from sale_detail;
三、修改上下游業務：入庫程序改爲寫入新分區表，查詢做業改爲重新分區表中查詢；
四、新分區表完成數據遷移和驗證後，刪除原分區表。

注意：若是您使用insert overwrite從新寫入全量數據合併小文件時，請注意必定不要同時存在insert overwrite和insert into同時存在的狀況，不然有丟失數據的風險。

如何避免產生小文件
優化表設計
合理設計表分區，分區字段是儘可能是可收斂或可管理的，若是分區數過多一樣會影響計算性能，建議用日期作分區，併合理設置表的生命週期，以方便對歷史數據回收，也可控制您的存儲成本。
參考文章：《MaxCompute 表(Table)設計規範》、《MaxCompute表設計最佳實踐》

避免使用各類數據集成工具產生小文件
一、Tunnel->MaxCompute
使用Tunnel上傳數據時避免頻繁commit，儘可能保證每次提交的DataSize大於64M，請參考《離線批量數據通道Tunnel的最佳實踐及常見問題》

二、Datahub->MaxCompute
若是用Datahub產生小文件，建議合理申請shard，能夠根據topic的Throughput合理作shard合併，減小shard數量。能夠根據topic的Throughput觀察數據流量變化，適當調大數據寫入的間隔時間。

申請Datahub shard數目的策略（申請過多的datahub shard將會產生小文件問題）
1）默認吞吐量單個shard是1MB/s，能夠按照這個分配實際的shard數目（能夠在此基礎上多加幾個）；
2）同步MaxCompute的邏輯是每一個shard有一個單獨的task（知足5分鐘或者64MB會commit一次），默認設置5分鐘是爲了儘快能在MaxCompute查到數據。若是是按照小時建partition，那個一個shard每一個小時有12個文件。若是這個時候數據量不多，可是shard不少，在MaxCompute裏面就會不少小文件（shard*12/hour）。因此不要過多的分配shard，按需分配。

參考建議：​​若是流量是5M/s，那麼就申請5個shard，爲預防流量峯值預留20%的Buffer，能夠申請6個shard。

三、DataX->MaxCompute由於datax也是封裝了tunnel的SDK來寫入MaxCompute的，所以，建議您在配置ODPSWriter的時候，把blockSizeInMB這個參數不要設置過小，最好是64M以上。