日常生產中 HDFS 上小檔案產生是一個很正常的事情，同時小檔案也是 Hadoop 集群運維中的常見挑戰，尤其對于大規模運行的集群來說可謂至關重要，

資料地圖是離線開發產品的基本使用單位，包含全部表和專案的相關資訊，可以對表做相關的權限管理和脫敏管理操作，以及可以展示對應專案占用情況和其表的占用情況，資料地圖可以幫助用戶更好地查找、理解和使用資料，

本文將結合兩者，和大家聊聊資料地圖中的小檔案治理應該怎么做，

小檔案的危害

小檔案通常指檔案大小要比 HDFS 塊大小還要小很多的檔案，大量的小檔案會給 Hadoop 集群的擴展性和性能帶來嚴重的影響，

NameNode 在記憶體中維護整個檔案系統的元資料鏡像、用戶 HDFS 的管理，其中每個 HDFS 檔案元資訊（位置、大小、分塊等）物件約占150位元組，如果小檔案過多，會占用大量記憶體，直接影響 NameNode 的性能，相對地，HDFS 讀寫小檔案也會更加耗時，因為每次都需要從 NameNode 獲取元資訊，并與對應的 DataNode 建立連接，如果 NameNode 在宕機中恢復，也需要更多的時間從元資料檔案中加載，

同時，小檔案會給 Spark SQL 等查詢引擎造成查詢性能的損耗，大量的資料分片資訊以及對應產生的 Task 元資訊也會給 Spark Driver 的記憶體造成壓力，帶來單點問題，此外，入庫操作最后的 commit job 操作，在 Spark Driver 端單點做，很容易出現單點的性能問題，

資料地圖中小檔案治理的做法

存盤在 HDFS 中的檔案被分成塊，然后將這些塊復制到多個計算機中（DataNode），塊的大小默認為128MB，當檔案大小為128時，Hadoop 集群的計算效率最高，因此對非磁區表按表進行資料檔案合并，使表/磁區資料檔案的大小接近128M，以此進行小檔案的優化，

具體到資料地圖中是怎么做的呢？

在離線開發平臺中創建出來的表或者底層表都可以通過資料地圖功能維護，我們每天會定時更新這些表的基本資訊進行統一維護管理，

在資料地圖中可以根據檔案數量和占用存盤創建相應的治理規則，按照每天每周或每月治理，

引數說明

· 規則名稱：新建規則的名稱

· 選擇專案：小檔案合并規則生效的專案

· 選擇表：這里配置的是圈定需要合并的表范圍，判斷條件是 and，例如表的檔案數量大于1000并且占用總存盤小于10M時，才會對該表中的檔案進行合并操作

· 治理時間：該規則的調度周期，例如每天的凌晨00:00～01:00進行小檔案合并，注意如果小檔案合并時間到了結束的時間，還沒有合并完成，則會結束當前的合并，等待下次處理

根據治理規則查詢出所有符合資訊的表，判斷該表是否為磁區表，如果為非磁區表則對該表進行檔案治理，如果為磁區表則按照磁區進行治理，最后創建治理記錄，

每天定時任務觸發，根據告警記錄查詢記錄中滿足條件的表的基本資訊狀態，

● 小檔案合并的具體步驟

1）備份檔案

先創建臨時路徑，把檔案復制到臨時路徑中去，再創建要合并的臨時檔案

2）小檔案合并

執行 HDFS 的 fileMerge 請求合并檔案

真正呼叫 hive-exec 方法處理,判斷是否達到閾值合并檔案

3）將合并的檔案覆寫到原檔案中去

判斷如果合并完成，洗掉原路徑下的資料，把臨時路徑修改為原來的真實路徑

全部處理完成后，查詢 rdos_file_merge_partition 表是否為例外資訊列印，若不存在例外資訊，更新治理記錄表完成治理，并更新資料地圖中的表資訊

治理記錄表把握整體的治理成功失敗狀態，磁區資訊治理信表維護了整個治理記錄哪些表治理失敗的記錄，最后全量回傳對應的是失敗或成功狀態，

