Hive存儲格式之ORC File詳解，什麼是ORC File

ORC檔案是以二進制的方式存儲的，不可以直接讀取，但由于ORC的自描述特性，其讀寫不依賴于 Hive Metastore 或任何其他外部中繼資料。本身存儲了檔案資料、資料類型及編碼資訊。因為檔案是自包含的，是以讀取ORC檔案資料無需考慮使用者使用環境。

目錄

• 概述
• 檔案存儲結構
  • Stripe
    • Index Data
    • Row Data
    • Stripe Footer
    • 兩個補充名詞
      • Row Group
      • Stream
  • File Footer
    • 條紋資訊
    • 列統計
    • 中繼資料
    • 類型資訊
      • 複雜資料類型
  • Postscript
• 資料讀取
  • 位置指針
  • 三層過濾
    • 檔案級
    • Stripe級
    • Row 級
  • 資料讀取
• 索引
  • 行組索引
  • 布隆過濾器
• 事務支援
• 壓縮
• 記憶體管理
• Hive中使用ORC
  • Hive使用
  • Hive參數設定

概述

本文基于上一篇文章 Hive存儲格式之RCFile詳解，RCFile的過去現在未來 撰寫，讀過上一篇文章，則更好了解以下内容。

2013年，HortonWorks在RCFile的基礎上開發出了ORC File（Optimied Row Columnar），在2015年成為Apache的頂級項目。以下簡稱ORC。

RCFile在被Facebook開源後，作為Hive之中典型的列存儲模型被廣泛使用，相比于之前的存儲格式有很大的優勢，但是同樣RCFile仍然有值得改進的地方。

ORC 做了相關優化，在Hive的使用中有更好的表現，它支援複雜資料類型、ACID支援及内置索引支援，非常适合海量資料的存儲。

ORC并不是一個單純的列式存儲格式，它也遵循了先水準分區，再垂直分區的理念，采用混合存儲結構。

除了Hive，目前也被Spark SQL，Flink，Presto，Impala等查詢引擎支援。

我上一篇中提及RCFile的兩個優化方向：

• 不同資料類型的列使用不同的壓縮方案（Facebook論文指出的優化方向-未做）
• 全局檢索性能查，提供更合理快速的檢索功能

ORC相對于RCFile提供了更優的解決方案：

• 列資料的類型感覺：與RCFile之前未對列資料都統一為BLOB（binary large object-二進制大對象）資料不同，ORC可以感覺列的資料類型，做出更為合理的資料壓縮選擇。
• 嵌套資料類型支援：ORC可以在列資料之中插入Struct，Union，List，Map等資料，讓資料操作更加靈活，也更加适合非結構化資料的存儲與處理。
• 謂詞下推：這個算是RCFile原先功能的補強，在中繼資料層面增加了很多内容，來利用謂詞下推加速處理的過程。ORC自己稱之為輕量級索引，其實就是一些相較于RCFile更為詳細的統計資料。
• 檔案可切分：檔案可切分，在Hive中使用ORC作為表的檔案存儲格式，不僅可以節省HDFS的存儲資源，查詢任務的輸入資料量減少，使用的MapTask也就減少了。
• 記憶體管理：提供了一個memory manager來管理記憶體使用情況。

接下來我們通過以下幾部分來完整的了解一下什麼是ORC。

檔案存儲結構

ORC檔案是以二進制的方式存儲的，不可以直接讀取，但由于ORC的自描述特性，其讀寫不依賴于 Hive Metastore 或任何其他外部中繼資料。本身存儲了檔案資料、資料類型及編碼資訊。因為檔案是自包含的，是以讀取ORC檔案資料無需考慮使用者使用環境。

由于ORC的中繼資料使用Protocol Buffers序列化，添加新字段不會破壞原有的資料結構。

如下圖所示，ORC引入了三個新的元件。

• Stripe
• File Footer
• PostScript

Stripe

ORC的主體由多個Stripe（也成為條帶）組成，類似于RCFile中的行組，但是其遠遠大于行組的4MB，最大可達到250M大小，更大的Stripe使ORC的資料讀取更加高效。

每個Stripe彼此獨立，這個很好了解，因為每行資料彼此獨立，而每行資料不會在多個Stripe中。

