長期歸檔數據格式調研匯總

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

19、般會比二進制格式高幾十倍以上，尤其是XML 和JSON，它們的解析開銷比Textfile 還要大，因此強烈不建議在生產系統(tǒng)中使用這些格式進行儲存。 如果需要輸出這些格式，請在客戶端做相應的轉換操作。 文本格式經常會用于日志收集，數據庫導入，Hive默認配置也是使用文本格式，而且常常容易忘了壓縮，所以請確保使用了正確的格式。另外文本格式的一個缺點是它不具備類型和模式，比如銷售金額、利潤這類數值數據或者日期時間類型的數據，如果使用文本格式保存，由于它們本身的字符串類型的長短不一，或者含有負數，導致MR沒有辦法排序，所以往往需要將它們預處理成含有模式的二進制格式，這又導致了不必要的預處理步驟的開銷和

20、儲存資源的浪費。3.1.5. 外部格式Hadoop實際上支持任意文件格式，只要能夠實現對應的RecordWriter和RecordReader即可。其中數據庫格式也是會經常儲存在Hadoop中，比如Hbase，Mysql，Cassandra，MongoDB。 這些格式一般是為了避免大量的數據移動和快速裝載的需求而用的。他們的序列化和反序列化都是由這些數據庫格式的客戶端完成，并且文件的儲存位置和數據布局(Data Layout)不由Hadoop控制，他們的文件切分也不是按HDFS的塊大?。╞locksize）進行切割。3.2. 文件存儲大小比較與分析選取一個TPC-H標準測試來說明不同的文件格式

21、在存儲上的開銷。因為此數據是公開的，所以讀者如果對此結果感興趣，也可以對照后面的實驗自行做一遍。Orders 表文本格式的原始大小為1.62G。 我們將其裝載進Hadoop 并使用Hive 將其轉化成以上幾種格式，在同一種LZO 壓縮模式下測試形成的文件的大小。表 31不同格式文件大小對比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從上述實驗結果可以看到，SequenceFile無論在壓縮和非壓縮的情況下都比原始純文本TextFile大，其中非壓縮模式下大11%， 壓縮模式下大6.4%。這跟SequenceFile的文件格式的定義有關： SequenceFile在文件頭中定義了其元數據，元數據的大小會根據壓縮模

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

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

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

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

27、gs或jobtracker.jsp 頁面找到日志。我們運行一個簡單的SQL語句來觀察RCFile 格式在序列化和反序列化上的開銷：hive select O_CUSTKEY,O_ORDERSTATUS from orders_rc2 where O_ORDERSTATUS=P;其中的O_CUSTKEY列為integer類型，O_ORDERSTATUS為String類型。在日志輸出的最后會包含內存和CPU 的消耗。下表是一次CPU 的開銷：表 32 一次CPU的開銷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其中第五列可以對照上面的Track信息查看到底調用了哪些函數。比如

29、CPU消耗排名20的函數對應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，它為了構造行而消耗了不必要的數組

31、移動開銷。其主要是因為RCFile 為了還原行，需要構造RowContainer，順序讀取一行構造RowContainer，然后給其中對應的列進行賦值，因為RCFile早期為了兼容SequenceFile所以可以合并兩個block，又由于RCFile不知道列在哪個row group結束，所以必須維持數組的當前位置，類似如下格式定義： ArrayRowContainer extends List而此數據格式可以改為面向列的序列化和反序列化方式。如：Maparray,array,array.這種方式的反序列化會避免不必要的數組移動，當然前提是我們必須知道列在哪個row group開始到哪個row

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