長(zhǎng)期歸檔數(shù)據(jù)格式調(diào)研匯總

1、歸檔格式研究工程協(xié)同研發(fā)過(guò)程涉及到多種工具，例如CAD軟件、PDM系統(tǒng)，產(chǎn)品設(shè)計(jì)數(shù)據(jù)一般有CAD模型、CAM模型、2D圖紙、文檔規(guī)范、有限元分析模型和各種報(bào)告等組成。傳統(tǒng)產(chǎn)品定義數(shù)據(jù)交換中間媒介是工程圖紙，工程圖紙也作為合法證據(jù)留存。專項(xiàng)裝置產(chǎn)品的生命周期通常超過(guò)50年，工程圖紙歸檔與長(zhǎng)期保存對(duì)于專項(xiàng)裝置產(chǎn)品來(lái)說(shuō)十分關(guān)鍵。目前，許多企業(yè)正在將傳統(tǒng)2D工程圖紙?zhí)鎿Q到更加先進(jìn)的3D標(biāo)注模型。因此，研究如何長(zhǎng)期保存3D條件下的產(chǎn)品定義數(shù)據(jù)十分必要和迫切。同時(shí)，軟件不斷過(guò)時(shí)導(dǎo)致計(jì)算機(jī)應(yīng)用程序、備份格式延續(xù)性受到挑戰(zhàn)。專業(yè)的工程設(shè)計(jì)軟件通常依賴于計(jì)算機(jī)平臺(tái)，隨著計(jì)算機(jī)平臺(tái)的不斷發(fā)展，專業(yè)工程設(shè)計(jì)軟件的數(shù)

2、據(jù)長(zhǎng)期保存問(wèn)題變得更加復(fù)雜。如何建立具備完整性、可持續(xù)性的數(shù)據(jù)倉(cāng)庫(kù)一直是近期研究熱點(diǎn)。1. 基于LOTAR項(xiàng)目研究成果的歸檔數(shù)據(jù)格式研究LOTAR（Long Term Archiving and Retrieval）是國(guó)際上一個(gè)著名的與航空工業(yè)相關(guān)的歸檔項(xiàng)目，該項(xiàng)目的參與者包括重要的航空工業(yè)企業(yè)（空客、波音、達(dá)索航空、洛克希德馬丁、BAE等）、監(jiān)管機(jī)構(gòu)（FAA、JAA等）和政府機(jī)構(gòu)（NASA、ESA、NIST等），LOTAR項(xiàng)目的目標(biāo)是歸檔3D CAD和PDM信息，并遵從監(jiān)管、法律和業(yè)務(wù)上的需求。該項(xiàng)目基于2個(gè)不斷改進(jìn)的標(biāo)準(zhǔn)：長(zhǎng)期歸檔系統(tǒng)框架OAIS，實(shí)際的產(chǎn)品定義數(shù)據(jù)標(biāo)準(zhǔn)STEP（即ISO1

3、0303）。1.1. 傳統(tǒng)數(shù)據(jù)保存技術(shù)傳統(tǒng)數(shù)字?jǐn)?shù)據(jù)的保存技術(shù)包括3個(gè)主策略：數(shù)據(jù)遷移、技術(shù)仿真和封裝。n 數(shù)據(jù)遷移旨在定期遷移與計(jì)算機(jī)應(yīng)用程序相關(guān)的數(shù)字化數(shù)據(jù)，一般是從舊版本軟件遷移到新版本軟件中。這類案例通常要求在短期內(nèi)完成，導(dǎo)致的風(fēng)險(xiǎn)是相關(guān)數(shù)據(jù)在傳輸過(guò)程中的由于版本兼容性問(wèn)題導(dǎo)致的數(shù)據(jù)損失。n 仿真旨在通過(guò)將現(xiàn)有軟件環(huán)境轉(zhuǎn)換到未來(lái)平臺(tái)環(huán)境以克服數(shù)據(jù)遷移方式的缺點(diǎn)。與數(shù)據(jù)遷移不同，仿真仍以原始格式存儲(chǔ)數(shù)據(jù)，通過(guò)仿真技術(shù)，重新生成數(shù)據(jù)的外觀、使用體驗(yàn)以及軟件環(huán)境，目前有VMWare、QEMU、Xen等虛擬仿真平臺(tái)能夠?qū)崿F(xiàn)該技術(shù)，但是不成熟。n 封裝旨在解決所依賴軟件和應(yīng)用系統(tǒng)技術(shù)陳舊的問(wèn)題。它

