一、背景

為了提升對敏感數(shù)據(jù)的保護(hù)，需要對Hive表一些敏感數(shù)據(jù)進(jìn)行加密存儲。

Spark組件已經(jīng)通過引入了Apache ORC項目（Java版本）對ORC格式的Hive表的數(shù)據(jù)進(jìn)行加解密。

StarRocks也使用了Apache ORC項目的C++版本讀寫ORC文件，但是C++版本沒有實現(xiàn)加解密功能，在使用StarRocks對Hive表進(jìn)行即席分析時，無法對具有加密列的Hive表進(jìn)行查詢，因此，需要對StarRocks 的Apache ORC模塊進(jìn)行改造，使其支持對ORC格式的Hive加密表數(shù)據(jù)讀取功能，數(shù)據(jù)架構(gòu)圖如下圖所示：

希望通過本文對ORC加密文件讀取功能的實現(xiàn)細(xì)節(jié)的剖析，讓讀者更加深刻理解ORC文件，同時了解StarRocks支持加解密數(shù)據(jù)分析的方案。

二、問題引入

在正式開啟全文的閱讀之前，我們首先引入幾個問題，然后帶著這些問題去閱讀后面的內(nèi)容，將會更有針對性與啟發(fā)性，通過深入解答這些問題，我們不僅能夠更好地理解相關(guān)的概念和技術(shù)，還能提升分析和解決問題的能力。

問題如下：

1. 程序解壓某個文件時，是否需要一次性讀取整個文件后再進(jìn)行解壓操作？
2. ORC 文件究竟是如何做到在不掃描全文件的情況下就能精準(zhǔn)查詢到想要的數(shù)據(jù)？
3. 當(dāng) SQL 查詢條件不符合最左前綴原則時，ORC文件中的索引是否就會失效？
4. 數(shù)據(jù)加密、解密、解壓以及壓縮之間的關(guān)聯(lián)關(guān)系到底是怎樣的？
5. 在寫ORC文件時為什么是先壓縮后加密，而不是先加密后解壓？

三、ORC文件介紹

ORC（Optimized Row Columnar）文件格式是一種高度優(yōu)化的列式存儲格式，它主要用于Hadoop生態(tài)系統(tǒng)中的大數(shù)據(jù)處理和分析。ORC文件結(jié)構(gòu)的設(shè)計旨在提高I/O效率、減少數(shù)據(jù)讀取時間，并支持復(fù)雜的數(shù)據(jù)類型和壓縮算法。

3.1 四層結(jié)構(gòu) File ,Stripe,Stream，Group

一個File中包含多個Stripe，一個Stripe包含多個Steam，一個Stream包含多個Group，每個Group默認(rèn)存儲1萬行數(shù)據(jù)，如下圖所示：

3.2 三層索引

• FileStat ：文件級別各列的統(tǒng)計信息，用于判斷SQL條件是否下推。
• StripeStat：Stripe級別各列的統(tǒng)計信息，用于判斷SQL條件是否下推。
• IndexData：每個Stripe 內(nèi)部各列的索引信息，用于判斷SQL條件是否下推。

在讀取文件中數(shù)據(jù)之前，會先讀取以上3類索引數(shù)據(jù)，根據(jù)SQL條件逐層進(jìn)行比對，來決定是否跳過某些數(shù)據(jù)的讀取，減少數(shù)據(jù)掃描量，從而提升SQL查詢效率。

下表是只包含id和name兩列的ORC文件的各層統(tǒng)計信息的案例：

FileStat

StripeStat

IndexData

3.3 ORC文件內(nèi)部詳細(xì)結(jié)構(gòu)

前面已經(jīng)大體介紹了ORC文件的結(jié)構(gòu)，下面詳細(xì)介紹其內(nèi)部結(jié)構(gòu)，ORC文件由多個邏輯層次組成，每個層次都有特定的作用和結(jié)構(gòu)，下圖具體描述了包含2列（id，name）的ORC文件結(jié)構(gòu)圖：

• Tail：存儲文件的元數(shù)據(jù)，如列的壓縮信息、統(tǒng)計信息、版本等，包含了三個部分：PostScript、Footer、MetaData。
• Body：實際存儲數(shù)據(jù)的部分，由多個Stripe組成。

