1、數(shù)據(jù)存儲(chǔ)格式：

?? ?①TEXTFILE

?? ?HIVE 中默認(rèn)的存儲(chǔ)格式；

?? ?一般使用在數(shù)據(jù)貼源層(ODS 或 STG) ，針對(duì)需要使用腳本 LOAD 加載數(shù)據(jù)到 HIVE 數(shù)倉(cāng)表中的情況；需要把表里數(shù)據(jù)導(dǎo)出或直接可以查看等場(chǎng)景，作為BI供數(shù)
?? ??? ?易讀性要比 ORC 高很多；

?? ?數(shù)據(jù)存儲(chǔ)時(shí)不壓縮，因此磁盤的開銷和數(shù)據(jù)解析開銷比較大；

?? ?TEXTFILE 可以結(jié)合 Gzip、Bzip2 等壓縮算法使用(系統(tǒng)自動(dòng)檢查，執(zhí)行查詢時(shí)自動(dòng)解壓)，但使用這種方式，HIVE 不會(huì)對(duì)數(shù)據(jù)進(jìn)行切分，從而無(wú)法對(duì)數(shù)據(jù)進(jìn)行并行操作；

?? ?在反序列化過程中，必須逐個(gè)字符判斷是不是分隔符和行結(jié)束符，因此反序列化開銷會(huì)比 SequenceFile 高幾十倍；

?? ?可以直接通過 LOAD 的方式從文件中加載數(shù)據(jù)到 HIVE 表中；

當(dāng)用戶的數(shù)據(jù)文件格式不能被當(dāng)前 HIVE 所識(shí)別的時(shí)候，可以自定義文件格式
?? ?通過實(shí)現(xiàn) inputformat 和 outputformat 來(lái)自定義輸入輸出格式

?? ?②SEQUENCE FILE

?? ?HADOOP API 提供的一種二進(jìn)制文件，以 key-value 的形式序列化到文件中；

?? ?支持切片；

?? ?數(shù)據(jù)加載導(dǎo)入方式可以通過INSERT方式加載數(shù)據(jù)；

?? ?③PARQUET

?? ?面向列的二進(jìn)制文件格式，所以是不可以直接讀取的；

?? ?文件中包括該文件的數(shù)據(jù)和元數(shù)據(jù)，因此 Parquet 格式文件是自解析的；

?? ?使用場(chǎng)景在 Impala 和 Hive 共享數(shù)據(jù)和元數(shù)據(jù)的場(chǎng)景；

?? ?④ORCFILE

?? ?運(yùn)用 ORC 可以提高 HIVE 的讀、寫、計(jì)算的性能，主要使用在 DWD、DWB、DWS 層

?? ?數(shù)據(jù)按行分塊，每塊按照列存儲(chǔ)；

?? ?壓縮快、快速列存取；

?? ?效率比 rcfile 高，是 rcfile 的改良版本；

?? ?不考慮 ORC 的場(chǎng)景：需要通過 LOAD 方式加載數(shù)據(jù)到表里；需要把表里數(shù)據(jù)導(dǎo)出或直接可以查看等場(chǎng)景，這兩種場(chǎng)景更適合使用 TEXTFILE ，易讀性要比 ORC 高很多；

?? ?ORC 文件格式可以使用 HIVE 自帶的命令 concatenate 快速合并小文件

? ??

在 Hive 中使用 ORC 文件格式時(shí)，是自動(dòng)實(shí)現(xiàn)文件的分割（splitting）。這是因?yàn)?ORC 文件格式是為優(yōu)化大規(guī)模數(shù)據(jù)處理而設(shè)計(jì)的，其中包括了有效的數(shù)據(jù)分割機(jī)制以支持并行處理。以下是一些關(guān)于 ORC 文件分割的關(guān)鍵點(diǎn)：

1.?塊與條帶（Stripes）

ORC 文件將數(shù)據(jù)分成多個(gè)條帶（Stripes），每個(gè)條帶都是自包含的數(shù)據(jù)集合，包括其自己的索引、數(shù)據(jù)和行索引。這些條帶是分割數(shù)據(jù)的物理單位，可以獨(dú)立于其他條帶處理，支持并行讀取和查詢。