4、將數(shù)字化歸檔信息和相關(guān)元數(shù)據(jù)封裝到一個(gè)邏輯容器中，輔以完整的規(guī)格說(shuō)明和描述歸檔格式所需要的信息。其缺點(diǎn)是在技術(shù)條件和用戶需求不斷變化的條件下，更新所有封裝信息十分復(fù)雜。1.2. 基于LOTAR項(xiàng)目研究成果數(shù)據(jù)歸檔實(shí)施建議專項(xiàng)裝置產(chǎn)品在開(kāi)展3D標(biāo)注模型歸檔問(wèn)題研究中，建議借鑒LOTAR項(xiàng)目的先進(jìn)經(jīng)驗(yàn)，研究NAS/EN9300系列標(biāo)準(zhǔn)等相關(guān)成果，結(jié)合專項(xiàng)裝置產(chǎn)品實(shí)際情況制定符合現(xiàn)狀的3D標(biāo)注模型歸檔系列標(biāo)準(zhǔn)。在此基礎(chǔ)上開(kāi)發(fā)歸檔系統(tǒng)并實(shí)施驗(yàn)證。具體實(shí)施過(guò)程如下：1) 基于STEP中性格式的系列標(biāo)準(zhǔn)研究及NAS/EN9300標(biāo)準(zhǔn)本地化。a) STEP中性格式產(chǎn)品模型數(shù)據(jù)交換標(biāo)準(zhǔn)STEP是國(guó)際標(biāo)準(zhǔn)化組織

5、(ISO)所屬技術(shù)委員會(huì)TC184(工業(yè)自動(dòng)化系統(tǒng)技術(shù)委員會(huì))下的“產(chǎn)品模型數(shù)據(jù)外部表示”(ExternalRepresentationofProductModelData)分委員會(huì)SC4所制訂的國(guó)際統(tǒng)一CAD數(shù)據(jù)交換標(biāo)準(zhǔn)。所謂產(chǎn)品模型數(shù)據(jù)是指為在覆蓋產(chǎn)品整個(gè)生命周期中的應(yīng)用而全面定義的產(chǎn)品所有數(shù)據(jù)元素，它包括為進(jìn)行設(shè)計(jì)、分析、制造、測(cè)試、檢驗(yàn)和產(chǎn)品支持而全面定義的零部件或構(gòu)件所需的幾何、拓?fù)?、公差、關(guān)系、屬性和性能等數(shù)據(jù)，另外，還可能包含一些和處理有關(guān)的數(shù)據(jù)。產(chǎn)品模型對(duì)于下達(dá)生產(chǎn)任務(wù)、直接質(zhì)量控制、測(cè)試和進(jìn)行產(chǎn)品支持功能可以提供全面的信息。 STEP為產(chǎn)品在它的生命周期內(nèi)規(guī)定了惟一的描述和計(jì)

6、算機(jī)可處理的信息表達(dá)形式。這種形式獨(dú)立于任何特定的計(jì)算機(jī)系統(tǒng)，并能保證在多種應(yīng)用和不同系統(tǒng)中的一致性。這一標(biāo)準(zhǔn)還允許采用不同的實(shí)現(xiàn)技術(shù)，便于產(chǎn)品數(shù)據(jù)的存取、傳輸和歸檔。STEP標(biāo)準(zhǔn)是為CAD/CAM系統(tǒng)提供中性產(chǎn)品數(shù)據(jù)而開(kāi)發(fā)的公共資源和應(yīng)用模型，它涉及到了建筑、工程、結(jié)構(gòu)、機(jī)械、電氣、電子工程及船體結(jié)構(gòu)等無(wú)所不包的所有產(chǎn)品領(lǐng)域。在產(chǎn)品數(shù)據(jù)共享方面，STEP標(biāo)準(zhǔn)提供四個(gè)層次的實(shí)現(xiàn)方法：n ASCII碼中性文件；n 訪問(wèn)內(nèi)存結(jié)構(gòu)數(shù)據(jù)的應(yīng)用程序界面；n 共享數(shù)據(jù)庫(kù)n 共享知識(shí)庫(kù)。STEP標(biāo)準(zhǔn)在下述幾個(gè)方面有著明顯的優(yōu)越性：一是經(jīng)濟(jì)效益顯著；二是數(shù)據(jù)范圍廣、精度高，通過(guò)應(yīng)用協(xié)議消除了產(chǎn)品數(shù)據(jù)的二義性；