在Hive中每個Stripe通常由不同的任務處理。列存儲格式的定義特征是每一列的資料是分開存儲的，從檔案中讀取資料的速度應該與讀取的列數成正比。

Stripe又包含三個部分：Index Data、Row Data和Stripe Footer。索引和資料部分都按列劃分，是以隻需要讀取所需列的資料。

Index Data

索引資料部分，存儲每列的統計資料。Index Data在Stripe的最前面，因為它們隻在使用謂詞下推或尋找指定行時加載。（這裡主要利用索引功能實作的，具體見下文條帶級别索引）

Row Data

實際存儲資料的單元，利用列存儲原理，對不同列可以實作不同的壓縮方案，所有的列資料可以組成行資料。

Stripe Footer

存儲了每個列的編碼，資料流目錄與位置。

message StripeFooter {
 // the location of each stream
 repeated Stream streams = 1;
 // the encoding of each column
 repeated ColumnEncoding columns = 2;
 optional string writerTimezone = 3;
 // one for each column encryption variant
 repeated StripeEncryptionVariant encryption = 4;
}
           

兩個補充名詞

在資料存儲和解析的過程中還使用到了兩個比較抽象的名詞描述，分别為Row Group和Stream，這裡單獨說明一下。

Row Group

這裡的Row Group和RCFile裡的行組不是同一個概念，RCFile的行組對标的是ORC中的Stripe。

Row Group是虛拟的(下文有詳細介紹)，Row Group Index是索引（index）的最小機關，一個Index Data中包含多個行組。預設值為 10000 個值。每一個Row Group Index中有多少條記錄在檔案的Footer中存儲。

Stream

本節以上部分是Stripe的邏輯結構，具體資料存儲還有更細粒度的機關存在，那就是Stream。在ORC檔案中，每一列都存儲在多個Stream中，這些Stream在檔案中彼此相鄰存儲。Stream儲存了使用者真正關心的業務資料内容。

這也是ORC列式存儲的根本所在：正如開頭的架構圖一樣，一個大檔案由各Stripe分割，每個Stripe負責多個行組，在一個Stripe負責的這多行範圍内，各列的資料内容以Stream的形式按列存儲。為了描述每個Stream，ORC以位元組為機關存儲Stream的類型、列ID和Stream的大小。每個Stream中存儲内容的詳細資訊取決于列的類型和編碼。也就是說，在一個Stripe中的每一列都可能有多個表示不同資訊的Stream，存儲内容如下所示：

message Stream {
 enum Kind {
   // boolean stream of whether the next value is non-null
   PRESENT = 0;
   // the primary data stream
   DATA = 1;
   // the length of each value for variable length data
   LENGTH = 2;
   // the dictionary blob
   DICTIONARY_DATA = 3;
   // deprecated prior to Hive 0.11
   // It was used to store the number of instances of each value in the
   // dictionary
   DICTIONARY_COUNT = 4;
   // a secondary data stream
   SECONDARY = 5;
   // the index for seeking to particular row groups
   ROW_INDEX = 6;
   // original bloom filters used before ORC-101
   BLOOM_FILTER = 7;
   // bloom filters that consistently use utf8
   BLOOM_FILTER_UTF8 = 8;
 
   // Virtual stream kinds to allocate space for encrypted index and data.
   ENCRYPTED_INDEX = 9;
   ENCRYPTED_DATA = 10;
 
   // stripe statistics streams
   STRIPE_STATISTICS = 100;
   // A virtual stream kind that is used for setting the encryption IV.
   FILE_STATISTICS = 101;
 }
 required Kind kind = 1;
 // the column id
 optional uint32 column = 2;
 // the number of bytes in the file
 optional uint64 length = 3;
}
           

這些不同類型的Stream會分布在ORC檔案裡的不同部分，每個Stream的資料會根據該列的類型使用特定的壓縮算法儲存。主要有以下幾種（Kind）。首先是下面這5種Stream，出現在各Stripe的Row Data位置，即文章開頭架構圖的藍色部分：

• PRESENT：幾乎每一列都會使用該Stream，按位标記該值是否為NULL
• DATA：記錄資料内容本身。
• LENGTH：記錄每個成員的長度，這個是針對string類型的列或者子列才有的。
• DICTIONARY_DATA：對string類型資料采用字典編碼以後的内容（該列所有去重值）。
• SECONDARY：和DATA搭配，存儲Decimal、timestamp類型的小數部分或者納秒數部分等。