2.?文件的索引

每個(gè) ORC 文件包含一個(gè)輕量級(jí)的文件尾部索引，其中包含有關(guān)文件中數(shù)據(jù)的統(tǒng)計(jì)信息和條帶位置的詳細(xì)信息。這使得查詢引擎能夠有效地確定哪些條帶需要讀取以滿足特定的查詢條件，從而實(shí)現(xiàn)快速的數(shù)據(jù)訪問。

3.?分割與并行處理

當(dāng) Hive 執(zhí)行查詢時(shí)，它會(huì)根據(jù)數(shù)據(jù)的存儲(chǔ)位置和條帶信息自動(dòng)對(duì) ORC 文件進(jìn)行分割。每個(gè)數(shù)據(jù)分割可以分配給不同的處理節(jié)點(diǎn)進(jìn)行并行處理。這種分割機(jī)制允許 Hive 在多個(gè)處理節(jié)點(diǎn)上有效地分配工作，從而優(yōu)化查詢性能和減少數(shù)據(jù)處理時(shí)間。

4.?設(shè)置條帶大小和行索引間隔

雖然分割機(jī)制自動(dòng)運(yùn)作，但你可以通過設(shè)置條帶大小和行索引間隔來(lái)優(yōu)化性能。例如，可以在創(chuàng)建表時(shí)通過以下方式設(shè)置條帶大小和行索引間隔：

CREATE TABLE my_table (column1 INT,column2 STRING
)
STORED AS ORC
TBLPROPERTIES ("orc.stripe.size"="67108864",       -- 設(shè)置條帶大小為64MB"orc.row.index.stride"="10000",     -- 設(shè)置行索引間隔"orc.compress"="SNAPPY"             -- 設(shè)置壓縮算法為SNAPPY
);

HIVE 中常用的存儲(chǔ)格式對(duì)比

存儲(chǔ)格式	是否默認(rèn)	存儲(chǔ)方式	支持壓縮算法
TextFile	是	行式存儲(chǔ)	Gzip、Bzip2
SequenceFile	否	行式存儲(chǔ)	NONE、RECORD、BLOCK
Parquet	否	列式存儲(chǔ)	Uncompress(默認(rèn))、Snappy、Gzip、Lzo
RCFile	否	數(shù)據(jù)按行分塊，每塊按列存儲(chǔ)	-
(RCFile的優(yōu)化)ORCFile	否	數(shù)據(jù)按行分塊，每塊按列存儲(chǔ)	NONE、ZLIB(默認(rèn))、SNAPPY

2、壓縮算法

文件存儲(chǔ)格式不同對(duì)應(yīng)不同的壓縮算法，從而帶來(lái)不同的性能，我們根據(jù)實(shí)際使用考慮壓縮算法的性能，
主要通過以下 3 個(gè)指標(biāo)：

① 壓縮比
?? ?壓縮比越高，壓縮后文件越小，所以壓縮比越高越好；
?? ?壓縮比越高，存儲(chǔ)磁盤空間占用越小，可以降低單節(jié)點(diǎn)的磁盤IO，同時(shí)可以減少占用的帶寬；

② 壓縮時(shí)間
?? ?越快越好，加快數(shù)據(jù)在Hadoop集群流動(dòng)的速度和磁盤 IO 的速度

③ 壓縮后的文件是否可以再分割
?? ?可以分割的格式允許單一文件由多個(gè)Mapper程序處理，可以更好的 并行化

壓縮算法對(duì)比

壓縮方式	壓縮比	壓縮速度	解壓縮速度	是否可分割
gzip	13.4%	21 MB/s	118 MB/s	否，無(wú)法并行處理
bzip2	13.2%	2.4MB/s	9.5MB/s	是，并行處理
LZO	20.5%	135 MB/s	410 MB/s	是，并行處理
snappy	22.2%	172 MB/s	409 MB/s	否，無(wú)法并行處理

3、使用場(chǎng)景

ODS 貼源層 ： TextFile + Gzip
DWD ? ： ORC + SNAPPY
DWS? ?： ORC + SNAPPY

① 數(shù)據(jù)量較大
如果單個(gè)文件比較大，可以使用 Parquet 存儲(chǔ)，LZO壓縮，可以避免由于讀取不可分割大文件引發(fā)的數(shù)據(jù)傾斜。