下面分別介紹Tail和Body內(nèi)部包含哪些結(jié)構(gòu)：

Tail文件尾部是讀取ORC文件的起點，它包含了文件關(guān)鍵信息：

• PostScript：存儲文件的壓縮類型、壓縮塊大小、版本信息，F(xiàn)ooter和MetaData的長度等，這部分?jǐn)?shù)據(jù)不會被壓縮。
• Footer：記錄了整個文件所有列的統(tǒng)計信息（FileStat），所有Stripe的元數(shù)據(jù)信息（stripesList），加密信息（encryption）以及文件body長度。
• MetaData：存儲該文件所有Stripe的統(tǒng)計信息（StripeStat）。

Body實際存儲數(shù)據(jù)的部分，由多個Stripe組成，每個Stripe包含多個Stream，先存儲索引相關(guān)的Stream（index-Stream），后面存儲實際數(shù)據(jù)相關(guān)的Stream（data-Stream），每一列包含多個index-Stream和data-Stream，Stripe是ORC文件中數(shù)據(jù)存儲的基本單元，每個Stripe數(shù)據(jù)大小一般不超過200M，主要包含下面幾塊內(nèi)容：

• Stripe Footer：包含所有Stream的元數(shù)據(jù)（streamsList）和加密信息（encryption）等。
• Index-Stream：存儲索引相關(guān)數(shù)據(jù)的Stream，按列存儲。
• Data-Stream：儲實際數(shù)據(jù)相關(guān)的Stream，按列存儲。

ORC文件的讀取是從尾部最后一個字節(jié)開始的，得到PostScript的長度，讀取PostScript，然后根據(jù)PostScript中的FooteLength，MetaDataLength信息讀取MetaData和Footer，最后根據(jù)Footer中的Stripe信息讀取具體的數(shù)據(jù)Stripe，上面的文字介紹可能不是很直觀，如果想更細(xì)節(jié)了解ORC文件結(jié)構(gòu)內(nèi)容可以參考（ORC文件結(jié)構(gòu)思維導(dǎo)圖，ORC文件官網(wǎng)介紹）。

四、相關(guān)概念的理解

4.1 對稱加解密

對稱加解密的要素包括密鑰、明文、密文和加密算法。以下是對這些要素關(guān)系的描述：

• 密鑰：密鑰是加密和解密過程中的關(guān)鍵元素，它是由隨機數(shù)生成的，通常是固定長度的一串二進(jìn)制數(shù)。
• 明文：明文是指原始的信息，可以是文本、圖片、音頻等各種形式的數(shù)據(jù)。
• 密文：密文是經(jīng)過加密算法處理后的數(shù)據(jù)，只有知道密鑰的人才能解密還原成明文。
• 加密算法：加密算法是將明文轉(zhuǎn)換成密文的過程，這個過程通常涉及到一系列的數(shù)學(xué)運算，比如AEC，RSA等。

注意：對稱加密的加密密鑰 和 解密密鑰是一樣的。

4.2 文件的壓縮和解壓縮

4.2.1 壓縮算法

壓縮算法是用于減小文件大小的數(shù)學(xué)方法。它通過各種技術(shù)，如替換、重新編碼、差分編碼、運行長度編碼、字典編碼、變換編碼等，來減少數(shù)據(jù)的冗余和實現(xiàn)數(shù)據(jù)的體積縮小。壓縮算法可以是無損的或有損的：

• 無損壓縮：意味著原始數(shù)據(jù)可以完全從壓縮文件中恢復(fù)，常用于文本和某些類型的數(shù)據(jù)文件。
• 有損壓縮：為了獲得更高的壓縮率，允許丟失一些數(shù)據(jù)，常用于圖像、音頻和視頻文件。

4.2.2 解壓算法

解壓算法是壓縮算法的逆過程，它用于將壓縮文件恢復(fù)到其原始狀態(tài)。無損壓縮的解壓算法能夠完全恢復(fù)原始數(shù)據(jù)，而有損壓縮的解壓算法則可能無法完全恢復(fù)所有原始數(shù)據(jù)。

文件壓縮和解壓縮簡單流程圖如下：

注意：數(shù)據(jù)的壓縮算法和解壓算法要一樣