7、三是易于集成，便于擴(kuò)充；四是技術(shù)先進(jìn)、層次清楚，分為通用資源(子標(biāo)準(zhǔn)40系列)、應(yīng)用資源(子標(biāo)準(zhǔn)100系列)和應(yīng)用協(xié)議(子標(biāo)準(zhǔn)200系列)三部分。如今，STEP標(biāo)準(zhǔn)已經(jīng)成為國(guó)際公認(rèn)的CAD數(shù)據(jù)文件交換全球統(tǒng)一標(biāo)準(zhǔn)，許多國(guó)家都依據(jù)STEP標(biāo)準(zhǔn)制訂了相應(yīng)的國(guó)家標(biāo)準(zhǔn)。我國(guó)STEP標(biāo)準(zhǔn)的制訂工作由CSBTSTC159/SC4完成，STEP標(biāo)準(zhǔn)在我國(guó)的對(duì)應(yīng)標(biāo)準(zhǔn)號(hào)為GB16656。STEP標(biāo)準(zhǔn)存在的問(wèn)題是整個(gè)體系極其龐大，標(biāo)準(zhǔn)的制訂過(guò)程進(jìn)展緩慢，數(shù)據(jù)文件比IGES更大。目前商用CAD系統(tǒng)提供的STEP應(yīng)用協(xié)議還只有AP203“配置控制設(shè)計(jì)”，內(nèi)容包括產(chǎn)品的配置管理、曲面和線框模型、實(shí)體模型的小平面邊界表示

8、和曲面邊界表示等以及AP214“汽車(chē)機(jī)械設(shè)計(jì)過(guò)程的核心數(shù)據(jù)”兩種。使用任何的主流三維設(shè)計(jì)軟件Pro/E、UG、CATIA、Solidworks等等都可以直接打開(kāi)。b) NAS/EN9300標(biāo)準(zhǔn)圖 11 9300-1XX系列標(biāo)準(zhǔn)2) 基于以上標(biāo)準(zhǔn)的應(yīng)用技術(shù)開(kāi)發(fā)及應(yīng)用實(shí)踐，包括：a) 選用或開(kāi)發(fā)合適的轉(zhuǎn)換和驗(yàn)證工具；b) 選擇某些典型零部件，開(kāi)展歸檔試點(diǎn)驗(yàn)證，建立3D歸檔管理流程；c) 開(kāi)展保障長(zhǎng)期存儲(chǔ)及原始憑證性的技術(shù)應(yīng)用。2. HTLM5數(shù)據(jù)格式研究HTML5是HTML下一個(gè)主要的修訂版本，現(xiàn)在仍處于發(fā)展階段。目標(biāo)是取代1999年所制定的HTML 4.01和XHTML 1.0標(biāo)準(zhǔn)，以期能在互聯(lián)

9、網(wǎng)應(yīng)用迅速發(fā)展的時(shí)候，使網(wǎng)絡(luò)標(biāo)準(zhǔn)達(dá)到符合當(dāng)代的網(wǎng)絡(luò)需求。廣義論及HTML5時(shí)，實(shí)際指的是包括HTML、CSS和JavaScript在內(nèi)的一套技術(shù)組合。它希望能夠減少瀏覽器對(duì)于需要插件的豐富性網(wǎng)絡(luò)應(yīng)用服務(wù)（plug-in-based rich internet application，RIA)，如Adobe Flash、Microsoft Silverlight，與Oracle JavaFX的需求，并且提供更多能有效增強(qiáng)網(wǎng)絡(luò)應(yīng)用的標(biāo)準(zhǔn)集。具體來(lái)說(shuō)，HTML5添加了許多新的語(yǔ)法特征，其中包括, ,和元素，同時(shí)集成了SVG內(nèi)容。這些元素是為了更容易的在網(wǎng)頁(yè)中添加和處理多媒體和圖片內(nèi)容而添加的。其它新

