Hadoop分布式文件系統(tǒng)針對日志型小文件的存儲和處理方法
【技術(shù)領(lǐng)域】
[0001] 本發(fā)明涉及計算機HDFS分布式文件系統(tǒng)領(lǐng)域，具體涉及一種HDFS針對日志型小 文件存儲和處理方法。
【背景技術(shù)】
[0002] HDFS是Hadoop Distributed File System的簡稱，是一個分布式文件存儲系統(tǒng)。
[0003] 隨著互聯(lián)網(wǎng)的應(yīng)用滲透到人們生活的方方面面，越來越多的設(shè)備被加入到互聯(lián)網(wǎng) 中。這些設(shè)備時時刻刻都在生產(chǎn)著數(shù)據(jù)，我們需要處理的數(shù)據(jù)的量和種類越來越多。Hadoop 下的HDFS作為GFS的開源實現(xiàn)，對大文件處理相當(dāng)出色，但是處理小文件的效率十分低下。 具體體現(xiàn)在大量小文件占用NameNode內(nèi)存資源及DataNode磁盤利用率低。
[0004] 業(yè)界已經(jīng)嘗試了一些HDFS針對小文件的優(yōu)化方法。但是這些方法都偏重于存儲， 提供的接口對Hadoop計算框架MapReduce并不透明，使得針對小文件的分析處理變得復(fù)雜 了。既能高效的存儲小文件又能保持與MapReduce框架兼容是一項極具意義且富有挑戰(zhàn)的 工作。
[0005] 所謂日志型小文件，是指由數(shù)據(jù)源（可以是物理的采集設(shè)備也可以是數(shù)據(jù)源抓 取、生成程序）產(chǎn)生的，與時序相關(guān)的一系列帶有相似結(jié)構(gòu)且一般具有相似含義的小型數(shù) 據(jù)塊（小文件）。

【發(fā)明內(nèi)容】