4.2.3 壓縮塊

文件壓縮塊是指對文件進(jìn)行壓縮處理后生成的一組連續(xù)的數(shù)據(jù)塊。在文件壓縮過程中，文件被分割成多個塊，每個塊都經(jīng)過壓縮算法處理。一般來說，文件壓縮塊的大小可配置。例如，ZIP壓縮的每個壓縮塊的大小可以達(dá)到64KB或更大，而在其他壓縮格式如7z中，壓縮塊的大小可以更大，通常為數(shù)MB。這些大小可以根據(jù)文件的特性和壓縮算法的性能進(jìn)行調(diào)整，以達(dá)到更好的壓縮比和解壓性能。

注意：在解壓文件的過程中會從文件中讀取整個壓縮塊數(shù)據(jù)到內(nèi)存之后再使用解壓算法進(jìn)行解壓處理，所以壓縮塊越大每次解壓讀取到內(nèi)存里的數(shù)據(jù)會越大。

4.3 加密壓縮文件讀寫大致流程

在掌握了數(shù)據(jù)加密和壓縮的基礎(chǔ)知識之后，讓我們從宏觀的角度了解一下ORC加密文件讀寫流程，如下圖所示：在寫入時，內(nèi)存中的數(shù)據(jù)首先被序列化，然后壓縮以減少體積，最后對數(shù)據(jù)加密。在讀取時，數(shù)據(jù)首先被解密以恢復(fù)原始格式，然后解壓數(shù)據(jù)得到原始數(shù)據(jù)，最后通過反序列化原始數(shù)據(jù)轉(zhuǎn)換為內(nèi)存對象。

詳細(xì)說明寫入和讀取過程中的各個步驟：

（1）寫入過程（序列化、壓縮、加密）

• 序列化：在數(shù)據(jù)寫入存儲系統(tǒng)之前，首先需要將內(nèi)存中的對象轉(zhuǎn)換成可以存儲或傳輸?shù)母袷剑@個過程稱為序列化。序列化后的數(shù)據(jù)通常是一個二進(jìn)制格式，便于后續(xù)的處理。
• 壓縮：序列化后的數(shù)據(jù)可能會占用較大的空間。為了減少存儲需求和提升后續(xù)數(shù)據(jù)加密處理效率，接下來對數(shù)據(jù)進(jìn)行壓縮。壓縮算法會嘗試去除數(shù)據(jù)中的冗余，從而減少數(shù)據(jù)的體積。
• 加密：壓縮后的數(shù)據(jù)需要進(jìn)行加密，以確保數(shù)據(jù)的安全性。加密算法會使用密鑰對數(shù)據(jù)進(jìn)行加密，生成密文。
• 存入文件中：加密后的密文被存儲在文件中，等待后續(xù)的讀取或傳輸。

（2）讀取過程（解密、解壓、反序列化）

• 解密：當(dāng)需要讀取文件中的數(shù)據(jù)時，首先需要使用正確的密鑰和加密算法對密文進(jìn)行解密，恢復(fù)為壓縮前的數(shù)據(jù)。
• 解壓：解密后，應(yīng)用解壓算法對數(shù)據(jù)進(jìn)行解壓，恢復(fù)到序列化前的狀態(tài)。
• 反序列化：解壓后的數(shù)據(jù)是一個二進(jìn)制格式，需要進(jìn)行反序列化，將其轉(zhuǎn)換為內(nèi)存中的對象。反序列化是序列化的逆過程，它將二進(jìn)制數(shù)據(jù)轉(zhuǎn)換為可讀可操作的數(shù)據(jù)結(jié)構(gòu)。
• 內(nèi)存對象：經(jīng)過解密、解壓和反序列化之后，數(shù)據(jù)最終以內(nèi)存對象的形式被程序處理。

五、StarRocks 讀取 ORC 加密文件實現(xiàn)方案

5.1 ORC文件內(nèi)部數(shù)據(jù)加密關(guān)系

首先，介紹幾個密鑰的含義：

statKey：用于解密加密列的FileStat，StripeStat的密鑰，每個列一個，加密存儲在文件Footer里。

dataKey：用于解密加密列的IndexData 和 RowData，每個Stripe的每一列都有一個，加密存儲在Stripe的Footer里。