Parquet 的特性：

更高效的壓縮和編碼策略：Parquet 對(duì)于數(shù)據(jù)的編碼和壓縮有著高度優(yōu)化，特別是對(duì)于重復(fù)數(shù)據(jù)的處理。
它使用多種壓縮技術(shù)和編碼策略，如字典編碼、RLE（Run-Length Encoding）和Delta 編碼，這些都有助于減少數(shù)據(jù)存儲(chǔ)量并提升讀取性能。
這種優(yōu)化使得即使是大文件，數(shù)據(jù)的物理存儲(chǔ)尺寸也可能相對(duì)更小，且讀取效率更高。

更細(xì)粒度的索引：Parquet 文件提供了詳盡的元數(shù)據(jù)和索引，例如 min/max 索引，這可以極大地加速查詢性能，因?yàn)樗试S在讀取數(shù)據(jù)前快速跳過不符合查詢條件的數(shù)據(jù)塊。
這對(duì)于大文件尤為重要，因?yàn)樗鼫p少了需要處理的數(shù)據(jù)量，從而提高了處理速度。

更靈活的列裁剪和數(shù)據(jù)訪問：由于 Parquet 是列式存儲(chǔ)，它允許只加載查詢所需的列，這稱為列裁剪。
這種能力在處理含有大量列的大文件時(shí)非常有用，因?yàn)樗梢燥@著減少I/O負(fù)載和提升查詢響應(yīng)時(shí)間。

更好的集成和優(yōu)化支持：Parquet 在現(xiàn)代數(shù)據(jù)處理框架中，如 Apache Spark 和 Databricks 等，獲得了廣泛的支持和優(yōu)化。
這些框架針對(duì) Parquet 進(jìn)行了大量?jī)?yōu)化，使其在這些環(huán)境中處理大型數(shù)據(jù)文件時(shí)表現(xiàn)更佳。

效率與性能的平衡：雖然 Parquet 的寫操作可能比 ORC 慢，它在讀取操作上通常更高效，特別是在需要高度優(yōu)化查詢的分析型工作負(fù)載中。
這種讀取性能上的優(yōu)勢(shì)在處理大數(shù)據(jù)文件時(shí)尤為重要，因?yàn)樗梢燥@著減少查詢時(shí)間和計(jì)算資源的消耗。

因此，盡管 ORC 和 Parquet 都有各自的優(yōu)勢(shì)和使用場(chǎng)景，但在處理單個(gè)大文件方面，Parquet 在很多情況下因其更精細(xì)的數(shù)據(jù)訪問控制、更有效的數(shù)據(jù)壓縮和編碼，以及更好的讀取性能而更受青睞。這使得它在數(shù)據(jù)分析和大規(guī)模數(shù)據(jù)處理中，尤其是在需要頻繁讀取的場(chǎng)景中，成為更合適的選擇。

② 計(jì)算邏輯比較少
使用 ORC 存儲(chǔ) + ZLIB 壓縮，可以盡量減少占用存儲(chǔ)空間

③ 計(jì)算邏輯比較多
使用 ORC 存儲(chǔ) + SNAPPY 壓縮，可以提高讀寫速度，從而提高整體計(jì)算性能

在 Hive 中，對(duì)于計(jì)算邏輯比較多且要求計(jì)算速度達(dá)到最佳狀態(tài)的場(chǎng)景，選擇 ORC 存儲(chǔ)格式是明智的，因?yàn)?ORC 格式具備高效的列存儲(chǔ)和強(qiáng)大的壓縮功能，能夠顯著提高查詢性能。
然而，在壓縮算法的選擇上，雖然 SNAPPY 和 LZO 各有優(yōu)劣，但選擇的依據(jù)需要綜合考慮多個(gè)因素。

3.1 ORC + SNAPPY 的優(yōu)勢(shì)

快速壓縮和解壓縮：
????????SNAPPY 以其快速的壓縮和解壓縮速度著稱。對(duì)于頻繁的讀寫操作，快速的解壓縮可以減少查詢延遲，從而提高整體計(jì)算性能。