[0006] 本發(fā)明的目的是克服現(xiàn)有技術(shù)的不足，提供一種HDFS針對日志型小文件的存儲 和處理方法，將文件按物理位置就近合并，同時使用Copy-On-Write機制優(yōu)化小文件的讀 寫。該方法能夠有效解決HDFS處理日志型小文件的效率低下，同時提供的存儲接口與 MapReduce框架兼容。
[0007] 本發(fā)明所采用的技術(shù)方案為：HDFS包括一個Hadoop集群，集群中包含一個名字節(jié) 點NameNode和多個數(shù)據(jù)節(jié)點DataNode，多個客戶端通過客戶端庫訪問Hadoop集群存儲的 文件，本發(fā)明將日志型小文件按照物理路徑就近合并，客戶端讀寫日志型小文件時先從名 字節(jié)點NameNode讀取合并文件和合并文件索引的元數(shù)據(jù)Metadata信息，然后根據(jù)合并文 件索引從合并文件中讀寫各個日志型小文件數(shù)據(jù)；客戶端讀寫非日志型小文件時流程保持 不變（保持原生HDFS的處理方式）。
[0008] 名字節(jié)點NameNode管理所有HDFS文件的元數(shù)據(jù)Metadata，包括普通HDFS文件 (即，非所述日志型小文件）以及合并文件的元數(shù)據(jù)Metadata，日志型小文件對名字節(jié)點 NameNode是透明的，合并文件對客戶端程序是透明的。客戶端程序庫提供與常規(guī)HDFS API 一致的接口供客戶端程序讀寫日志型小文件。
[0009] 日志型小文件的合并是按物理路徑就近合并的，具體來說，同一目錄下（不包含 子目錄）的日志型小文件被合并為一個文件，稱之為合并文件MergeFile。日志型小文件 的元數(shù)據(jù)Metadata被順序存入一個文件，稱之為合并文件索引Mergelndex。合并文件 MergeFile與合并文件索引MergeIndex位于原HDFS目錄下，采用保留的文件名命名；日志 型小文件被合并之后其對應(yīng)的HDFS文件對象及元數(shù)據(jù)Metadata結(jié)構(gòu)將從HDFS中刪除。 MergeFile支持追加、修改、刪除操作，追加、修改、刪除的原子操作單位都是日志型小文件； MergeFile修改過后，MergeIndex也做出對應(yīng)改變，文件的追加、修改、刪除均通過向合并 文件索引中追加文件項記錄完成。
[0010] 客戶端讀寫特定路徑的文件時，先嘗試從名字節(jié)點NameNode讀取文件的元數(shù)據(jù) Metadata信息，如果讀取成功則說明該文件是普通HDFS文件，按照HDFS原生處理流程處 理，如果讀取失敗則說明該文件或者是一個日志型小文件或者不存在，此時需要獲取該文 件路徑父目錄下的Mergelndex，并搜索待讀寫的文件名。如果搜索成功則說明該路徑指向 一個被合并的文件，讀寫操作轉(zhuǎn)入MergeFile的處理流程，如果搜索失敗則說明該路徑不 存在。
[0011] 客戶端程序讀取日志型小文件時客戶端程序庫返回一個與HDFS原生API兼容的 文件輸入流對象，任何針對該對象的讀操作都將重定向至目標(biāo)文件在MergeFiIe中的對應(yīng) 數(shù)據(jù)塊。該文件流對象確保客戶程序不會讀取到目標(biāo)文件數(shù)據(jù)之外的任何數(shù)據(jù)。
[0012] 客戶端程序?qū)懭肴罩拘托∥募r，若目標(biāo)文件已存在于MergeFile，客戶端庫建 立一份HDFS文件格式的目標(biāo)文件數(shù)據(jù)的副本，返回一個與該副本文件關(guān)聯(lián)的文件輸出流 對象，對目標(biāo)文件的寫操作重定向至副本文件。輸出流對象被關(guān)閉時文件副本被合并回 MergeFile0
[0013] 日志型小文件的合并發(fā)生于文件寫入結(jié)束，也即是以寫方式打開文件后關(guān)閉文 件時進行文件合并。合并操作分為三類情形：（1)當(dāng)前寫入的文件是新創(chuàng)建的文件，此時 文件被追加至MergeFile末尾，在MergeIndex文件中同時追加一條記錄，記錄當(dāng)前文件 的文件名、在MergeFile中的偏移量、文件大小、文件所屬用戶、權(quán)限、刪除標(biāo)記及其他元 數(shù)據(jù)Metadata。（2)當(dāng)前寫入的文件是已經(jīng)存在的文件，并確有數(shù)據(jù)修改發(fā)生，此時先從 MergeFile中刪除原文件，再將寫入的文件追加至MergeFile。（3)當(dāng)前寫入的文件是已經(jīng) 存在的文件，但是沒有數(shù)據(jù)修改，此時直接拋棄當(dāng)前文件。
[0014] 刪除所述日志型小文件的操作通過向合并文件索引中追加一條墓碑記錄完成，日 志型小文件的數(shù)據(jù)在下一次整理合并文件之前都不會被從磁盤清除；墓碑記錄中，刪除標(biāo) 志位FileDeleted被置為1 ;在文件搜索過程中，F(xiàn)ileDeleted為1的文件被作為無效數(shù)據(jù) 忽略。文件整理操作是根據(jù)MergeIndex中有效的項，即排除FileDeleted為1的項，重建 MergeFile的過程；經(jīng)過文件整理操作后，MergeFile和MergeIndex不再包含無效的文件數(shù) 據(jù)。
[0015] MergeIndex和MergeFile的碎片化程度由兩個指標(biāo)衡量：目錄文件碎片率FF和 目錄磁盤碎片率DF，任一指標(biāo)超過設(shè)定的閾值都將觸發(fā)文件整理操作；整理結(jié)束后，F(xiàn)F = 0%且DF = 0%。其中，目錄文件碎片率FF定義為MergeIndex中無效文件數(shù)與總文件數(shù)之 比；目錄磁盤碎片率DF定義為MergeFile中無效數(shù)據(jù)字節(jié)與總文件數(shù)據(jù)字節(jié)之比。
[0016] 本發(fā)明的優(yōu)點是：本發(fā)明針對日志型小文件，提出了一種新的處理方法，該方法將 小文件metadata的內(nèi)存負(fù)擔(dān)從NameNode轉(zhuǎn)移到了客戶端，有效的解決了 HDFS處理大量小 文件的低效問題?？蛻舳司彺嫘∥募etadata也使得小文件的訪問得到加速，多次連續(xù) 訪問物理位置臨近的小文件時無需向NameNode請求metadata。解決了大量小文件引發(fā)的 NameNode內(nèi)存負(fù)載問題，以及客戶端向NameNode頻繁地請求元數(shù)據(jù)Metadata造成的性能 瓶頸。本發(fā)明的數(shù)據(jù)存儲接口與原生HDFS在應(yīng)用程序接口（API)層次兼容。
【附圖說明】
[0017] 圖1為MergeFile結(jié)構(gòu)示意圖。
[0018] 圖2為MergeIndex結(jié)構(gòu)不意圖。
[0019] 圖3為MergeIndex單個文件項所存儲的文件元數(shù)據(jù)結(jié)構(gòu)示意圖。
[0020] 圖4為本發(fā)明改進后的HDFS讀文件操作流程圖。
[0021] 圖5為本發(fā)明改進后的HDFS寫文件操作流程圖。
【具體實施方式】
[0022] 下面結(jié)合附圖和實施例對本發(fā)明作進一步說明。
[0023] 本發(fā)明包括一個Hadoop集群，集群中包含一個NameNode和多個DataNod