masterKey：文件的根密鑰，用于解密ORC文件中被加密的statKey 和 dataKey，該密鑰沒有存儲在文件中，一般存儲在Hive表屬性上。要解密ORC文件中的數(shù)據(jù)，首先需要獲取這個masterKey。然而，masterKey本身也是加密的，因此在讀取Hive表之前，必須先從表屬性中提取出加密的masterKey,訪問密鑰管理服務(wù)（Key Management Service, KMS），對加密的masterKey進(jìn)行解密，從而獲得可用于實際解密操作的明文masterKey密鑰，一旦獲得了masterKey的明文形式，就可以用它來解密ORC文件中的dataKey和statKey。

下圖是描述了masterKey、statKey，dataKey之間的關(guān)系，灰色部分代表是存儲在文件中被加密的數(shù)據(jù)，綠色部分則是解密之后的數(shù)據(jù)，包括我們解密后的statKey，dataKey。獲得這兩個密鑰之后分別用于解密統(tǒng)計信息和文件中的真實數(shù)據(jù)。

5.2 StarRocks讀取ORC加密文件流程

在深入掌握了ORC文件中密鑰的相互關(guān)系和功能后，我們現(xiàn)在轉(zhuǎn)向探討StarRocks是如何讀取ORC加密表的數(shù)據(jù)。這個過程如下圖所示：

1）提交SQL查詢：用戶首先通過SQL客戶端向StarRocks FE節(jié)點提交查詢請求。這通常涉及到對Hive表下存儲的ORC加密文件進(jìn)行讀取操作。

2）獲取解密的masterKey：查詢提交后，系統(tǒng)首要根據(jù)SQL獲取Hive表中的ORC文件所需的masterKey。這個masterKey一般存儲在表屬性里，并且是加密存儲的，必須調(diào)用KMS服務(wù)來解密，得到密鑰明文。

3）傳遞masterKey明文：解密后的masterKey，以明文形式傳遞給StarRocks BE節(jié)點。

4）讀取并解密密鑰：BE 拿到已解密的masterKey 之后 讀取并解密ORC文件中的statKey和dataKey，這兩個密鑰分別用于解密統(tǒng)計信息（FileStat，StripeStat）和實際數(shù)據(jù)內(nèi)容，為接下來的統(tǒng)計信息和數(shù)據(jù)解密做準(zhǔn)備。

5）使用statKey和dataKey解密數(shù)據(jù)：BE使用statKey來解密文件的統(tǒng)計信息（fileStat和StripeStat）同時使用dataKey來解密實際的數(shù)據(jù)內(nèi)容。

5.3 讀取ORC加密文件的關(guān)鍵實現(xiàn)細(xì)節(jié)

通過了解前文StarRocks讀取ORC加密文件流程，我們將深入探討讀取ORC加密文件的數(shù)據(jù)關(guān)鍵實現(xiàn)細(xì)節(jié)。首先，我們提出一個問題：在物理存儲中，文件存儲的是什么內(nèi)容？答案是二進(jìn)制數(shù)據(jù)。這些二進(jìn)制數(shù)據(jù)通常會經(jīng)過壓縮處理。

ORC文件的讀取流程是自外向內(nèi)的，類似于剝洋蔥的過程，逐步深入到我們需要讀取的目標(biāo)數(shù)據(jù)。讀取流程可以概括為：首先讀取文件元數(shù)據(jù)，通過元數(shù)據(jù)獲取目標(biāo)數(shù)據(jù)的偏移量（offset）和數(shù)據(jù)長度如下圖所示，然后通過流的方式讀取目標(biāo)數(shù)據(jù)。

具體到ORC加密文件的讀取實現(xiàn)代碼，主要采用了設(shè)計模式中的裝飾模式方式來組織代碼的。在這個模式中，原始的文件流（SeekableFileInputStream）首先被解密流（DecryptionInputStream）所包裝，如果是非加密文件就沒有這一層，然后解密流又被解壓縮流（DecompressionStream）所包裝。每一層流都只負(fù)責(zé)向其包裝的流請求數(shù)據(jù)，并在接收到一定量數(shù)據(jù)后開始處理自己的邏輯。如下圖所示：