下面兩種Stream出現在Index Data中。

• ROW_INDEX：儲存Stripe中每個row group的統計資訊和每個row group起始位置資訊。
• BLOOM_FILTER：用于記錄目前列在該Stripe中每一個row group的布隆過濾器資訊，用于謂詞下推跳過不用讀取的行組。

File Footer

檔案頁腳包含檔案主體的布局，類型架構資訊，行數和每個列的統計資訊。通過它們可以篩選出需要讀取列的資料。

條紋資訊

檔案的主體被分成stripe。每個stripe都是自包含的，可以僅使用其自己的位元組以及檔案的頁腳和後記來讀取。每個stripe包含整行，是以行永遠不會跨越stripe邊界。

它包含了每一個stripe的長度和偏移量，該檔案的schema資訊(将schema樹按照schema中的編号儲存在數組中，如下圖)、整個檔案的統計資訊以及每一個stripe的行數。

列統計

列統計的目标是，對于每一列，記錄總數并根據類型記錄其他有用字段。對于大多數原始類型，它記錄了最小值和最大值；對于數字類型，多了一個總和記錄。列統計資訊還通過設定 hasNull 标志記錄行組内是否有任何空值。ORC 的謂詞下推使用 hasNull 标志來更好地支援“IS NULL”查詢。

對于整數類型（tinyint、smallint、int、bigint），列統計資訊包括最小值、最大值和總和。如果計算的總和存儲大于資料本身，則不會記錄總和。

message IntegerStatistics {
 optional sint64 minimum = 1;
 optional sint64 maximum = 2;
 optional sint64 sum = 3;
}
           

對于浮點類型（float、double），列統計資訊包括最小值、最大值和總和。如果總和溢出雙倍，則不記錄總和。

對于字元串，記錄最小值、最大值和所有值的長度之和。

對于布爾值，統計資訊包括假值和真值的計數。

對于小數，存儲最小值、最大值和總和。

日期列将最小值和最大值記錄為自 UNIX 紀元（UTC 時間為 1970 年 1 月 1 日）以來的天數。

時間戳列将最小值和最大值記錄為自 UNIX 紀元 (1/1/1970 00:00:00) 以來的毫秒數。在 ORC-135 之前，包括本地時區偏移量，它們存儲為

minimum

和

maximum

. 在 ORC-135 之後，時間戳調整為 UTC，然後再轉換為毫秒并存儲在

minimumUtc

和

maximumUtc

中。

message TimestampStatistics {
 // min,max values saved as milliseconds since epoch
 optional sint64 minimum = 1;
 optional sint64 maximum = 2;
 // min,max values saved as milliseconds since UNIX epoch
 optional sint64 minimumUtc = 3;
 optional sint64 maximumUtc = 4;
}
           

二進制列存儲所有值的總位元組數。

中繼資料

中繼資料（Metadata）包括使用者中繼資料和檔案中繼資料，使用者中繼資料通常作為秘鑰使用，這裡不做闡述了。

檔案中繼資料部分包含條帶級别粒度的列統計資訊。這些統計資訊可以根據每個條帶的謂詞下推過濾資料。

類型資訊

ORC檔案中的所有行具有相同的架構，定義的類型是如同下圖的嵌套模式，其中複合類型在其下具有子列。

等效的Hive DDL是：

create table orc_temp(
	myInt int,
	myMap map<string,struct<myStirng:string,myDouble:double>>,
	myTime timestamp
)
           

類型樹通過前序周遊被展平到一個清單中，其中每個類型都被配置設定了下一個id。

複雜資料類型

對于複雜資料類型，比如Map，ORC檔案會将一個複雜資料類型字段解析成多個子字段。下表中列舉了ORC檔案中對于複雜資料類型的解析：

資料類型	子列
Array	一個包含所有數組元素的單個子列
Map	兩個子列，一個key子列，一個value子列
Struct	每一個屬性對應一個子列
Union	每一個屬性對應一個子列

等效的DDL

CREATE TABLE tbl (
    col1 Int,
    col2 Array<Int>,
    col4 Map<String,
    	Struct<col7:String,col8:Int>
    >,
    col9 String
)
           

Postscript