10、的元素包括, , , 和,是為了豐富文檔的數(shù)據(jù)內(nèi)容。新的屬性的添加也是為了同樣的目的。同時(shí)也有一些屬性和元素被卸載掉了。一些元素，像, 和被修改，重新定義或標(biāo)準(zhǔn)化了。同時(shí)APIs和DOM已經(jīng)成為HTML5中的基礎(chǔ)部分了。HTML5還定義了處理非法文檔的具體細(xì)節(jié)，使得所有瀏覽器和客戶端程序能夠一致地處理語(yǔ)法錯(cuò)誤。. HTML5特性1) 語(yǔ)義特性（Class：Semantic）HTML5賦予網(wǎng)頁(yè)更好的意義和結(jié)構(gòu)。更加豐富的標(biāo)簽將隨著對(duì)RDFa的，微數(shù)據(jù)與微格式等方面的支持，構(gòu)建對(duì)程序、對(duì)用戶都更有價(jià)值的數(shù)據(jù)驅(qū)動(dòng)的Web。2) 本地存儲(chǔ)特性（Class: OFFLINE & STORA

11、GE）基于HTML5開(kāi)發(fā)的網(wǎng)頁(yè)APP擁有更短的啟動(dòng)時(shí)間，更快的聯(lián)網(wǎng)速度，這些全得益于HTML5 APP Cache，以及本地存儲(chǔ)功能。Indexed DB（html5本地存儲(chǔ)最重要的技術(shù)之一）和API說(shuō)明文檔。3) 設(shè)備兼容特性 (Class: DEVICE ACCESS)從Geolocation功能的API文檔公開(kāi)以來(lái)，HTML5為網(wǎng)頁(yè)應(yīng)用開(kāi)發(fā)者們提供了更多功能上的優(yōu)化選擇，帶來(lái)了更多體驗(yàn)功能的優(yōu)勢(shì)。HTML5提供了前所未有的數(shù)據(jù)與應(yīng)用接入開(kāi)放接口。使外部應(yīng)用可以直接與瀏覽器內(nèi)部的數(shù)據(jù)直接相連，例如視頻影音可直接與microphones及攝像頭相聯(lián)。4) 連接特性（Class: CONNEC

12、TIVITY）更有效的連接工作效率，使得基于頁(yè)面的實(shí)時(shí)聊天，更快速的網(wǎng)頁(yè)游戲體驗(yàn)，更優(yōu)化的在線交流得到了實(shí)現(xiàn)。HTML5擁有更有效的服務(wù)器推送技術(shù)，Server-Sent Event和WebSockets就是其中的兩個(gè)特性，這兩個(gè)特性能夠幫助我們實(shí)現(xiàn)服務(wù)器將數(shù)據(jù)“推送”到客戶端的功能。5) 網(wǎng)頁(yè)多媒體特性(Class: MULTIMEDIA)支持網(wǎng)頁(yè)端的Audio、Video等多媒體功能， 與網(wǎng)站自帶的APPS，攝像頭，影音功能相得益彰。6) 三維、圖形及特效特性（Class: 3D, Graphics & Effects）基于SVG、Canvas、WebGL及CSS3的3D功能，用戶會(huì)驚嘆于

13、在瀏覽器中，所呈現(xiàn)的驚人視覺(jué)效果。7) 性能與集成特性（Class: Performance & Integration）沒(méi)有用戶會(huì)永遠(yuǎn)等待你的LoadingHTML5會(huì)通過(guò)XMLHttpRequest2等技術(shù)，解決以前的跨域等問(wèn)題，幫助您的Web應(yīng)用和網(wǎng)站在多樣化的環(huán)境中更快速的工作。8) CSS3特性(Class: CSS3)在不犧牲性能和語(yǔ)義結(jié)構(gòu)的前提下，CSS3中提供了更多的風(fēng)格和更強(qiáng)的效果。此外，較之以前的Web排版，Web的開(kāi)放字體格式（WOFF）也提供了更高的靈活性和控制性。2.2. HTML5標(biāo)準(zhǔn)語(yǔ)義化格式 一個(gè)不帶CSS樣式的HTML5布局HTML5文檔的頭部區(qū)域HTML5文

