一、Hive的數據文件

和ClickHouse不同，由于Hive本身并不存儲數據，而是為HDFS上的文件賦予數據庫表、列的語義，保存對應的元數據供查詢時使用，因此Hive的數據文件存在多種類型

1、textfile

textfile（文本文件）是Hive中默認的數據文件，是一類基于純文本的數據文件格式。在大數據時代之前的CSV、TSV都屬于該類文件。這類文件的特點如下。

• 按行存儲，文件內的一個物理行對應數據表中的一行數據。
• 行內以特殊的符號分列。
• 純文本保存，不需要特殊解編碼器即可識別。
• 受限于純文本表現力的限制，復雜類型可能需要額外的信息才能正確解析（即單獨的數據文件不足以保存所有信息），例如日期等。
• 默認情況下無壓縮。

文本文件由于其按行存儲的特性，導致其在Spark中是性能最差的一種數據文件格式。文本文件通常由業務側的程序直接生成，且在業務側被大量使用。因此Hive默認情況下使用文本文件作為數據文件的存儲格式，保證這些文本文件在導入大數據系統后可以不用轉換而直接被Hive識別和處理。

2、Apache ORC

Apache ORC（Optimized Row Columnar,優化行列式）是Hive中一種列式存儲的數據文件格式，ORC在textfile的基礎上進行了大量的修改以優化大數據場景下的查詢性能，ORC的主要特點如下。

• 按列存儲。
• 二進制存儲，自描述。
• 包含稀疏索引。
• 支持數據壓縮。
• 支持ACID事務。

3、Parquet

Hadoop Parquet是Hadoop生態中的一種語言無關的，不與任何數據計算框架綁定的新型列式存儲格式。Parquet可以兼容多種計算框架和計算引擎，由于其優秀的兼容性，在生產中被大量使用。其主要特點如下。

• 按列存儲。
• 二進制存儲，自描述。
• 包含稀疏索引。
• 支持數據壓縮。
• 語言獨立、平臺獨立、計算框架獨立。

4、Parquet與ORC

Parquet和ORC格式有著很多的相同點，那么在使用時應當如何選擇呢？

（1）  原則一：希望平臺獨立，更好的兼容性，選擇Parquet

Parquet在設計時考慮了通用性，如果希望進行聯邦查詢或為了將數據文件交給其他計算引擎使用，那么應該選擇Parquet。

（2）  原則二：數據量龐大，希望獲得最強的查詢性能，選擇ORC

ORC針對HDFS進行了針對性的優化，當數據非常龐大且需對查詢性能有要求時，務必選擇ORC格式。ORC在大數據量下的性能一定強于Parquet，大量的實驗證明了這一點。因此本書后續的性能比較都是基于ORC格式的Hive。

ORC的設計原則和ClickHouse類似，都是存儲服務于計算的典范。這也提現了性能和通用性不可兼得。再次強調，架構設計沒有銀彈，有得必有失。不要試圖設計各方面都優秀的架構，即使是Parquet，也為了通用性放棄了性能。

二、Hive的存儲系統

Hive本身不提供存儲，其數據都存儲于HDFS(Hadoop Distribution File System,Hadoop分布式文件系統)上。HDFS是大數據中專用的分布式文件系統，專為大數據處理而設計。

三、Hive計算引擎與ClickHouse計算引擎的差異

Hive本身并不提供計算引擎，而是使用Hadoop生態的MapReduce或Spark實現計算。由于Spark更高層次的抽象，使得Spark的計算引擎的性能遠高于MapReduce。兩者之間的區別如下：

1、運行模式不同

ClickHouse是MPP架構，強調充分發揮單機性能，沒有真正的分布式表，ClickHouse的分布式表只是本地表的代理，對分布式表的查詢都會被轉換為對本地表的查詢。這導致ClickHouse在執行部分大表join時可能出現資源不足的情況。

Hive的數據存儲于分布式文件系統，因此Hive的計算引擎Spark在執行計算任務時，需要依據數據分布進行調度。在必要時，Spark可以通過CBO將數據重新排序后再分散到多臺機器執行，以實現復雜的查詢。

ClickHouse適合簡單的DW之上的即席查詢。而Spark由于其分布式特性，導致其任務啟動時間很長，因此不適合實現即席查詢，但是對于大數據量的join等復雜查詢時具備非常大的優勢。

2、優化重點不同

ClickHouse的優化重點在如何提高單機的處理能力，而Spark的優化重點在于如何提高分布式的協作效率。

四、ClickHouse比Hive快的原因

需要再次強調的是，ClickHouse只是在DW即席查詢場景下比Hive快，并沒有在所有場景都比Spark快，詳細的分析請參考第5章。本節對比的是，當ClickHouse和Hive都進行即席查詢，ClickHouse比Hive快的原因。

1、嚴格數據組織更適合做分析

ClickHouse的數據組織相對于Hive更嚴格，需要用戶在建表時制定排序鍵進行預排序。雖然Hive的ORC格式和ClickHouse的數據文件其實一定程度上是等價的，但是Hive的ORC格式并不要求數據存儲前進行預排序。

在預排序的情況下，數據在寫入物理存儲時已經按照一定的規律進行了聚集，在理想條件下可以大幅度降低I/O時間，避免數據的遍歷。Hive的ORC格式在這一塊并沒有嚴格要求，因此ORC的存儲就已經比ClickHouse消耗更多的I/O來遍歷數據了。而ClickHouse卻可以通過實現預排序好的數據和良好的索引，直接定位到對應的數據，節省了大量的I/O時間。

2、更簡單的調度

ClickHouse目的在于壓榨單機性能，并沒有真正的分布式表，數據都在本地，這也使得ClickHouse不需要復雜的調度，直接在本機執行SQL即可。而Hive的數據都在HDFS上，在真正任務前需要依據數據分布確定更復雜的物理計劃，然后將Spark程序調度到對應的Data Node上，調度的過程非常消耗時間。

關于作者：陳峰，資深大數據專家和架構師，ClickHouse技術專家，滴普科技（2B領域獨角獸）合伙人兼首席架構師。《ClickHouse性能之巔：從架構設計解讀性能之謎》作者。