低 CPU 開銷：
????????SNAPPY 的壓縮和解壓縮操作對(duì) CPU 資源的消耗較低。對(duì)于計(jì)算密集型任務(wù)，低 CPU 開銷有助于將更多的 CPU 資源用于計(jì)算本身，而不是浪費(fèi)在壓縮和解壓縮過程中。

適合查詢優(yōu)化：

????????ORC 文件格式支持謂詞下推（predicate pushdown）、列裁剪（column pruning）和其他查詢優(yōu)化技術(shù)。SNAPPY 的低延遲特性使得這些優(yōu)化技術(shù)能夠更快地生效，從而提高查詢性能。

在 ORC 文件格式中使用 SNAPPY 壓縮時(shí)，壓縮是在分割（條帶創(chuàng)建）之后進(jìn)行的。

下面是 ORC 文件結(jié)構(gòu)處理數(shù)據(jù)的一般流程：

1. 數(shù)據(jù)組織與條帶創(chuàng)建：首先，數(shù)據(jù)被組織成多個(gè)條帶（Stripes）。每個(gè)條帶包含一部分?jǐn)?shù)據(jù)，通常是幾千到幾萬(wàn)行，具體取決于配置的條帶大小和數(shù)據(jù)的實(shí)際特性。

2. 列式存儲(chǔ)：在 ORC 文件中，數(shù)據(jù)按列而非按行存儲(chǔ)。這意味著每個(gè)條帶中的數(shù)據(jù)會(huì)按列組織，這有助于提高數(shù)據(jù)訪問的效率并優(yōu)化查詢性能。

3. 壓縮：數(shù)據(jù)在條帶級(jí)別被組織好之后，每個(gè)條帶的數(shù)據(jù)會(huì)根據(jù)配置的壓縮算法進(jìn)行壓縮。如果選擇了 SNAPPY 壓縮，每個(gè)條帶的數(shù)據(jù)會(huì)被 SNAPPY 壓縮算法壓縮。壓縮是獨(dú)立于每個(gè)條帶進(jìn)行的，這允許在讀取數(shù)據(jù)時(shí)可以并行解壓縮不同的條帶。

4. 索引和元數(shù)據(jù)寫入：ORC 文件還會(huì)包含每個(gè)條帶的索引信息和整個(gè)文件的元數(shù)據(jù)，包括每個(gè)列的統(tǒng)計(jì)信息，如最大值、最小值等。這些信息也存儲(chǔ)在文件的尾部，并可以用來(lái)優(yōu)化讀取操作，因?yàn)樗鼈兛梢詭椭焖俅_定是否需要讀取某個(gè)條帶來(lái)滿足查詢條件。

因此，SNAPPY 壓縮在 ORC 文件的條帶創(chuàng)建之后執(zhí)行，這樣做的好處是可以保持壓縮數(shù)據(jù)的獨(dú)立性，支持高效的并行處理。每個(gè)條帶壓縮后仍可獨(dú)立解壓，這有利于分布式處理和快速數(shù)據(jù)訪問。

3.2 ORC + LZO 的情況

并行處理：
????????LZO 支持并行處理和分片（splitting），這在寫入大規(guī)模數(shù)據(jù)時(shí)是一個(gè)優(yōu)勢(shì)，因?yàn)樗軌虺浞掷枚嗪?CPU 進(jìn)行并行壓縮，縮短寫入時(shí)間。

壓縮率：
????????LZO 的壓縮率可能會(huì)比 SNAPPY 高一些，這意味著在相同的數(shù)據(jù)量下，LZO 壓縮后的文件會(huì)更小，可以節(jié)省存儲(chǔ)空間和 I/O 開銷。

綜合考慮：

????????盡管 LZO 支持并行處理和分片，適合大規(guī)模數(shù)據(jù)的寫入，但在大多數(shù)計(jì)算密集型場(chǎng)景下，查詢性能的提升往往比寫入性能更為重要。
?? ?SNAPPY 在讀取時(shí)的快速解壓縮和低 CPU 開銷，使得它在讀取和計(jì)算過程中表現(xiàn)更優(yōu)。這些優(yōu)勢(shì)在以下方面尤為明顯：

