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

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

2、據(jù)長期保存問題變得更加復(fù)雜。如何建立具備完整性、可持續(xù)性的數(shù)據(jù)倉庫一直是近期研究熱點。1. 基于LOTAR項目研究成果的歸檔數(shù)據(jù)格式研究LOTAR（Long Term Archiving and Retrieval）是國際上一個著名的與航空工業(yè)相關(guān)的歸檔項目，該項目的參與者包括重要的航空工業(yè)企業(yè)（空客、波音、達(dá)索航空、洛克希德馬丁、BAE等）、監(jiān)管機構(gòu)（FAA、JAA等）和政府機構(gòu)（NASA、ESA、NIST等），LOTAR項目的目標(biāo)是歸檔3D CAD和PDM信息，并遵從監(jiān)管、法律和業(yè)務(wù)上的需求。該項目基于2個不斷改進(jìn)的標(biāo)準(zhǔn)：長期歸檔系統(tǒng)框架OAIS，實際的產(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個主策略：數(shù)據(jù)遷移、技術(shù)仿真和封裝。n 數(shù)據(jù)遷移旨在定期遷移與計算機應(yīng)用程序相關(guān)的數(shù)字化數(shù)據(jù)，一般是從舊版本軟件遷移到新版本軟件中。這類案例通常要求在短期內(nèi)完成，導(dǎo)致的風(fēng)險是相關(guān)數(shù)據(jù)在傳輸過程中的由于版本兼容性問題導(dǎo)致的數(shù)據(jù)損失。n 仿真旨在通過將現(xiàn)有軟件環(huán)境轉(zhuǎn)換到未來平臺環(huán)境以克服數(shù)據(jù)遷移方式的缺點。與數(shù)據(jù)遷移不同，仿真仍以原始格式存儲數(shù)據(jù)，通過仿真技術(shù)，重新生成數(shù)據(jù)的外觀、使用體驗以及軟件環(huán)境，目前有VMWare、QEMU、Xen等虛擬仿真平臺能夠?qū)崿F(xiàn)該技術(shù)，但是不成熟。n 封裝旨在解決所依賴軟件和應(yīng)用系統(tǒng)技術(shù)陳舊的問題。它

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

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

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

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

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

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

10、G內(nèi)容。這些元素是為了更容易的在網(wǎng)頁中添加和處理多媒體和圖片內(nèi)容而添加的。其它新的元素包括<section>, <article>, <header>, 和<nav>,是為了豐富文檔的數(shù)據(jù)內(nèi)容。新的屬性的添加也是為了同樣的目的。同時也有一些屬性和元素被卸載掉了。一些元素，像<a>, 和<menu>被修改，重新定義或標(biāo)準(zhǔn)化了。同時APIs和DOM已經(jīng)成為HTML5中的基礎(chǔ)部分了。HTML5還定義了處理非法文檔的具體細(xì)節(jié)，使得所有瀏覽器和客戶端程序能夠一致地處理語法錯誤。. HTML5特性1) 語義特性（Clas

11、s：Semantic）HTML5賦予網(wǎng)頁更好的意義和結(jié)構(gòu)。更加豐富的標(biāo)簽將隨著對RDFa的，微數(shù)據(jù)與微格式等方面的支持，構(gòu)建對程序、對用戶都更有價值的數(shù)據(jù)驅(qū)動的Web。2) 本地存儲特性（Class: OFFLINE & STORAGE）基于HTML5開發(fā)的網(wǎng)頁APP擁有更短的啟動時間，更快的聯(lián)網(wǎng)速度，這些全得益于HTML5 APP Cache，以及本地存儲功能。Indexed DB（html5本地存儲最重要的技術(shù)之一）和API說明文檔。3) 設(shè)備兼容特性 (Class: DEVICE ACCESS)從Geolocation功能的API文檔公開以來，HTML5為網(wǎng)頁應(yīng)用開發(fā)者們提供了更

