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

ITPUB社群發表於2022-12-29

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

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/70024420/viewspace-2929993/,如需轉載,請註明出處,否則將追究法律責任。

相關文章