查詢性能：SNAPPY 的快速解壓縮速度有助于加快數(shù)據(jù)加載和處理，特別是對(duì)于復(fù)雜查詢和計(jì)算邏輯多的場(chǎng)景。
CPU 利用率：低 CPU 開銷意味著更多的計(jì)算資源可以用于執(zhí)行實(shí)際的查詢和分析任務(wù)，而不是消耗在解壓縮過程中。
實(shí)際表現(xiàn)：實(shí)際測(cè)試和基準(zhǔn)測(cè)試往往顯示，對(duì)于計(jì)算密集型任務(wù)，SNAPPY 的整體表現(xiàn)（包括讀取和計(jì)算階段）優(yōu)于 LZO。
因此，在大多數(shù)需要高計(jì)算性能的 Hive 使用場(chǎng)景中，推薦使用 ORC + SNAPPY 作為存儲(chǔ)和壓縮組合，盡管 SNAPPY 不支持并行處理，但當(dāng)與 ORC 文件格式配合使用時(shí)，實(shí)際情況可能有所不同。
????????有幾個(gè)關(guān)鍵因素說(shuō)明為什么在某些情況下使用 ORC 存儲(chǔ)格式配合 SNAPPY 壓縮依然能實(shí)現(xiàn)高效的計(jì)算速度：

1. ORC 文件的結(jié)構(gòu)特性
ORC 文件是一種高效的列式存儲(chǔ)格式，它自帶索引和分區(qū)數(shù)據(jù)的功能。即使在使用 SNAPPY 壓縮時(shí)，ORC 文件格式還是可以支持有效的數(shù)據(jù)拆分（split）和并行處理。ORC 文件將數(shù)據(jù)存儲(chǔ)在多個(gè)塊中，每個(gè)塊可以獨(dú)立壓縮和解壓縮。這意味著在處理時(shí)，每個(gè)數(shù)據(jù)塊可以被獨(dú)立加載和解碼，允許并行處理。

2. SNAPPY 壓縮的性能優(yōu)勢(shì)
SNAPPY 壓縮提供了快速的壓縮和解壓速度，這是其設(shè)計(jì)的主要目標(biāo)。雖然它不支持壓縮數(shù)據(jù)的拆分，但其快速的解壓速度對(duì)于計(jì)算密集型任務(wù)來(lái)說(shuō)非常重要，因?yàn)樗梢钥焖俚貙?shù)據(jù)送入處理流程。對(duì)于需要頻繁讀取的應(yīng)用，這種快速的解壓速度可以顯著提高數(shù)據(jù)處理的效率。

3. 計(jì)算和 I/O 開銷的平衡
在使用 ORC 和 SNAPPY 的組合時(shí)，可以實(shí)現(xiàn)對(duì)計(jì)算資源和 I/O 開銷的良好平衡。由于 SNAPPY 提供了快速的解壓縮，它可以減少?gòu)拇疟P讀取數(shù)據(jù)所需的時(shí)間，從而允許更多的資源被用于執(zhí)行計(jì)算邏輯。這種快速的數(shù)據(jù)流轉(zhuǎn)對(duì)于計(jì)算密集型任務(wù)尤其重要。

4. 總體系統(tǒng)性能
在選擇壓縮算法時(shí)，還需要考慮到整個(gè)數(shù)據(jù)平臺(tái)的架構(gòu)和性能。雖然 LZO 提供了并行壓縮的能力，但其解壓速度通常不如 SNAPPY 快。此外，如果大部分時(shí)間都在進(jìn)行數(shù)據(jù)讀取和計(jì)算而不是寫入，那么解壓縮性能將更為關(guān)鍵。

結(jié)論：

????????因此，盡管 SNAPPY 不支持拆分壓縮數(shù)據(jù)，但由于 ORC 的結(jié)構(gòu)使得數(shù)據(jù)可以在塊級(jí)別進(jìn)行并行處理，再加上 SNAPPY 的高解壓速度，使得這種組合在很多場(chǎng)景下仍然可以實(shí)現(xiàn)非常高效的查詢和計(jì)算性能。當(dāng)然，這種選擇也應(yīng)基于具體的使用場(chǎng)景和性能測(cè)試來(lái)確定，以確保滿足特定的性能和成本效益需求。