一、ORC File文件結構
ORC的全稱是(Optimized Row Columnar)，ORC文件格式是一種Hadoop生態圈中的列式存儲格式，它的產生早在2013年初，最初產生自Apache Hive，用於降低Hadoop數據存儲空間和加速Hive查詢速度。和Parquet類似，它並不是一個單純的列式存儲格式，仍然是首先根據行組分割整個表，在每一個行組內進行按列存儲。ORC文件是自描述的，它的元數據使用Protocol Buffers序列化，並且文件中的數據儘可能的壓縮以降低存儲空間的消耗，目前也被Spark SQL、Presto等查詢引擎支持，但是Impala對於ORC目前沒有支持，仍然使用Parquet作爲主要的列式存儲格式。2015年ORC項目被Apache項目基金會提升爲Apache頂級項目。ORC具有以下一些優勢:
- ORC是列式存儲，有多種文件壓縮方式，並且有着很高的壓縮比。
- 文件是可切分（Split）的。因此，在Hive中使用ORC作爲表的文件存儲格式，不僅節省HDFS存儲資源，查詢任務的輸入數據量減少，使用的MapTask也就減少了。
- 提供了多種索引，row group index、bloom filter index。
- ORC可以支持複雜的數據結構（比如Map等）
列式存儲
由於OLAP查詢的特點，列式存儲可以提升其查詢性能，但是它是如何做到的呢？這就要從列式存儲的原理說起，從圖1中可以看到，相對於關係數據庫中通常使用的行式存儲，在使用列式存儲時每一列的所有元素都是順序存儲的。由此特點可以給查詢帶來如下的優化：
- 查詢的時候不需要掃描全部的數據，而只需要讀取每次查詢涉及的列，這樣可以將I/O消耗降低N倍，另外可以保存每一列的統計信息(min、max、sum等)，實現部分的謂詞下推。
- 由於每一列的成員都是同構的，可以針對不同的數據類型使用更高效的數據壓縮算法，進一步減小I/O。
- 由於每一列的成員的同構性，可以使用更加適合CPU pipeline的編碼方式，減小CPU的緩存失效。
關於Orc文件格式的官網介紹，見：
https://cwiki.apache.org/confluence/display/Hive/LanguageManual+ORC
需要注意的是，ORC在讀寫時候需要消耗額外的CPU資源來壓縮和解壓縮，當然這部分的CPU消耗是非常少的。
數據模型
和Parquet不同，ORC原生是不支持嵌套數據格式的，而是通過對複雜數據類型特殊處理的方式實現嵌套格式的支持，例如對於如下的hive表：
CREATE TABLE `orcStructTable`( `name` string, `course` struct<course:string,score:int>, `score` map<string,int>, `work_locations` array<string> )
在ORC的結構中包含了複雜類型列和原始類型，前者包括LIST、STRUCT、MAP和UNION類型，後者包括BOOLEAN、整數、浮點數、字符串類型等，其中STRUCT的孩子節點包括它的成員變量，可能有多個孩子節點，MAP有兩個孩子節點，分別爲key和value，LIST包含一個孩子節點，類型爲該LIST的成員類型，UNION一般不怎麼用得到。每一個Schema樹的根節點爲一個Struct類型，所有的column按照樹的中序遍歷順序編號。
ORC只需要存儲schema樹中葉子節點的值，而中間的非葉子節點只是做一層代理，它們只需要負責孩子節點值得讀取，只有真正的葉子節點纔會讀取數據，然後交由父節點封裝成對應的數據結構返回。
文件結構
和Parquet類似，ORC文件也是以二進制方式存儲的，所以是不可以直接讀取，ORC文件也是自解析的，它包含許多的元數據，這些元數據都是同構ProtoBuffer進行序列化的。ORC的文件結構如下圖，其中涉及到如下的概念：
- ORC文件：保存在文件系統上的普通二進制文件，一個ORC文件中可以包含多個stripe，每一個stripe包含多條記錄，這些記錄按照列進行獨立存儲，對應到Parquet中的row group的概念。
- 文件級元數據：包括文件的描述信息PostScript、文件meta信息（包括整個文件的統計信息）、所有stripe的信息和文件schema信息。
- stripe：一組行形成一個stripe，每次讀取文件是以行組爲單位的，一般爲HDFS的塊大小，保存了每一列的索引和數據。
- stripe元數據：保存stripe的位置、每一個列的在該stripe的統計信息以及所有的stream類型和位置。
- row group：索引的最小單位，一個stripe中包含多個row group，默認爲10000個值組成。
- stream：一個stream表示文件中一段有效的數據，包括索引和數據兩類。索引stream保存每一個row group的位置和統計信息，數據stream包括多種類型的數據，具體需要哪幾種是由該列類型和編碼方式決定。
在ORC文件中保存了三個層級的統計信息，分別爲文件級別、stripe級別和row group級別的，他們都可以用來根據Search ARGuments（謂詞下推條件）判斷是否可以跳過某些數據，在統計信息中都包含成員數和是否有null值，並且對於不同類型的數據設置一些特定的統計信息。
（1）file level
在ORC文件的末尾會記錄文件級別的統計信息，會記錄整個文件中columns的統計信息。這些信息主要用於查詢的優化，也可以爲一些簡單的聚合查詢比如max, min, sum輸出結果。
（2）stripe level
ORC文件會保存每個字段stripe級別的統計信息，ORC reader使用這些統計信息來確定對於一個查詢語句來說，需要讀入哪些stripe中的記錄。比如說某個stripe的字段max(a)=10，min(a)=3，那麼當where條件爲a >10或者a <3時，那麼這個stripe中的所有記錄在查詢語句執行時不會被讀入。
（3）row level
爲了進一步的避免讀入不必要的數據，在邏輯上將一個column的index以一個給定的值(默認爲10000，可由參數配置)分割爲多個index組。以10000條記錄爲一個組，對數據進行統計。Hive查詢引擎會將where條件中的約束傳遞給ORC reader，這些reader根據組級別的統計信息，過濾掉不必要的數據。如果該值設置的太小，就會保存更多的統計信息，用戶需要根據自己數據的特點權衡一個合理的值
ORC元數據
請參考：更高的壓縮比，更好的性能–使用ORC文件格式優化Hive
數據訪問
讀取ORC文件是從尾部開始的，第一次讀取16KB的大小，儘可能的將Postscript和Footer數據都讀入內存。文件的最後一個字節保存着PostScript的長度，它的長度不會超過256字節，PostScript中保存着整個文件的元數據信息，它包括文件的壓縮格式、文件內部每一個壓縮塊的最大長度(每次分配內存的大小)、Footer長度，以及一些版本信息。在Postscript和Footer之間存儲着整個文件的統計信息(上圖中未畫出)，這部分的統計信息包括每一個stripe中每一列的信息，主要統計成員數、最大值、最小值、是否有空值等。
接下來讀取文件的Footer信息，它包含了每一個stripe的長度和偏移量，該文件的schema信息(將schema樹按照schema中的編號保存在數組中)、整個文件的統計信息以及每一個row group的行數。
處理stripe時首先從Footer中獲取每一個stripe的其實位置和長度、每一個stripe的Footer數據(元數據，記錄了index和data的的長度)，整個striper被分爲index和data兩部分，stripe內部是按照row group進行分塊的(每一個row group中多少條記錄在文件的Footer中存儲)，row group內部按列存儲。每一個row group由多個stream保存數據和索引信息。每一個stream的數據會根據該列的類型使用特定的壓縮算法保存。在ORC中存在如下幾種stream類型：
- PRESENT：每一個成員值在這個stream中保持一位(bit)用於標示該值是否爲NULL，通過它可以只記錄部位NULL的值
- DATA：該列的中屬於當前stripe的成員值。
- LENGTH：每一個成員的長度，這個是針對string類型的列纔有的。
- DICTIONARY_DATA：對string類型數據編碼之後字典的內容。
- SECONDARY：存儲Decimal、timestamp類型的小數或者納秒數等。
- ROW_INDEX：保存stripe中每一個row group的統計信息和每一個row group起始位置信息。
在初始化階段獲取全部的元數據之後，可以通過includes數組指定需要讀取的列編號，它是一個boolean數組，如果不指定則讀取全部的列，還可以通過傳遞SearchArgument參數指定過濾條件，根據元數據首先讀取每一個stripe中的index信息，然後根據index中統計信息以及SearchArgument參數確定需要讀取的row group編號，再根據includes數據決定需要從這些row group中讀取的列，通過這兩層的過濾需要讀取的數據只是整個stripe多個小段的區間，然後ORC會儘可能合併多個離散的區間儘可能的減少I/O次數。然後再根據index中保存的下一個row group的位置信息調至該stripe中第一個需要讀取的row group中。
ORC文件格式只支持讀取指定字段，還不支持只讀取特殊字段類型中的指定部分。
使用ORC文件格式時，用戶可以使用HDFS的每一個block存儲ORC文件的一個stripe。對於一個ORC文件來說，stripe的大小一般需要設置得比HDFS的block小，如果不這樣的話，一個stripe就會分別在HDFS的多個block上，當讀取這種數據時就會發生遠程讀數據的行爲。如果設置stripe的只保存在一個block上的話，如果當前block上的剩餘空間不足以存儲下一個strpie，ORC的writer接下來會將數據打散保存在block剩餘的空間上，直到這個block存滿爲止。這樣，下一個stripe又會從下一個block開始存儲。
由於ORC中使用了更加精確的索引信息，使得在讀取數據時可以指定從任意一行開始讀取，更細粒度的統計信息使得讀取ORC文件跳過整個row group，ORC默認會對任何一塊數據和索引信息使用ZLIB壓縮，因此ORC文件佔用的存儲空間也更小，這點在後面的測試對比中也有所印證。
關於row group index和bloom filter index的性能優化，請參考Hive性能優化之ORC索引–Row Group Index vs Bloom Filter Index
文件壓縮
ORC文件使用兩級壓縮機制，首先將一個數據流使用流式編碼器進行編碼，然後使用一個可選的壓縮器對數據流進行進一步壓縮。
一個column可能保存在一個或多個數據流中，可以將數據流劃分爲以下四種類型：
• Byte Stream
字節流保存一系列的字節數據，不對數據進行編碼。
• Run Length Byte Stream
字節長度字節流保存一系列的字節數據，對於相同的字節，保存這個重複值以及該值在字節流中出現的位置。
• Integer Stream
整形數據流保存一系列整形數據。可以對數據量進行字節長度編碼以及delta編碼。具體使用哪種編碼方式需要根據整形流中的子序列模式來確定。
• Bit Field Stream
比特流主要用來保存boolean值組成的序列，一個字節代表一個boolean值，在比特流的底層是用Run Length Byte Stream來實現的。
接下來會以Integer和String類型的字段舉例來說明。
（1）Integer
對於一個整形字段，會同時使用一個比特流和整形流。比特流用於標識某個值是否爲null，整形流用於保存該整形字段非空記錄的整數值。
（2）String
對於一個String類型字段，ORC writer在開始時會檢查該字段值中不同的內容數佔非空記錄總數的百分比不超過0.8的話，就使用字典編碼，字段值會保存在一個比特流，一個字節流及兩個整形流中。比特流也是用於標識null值的，字節流用於存儲字典值，一個整形流用於存儲字典中每個詞條的長度，另一個整形流用於記錄字段值。
如果不能用字典編碼，ORC writer會知道這個字段的重複值太少，用字典編碼效率不高，ORC writer會使用一個字節流保存String字段的值，然後用一個整形流來保存每個字段的字節長度。
在ORC文件中，在各種數據流的底層，用戶可以自選ZLIB, Snappy和LZO壓縮方式對數據流進行壓縮。編碼器一般會將一個數據流壓縮成一個個小的壓縮單元，在目前的實現中，壓縮單元的默認大小是256KB。
參數
二、Hive+ORC建立數據倉庫
在建Hive表的時候我們就應該指定文件的存儲格式。所以你可以在Hive QL語句裏面指定用ORCFile這種文件格式，如下：
CREATE TABLE ... STORED AS ORC ALTER TABLE ... [PARTITION partition_spec] SET FILEFORMAT ORC SET hive.default.fileformat=Orc
所有關於ORCFile的參數都是在Hive QL語句的TBLPROPERTIES字段裏面出現，他們是：
|
Key |
Default |
Notes |
|
orc.compress |
ZLIB |
high level compression (one of NONE, ZLIB, SNAPPY) |
|
orc.compress.size |
262,144 |
number of bytes in each compression chunk |
|
orc.stripe.size |
268435456 |
number of bytes in each stripe |
|
orc.row.index.stride |
10,000 |
number of rows between index entries (must be >= 1000) |
|
orc.create.index |
true |
whether to create row indexes |
三、Java操作ORC
到https://orc.apache.org官網下載orc源碼包，然後編譯獲取orc-core-1.3.0.jar、orc-mapreduce-1.3.0.jar、orc-tools-1.3.0.jar，將其加入項目中
import org.apache.hadoop.conf.Configuration;
import org.apache.hadoop.fs.Path;
import org.apache.hadoop.hive.ql.exec.vector.LongColumnVector;
import org.apache.hadoop.hive.ql.exec.vector.VectorizedRowBatch;
import org.apache.orc.CompressionKind;
import org.apache.orc.OrcFile;
import org.apache.orc.TypeDescription;
import org.apache.orc.Writer;
public class TestORCWriter {
public static void main(String[] args) throws Exception {
Path testFilePath = new Path("/tmp/test.orc");
Configuration conf = new Configuration();
TypeDescription schema = TypeDescription.fromString("struct<field1:int,field2:int,field3:int>");
Writer writer = OrcFile.createWriter(testFilePath, OrcFile.writerOptions(conf).setSchema(schema).compress(CompressionKind.SNAPPY));
VectorizedRowBatch batch = schema.createRowBatch();
LongColumnVector first = (LongColumnVector) batch.cols[0];
LongColumnVector second = (LongColumnVector) batch.cols[1];
LongColumnVector third = (LongColumnVector) batch.cols[2];
final int BATCH_SIZE = batch.getMaxSize();
// add 1500 rows to file
for (int r = 0; r < 15000000; ++r) {
int row = batch.size++;
first.vector[row] = r;
second.vector[row] = r * 3;
third.vector[row] = r * 6;
if (row == BATCH_SIZE - 1) {
writer.addRowBatch(batch);
batch.reset();
}
}
if (batch.size != 0) {
writer.addRowBatch(batch);
batch.reset();
}
writer.close();
}
}
大多情況下，還是建議在Hive中將文本文件轉成ORC格式，這種用JAVA在本地生成ORC文件，屬於特殊需求場景。