本文來自twt企業(yè)IT社區(qū)，作者某金融機(jī)構(gòu)架構(gòu)師 李威。
海量小文件，不僅是一個(gè)行業(yè)難題，更是一個(gè)世界性難題，各行各業(yè)的諸多場景下都存在類似困境。此類問題難以根治，一部分原因是傳統(tǒng)存儲(chǔ)解決方案無法高效匹配海量小文件的場景，另一部分原因是從傳統(tǒng)存儲(chǔ)切換到對(duì)象存儲(chǔ)的成本略高。此前，針對(duì)影像系統(tǒng)和打印系統(tǒng)的海量小文件場景，我們?cè)ㄙM(fèi)大量的時(shí)間和精力來優(yōu)化海量小文件的業(yè)務(wù)存儲(chǔ)。借此機(jī)會(huì)拋磚引玉，來深入聊一下海量小文件問題，分享些許我們?cè)诤Ａ啃∥募?yōu)化上的一點(diǎn)心得。
對(duì)于海量小文件的定義，行業(yè)上尚未有精確規(guī)定，更像一個(gè)事實(shí)標(biāo)準(zhǔn)，而非定義標(biāo)準(zhǔn)。一般情況下，單個(gè)文件的體積并不大，一般為數(shù)十KB至數(shù)MB，但數(shù)量規(guī)模數(shù)十萬甚至百萬以上級(jí)別之巨，這類場景我們稱為“海量小文件”。海量小文件通常呈現(xiàn)出一種非結(jié)構(gòu)化文件的大小與數(shù)量極不平衡的特性，也正是難以根治的癥結(jié)所在。
在金融保險(xiǎn)的業(yè)務(wù)系統(tǒng)中，以壽險(xiǎn)為例，有兩大核心系統(tǒng)最易形成海量小文件場景：一是影像系統(tǒng)，影像系統(tǒng)中需要存儲(chǔ)大量非結(jié)構(gòu)化數(shù)據(jù)，如保險(xiǎn)人相關(guān)的證件、圖片、PDF文件等，同時(shí)還有海量的業(yè)務(wù)過程文件，如交易報(bào)文、日志記錄等；二是打印系統(tǒng)，打印系統(tǒng)會(huì)生成大量的電子保單，同樣存在大量過程文件，如渠道交易圖像、電子簽名照片、電子合同、相關(guān)OCR文件等。這兩大系統(tǒng)中圖像類文件在MB級(jí)別，中間過程文件在KB級(jí)別，相對(duì)比之下中間過程文件的數(shù)量級(jí)遠(yuǎn)高于影像類文件，單個(gè)系統(tǒng)存儲(chǔ)的非結(jié)構(gòu)化數(shù)據(jù)量在TB級(jí)別以上。伴隨業(yè)務(wù)高峰期的到來，單目錄下小文件數(shù)量可達(dá)百萬級(jí)別，嚴(yán)重影響目錄的讀寫效率，甚至長時(shí)間無響應(yīng)。
在我們的業(yè)務(wù)實(shí)踐中，單目錄下小文件數(shù)量達(dá)到一定規(guī)模后，該共享存儲(chǔ)目錄的讀寫效率會(huì)出現(xiàn)顯著下降，但影像系統(tǒng)與打印系統(tǒng)對(duì)這些非結(jié)構(gòu)化數(shù)據(jù)的IOPS要求并不低。根據(jù)業(yè)務(wù)險(xiǎn)種及渠道的不同，對(duì)保險(xiǎn)人影像件的調(diào)取、電子保單的合成一般都要求在數(shù)秒之間，實(shí)時(shí)單批次電子保單合成同樣如此，非實(shí)時(shí)大批量電子保單合成不超過數(shù)分鐘。
海量小文件不僅會(huì)對(duì)在線業(yè)務(wù)的IOPS有很大影響，而且對(duì)這部分業(yè)務(wù)數(shù)據(jù)的連續(xù)數(shù)據(jù)保護(hù)也構(gòu)成巨大挑戰(zhàn)。根據(jù)監(jiān)管單位的關(guān)鍵業(yè)務(wù)數(shù)據(jù)保留要求，近三年至五年的數(shù)據(jù)均需要可回溯，所有數(shù)據(jù)均需要永久保留。夜間閑時(shí)窗口，是數(shù)據(jù)備份的重要時(shí)間段，錯(cuò)開核心業(yè)務(wù)夜間核心批處理作業(yè)時(shí)間后，數(shù)據(jù)保護(hù)的執(zhí)行窗口相當(dāng)有限。然而當(dāng)使用備份軟件對(duì)海量小文件進(jìn)行備份、歸檔時(shí)，發(fā)現(xiàn)在數(shù)據(jù)掃描階段會(huì)消耗大量時(shí)間掃描小文件來建立備份索引。數(shù)據(jù)備份階段，數(shù)百萬計(jì)的小文件將寫入磁帶或歸檔存儲(chǔ)，速率極其低效。若再加上網(wǎng)絡(luò)等相關(guān)因素影響，海量小文件的備份歸檔窗口將遠(yuǎn)超計(jì)劃，甚至以天計(jì)算。
造成海量小文件存儲(chǔ)如此低效的根源到底是什么？為什么至今還能成為一個(gè)世界性的難題？
要想明白這個(gè)問題，就得回到存儲(chǔ)本身來追根溯源了。
首先，主要是存儲(chǔ)介質(zhì)問題。傳統(tǒng)的存儲(chǔ)以機(jī)械磁盤為主要介質(zhì)，而機(jī)械磁盤適合順序的大文件IO讀寫，不適合隨機(jī)的小文件IO讀寫。因此海量小文件的體積、數(shù)量都會(huì)進(jìn)一步加劇機(jī)械磁盤的劣勢。
其次是數(shù)據(jù)效率問題。傳統(tǒng)磁盤文件系統(tǒng)體系結(jié)構(gòu)依靠目錄項(xiàng)(Dentry)、索引節(jié)點(diǎn)(Inode)以及數(shù)據(jù)塊(Data)來指導(dǎo)、定位、讀寫文件系統(tǒng)的數(shù)據(jù)，而目錄項(xiàng)(Dentry)、索引節(jié)點(diǎn)(Inode)以及數(shù)據(jù)塊(Data)均存儲(chǔ)在不同地方，也就是說一次隨機(jī)文件讀寫至少進(jìn)行3次獨(dú)立訪問。面對(duì)海量小文件場景時(shí)，海量小文件的并發(fā)讀寫匯聚形成了大量的隨機(jī)訪問，磁盤文件系統(tǒng)的體系機(jī)制放大了IO的體量，大幅降低磁盤的吞吐。
再者，磁盤文件系統(tǒng)的索引結(jié)構(gòu)在海量小文件場景下無法發(fā)揮優(yōu)勢。磁盤文件系統(tǒng)通常采用Hash、B+樹組織索引，當(dāng)面對(duì)單目錄下數(shù)以百萬計(jì)的小文件時(shí)，索引的增刪改查將消耗非常多系統(tǒng)資源，甚至耗盡。這一點(diǎn)在對(duì)象存儲(chǔ)的體系結(jié)構(gòu)里得到了極大的優(yōu)化和改善，如圖1。
圖1傳統(tǒng)NAS存儲(chǔ)與對(duì)象存儲(chǔ)體系結(jié)構(gòu)
最后是操作系統(tǒng)IO訪問機(jī)制受制。以LinuxVirtual Filesystem（簡稱VFS）為例，VFS提供了統(tǒng)一訪問接口和流程，方便與不同磁盤文件系統(tǒng)的對(duì)接與擴(kuò)展。VFS的四種對(duì)象的交互太復(fù)雜，我們重點(diǎn)關(guān)注Process與VFS之間的交互操作，簡化Linux I/O堆棧（如圖2）。
圖2 Linux I/O Stack簡化版
當(dāng)應(yīng)用觸發(fā)文件的隨機(jī)訪問時(shí)，會(huì)調(diào)用一組Syscall去完成文件的操作訪問，如open()/seek()/read()/write()/close()等。在這組Syscall中，open()將對(duì)文件進(jìn)行路徑查找，將操作系統(tǒng)層級(jí)上的路徑名轉(zhuǎn)換成其在內(nèi)核中的表示。open()涉及大量的關(guān)聯(lián)操作，非常消耗系統(tǒng)資源，尤其是針對(duì)深層次目錄下的文件進(jìn)行訪問。在海量小文件場景下，大量深層次文件的檢索直接劣化了open()操作的效率。
隨著IT信息科技的發(fā)展，針對(duì)海量小文件場景已經(jīng)推出了對(duì)象存儲(chǔ)。與傳統(tǒng)存儲(chǔ)不同，對(duì)象存儲(chǔ)在體系結(jié)構(gòu)上更加扁平，OIDs映射Object對(duì)象，直接通過唯一標(biāo)識(shí)定位文件,不論訪問什么數(shù)據(jù)，都能實(shí)高效響應(yīng),既解決了文件系統(tǒng)體系結(jié)構(gòu)的低效，又屏蔽了文件目錄深度帶來的巨大開銷。
然而，使用對(duì)象存儲(chǔ)雖然優(yōu)化了海量小文件場景的訪問效率問題，但作為非結(jié)構(gòu)化文件的主存儲(chǔ)也會(huì)面臨些許問題：數(shù)據(jù)保護(hù)手段薄弱、主流備份軟件對(duì)對(duì)象存儲(chǔ)的備份支持尚未完善、無法實(shí)現(xiàn)全功能數(shù)據(jù)保護(hù)等。雖然可以借助對(duì)象存儲(chǔ)的跨域復(fù)制形成數(shù)據(jù)冗余，但不滿足監(jiān)管單位對(duì)關(guān)鍵數(shù)據(jù)離線保存的要求。同時(shí)，不同于傳統(tǒng)NAS存儲(chǔ)，對(duì)象存儲(chǔ)的讀寫方式也發(fā)生了變化，因此涉及業(yè)務(wù)代碼改造。存儲(chǔ)更替的過程還涉及大量的業(yè)務(wù)數(shù)據(jù)遷移等。
且由傳統(tǒng)存儲(chǔ)切換到對(duì)象存儲(chǔ)，對(duì)于企業(yè)的代價(jià)也是相當(dāng)大的。影像系統(tǒng)和打印系統(tǒng)，都屬于保險(xiǎn)業(yè)務(wù)核心，多采用NAS存儲(chǔ)業(yè)務(wù)數(shù)據(jù)，數(shù)十年的更迭都未曾改變。影像、打印系統(tǒng)牽一發(fā)而動(dòng)全身，若需更替存儲(chǔ)，涉及大量業(yè)務(wù)代碼改造。影像、打印系統(tǒng)的割接也必須“一刀切”快速切換，無法容忍長時(shí)間的業(yè)務(wù)中斷。
那么該如何優(yōu)化海量小文件呢？
海量小文件所在的環(huán)境及鏈路若未更改，優(yōu)化的范圍就相當(dāng)有限，唯有從海量小文件結(jié)構(gòu)入手，優(yōu)化實(shí)踐的思路大概分為三步：
（1）優(yōu)化目錄層次結(jié)構(gòu)。
深層次的目錄結(jié)構(gòu)極大劣化了IO效率，使得文件尋址定位消耗大量的系統(tǒng)資源。過深的目錄層次更加劇了海量小文件的歸檔難度。結(jié)合業(yè)務(wù)實(shí)際，我們對(duì)影像的存儲(chǔ)目錄進(jìn)行了最多6層級(jí)的設(shè)計(jì)，以存儲(chǔ)掛載點(diǎn)目錄為根，第一級(jí)子目錄為渠道目錄，從不同渠道上傳、回寫的數(shù)據(jù)存放至對(duì)應(yīng)目錄。第二級(jí)子目錄為業(yè)務(wù)功能目錄，建立各場景對(duì)應(yīng)的數(shù)據(jù)目錄，數(shù)據(jù)按照既定的規(guī)則寫入。第三級(jí)至第六級(jí)，分別對(duì)應(yīng)年—月—周，方便數(shù)據(jù)以時(shí)間單位歸檔。值得一提的是“周”目錄邏輯作了簡化，我們始終以每月的1-7日為第一個(gè)周目錄，8-14為第二個(gè)周目錄，以此類推。
目錄層次的設(shè)計(jì)需要貼合業(yè)務(wù)實(shí)際。在我們的設(shè)計(jì)中，渠道目錄為第一級(jí)子目錄，兼顧了各渠道下的差異，方便各渠道已開展的差異化業(yè)務(wù)都能有對(duì)應(yīng)數(shù)據(jù)存儲(chǔ)目標(biāo)。“周”目錄的設(shè)計(jì)沒有按照常規(guī)周的方式設(shè)置，直接規(guī)定7天為一個(gè)周目錄，保持最末子目錄的統(tǒng)一性，也屏蔽星期幾帶來的難度升級(jí)。
（2）冷熱分離、使用SSD緩存熱數(shù)據(jù)，數(shù)據(jù)遇冷后轉(zhuǎn)移至NAS存儲(chǔ)。
冷熱分離能最大化生產(chǎn)實(shí)時(shí)業(yè)務(wù)的IO效率，實(shí)時(shí)業(yè)務(wù)數(shù)據(jù)寫入SSD上經(jīng)過優(yōu)化的目錄層次，小文件不會(huì)明顯大量堆積，IO效率保持穩(wěn)定。同時(shí)SSD高吞吐優(yōu)勢，提供了冷熱分離操作的性能基礎(chǔ)，分離時(shí)不會(huì)大幅降低實(shí)時(shí)業(yè)務(wù)IO。冷熱分離策略可通過腳本或者應(yīng)用完成，建議至少保證1個(gè)月的業(yè)務(wù)數(shù)據(jù)作為在線數(shù)據(jù)。
（3）數(shù)據(jù)歸檔。
數(shù)據(jù)歸檔是優(yōu)化的核心之一，其維系著SSD性能發(fā)揮與NAS存儲(chǔ)效率的平衡。數(shù)據(jù)由熱轉(zhuǎn)冷時(shí)，同步進(jìn)行打包、壓縮、歸檔處理，進(jìn)在“周”目錄對(duì)冷數(shù)據(jù)目錄進(jìn)行打包壓縮，將小文件壓縮匯聚成大文件。離散的小文件數(shù)據(jù)都在“周”目錄層級(jí)，打包壓縮后會(huì)大幅降低小文件的量級(jí)，將離散的小文件轉(zhuǎn)換為數(shù)據(jù)塊連續(xù)的大文件，既方便數(shù)據(jù)歸檔離線，也大大提高了備份恢復(fù)的效率，如圖3。
圖3影像海量小文件優(yōu)化實(shí)踐示意圖
針對(duì)傳統(tǒng)共享存儲(chǔ)海量小文件場景，數(shù)據(jù)目錄結(jié)構(gòu)的設(shè)計(jì)存在局限性和可維護(hù)性差的劣勢，有同行反饋可以借鑒一些中高端存儲(chǔ)的功能設(shè)計(jì)，如：訪問目錄優(yōu)化，大小IO識(shí)別，冷熱緩存，自動(dòng)歸檔等等特性。
在我們對(duì)影像、打印系統(tǒng)的海量小文件進(jìn)行治理時(shí)，就想到了這些優(yōu)化手段并將其中的部分思路進(jìn)行了實(shí)踐，簡單分享下我們的優(yōu)化心得：
1.數(shù)據(jù)目錄優(yōu)化
優(yōu)化前我們對(duì)影像、打印系統(tǒng)的業(yè)務(wù)邏輯和數(shù)據(jù)邏輯進(jìn)行了調(diào)研，涉及分支機(jī)構(gòu)、合作單位、各級(jí)渠道類別繁多，每家實(shí)現(xiàn)業(yè)務(wù)功能、交互數(shù)據(jù)有明顯區(qū)別。因此，我們結(jié)合系統(tǒng)實(shí)際重新設(shè)計(jì)了共享存儲(chǔ)的數(shù)據(jù)目錄結(jié)構(gòu)，以渠道目錄為主要區(qū)分，按照業(yè)務(wù)功能做數(shù)據(jù)歸集，同時(shí)對(duì)業(yè)務(wù)功能內(nèi)數(shù)據(jù)按照“年-月-周”分類，減輕單一目錄下小文件聚集的問題。目錄結(jié)構(gòu)的設(shè)計(jì)方法是多樣化的，怎么減輕目錄優(yōu)化給業(yè)務(wù)數(shù)據(jù)處理邏輯代碼的改動(dòng)最小才是關(guān)鍵。
2.大小IO識(shí)別
NAS存儲(chǔ)的大小IO識(shí)別功能，在海量小文件場景下發(fā)揮的效能十分有限，我們?cè)M(jìn)行簡單測試，百萬級(jí)別小文件隨機(jī)讀寫效率在開啟NAS IO優(yōu)化功能前后并沒有拉開差距，這也說明“IO數(shù)據(jù)流”讀寫效率并不是海量小文件的根因。
由于共享目錄的數(shù)據(jù)讀寫已經(jīng)是在文件系統(tǒng)層之上的實(shí)現(xiàn)，做大小IO智能識(shí)別就不現(xiàn)實(shí)了，但這也給我們提供了一種思路：可以把小文件的隨機(jī)IO聚合成大文件的連續(xù)IO。在數(shù)據(jù)目錄優(yōu)化之后，根據(jù)各系統(tǒng)模塊對(duì)歷史數(shù)據(jù)保留的需求，對(duì)“年”“月”“周”目錄進(jìn)行周期性打包壓縮，方便后續(xù)對(duì)歷史數(shù)據(jù)的處理。
3.冷熱緩存
在共享存儲(chǔ)IO優(yōu)化的測試后，我們緊跟了冷熱分層的緩存功能測試，測試效果如預(yù)期一致，也沒有明顯改善。在這一部分，我們想到了在OS層面做了冷熱分離，近期數(shù)據(jù)在SSD磁盤上，歷史數(shù)據(jù)在NAS上。這種冷熱存儲(chǔ)分層的優(yōu)化，并沒有改變小文件的存取效率，但提供了對(duì)歷史數(shù)據(jù)打包、壓縮、歸檔以及備份等綜合處理的性能基礎(chǔ)。
4.自動(dòng)歸檔
歸檔最初的設(shè)計(jì)是針對(duì)歷史數(shù)據(jù)的永久性保存，將時(shí)間久遠(yuǎn)的歷史數(shù)據(jù)處理完成后轉(zhuǎn)存至NAS上，再由備份恢復(fù)軟件進(jìn)行離線出庫。后來根據(jù)業(yè)務(wù)的調(diào)研，發(fā)現(xiàn)可以將部分非實(shí)時(shí)數(shù)據(jù)異步處理后歸檔至NAS，進(jìn)一步減緩海量小文件的發(fā)生。熱數(shù)據(jù)轉(zhuǎn)冷后一連串的打包、壓縮、歸檔，我們使用統(tǒng)一的定制化腳本實(shí)現(xiàn)或直接由應(yīng)用程序的數(shù)據(jù)處理部分代碼實(shí)現(xiàn)，若操作失敗則發(fā)送告警信息。離線出庫也是如此，正式備份前會(huì)調(diào)用特定腳本去檢查數(shù)據(jù)的完整性，若缺失數(shù)據(jù)目錄也告警通知負(fù)責(zé)人介入。
