最近在書寫大數據基礎組件的時候對hadoop平臺的文件格式感覺到有些困惑，不知道各自的優缺點及如何使用。現特意總結一下：
hdfs支持哪些文件格式：
TEXTFILE：
textfile爲默認格式，存儲方式爲行式存儲，在檢索時磁盤開銷大 數據解析開銷大，而對壓縮的text文件 hive無法進行合併和拆分
SEQUENCEFILE：
二進制文件,以<key,value>的形式序列化到文件中,存儲方式爲行式存儲，可以對文件進行分割和壓縮，一般使用block壓縮，使用Hadoop 的標準的Writable 接口實現序列化和反序列化,和hadoop api中的mapfile是相互兼容的。
RCFILE：
存儲方式爲數據按行分塊，每塊按照列存儲的行列混合模式，具有壓縮快，列存取快的特點。
在使用時，讀記錄儘量涉及到的block最少，這樣讀取需要的列只需要讀取每個row group 的頭部定義，具有明顯速度優勢。
讀取全量數據的操作 性能可能比sequencefile沒有明顯的優勢。
Orc：
Orc是從HIVE的原生格式RCFILE優化改進而來。
Parquet：
Parquet是Cloudera公司研發並開源的格式。
這兩者都屬於列存儲格式，但Orc嚴格上應該算是行列混合存儲，首先根據行組分割整個表，在每一個行組內進行按列存儲。
Parquet文件和Orc文件都是是自解析的，文件中包括該文件的數據和元數據，Orc的元數據使用Protocol Buffers序列化。
兩者都支持嵌套數據格式（struct\map\list），但策略不同：
- Parquet支持嵌套的數據模型，類似於Protocol Buffers，每一個數據模型的schema包含多個字段，每一個字段有三個屬性：重複次數、數據類型和字段名。
- ORC原生是不支持嵌套數據格式的，而是通過對複雜數據類型特殊處理的方式實現嵌套格式的支持。
壓縮：
兩者都相比txt格式進行了數據壓縮，相比而言，Orc的壓縮比例更大，效果更好。
計算引擎支持：都支持spark、MR計算引擎。
查詢引擎支持：Parquet被Spark SQL、Hive、Impala、Drill等支持，而Orc被Spark SQL、Presto、Hive支持，Orc不被Impala支持。
功能及性能對比：
使用TPC-DS數據集並且對它進行改造以生成寬表、嵌套和多層嵌套的數據。使用最常用的Hive作爲SQL引擎進行測試
最終表現：
功能：
- ORC的壓縮比更大，對存儲空間的利用更好
- ORC可以一定程度上支持ACID操作，Parquet不可以
性能： - 數據導入 orc更快
- 聚合查詢 orc更快
- 單表查詢 orc快一點點點
- 帶有複雜數據構成的表查詢 （1層） orc更快
- 帶有複雜數據構成的表查詢 （3層） orc更快
結果分析
從上述測試結果來看，星狀模型對於數據分析場景並不是很合適，多個表的join會大大拖慢查詢速度，並且不能很好的利用列式存儲帶來的性能提升，在使用寬表的情況下，列式存儲的性能提升明顯，ORC文件格式在存儲空間上要遠優於Text格式，較之於PARQUET格式有一倍的存儲空間提升，在導數據（insert into table select 這樣的方式）方面ORC格式也要優於PARQUET，在最終的查詢性能上可以看到，無論是無嵌套的扁平式寬表，或是一層嵌套表，還是多層嵌套的寬表，兩者的查詢性能相差不多，較之於Text格式有2到3倍左右的提升。
另外，扁平式的表結構要比嵌套式結構的查詢性能有所提升，所以如果選擇使用大寬表，則設計寬表的時候儘可能的將表設計的扁平化，減少嵌套數據。
通過測試對比，ORC文件存儲格式無論是在空間存儲、導數據速度還是查詢速度上表現的都較好一些，並且ORC可以一定程度上支持ACID操作，社區的發展目前也是Hive中比較提倡使用的一種列式存儲格式，另外，本次測試主要針對的是Hive引擎，所以不排除存在Hive與ORC的敏感度比PARQUET要高的可能性。Parquet更多的是在Impala環境下使用