12、多功能上的優(yōu)化選擇，帶來了更多體驗功能的優(yōu)勢。HTML5提供了前所未有的數(shù)據(jù)與應(yīng)用接入開放接口。使外部應(yīng)用可以直接與瀏覽器內(nèi)部的數(shù)據(jù)直接相連，例如視頻影音可直接與microphones及攝像頭相聯(lián)。4) 連接特性（Class: CONNECTIVITY）更有效的連接工作效率，使得基于頁面的實時聊天，更快速的網(wǎng)頁游戲體驗，更優(yōu)化的在線交流得到了實現(xiàn)。HTML5擁有更有效的服務(wù)器推送技術(shù)，Server-Sent Event和WebSockets就是其中的兩個特性，這兩個特性能夠幫助我們實現(xiàn)服務(wù)器將數(shù)據(jù)“推送”到客戶端的功能。5) 網(wǎng)頁多媒體特性(Class: MULTIMEDIA)支持網(wǎng)頁端的Au

13、dio、Video等多媒體功能， 與網(wǎng)站自帶的APPS，攝像頭，影音功能相得益彰。6) 三維、圖形及特效特性（Class: 3D, Graphics & Effects）基于SVG、Canvas、WebGL及CSS3的3D功能，用戶會驚嘆于在瀏覽器中，所呈現(xiàn)的驚人視覺效果。7) 性能與集成特性（Class: Performance & Integration）沒有用戶會永遠(yuǎn)等待你的LoadingHTML5會通過XMLHttpRequest2等技術(shù)，解決以前的跨域等問題，幫助您的Web應(yīng)用和網(wǎng)站在多樣化的環(huán)境中更快速的工作。8) CSS3特性(Class: CSS3)在不犧牲性能

14、和語義結(jié)構(gòu)的前提下，CSS3中提供了更多的風(fēng)格和更強的效果。此外，較之以前的Web排版，Web的開放字體格式（WOFF）也提供了更高的靈活性和控制性。2.2. HTML5標(biāo)準(zhǔn)語義化格式 <!DOCTYPE html><!- 聲明文檔結(jié)構(gòu)類型 -><html lang=zh-cn><!- 聲明文檔文字區(qū)域-><head><!- 文檔的頭部區(qū)域 -><meta charset=utf-8><!- 文檔的頭部區(qū)域中元數(shù)據(jù)區(qū)的字符集定義，這里是utf-8，表示國際通用的字符集編碼格式 -><!-if

15、IE><!endif-><!- 文檔的頭部區(qū)域的兼容性寫法 -><title>一個不帶CSS樣式的HTML5布局</title><!- 文檔的頭部區(qū)域的標(biāo)題。這里要注意，這個title的內(nèi)容對于SEO來說極其重要-><!-if IE 9><meta name=ie content=9><!endif-><!- 文檔的頭部區(qū)域的兼容性寫法 -><!-if IE 8><meta name=ie content=8 ><!endif-><!- 文

16、檔的頭部區(qū)域的兼容性寫法 -><meta name=de script ion content=一個不帶CSS樣式的HTML5布局><!- 文檔的頭部區(qū)域元數(shù)據(jù)區(qū)關(guān)于文檔描述的定義 -><meta name=author content=秀野堂主><!- 文檔的頭部區(qū)域元數(shù)據(jù)區(qū)關(guān)于開發(fā)人員姓名的定義 -><meta name=copyright content=HTML5研究小組><!- 文檔的頭部區(qū)域元數(shù)據(jù)區(qū)關(guān)于版權(quán)的定義 -><link rel=shortcut icon href=favicon.ico&

17、gt;<!- 文檔的頭部區(qū)域的兼容性寫法 -><link rel=apple-touch-icon href=custom_icon.png><!- 文檔的頭部區(qū)域的apple設(shè)備的圖標(biāo)的引用 -><meta name=viewport content=width=device-width, user-scalable=no ><!- 文檔的頭部區(qū)域?qū)τ诓煌涌谠O(shè)備的特殊聲明。寬=設(shè)備寬，用戶不能自行縮放 -><link rel=stylesheet href=main.css><!- 文檔的頭部區(qū)域的樣式文件引用

18、-><!-if IE><link rel=stylesheet href=win-ie-all.css><!endif-><!- 文檔的頭部區(qū)域的兼容性樣式文件引用寫法 -><!-if IE 7><link rel=stylesheet type=text/css href=win-ie7.css><!endif-><!- 文檔的頭部區(qū)域的IE7瀏覽器的兼容性寫法 -><!-if lt IE 8><script src=http:/ie7- js></>&l

