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

是 的基本使用單位，包含全部表和專案的相關資訊，可以對錶做相關的許可權管理和 ，以及可以展示對應專案佔用情況和其表的佔用情況。資料地圖可以幫助使用者更好地查詢、理解和使用資料。

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

小檔案的危害

通常指檔案大小要比 HDFS 塊大小還要小很多的檔案，大量的小檔案會給 Hadoop 叢集的擴充套件性和效能帶來嚴重的影響。

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

同時，小檔案會給 Spark SQL 等查詢引擎造成查詢效能的損耗，大量的 以及對應產生的 Task 元資訊也會給 的記憶體造成壓力，帶來單點問題。此外，入庫操作最後的 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='小檔案合併記錄表';