14、檔的導(dǎo)航區(qū)域HTML5文檔的主要內(nèi)容區(qū)域 HTML5文檔的主要內(nèi)容區(qū)域的側(cè)邊導(dǎo)航或菜單區(qū) HTML5文檔的主要內(nèi)容區(qū)域的內(nèi)容區(qū) 以下是一個(gè)section和article的嵌套，循環(huán)表現(xiàn)章節(jié)與內(nèi)容之間的父子關(guān)系，包含關(guān)系。 HTML5文檔的嵌套區(qū)域，可以對(duì)某個(gè)article區(qū)域進(jìn)行頭部和腳部的定義。 這樣做，可以有非常清晰和嚴(yán)謹(jǐn)?shù)奈臋n目錄結(jié)構(gòu)關(guān)系。 HTML5文檔的腳部區(qū)域3. 基于分布式文件系統(tǒng)（HDFS）的數(shù)據(jù)格式研究Hadoop Distributed File System，簡(jiǎn)稱HDFS，是一個(gè)分布式文件系統(tǒng)。HDFS有著高容錯(cuò)性的特點(diǎn)，而且它提供高吞吐量來(lái)訪問(wèn)應(yīng)用程序的數(shù)據(jù)，適合那些有

15、著超大數(shù)據(jù)集的應(yīng)用程序。HDFS放寬了POSIX的要求這樣可以實(shí)現(xiàn)流的形式訪問(wèn)文件系統(tǒng)中的數(shù)據(jù)。Hadoop 作為MR 的開(kāi)源實(shí)現(xiàn)，一直以動(dòng)態(tài)運(yùn)行解析文件格式并獲得比MPP數(shù)據(jù)庫(kù)快上幾倍的裝載速度為優(yōu)勢(shì)。不過(guò)， Hadoop由于文件格式并非為特定目的而建，因此序列化和反序列化的成本過(guò)高。下文介紹Hadoop目前已有的幾種文件格式，分析其特點(diǎn)、開(kāi)銷(xiāo)及使用場(chǎng)景。3.1. Hadoop中的文件格式3.1.1. SequenceFileSequenceFile是Hadoop API 提供的一種二進(jìn)制文件，它將數(shù)據(jù)以的形式序列化到文件中。這種二進(jìn)制文件內(nèi)部使用Hadoop 的標(biāo)準(zhǔn)的Writable 接口

16、實(shí)現(xiàn)序列化和反序列化。它與Hadoop API中的MapFile 是互相兼容的。Hive 中的SequenceFile 繼承自Hadoop API 的SequenceFile，不過(guò)它的key為空，使用value 存放實(shí)際的值， 這樣是為了避免MR 在運(yùn)行map 階段的排序過(guò)程。如果你用Java API 編寫(xiě)SequenceFile，并讓Hive 讀取的話，請(qǐng)確保使用value字段存放數(shù)據(jù)，否則你需要自定義讀取這種SequenceFile 的InputFormat class 和OutputFormat class。圖 31 Sequencefile 文件結(jié)構(gòu)3.1.2. RCFileRCFil

17、e是Hive推出的一種專門(mén)面向列的數(shù)據(jù)格式。 它遵循“先按列劃分，再垂直劃分”的設(shè)計(jì)理念。當(dāng)查詢過(guò)程中，針對(duì)它并不關(guān)心的列時(shí)，它會(huì)在IO上跳過(guò)這些列。需要說(shuō)明的是，RCFile在map階段從遠(yuǎn)端拷貝仍然是拷貝整個(gè)數(shù)據(jù)塊，并且拷貝到本地目錄后RCFile并不是真正直接跳過(guò)不需要的列，并跳到需要讀取的列， 而是通過(guò)掃描每一個(gè)row group的頭部定義來(lái)實(shí)現(xiàn)的，但是在整個(gè)HDFS Block 級(jí)別的頭部并沒(méi)有定義每個(gè)列從哪個(gè)row group起始到哪個(gè)row group結(jié)束。所以在讀取所有列的情況下，RCFile的性能反而沒(méi)有SequenceFile高。圖 32 RCFile 文件結(jié)構(gòu)3.1.3.

