ClickHouse與Hive的區別，終於有人講明白了

導讀：Hive是Hadoop生態系統中事實上的資料倉儲標準。Hive是建立在Hadoop生態中的資料倉儲中介軟體，其本身並不提供儲存與計算能力。Hive的儲存引擎使用HDFS，計算引擎使用MapReduce或Spark。

Hive本質上是一個後設資料管理平臺，透過對儲存於HDFS上的資料檔案附加後設資料，賦予HDFS上的檔案以資料庫表的語義。並對外提供統一的Hive SQL介面，將使用者提交的SQL翻譯為對應的MapReduce程式或Hive程式，交給相應的計算引擎執行。

由於MapReduce計算模型本身的缺陷，因此目前一般情況下會將Hive結合Spark使用。本文主要對比Hive On Spark與ClickHouse的區別。

01

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，也為了通用性放棄了效能。

02

Hive的儲存系統

Hive本身不提供儲存，其資料都儲存於HDFS(Hadoop Distribution File System,Hadoop分散式檔案系統)上。HDFS是大資料中專用的分散式檔案系統，專為大資料處理而設計。

03

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的最佳化重點在於如何提高分散式的協作效率。

04

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效能之巔：從架構設計解讀效能之謎》作者。