· 磁區資訊治理信表：rdos_file_merge_partition

· 治理記錄表：rdos_file_merge_record

最后把表結構放在下面，有興趣的小伙伴可以自行查看：

CREATE TABLE `rdos_file_merge_partition` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `project_id` int(11) DEFAULT NULL COMMENT '專案id',
  `tenant_id` int(11) DEFAULT NULL COMMENT '租戶id',
  `record_id` int(11) DEFAULT NULL COMMENT '合并記錄id',
  `status` tinyint(1) DEFAULT NULL COMMENT '合并狀態',
  `start_time` datetime DEFAULT NULL COMMENT '開始時間',
  `end_time` datetime DEFAULT NULL COMMENT '結束時間',
  `error_msg` longtext COMMENT '錯誤資訊',
  `partition_name` varchar(255) DEFAULT NULL COMMENT '磁區名',
  `copy_location` varchar(1024) DEFAULT NULL COMMENT '備份路徑',
  `storage_before` varchar(255) DEFAULT NULL COMMENT '合并前占用存盤',
  `storage_after` varchar(255) DEFAULT NULL COMMENT '合并后占用存盤',
  `file_count_before` int(11) DEFAULT NULL COMMENT '合并前檔案數量',
  `file_count_after` int(11) DEFAULT NULL COMMENT '合并后檔案數量',
  `gmt_create` datetime DEFAULT NULL COMMENT '創建時間',
  `gmt_modified` datetime DEFAULT NULL COMMENT '修改時間',
  `is_deleted` tinyint(1) DEFAULT '0' COMMENT '是否洗掉 0：未洗掉，1 ：已洗掉',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='小檔案合并磁區資訊表';

CREATE TABLE `rdos_file_merge_record` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `project_id` int(11) DEFAULT NULL COMMENT '專案id',
  `tenant_id` int(11) DEFAULT NULL COMMENT '租戶id',
  `table_id` int(11) DEFAULT NULL COMMENT '合并hive表id',
  `table_name` varchar(255) DEFAULT NULL COMMENT '表名',
  `rule_id` int(11) DEFAULT NULL COMMENT '小檔案合并規則id',
  `location` varchar(1024) DEFAULT NULL COMMENT '存盤位置',
  `status` tinyint(1) DEFAULT NULL COMMENT '合并狀態',
  `error_msg` longtext COMMENT '錯誤資訊',
  `start_time` datetime DEFAULT NULL COMMENT '合并開始時間',
  `end_time` datetime DEFAULT NULL COMMENT '合并結束時間',
  `is_partition` tinyint(1) DEFAULT NULL COMMENT '是否是磁區表',
  `count_before` int(11) DEFAULT NULL COMMENT '合并前檔案數量',
  `count_after` int(11) DEFAULT NULL COMMENT '合并后檔案數量',
  `create_user_id` int(11) DEFAULT NULL COMMENT '創建用戶',
  `modify_user_id` int(11) DEFAULT NULL COMMENT '修改人id',
  `gmt_create` datetime DEFAULT NULL COMMENT '創建時間',
  `gmt_modified` datetime DEFAULT NULL COMMENT '修改時間',
  `is_deleted` tinyint(1) DEFAULT '0' COMMENT '是否洗掉 0:未洗掉， 1：已洗掉',
  `plan_time` datetime NOT NULL COMMENT '計劃時間',
  PRIMARY KEY (`id`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='小檔案合并記錄表';

《資料治理行業實踐白皮書》下載地址：https://fs80.cn/380a4b

想了解或咨詢更多有關袋鼠云大資料產品、行業解決方案、客戶案例的朋友，瀏覽袋鼠云官網：https://www.dtstack.com/?src=https://www.cnblogs.com/DTinsight/p/szbky

同時，歡迎對大資料開源專案有興趣的同學加入「袋鼠云開源框架釘釘技術qun」，交流最新開源技術資訊，qun號碼：30537511，專案地址：https://github.com/DTStack

標籤：大數據

上一篇：讀SQL進階教程筆記01_CASE運算式

下一篇：MySQL之 InnoDB 記憶體結構