18、 AvroAvro是一種用于支持?jǐn)?shù)據(jù)密集型的二進(jìn)制文件格式。它的文件格式更為緊湊，若要讀取大量數(shù)據(jù)時(shí)，Avro能夠提供更好的序列化和反序列化性能。并且Avro數(shù)據(jù)文件天生是帶Schema定義的，所以它不需要開(kāi)發(fā)者在API 級(jí)別實(shí)現(xiàn)自己的Writable對(duì)象。最近多個(gè)Hadoop 子項(xiàng)目都支持Avro 數(shù)據(jù)格式，如Pig 、Hive、Flume、Sqoop和Hcatalog。圖 33 Avro MR 文件格式3.1.4. 文本格式除上面提到的3種二進(jìn)制格式之外，文本格式的數(shù)據(jù)也是Hadoop中經(jīng)常碰到的。如TextFile 、XML和JSON。 文本格式除了會(huì)占用更多磁盤(pán)資源外，對(duì)它的解析開(kāi)銷(xiāo)一

19、般會(huì)比二進(jìn)制格式高幾十倍以上，尤其是XML 和JSON，它們的解析開(kāi)銷(xiāo)比Textfile 還要大，因此強(qiáng)烈不建議在生產(chǎn)系統(tǒng)中使用這些格式進(jìn)行儲(chǔ)存。 如果需要輸出這些格式，請(qǐng)?jiān)诳蛻舳俗鱿鄳?yīng)的轉(zhuǎn)換操作。 文本格式經(jīng)常會(huì)用于日志收集，數(shù)據(jù)庫(kù)導(dǎo)入，Hive默認(rèn)配置也是使用文本格式，而且常常容易忘了壓縮，所以請(qǐng)確保使用了正確的格式。另外文本格式的一個(gè)缺點(diǎn)是它不具備類型和模式，比如銷(xiāo)售金額、利潤(rùn)這類數(shù)值數(shù)據(jù)或者日期時(shí)間類型的數(shù)據(jù)，如果使用文本格式保存，由于它們本身的字符串類型的長(zhǎng)短不一，或者含有負(fù)數(shù)，導(dǎo)致MR沒(méi)有辦法排序，所以往往需要將它們預(yù)處理成含有模式的二進(jìn)制格式，這又導(dǎo)致了不必要的預(yù)處理步驟的開(kāi)銷(xiāo)和

20、儲(chǔ)存資源的浪費(fèi)。3.1.5. 外部格式Hadoop實(shí)際上支持任意文件格式，只要能夠?qū)崿F(xiàn)對(duì)應(yīng)的RecordWriter和RecordReader即可。其中數(shù)據(jù)庫(kù)格式也是會(huì)經(jīng)常儲(chǔ)存在Hadoop中，比如Hbase，Mysql，Cassandra，MongoDB。 這些格式一般是為了避免大量的數(shù)據(jù)移動(dòng)和快速裝載的需求而用的。他們的序列化和反序列化都是由這些數(shù)據(jù)庫(kù)格式的客戶端完成，并且文件的儲(chǔ)存位置和數(shù)據(jù)布局(Data Layout)不由Hadoop控制，他們的文件切分也不是按HDFS的塊大?。╞locksize）進(jìn)行切割。3.2. 文件存儲(chǔ)大小比較與分析選取一個(gè)TPC-H標(biāo)準(zhǔn)測(cè)試來(lái)說(shuō)明不同的文件格式

21、在存儲(chǔ)上的開(kāi)銷(xiāo)。因?yàn)榇藬?shù)據(jù)是公開(kāi)的，所以讀者如果對(duì)此結(jié)果感興趣，也可以對(duì)照后面的實(shí)驗(yàn)自行做一遍。Orders 表文本格式的原始大小為1.62G。 我們將其裝載進(jìn)Hadoop 并使用Hive 將其轉(zhuǎn)化成以上幾種格式，在同一種LZO 壓縮模式下測(cè)試形成的文件的大小。表 31不同格式文件大小對(duì)比Orders_text117326900451.61G非壓縮TextFileOrders_tex2772681211736MLZO壓縮TextFileOrders_seq119355135871.80G非壓縮SequenceFileOrders_seq2822048201783MLZO壓縮SequenceFi

