乾貨分享|袋鼠雲數棧離線開發平臺在小檔案治理上的探索實踐之路
日常生產中 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='小檔案合併記錄表';
《資料治理行業實踐白皮書》下載地址:http://fs80.cn/380a4b
想了解或諮詢更多有關袋鼠雲大資料產品、行業解決方案、客戶案例的朋友,瀏覽袋鼠雲官網:http://www.dtstack.com/?src=szkyzg
同時,歡迎對大資料開源專案有興趣的同學加入「袋鼠雲開源框架釘釘技術qun」,交流最新開源技術資訊,qun號碼:30537511,專案地址:http://github.com/DTStack
- 乾貨分享|袋鼠雲數棧離線開發平臺在小檔案治理上的探索實踐之路
- 大資料計算引擎 EasyMR:擁抱開源,引領技術創新
- 資料湖選型指南|Hudi vs Iceberg 資料更新能力深度對比
- 深入理解 Taier:MR on Yarn 的實現原理
- 從5分鐘到60秒,袋鼠雲數棧在熱重啟技術上的提效探索之路
- 詳細剖析|袋鼠雲數棧前端框架Antd 3.x 升級 4.x 的踩坑之路
- Teradata在華落幕,國產化崛起,袋鼠雲數棧會是更好的選擇嗎?
- 大資料應用場景下,標籤策略如何實現價值最大化?
- 袋鼠雲數棧UI5.0煥新升級,全新設計語言DT Design,更懂視覺更懂你!
- 一看就懂!任務提交的資源判斷在Taier中的實踐
- 我的 React 最佳實踐
- 看這篇就夠了丨基於Calcite框架的SQL語法擴充套件探索
- 無監控,不運維!深入淺出介紹ChengYing監控設計和使用
- DAG任務排程系統 Taier 演進之道,探究DataSourceX 模組
- 數字孿生賦能智慧港口解決方案,助力港口數字化轉型
- Iceberg在袋鼠雲的探索及實踐
- Kerberos身份驗證在ChunJun中的落地實踐
- 從資料治理到資料應用,製造業企業如何突破數字化轉型困境丨行業方案
- 行業方案 | 新規落地,企業集團財務公司如何構建數智財務體系?
- 資料安全新戰場,EasyMR為企業築起“安全防線”