這種分層的方法保證每一層都專注于自己的職責(zé)，共同協(xié)作完成ORC文件的讀取任務(wù)。通過這種方式，我們不僅能夠高效地讀取ORC文件，還能確保數(shù)據(jù)的安全性和完整性。綜上所述，ORC文件的讀取流程是一個從文件元數(shù)據(jù)到具體數(shù)據(jù)內(nèi)容的逐步深入過程。

5.4 加密字段跳讀機制

為了提升數(shù)據(jù)的查詢效率，查詢數(shù)據(jù)時會根據(jù)索引數(shù)據(jù)跳過不必要的數(shù)據(jù)讀取，下面我們介紹加密列跳讀機制，理解了這部分的內(nèi)容，就能非常清晰的知道，讀取加密字段時，對數(shù)據(jù)解密與解壓是怎樣協(xié)作的。

5.4.1 加密塊與壓縮塊的關(guān)系

加密列的數(shù)據(jù)劃分了多個加密塊與壓縮塊，一個壓縮塊 包含多個加密塊，讀取數(shù)據(jù)時，先對每個加密塊進(jìn)行解密，解密多個加密塊之后，把這些解密后的數(shù)據(jù)塊合并成一個完整的壓縮塊，然后對這個壓縮塊進(jìn)行解壓得到原始數(shù)據(jù)下圖是加密塊與壓縮塊的關(guān)系圖：

5.4.2 ORC文件使用的加解密算法和模式

下圖描述了具體的數(shù)據(jù)加解密過程中以及設(shè)計到整個過程中各種元素輸入輸出的關(guān)系：

注意：同一個數(shù)據(jù)塊（16字節(jié)）加密過程和解密過程中的 密鑰、IV值、加密算法和加密模式必須相同。

明文塊：我們對ORC文件加密使用的加密算法是AES-128-CTR/NoPadding，該算法加密數(shù)據(jù)時 ，會把明文按照16個字節(jié)劃分多個塊，每個塊加密之后得到的數(shù)據(jù)就是加密塊。

加密塊：每個明文數(shù)據(jù)塊加密之后得到的數(shù)據(jù)就是加密塊。

初始向量IV：初始向量IV的作用是使加密更加安全可靠（加鹽），我們使用AES加密時需要主動提供這個初始向量IV，而且只需要提供一個初始向量就夠了，后面每個數(shù)據(jù)塊的加密向量由加密模式?jīng)Q定，所以每個數(shù)據(jù)塊的加密向量都不一樣。初始向量IV的長度規(guī)定為128位16個字節(jié)，ORC文件解密參數(shù) IV的描述如下：總共16個字節(jié)，前面8個字節(jié)分別存儲：列ID，Stream類型，Stripe的ID ，后面8個字節(jié)用于填充min_count，由于我們使用的是CTR加密模式，所以這個min_count就是加密塊在整個加密數(shù)據(jù)中的計數(shù)，iv各個內(nèi)容長度定義如下圖：

密鑰：AES要求密鑰的長度可以是128位16個字節(jié)、192位或者256位，位數(shù)越高，加密強度自然越大，但是加密的效率自然會低一些，因此要做好權(quán)衡。我們開發(fā)通常采用128位16個字節(jié)的密鑰，我們使用AES加密時需要主動提供密鑰，而且只需要提供一個密鑰就夠了，每個數(shù)據(jù)塊加解密使用的都是同一個密鑰。

加密模式：有5種加密模式，這些加密模式的主要目的是為了不讓重復(fù)的明文加密之后得到的密文一樣，提升數(shù)據(jù)安全性，我們使用的是CTR模式（計數(shù)器模式）對數(shù)據(jù)加密，那解密的時候也需要CTR模式對數(shù)據(jù)解密，計數(shù)器模式介紹請參考鏈接，CTR模式 的iv參數(shù) 包含了 加密塊計數(shù)（min_count），所以 每次對一個加密塊解密時 需要知道 當(dāng)前加密塊的初始計數(shù)值。

5.4.3 舉例說明跳讀流程