22、leOrders_rcfile116487463551.53G非壓縮RCFileOrders_rcfile2686927221655MLZO壓縮RCFileOrders_avro_table115683593341.46G非壓縮AvroOrders_avro_table2652962989622MLZO壓縮Avro從上述實(shí)驗(yàn)結(jié)果可以看到，SequenceFile無(wú)論在壓縮和非壓縮的情況下都比原始純文本TextFile大，其中非壓縮模式下大11%， 壓縮模式下大6.4%。這跟SequenceFile的文件格式的定義有關(guān)： SequenceFile在文件頭中定義了其元數(shù)據(jù)，元數(shù)據(jù)的大小會(huì)根據(jù)壓縮模

23、式的不同略有不同。一般情況下，壓縮都是選取block 級(jí)別進(jìn)行的，每一個(gè)block都包含key的長(zhǎng)度和value的長(zhǎng)度，另外每4K字節(jié)會(huì)有一個(gè)sync-marker的標(biāo)記。對(duì)于TextFile文件格式來(lái)說(shuō)不同列之間只需要用一個(gè)行間隔符來(lái)切分，所以TextFile文件格式比SequenceFile文件格式要小。但是TextFile 文件格式不定義列的長(zhǎng)度，所以它必須逐個(gè)字符判斷每個(gè)字符是不是分隔符和行結(jié)束符。因此TextFile 的反序列化開(kāi)銷(xiāo)會(huì)比其他二進(jìn)制的文件格式高幾十倍以上。RCFile文件格式同樣也會(huì)保存每個(gè)列的每個(gè)字段的長(zhǎng)度。但是它是連續(xù)儲(chǔ)存在頭部元數(shù)據(jù)塊中，它儲(chǔ)存實(shí)際數(shù)據(jù)值也是連續(xù)的

24、。另外RCFile 會(huì)每隔一定塊大小重寫(xiě)一次頭部的元數(shù)據(jù)塊（稱為row group，由hive.io.rcfile.record.buffer.size控制，其默認(rèn)大小為4M），這種做法對(duì)于新出現(xiàn)的列是必須的，但是如果是重復(fù)的列則不需要。RCFile 本來(lái)應(yīng)該會(huì)比SequenceFile 文件大，但是RCFile 在定義頭部時(shí)對(duì)于字段長(zhǎng)度使用了Run Length Encoding進(jìn)行壓縮，所以RCFile 比SequenceFile又小一些。Run length Encoding針對(duì)固定長(zhǎng)度的數(shù)據(jù)格式有非常高的壓縮效率，比如Integer、Double和Long等占固定長(zhǎng)度的數(shù)據(jù)類型。在此提

25、一個(gè)特例Hive 0.8引入的TimeStamp 時(shí)間類型，如果其格式不包括毫秒，可表示為”YYYY-MM-DD HH:MM:SS”，那么就是固定長(zhǎng)度占8個(gè)字節(jié)。如果帶毫秒，則表示為”YYYY-MM-DD HH:MM:SS.fffffffff”，后面毫秒的部分則是可變的。Avro文件格式也按group進(jìn)行劃分。但是它會(huì)在頭部定義整個(gè)數(shù)據(jù)的模式（Schema）， 而不像RCFile那樣每隔一個(gè)row group就定義列的類型，并且重復(fù)多次。另外，Avro在使用部分類型的時(shí)候會(huì)使用更小的數(shù)據(jù)類型，比如Short或者Byte類型，所以Avro的數(shù)據(jù)塊比RCFile 的文件格式塊更小。3.3. 序列化

26、與反序列化開(kāi)銷(xiāo)分析我們可以使用Java的profile工具來(lái)查看Hadoop 運(yùn)行時(shí)任務(wù)的CPU和內(nèi)存開(kāi)銷(xiāo)。以下是在Hive 命令行中的設(shè)置：hiveset file=true;hiveset file.params =-agentlib:hprof=cpu=samples,heap=sites, depth=6,force=n,thread=y,verbose=n,file=%s當(dāng)map task 運(yùn)行結(jié)束后，它產(chǎn)生的日志會(huì)寫(xiě)在$logs/userlogs/job-文件夾下。當(dāng)然，你也可以直接在JobTracker的Web界面的lo

