小文件背景知識(shí)

小文件定義

分布式文件系統(tǒng)按塊Block存放，文件大小比塊大小小的文件（默認(rèn)塊大小為64M），叫做小文件。

如何判斷存在小文件數(shù)量多的問題

查看文件數(shù)量

desc?extended?+?表名

判斷小文件數(shù)量多的標(biāo)準(zhǔn)

1、非分區(qū)表，表文件數(shù)達(dá)到1000個(gè)，文件平均大小小于64M
2、分區(qū)表: a) 單個(gè)分區(qū)文件數(shù)達(dá)到1000個(gè)，文件平均大小小于64M，
? ? ? ? ? ? ? ?b) 整個(gè)非分區(qū)表分區(qū)數(shù)達(dá)到五萬 （系統(tǒng)限制為6萬）

產(chǎn)生小文件數(shù)量多的主要原因

1、表設(shè)計(jì)不合理導(dǎo)致：分區(qū)多導(dǎo)致文件多，比如按天按小時(shí)按業(yè)務(wù)單元（假如有6個(gè)業(yè)務(wù)單元BU）分區(qū)，那么一年下來，分區(qū)數(shù)將會(huì)達(dá)到365246=52560。
2、在使用Tunnel、Datahub、Console等數(shù)據(jù)集成工具上傳上傳數(shù)據(jù)時(shí)，頻繁Commit，寫入表（表分區(qū)）使用不合理導(dǎo)致：每個(gè)分區(qū)存在多個(gè)文件，文件數(shù)達(dá)到幾百上千，其中大多數(shù)是大小只有幾 k 的小文件。
3、在使用insert into寫入數(shù)據(jù)時(shí)過，幾條數(shù)據(jù)就寫入一次，并且頻繁的寫入。
4、Reduce過程中產(chǎn)生小文件過多。
5、Job執(zhí)行過程中生成的各種臨時(shí)文件、回收站保留的過期的文件過多。

注意：雖然在MaxCompute系統(tǒng)側(cè)會(huì)自動(dòng)做小文件合并的優(yōu)化，但對于原因1、2、3需要客戶采用合理的表分區(qū)設(shè)計(jì)和上傳數(shù)據(jù)的方法才可以避免。

小文件數(shù)量過多產(chǎn)生的影響

MaxCompute處理單個(gè)大文件比處理多個(gè)小文件更有效率，小文件過多會(huì)影響整體的執(zhí)行性能;小文件過多會(huì)給文件系統(tǒng)帶來一定的壓力，且影響空間的有效利用。MaxCompute對單個(gè)fuxi Instance可以處理的小文件數(shù)限制為120個(gè)，文件數(shù)過多影響fuxi instance數(shù)目，影響整體性能。

合并小文件命令

set?odps.merge.max.filenumber.per.job=50000;?--值默認(rèn)為50000個(gè)；當(dāng)分區(qū)數(shù)大于50000時(shí)需要調(diào)整，最大可到1000000萬，大于1000000的提交多次merge
ALTER?TABLE?表名[partition]?MERGE?SMALLFILES;

如何合并小文件

分區(qū)表：

如果您的表已經(jīng)是分區(qū)表，請檢查您的分區(qū)字段是否是可收斂的，如果分區(qū)數(shù)過多同樣會(huì)影響計(jì)算性能，建議用日期做分區(qū)。
1、定期執(zhí)行合并小文件命令；
2、如果是按日期建的分區(qū)，可以每天對前一天的分區(qū)數(shù)據(jù)用insert overwrite重新覆蓋寫入。
例如：

insert?overwrite?table?tableA?partition?(ds='20181220')
select?*?from?tableA?where?ds='20181220';

非分區(qū)表：

如果您的表是非分區(qū)表，您可以定期執(zhí)行合并小文件命令來優(yōu)化小文件問題，但強(qiáng)烈建議您設(shè)計(jì)成分區(qū)表：
1、先創(chuàng)建一個(gè)新的分區(qū)表，建議按日期做分區(qū)，合理設(shè)置生命周期，以方便進(jìn)行歷史數(shù)據(jù)回收；
2、把原非分區(qū)表的數(shù)據(jù)導(dǎo)入新的分區(qū)表；（建議先暫停原非分區(qū)表的實(shí)時(shí)寫入業(yè)務(wù)）
例如：

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;

3、修改上下游業(yè)務(wù)：入庫程序改成寫入新分區(qū)表，查詢作業(yè)改成從新分區(qū)表中查詢；
4、新分區(qū)表完成數(shù)據(jù)遷移和驗(yàn)證后，刪除原分區(qū)表。

注意：如果您使用insert overwrite重新寫入全量數(shù)據(jù)合并小文件時(shí)，請注意一定不要同時(shí)存在insert overwrite和insert into同時(shí)存在的情況，否則有丟失數(shù)據(jù)的風(fēng)險(xiǎn)。

如何避免產(chǎn)生小文件

優(yōu)化表設(shè)計(jì)

合理設(shè)計(jì)表分區(qū)，分區(qū)字段是盡量是可收斂或可管理的，如果分區(qū)數(shù)過多同樣會(huì)影響計(jì)算性能，建議用日期做分區(qū)，并合理設(shè)置表的生命周期，以方便對歷史數(shù)據(jù)回收，也可控制您的存儲(chǔ)成本。
參考文章：《MaxCompute 表(Table)設(shè)計(jì)規(guī)范》、《MaxCompute表設(shè)計(jì)最佳實(shí)踐》

避免使用各種數(shù)據(jù)集成工具產(chǎn)生小文件

1、Tunnel->MaxCompute
使用Tunnel上傳數(shù)據(jù)時(shí)避免頻繁commit，盡量保證每次提交的DataSize大于64M，請參考《離線批量數(shù)據(jù)通道Tunnel的最佳實(shí)踐及常見問題》

2、Datahub->MaxCompute
如果用Datahub產(chǎn)生小文件，建議合理申請shard，可以根據(jù)topic的Throughput合理做shard合并，減少shard數(shù)量。可以根據(jù)topic的Throughput觀察數(shù)據(jù)流量變化，適當(dāng)調(diào)大數(shù)據(jù)寫入的間隔時(shí)間。

申請Datahub shard數(shù)目的策略（申請過多的datahub shard將會(huì)產(chǎn)生小文件問題）
1）默認(rèn)吞吐量單個(gè)shard是1MB/s，可以按照這個(gè)分配實(shí)際的shard數(shù)目（可以在此基礎(chǔ)上多加幾個(gè)）；
2）同步MaxCompute的邏輯是每個(gè)shard有一個(gè)單獨(dú)的task（滿足5分鐘或者64MB會(huì)commit一次），默認(rèn)設(shè)置5分鐘是為了盡快能在MaxCompute查到數(shù)據(jù)。如果是按照小時(shí)建partition，那個(gè)一個(gè)shard每個(gè)小時(shí)有12個(gè)文件。如果這個(gè)時(shí)候數(shù)據(jù)量很少，但是shard很多，在MaxCompute里面就會(huì)很多小文件（shard*12/hour）。所以不要過多的分配shard，按需分配。

參考建議：如果流量是5M/s，那么就申請5個(gè)shard，為預(yù)防流量峰值預(yù)留20%的Buffer，可以申請6個(gè)shard。

3、DataX->MaxCompute
因?yàn)閐atax也是封裝了tunnel的SDK來寫入MaxCompute的，因此，建議您在配置ODPSWriter的時(shí)候，把blockSizeInMB這個(gè)參數(shù)不要設(shè)置太小，最好是64M以上。

?