檔案的最後一個位元組儲存着PostScript的長度，它的長度不會超過256位元組，PostScript提供了解釋檔案其餘部分的必要資訊，包括檔案的 Footer 和 Metadata 部分的長度、檔案的版本以及使用的一般壓縮類型（例如 none、zlib 或 snappy）、檔案内部每個壓縮塊的最大長度（每次配置設定記憶體的大小）以及一些版本資訊。

資料讀取

orc檔案結構對資料的查找和索引本質上是三層過濾結合位置指針來實作的：檔案級、Stripe級、Row級。這樣可以把最終實際要掃描讀取的資料減少到部分Stripe的部分Row，不用全掃整個檔案。也就是先從檔案末尾往前讀檔案中繼資料，再跳着讀Stripe中繼資料，最終讀需要的Stripe中的部分資料。

位置指針

在讀取ORC檔案時，讀取器需要知道兩種位置，才能執行有效的資料讀取操作。

首先，由于條帶中的一列具有多個邏輯索引組（Row Group Index），是以ORC檔案的讀取器需要知道中繼資料流和資料流中每個索引組的起點。在上圖中，指向中繼資料流和資料流的圓虛線表示這種位置指針。

其次，一個ORC檔案可以包含多個Stripe，而這個ORC檔案的一個HDFS塊可以包含多個Stripe。為了有效地定位Stripe的起點，需要定位Stripe的位置指針。這些指針存儲在ORC檔案的檔案頁腳中（圓角虛線指向上圖中條紋的起點）。

三層過濾

檔案級

在ORC檔案的末尾（檔案頁腳）會記錄檔案級别的統計資訊，會記錄整個檔案中每列的統計資訊。這些資訊主要用于查詢的優化，也可以為一些簡單的聚合查詢比如max, min, sum輸出結果。

Stripe級

ORC檔案會儲存每個字段Stripe級别的統計資訊，每個條帶中的每列的值的統計資訊，ORC reader使用這些統計資訊來确定對于一個查詢語句來說，需要讀入哪些Stripe中的記錄。例如，如果查詢要查找年齡超過 100 歲的人，則 SARG 将為“年齡 > 100”，并且隻會讀取年齡超過 100 歲的條帶。

Row 級

為了進一步的避免讀入不必要的資料，在邏輯上将一個column的index（Index Data部分）以一個給定的值（預設為10000，可由參數配置）分割為多個index組（Row Group Index），存儲統計資訊和行組索引開始的位置。

Hive查詢引擎會将where條件中的限制傳遞給ORC reader，這些reader根據組級别的統計資訊，過濾掉不必要的資料。如果該值設定的太小，就會儲存更多的統計資訊，使用者需要根據自己資料的特點權衡一個合理的值。

關于虛拟的Row Group，這10000個值的Row group Index映射到資料裡，就是一個個的Row Group。反向看起來好像是Row Group的存在産生了Row group Index。但實際上Row Group是不存在的。為了便于了解，有些文章裡也會說在Stripe之下還會有一個Row Group的存在。

資料讀取

看了以上三級檔案結構，就能很好的了解整個ORC的資料讀取流程了。

讀取檔案中繼資料：讀取 ORC 檔案是從尾部開始的。第一次讀取16KB的大小，盡量的将Postscript和Footer資料都讀入記憶體。

讀取Stripe中繼資料：處理Stripe時首先從Footer中擷取每一個Stripe的起始位置和長度、每一個Stripe的Footer資料(中繼資料，記錄了index和data的的長度)。在初始化階段擷取所有的中繼資料以後，會得到一個指定讀取哪些列的編号構成的Boolean數組。如果不指定則讀取所有的列。

讀取Row Group級中繼資料：接下來通過傳遞SearchArgument參數指定過濾條件，根據中繼資料首先讀取每個stripe中的index資訊，而後根據index中的統計資訊以及SearchArgument參數讀取的row group編号，擷取到所要讀取資料範圍包含了哪些row group，在對應的row group中讀取需要的資料。

讀取資料處理：經過這兩層的過濾，需要讀取的資料隻是整個Stripe多個小段的區間，而後ORC會盡量合并多個離散的區間盡量減少I/O次數。下一步再根據Index中儲存的下一個row group的位置資訊開始該Stripe中的下一個需要讀取的row group中進行資料讀取。

使用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檔案占用的存儲空間也更小。

索引