27、gs或jobtracker.jsp 頁(yè)面找到日志。我們運(yùn)行一個(gè)簡(jiǎn)單的SQL語(yǔ)句來(lái)觀察RCFile 格式在序列化和反序列化上的開(kāi)銷(xiāo)：hive select O_CUSTKEY,O_ORDERSTATUS from orders_rc2 where O_ORDERSTATUS=P;其中的O_CUSTKEY列為integer類型，O_ORDERSTATUS為String類型。在日志輸出的最后會(huì)包含內(nèi)存和CPU 的消耗。下表是一次CPU 的開(kāi)銷(xiāo)：表 32 一次CPU的開(kāi)銷(xiāo)rankselfaccumcounttracemethod200.48%79.64%65315554org.apache.hadoo

28、p.hive.ql.io.RCFile$Reader.getCurrentRow280.24%82.07%32315292org.apache.hadoop.hive.serde2.columnar.ColumnarStruct.init550.10%85.98%14315788org.apache.hadoop.hive.ql.io.RCFileRecordReader.getPos560.10%86.08%14315797org.apache.hadoop.hive.ql.io.RCFileRecordReader.next其中第五列可以對(duì)照上面的Track信息查看到底調(diào)用了哪些函數(shù)。比如

29、CPU消耗排名20的函數(shù)對(duì)應(yīng)Track：TRACE 315554: (thread=200001)org.apache.hadoop.hive.ql.io.RCFile$Reader.getCurrentRow(RCFile.java:1434)org.apache.hadoop.hive.ql.io.RCFileRecordReader.next(RCFileRecordReader.java:88)org.apache.hadoop.hive.ql.io.RCFileRecordReader.next(RCFileRecordReader.java:39)org.apache.hadoop

30、.hive.ql.io.CombineHiveRecordReader.doNext(CombineHiveRecordReader.java:98)org.apache.hadoop.hive.ql.io.CombineHiveRecordReader.doNext(CombineHiveRecordReader.java:42) org.apache.hadoop.hive.ql.io.HiveContextAwareRecordReader.next(HiveContextAwareRecordReader.java:67)其中，比較明顯的是RCFile，它為了構(gòu)造行而消耗了不必要的數(shù)組

31、移動(dòng)開(kāi)銷(xiāo)。其主要是因?yàn)镽CFile 為了還原行，需要構(gòu)造RowContainer，順序讀取一行構(gòu)造RowContainer，然后給其中對(duì)應(yīng)的列進(jìn)行賦值，因?yàn)镽CFile早期為了兼容SequenceFile所以可以合并兩個(gè)block，又由于RCFile不知道列在哪個(gè)row group結(jié)束，所以必須維持?jǐn)?shù)組的當(dāng)前位置，類似如下格式定義： ArrayRowContainer extends List而此數(shù)據(jù)格式可以改為面向列的序列化和反序列化方式。如：Maparray,array,array.這種方式的反序列化會(huì)避免不必要的數(shù)組移動(dòng)，當(dāng)然前提是我們必須知道列在哪個(gè)row group開(kāi)始到哪個(gè)row

32、group結(jié)束。這種方式會(huì)提高整體反序列化過(guò)程的效率。3.4. 關(guān)于Hadoop文件格式的思考3.4.1. 高效壓縮Hadoop目前尚未出現(xiàn)針對(duì)數(shù)據(jù)特性的高效編碼（Encoding）和解碼(Decoding)數(shù)據(jù)格式。尤其是支持Run Length Encoding、Bitmap 這些極為高效算法的數(shù)據(jù)格式。HIVE-2065 討論過(guò)使用更加高效的壓縮形式，但是對(duì)于如何選取列的順序沒(méi)有結(jié)論。3.4.2. 基于列和塊的序列化和反序列化不論排序后的結(jié)果是不是真的需要，目前Hadoop的整體框架都需要不斷根據(jù)數(shù)據(jù)key進(jìn)行排序。除了上面提到的基于列的排序，序列化和反序列化之外，Hadoop的文件格式應(yīng)該支持某種基于塊（