19、t;!endif-><!- 文檔的頭部區(qū)域的關(guān)于讓IE8也兼容HTML5的Javascript腳本（本書作者希望讀者可以少考慮兼容性， 多做技術(shù)研究） ->< script src= script.js></ script ><!- 文檔的頭部區(qū)域的Java script腳本文件調(diào)用 -></head><body><header>HTML5文檔的頭部區(qū)域</header><nav>HTML5文檔的導(dǎo)航區(qū)域</nav><section>HTML5文檔的主要內(nèi)容

20、區(qū)域 <aside> HTML5文檔的主要內(nèi)容區(qū)域的側(cè)邊導(dǎo)航或菜單區(qū) </aside> <article> HTML5文檔的主要內(nèi)容區(qū)域的內(nèi)容區(qū) <section>以下是一個section和article的嵌套，循環(huán)表現(xiàn)章節(jié)與內(nèi)容之間的父子關(guān)系，包含關(guān)系。 <aside> </aside> <article> <header> HTML5文檔的嵌套區(qū)域，可以對某個article區(qū)域進(jìn)行頭部和腳部的定義。 這樣做，可以有非常清晰和嚴(yán)謹(jǐn)?shù)奈臋n目錄結(jié)構(gòu)關(guān)系。 <footer> </art

21、icle> </section> </article></section><footer>HTML5文檔的腳部區(qū)域</footer></body></HTML>3. 基于分布式文件系統(tǒng)（HDFS）的數(shù)據(jù)格式研究Hadoop Distributed File System，簡稱HDFS，是一個分布式文件系統(tǒng)。HDFS有著高容錯性的特點，而且它提供高吞吐量來訪問應(yīng)用程序的數(shù)據(jù)，適合那些有著超大數(shù)據(jù)集的應(yīng)用程序。HDFS放寬了POSIX的要求這樣可以實現(xiàn)流的形式訪問文件系統(tǒng)中的數(shù)據(jù)。Hadoop 作為MR 的開

22、源實現(xiàn)，一直以動態(tài)運行解析文件格式并獲得比MPP數(shù)據(jù)庫快上幾倍的裝載速度為優(yōu)勢。不過， Hadoop由于文件格式并非為特定目的而建，因此序列化和反序列化的成本過高。下文介紹Hadoop目前已有的幾種文件格式，分析其特點、開銷及使用場景。3.1. Hadoop中的文件格式3.1.1. SequenceFileSequenceFile是Hadoop API 提供的一種二進(jìn)制文件，它將數(shù)據(jù)以<key,value>的形式序列化到文件中。這種二進(jìn)制文件內(nèi)部使用Hadoop 的標(biāo)準(zhǔn)的Writable 接口實現(xiàn)序列化和反序列化。它與Hadoop API中的MapFile 是互相兼容的。Hive

23、中的SequenceFile 繼承自Hadoop API 的SequenceFile，不過它的key為空，使用value 存放實際的值， 這樣是為了避免MR 在運行map 階段的排序過程。如果你用Java API 編寫SequenceFile，并讓Hive 讀取的話，請確保使用value字段存放數(shù)據(jù)，否則你需要自定義讀取這種SequenceFile 的InputFormat class 和OutputFormat class。圖 31 Sequencefile 文件結(jié)構(gòu)3.1.2. RCFileRCFile是Hive推出的一種專門面向列的數(shù)據(jù)格式。 它遵循“先按列劃分，再垂直劃分”的設(shè)計理念。

24、當(dāng)查詢過程中，針對它并不關(guān)心的列時，它會在IO上跳過這些列。需要說明的是，RCFile在map階段從遠(yuǎn)端拷貝仍然是拷貝整個數(shù)據(jù)塊，并且拷貝到本地目錄后RCFile并不是真正直接跳過不需要的列，并跳到需要讀取的列， 而是通過掃描每一個row group的頭部定義來實現(xiàn)的，但是在整個HDFS Block 級別的頭部并沒有定義每個列從哪個row group起始到哪個row group結(jié)束。所以在讀取所有列的情況下，RCFile的性能反而沒有SequenceFile高。圖 32 RCFile 文件結(jié)構(gòu)3.1.3. AvroAvro是一種用于支持?jǐn)?shù)據(jù)密集型的二進(jìn)制文件格式。它的文件格式更為緊湊，若要讀取