學(xué)習(xí)了前面讀取加密數(shù)據(jù)的關(guān)鍵細(xì)節(jié)之后，舉個例子說明跳讀ORC文件流程，假設(shè)根據(jù)索引數(shù)據(jù)和查詢條件確定需要讀取某個文件中第1個Strip中第1列的第5個group的數(shù)據(jù)，那么我們知道group5數(shù)據(jù)的偏移量offset，文件結(jié)構(gòu)如下圖所示：

具體邏輯大體流程如下：

注意：解壓數(shù)據(jù)塊時，必須把當(dāng)前解壓塊的所有數(shù)據(jù)讀出來才能使用對應(yīng)的解壓算法解壓數(shù)據(jù)。

1）group5數(shù)據(jù)的偏移量group_offset計算出 group5數(shù)據(jù)在哪個壓縮塊里,計算公式為：block_index = group_offset/zipBlockSize（壓縮塊大?。?，并得到該壓縮塊的起始位置zip_head_offset 公式為：zip_head_offset = block_index*zipBlockSize。

2）獲取zip_head_offset位置對應(yīng)的加密塊計數(shù)，加密塊計數(shù)值計算公式為：min_count = zip_head_offset/encrypted-size（加密塊大?。?更新iv向量的min_count值。

3）文件讀指針定位到zip_head_offset，開始讀取壓縮塊的數(shù)據(jù)，這個壓縮塊的數(shù)據(jù)全部讀出之后，使用解壓算法進(jìn)行解壓。

4）通過group5在解壓的數(shù)據(jù)上偏移量和長度，讀取group5 數(shù)據(jù)，然后再對數(shù)據(jù)進(jìn)行解碼。

六、問題解答

通過前面對相關(guān)內(nèi)容的講解，下面我們來解答前文提出的問題：

1）文件解壓是否意味著一定是對整個文件進(jìn)行解壓操作？

答：不需要，文件是按照一定大小劃分出若干個壓縮塊，只要讀出相應(yīng)的壓縮塊進(jìn)行解壓就行。

2）ORC 文件究竟是如何做到在不掃描全文件的情況下就能精準(zhǔn)查詢到想要的數(shù)據(jù)？

答：ORC文件有三層索引，在讀取文件數(shù)據(jù)之前先讀取各層級的索引信息，根據(jù)過濾條件過濾掉不必要的數(shù)據(jù)掃描，從而提升數(shù)據(jù)查詢效率。

3）當(dāng) SQL 查詢條件不符合最左前綴原則時，其索引效果是否就會失效呢？

答：不會失效，ORC文件是列式存儲的，各列信息都是相互獨立的，有自己的索引信息，與行式數(shù)據(jù)庫的索引最左前綴規(guī)則不同。

4）數(shù)據(jù)加密、解密、解壓以及壓縮之間的關(guān)聯(lián)關(guān)系到底是怎樣的？

答：請參考本文：5.1 ORC文件內(nèi)部數(shù)據(jù)加密關(guān)系 內(nèi)容。

5）在寫加密列數(shù)據(jù)時，為什么不是先加密數(shù)據(jù)再壓縮，而是先壓縮后加密？

答：主要是為了提升加密效率，數(shù)據(jù)被壓縮處理之后，數(shù)據(jù)量變少了，加密效率就提升了。

七、總結(jié)

本文介紹了StarRocks數(shù)據(jù)庫如何讀取ORC文件的加密數(shù)據(jù)，包括相關(guān)概念理解、ORC文件介紹、以及StarRocks讀取加密ORC文件的具體實現(xiàn)方案。闡述了出于數(shù)據(jù)安全的需要，對Hive表中的敏感數(shù)據(jù)進(jìn)行加密存儲的必要性，介紹了對稱加密、文件壓縮與解壓、加密壓縮文件讀寫流程等概念，深入探討了ORC文件的三層結(jié)構(gòu)和索引機制，以及如何利用這些特性實現(xiàn)高效查詢加密數(shù)據(jù)。還詳細(xì)描述了StarRocks讀取加密ORC文件的流程，包括獲取解密的masterKey、使用masterKey解密ORC文件中的密鑰、以及使用這些密鑰解密數(shù)據(jù)。

希望通過本文對ORC加密文件讀取功能的實現(xiàn)細(xì)節(jié)，讓讀者對ORC文件的理解更深刻。最后如果想從代碼層面了解ORC文件解密過程可以參考開源PR。