ORC檔案在Row級過濾中使用的索引具體分為兩種。行組索引和布隆過濾器。後者為支援更好的使用謂詞下推過濾資料。布隆過濾器流與行組索引交錯。這種布局便于在單次讀取操作中同時讀取布隆過濾器流和行索引流。

行組索引

行組索引（Row Group Index）由每個原始列的 ROW_INDEX 流組成，每個原始列被行組索引覆寫。行組可調節，預設為 10,000 行。存儲列的每個流的位置以及該行組的統計資訊。

索引流被放置在條帶的前面，因為在預設的流式傳輸情況下，它們不需要被讀取。它們僅在使用謂詞下推或讀者尋找特定行時加載。

message RowIndexEntry {
 repeated uint64 positions = 1 [packed=true];
 optional ColumnStatistics statistics = 2;
}
message RowIndex {
 repeated RowIndexEntry entry = 1;
}
           

對于具有多個流的列，每個流中的位置序列是連接配接的。

因為字典是随機通路的，即使隻讀取部分條帶，也必須讀取整個字典。

布隆過濾器

從 Hive 1.2.0 開始，Bloom Filters 被添加到 ORC 索引中。謂詞下推可以利用布隆過濾器更好地修剪不滿足過濾條件的行組。布隆過濾器索引由通過“orc.bloom.filter.columns”表屬性指定的每一列的 BLOOM_FILTER 流組成。

布隆過濾器的具體使用參見上篇--什麼是謂詞下推篇中的列式存儲中的謂詞下推（RF算法）。

事務支援

在 Hive 中以原子方式向表中添加資料的唯一方法是添加新分區。更新或删除分區中的資料需要删除舊分區并将其與新資料一起添加回來，并且不可能以原子方式進行。

為了資料可靠性得到保證，需要實作保證原子性、一緻性、隔離性和持久性的 ACID 事務。ORC支援 ACID 事務，支援流式攝取到 Hive 表中，查詢要麼看到所有事務，要麼看不到任何事務。

HDFS 是一次寫入檔案系統，而 ORC 是一次寫入檔案格式，不支援編輯檔案。

Hive在 ORC File基礎上，基于“base file+delta file”的模型實作了對ACID的支援，即資料首先被寫入一個 base file中，之後的修改資料被寫入一個 delta file，Hive将定期合并這兩個檔案。

但需要注意的是， Hive ORC ACID并不是為OLTP場景設計的，它能較好地支援一個事務中更新上百萬(甚至更多)條記錄，但難以應對一小時内上百萬個事務的場景。

壓縮

ORC檔案使用了一個兩級壓縮方案。流首先由特定于流類型的資料編碼方案進行編碼。然後，可以使用一個可選的通用資料壓縮方案（zlib 或 snappy）來進一步壓縮該流。

上文提到對于一個列，它被存儲在一個或多個流中。根據流的類型，我們可以将流分為四種基本類型。根據其類型，每個流有自己的資料編碼方案。下面介紹了這四種流的類型。

• 位元組流：一個位元組流基本上存儲一個位元組序列，它不編碼資料。
• 運作長度位元組流：一個運作長度位元組流存儲一個位元組序列。對于一個相同的位元組序列，它存儲重複的位元組和出現的情況。
• 整數流：一個整數流存儲一個整數序列。它可以用運作長度編碼和增量編碼來編碼這些整數。整數子序列的特定編碼方案是根據其模式确定的。
• 比特流：一個位字段流用于存儲一個布爾值的序列。在這個流中，一個位表示一個布爾值。在底層，位字段流由運作長度位元組流支援。

對于Int列，将使用一個比特流和一個整數流。比特流用于記錄一個值是否為空。整數流用于記錄此Int列的整數值。

對于二進制資料，ORC 使用三個流 ，比特流、位元組流 和 整數流，它們存儲每個值的長度。

對于字元串列，ORC寫入器将首先檢查使用字典編碼是否可以有效地通過評估字典中不同條目的數量與編碼值的數量的比率是否大于可配置的門檻值（預設門檻值為0.8）來有效地存儲資料。

如果小于0.8，ORC寫入器将使用字典編碼方案，該列将存儲在一個比特流、一個位元組流和兩個整數流中。與Int列一樣，比特流也用于記錄一個值是否為空。位元組流用于存儲字典。一個整數流用于存儲字典中每個詞條的長度。第二個整數流用于存儲此列的值。