25、大量數(shù)據(jù)時，Avro能夠提供更好的序列化和反序列化性能。并且Avro數(shù)據(jù)文件天生是帶Schema定義的，所以它不需要開發(fā)者在API 級別實現(xiàn)自己的Writable對象。最近多個Hadoop 子項目都支持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。 文本格式除了會占用更多磁盤資源外，對它的解析開銷一般會比二進(jìn)制格式高幾十倍以上，尤其是XML 和JSON，它們的解析開銷比Textfile

26、還要大，因此強烈不建議在生產(chǎn)系統(tǒng)中使用這些格式進(jìn)行儲存。 如果需要輸出這些格式，請在客戶端做相應(yīng)的轉(zhuǎn)換操作。 文本格式經(jīng)常會用于日志收集，數(shù)據(jù)庫導(dǎo)入，Hive默認(rèn)配置也是使用文本格式，而且常常容易忘了壓縮，所以請確保使用了正確的格式。另外文本格式的一個缺點是它不具備類型和模式，比如銷售金額、利潤這類數(shù)值數(shù)據(jù)或者日期時間類型的數(shù)據(jù)，如果使用文本格式保存，由于它們本身的字符串類型的長短不一，或者含有負(fù)數(shù)，導(dǎo)致MR沒有辦法排序，所以往往需要將它們預(yù)處理成含有模式的二進(jìn)制格式，這又導(dǎo)致了不必要的預(yù)處理步驟的開銷和儲存資源的浪費。3.1.5. 外部格式Hadoop實際上支持任意文件格式，只要能夠?qū)崿F(xiàn)對應(yīng)

27、的RecordWriter和RecordReader即可。其中數(shù)據(jù)庫格式也是會經(jīng)常儲存在Hadoop中，比如Hbase，Mysql，Cassandra，MongoDB。 這些格式一般是為了避免大量的數(shù)據(jù)移動和快速裝載的需求而用的。他們的序列化和反序列化都是由這些數(shù)據(jù)庫格式的客戶端完成，并且文件的儲存位置和數(shù)據(jù)布局(Data Layout)不由Hadoop控制，他們的文件切分也不是按HDFS的塊大?。╞locksize）進(jìn)行切割。3.2. 文件存儲大小比較與分析選取一個TPC-H標(biāo)準(zhǔn)測試來說明不同的文件格式在存儲上的開銷。因為此數(shù)據(jù)是公開的，所以讀者如果對此結(jié)果感興趣，也可以對照后面的實驗自行做

28、一遍。Orders 表文本格式的原始大小為1.62G。 我們將其裝載進(jìn)Hadoop 并使用Hive 將其轉(zhuǎn)化成以上幾種格式，在同一種LZO 壓縮模式下測試形成的文件的大小。表 31不同格式文件大小對比Orders_text117326900451.61G非壓縮TextFileOrders_tex2772681211736MLZO壓縮TextFileOrders_seq119355135871.80G非壓縮SequenceFileOrders_seq2822048201783MLZO壓縮SequenceFileOrders_rcfile116487463551.53G非壓縮RCFileOrder

29、s_rcfile2686927221655MLZO壓縮RCFileOrders_avro_table115683593341.46G非壓縮AvroOrders_avro_table2652962989622MLZO壓縮Avro從上述實驗結(jié)果可以看到，SequenceFile無論在壓縮和非壓縮的情況下都比原始純文本TextFile大，其中非壓縮模式下大11%， 壓縮模式下大6.4%。這跟SequenceFile的文件格式的定義有關(guān)： SequenceFile在文件頭中定義了其元數(shù)據(jù)，元數(shù)據(jù)的大小會根據(jù)壓縮模式的不同略有不同。一般情況下，壓縮都是選取block 級別進(jìn)行的，每一個block都包含k