如果字典中不同條目目的數量與編碼值的數量大于門檻值，ORC編寫器将知道有許多不同的值，使用字典編碼不能有效地存儲資料。是以，它将自動存儲此列，而不需要進行字典編碼。ORC寫入器将使用位元組流來存儲此字元串列的值，并使用整數流來存儲每個值的長度，而不是将字典和将值存儲為對字典的索引。

在ORC檔案中，可以進一步對ORC檔案使用通用的編解碼器壓縮流（ZLIB、Snappy）。對于一個流，通用編解碼器将這個流壓縮為多個小壓縮單元。壓縮單元的預設大小為256KB。

ORC存儲格式支援三種通用壓縮格式，NONE，ZLIB和snappy壓縮，預設為ZLIB壓縮，即不設定壓縮格式則為ZLIB壓縮格式，可以通過

"orc.compress"="NONE"

來設定其餘兩種壓縮格式。

關于以上四種類型的編碼詳解，感興趣的人可以去ORC官網具體檢視。

記憶體管理

當ORC檔案的寫入器寫入資料時，它會緩沖記憶體中的整個Stripe。是以，ORC寫入器的記憶體占用是Stripe的大小。由于Stripe的預設大小很大，當有許多使用者同時寫入多個映射或減少任務中的ORC檔案時（例如，當使用者使用動态分區，并且分區列有許多不同的值時），此任務可能會耗盡記憶體。為了綁定這些并發寫入器的記憶體消耗，ORC檔案中提供了一個記憶體管理器。在“映射”或“減少”任務中，記憶體管理器會設定一個門檻值，以限制此任務中的寫入者可以使用的最大記憶體量。然後，每個新寫入器都以其Stripe大小（已設定的Stripe大小）注冊到此記憶體管理器。

當寫入器使用的記憶體總量（設定的Stripe大小總數）超過記憶體門檻值時，記憶體管理器将以記憶體門檻值與注冊的Stripe大小總數的比值縮小這些寫入器中使用的實際Stripe大小。當寫入器關閉時，記憶體管理器将從注冊的Stripe大小中減去此寫入器的注冊Stripe大小。如果注冊的總條帶大小低于門檻值，則所有寫入器的實際條帶大小将被設定為其原始條帶大小。使用這種控制機制，來限制任務中ORC檔案的活動寫入器的記憶體。

Hive中使用ORC

Hive使用

在建Hive表的時候指定檔案的存儲格式。

CREATE TABLE ... STORED AS ORC

ALTER TABLE ... [PARTITION partition_spec] SET FILEFORMAT ORC

SET hive.default.fileformat=Orc
           

示例

-- 建表
create table lubian_orc(
	id int,
  name string,
  extra string
) comment 'orc格式測試表'
stored as orc;
-- 寫入資料
insert overwrite table lubian_orc
select id,name,extra from lubian_text
           

大多情況下，還是建議在Hive中将文本檔案轉成ORC格式（以上），使用程式生成ORC檔案，例如Java，屬于特殊需求場景，感興趣可以在orc官網找對應api做一些測試。

Hive參數設定

所有關于ORCFile的參數都是在Hive QL語句的TBLPROPERTIES字段裡面出現

參數名	預設值	說明
hive.exec.orc.memory.pool	0.5	每個寫入任務使用記憶體最大比例
hive.exec.orc.default.stripe.size	256M	stripe的預設大小
hive.exec.orc.default.block.size	25610241024	orc檔案在檔案系統中的預設block大小，從hive-0.14開始
hive.exec.orc.dictionary.key.size.threshold	0.8	String類型字段使用字典編碼的門檻值，大于該門檻值，不使用字典編碼
hive.exec.orc.default.row.index.stride	10000	stripe中的分組大小
hive.exec.orc.default.compress	ZLIB	ORC檔案的預設壓縮方式
hive.exec.orc.skip.corrupt.data	false	遇到錯誤資料的處理方式，false直接抛出異常，true則跳過該記錄

更多參數參考官網

以上，就是關于ORC檔案格式的詳細說明了，如果覺得不錯，點個贊再走吧。

按例，歡迎點選此處關注我的個人公衆号，交流更多知識。

背景回複關鍵字 hive，随機贈送一本魯邊備注版珍藏大資料書籍。