30、ey的長度和value的長度，另外每4K字節(jié)會有一個sync-marker的標(biāo)記。對于TextFile文件格式來說不同列之間只需要用一個行間隔符來切分，所以TextFile文件格式比SequenceFile文件格式要小。但是TextFile 文件格式不定義列的長度，所以它必須逐個字符判斷每個字符是不是分隔符和行結(jié)束符。因此TextFile 的反序列化開銷會比其他二進(jìn)制的文件格式高幾十倍以上。RCFile文件格式同樣也會保存每個列的每個字段的長度。但是它是連續(xù)儲存在頭部元數(shù)據(jù)塊中，它儲存實際數(shù)據(jù)值也是連續(xù)的。另外RCFile 會每隔一定塊大小重寫一次頭部的元數(shù)據(jù)塊（稱為row group，由hi

31、ve.io.rcfile.record.buffer.size控制，其默認(rèn)大小為4M），這種做法對于新出現(xiàn)的列是必須的，但是如果是重復(fù)的列則不需要。RCFile 本來應(yīng)該會比SequenceFile 文件大，但是RCFile 在定義頭部時對于字段長度使用了Run Length Encoding進(jìn)行壓縮，所以RCFile 比SequenceFile又小一些。Run length Encoding針對固定長度的數(shù)據(jù)格式有非常高的壓縮效率，比如Integer、Double和Long等占固定長度的數(shù)據(jù)類型。在此提一個特例Hive 0.8引入的TimeStamp 時間類型，如果其格式不包括毫秒，可表示為

32、”YYYY-MM-DD HH:MM:SS”，那么就是固定長度占8個字節(jié)。如果帶毫秒，則表示為”YYYY-MM-DD HH:MM:SS.fffffffff”，后面毫秒的部分則是可變的。Avro文件格式也按group進(jìn)行劃分。但是它會在頭部定義整個數(shù)據(jù)的模式（Schema）， 而不像RCFile那樣每隔一個row group就定義列的類型，并且重復(fù)多次。另外，Avro在使用部分類型的時候會使用更小的數(shù)據(jù)類型，比如Short或者Byte類型，所以Avro的數(shù)據(jù)塊比RCFile 的文件格式塊更小。3.3. 序列化與反序列化開銷分析我們可以使用Java的profile工具來查看Hadoop 運行時任務(wù)的

33、CPU和內(nèi)存開銷。以下是在Hive 命令行中的設(shè)置：hive>set file=true;hive>set file.params =-agentlib:hprof=cpu=samples,heap=sites, depth=6,force=n,thread=y,verbose=n,file=%s當(dāng)map task 運行結(jié)束后，它產(chǎn)生的日志會寫在$logs/userlogs/job- 文件夾下。當(dāng)然，你也可以直接在JobTracker的Web界面的logs或jobtracker.jsp 頁面找到日志。我們運行一個

34、簡單的SQL語句來觀察RCFile 格式在序列化和反序列化上的開銷：hive> select O_CUSTKEY,O_ORDERSTATUS from orders_rc2 where O_ORDERSTATUS='P'其中的O_CUSTKEY列為integer類型，O_ORDERSTATUS為String類型。在日志輸出的最后會包含內(nèi)存和CPU 的消耗。下表是一次CPU 的開銷：表 32 一次CPU的開銷rankselfaccumcounttracemethod20  0.48%79.64%65315554org.apache.hadoop.hive

35、.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其中第五列可以對照上面的Track信息查看到底調(diào)用了哪些函數(shù)。比如CPU消耗排

36、名20的函數(shù)對應(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.hive.

37、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ù)組移動開銷。其

38、主要是因為RCFile 為了還原行，需要構(gòu)造RowContainer，順序讀取一行構(gòu)造RowContainer，然后給其中對應(yīng)的列進(jìn)行賦值，因為RCFile早期為了兼容SequenceFile所以可以合并兩個block，又由于RCFile不知道列在哪個row group結(jié)束，所以必須維持?jǐn)?shù)組的當(dāng)前位置，類似如下格式定義： Array<RowContainer extends List<Object>>而此數(shù)據(jù)格式可以改為面向列的序列化和反序列化方式。如：Map<array<col1Type>,array<col2Type>,array<col3Type>.>這種方式的反序列化會避免不必要的數(shù)組移動，當(dāng)然前提是我們必須知道列在哪個row group開始到哪個row group結(jié)束。這種方式會提高整體反序列化過程的效率。3.4. 關(guān)于Hadoop文件格式的思考3.4.1. 高效壓縮Hadoop目前尚未出現(xiàn)針對數(shù)據(jù)特性的高效編碼（Encoding）和解