一、Hive的數(shù)據(jù)文件

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

1、textfile

textfile（文本文件）是Hive中默認(rèn)的數(shù)據(jù)文件，是一類基于純文本的數(shù)據(jù)文件格式。在大數(shù)據(jù)時(shí)代之前的CSV、TSV都屬于該類文件。這類文件的特點(diǎn)如下。

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

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

2、Apache ORC

Apache ORC（Optimized Row Columnar,優(yōu)化行列式）是Hive中一種列式存儲的數(shù)據(jù)文件格式，ORC在textfile的基礎(chǔ)上進(jìn)行了大量的修改以優(yōu)化大數(shù)據(jù)場景下的查詢性能，ORC的主要特點(diǎn)如下。

• 按列存儲。
• 二進(jìn)制存儲，自描述。
• 包含稀疏索引。
• 支持?jǐn)?shù)據(jù)壓縮。
• 支持ACID事務(wù)。

3、Parquet

Hadoop Parquet是Hadoop生態(tài)中的一種語言無關(guān)的，不與任何數(shù)據(jù)計(jì)算框架綁定的新型列式存儲格式。Parquet可以兼容多種計(jì)算框架和計(jì)算引擎，由于其優(yōu)秀的兼容性，在生產(chǎn)中被大量使用。其主要特點(diǎn)如下。

• 按列存儲。
• 二進(jìn)制存儲，自描述。
• 包含稀疏索引。
• 支持?jǐn)?shù)據(jù)壓縮。
• 語言獨(dú)立、平臺獨(dú)立、計(jì)算框架獨(dú)立。

4、Parquet與ORC

Parquet和ORC格式有著很多的相同點(diǎn)，那么在使用時(shí)應(yīng)當(dāng)如何選擇呢？

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

Parquet在設(shè)計(jì)時(shí)考慮了通用性，如果希望進(jìn)行聯(lián)邦查詢或?yàn)榱藢?shù)據(jù)文件交給其他計(jì)算引擎使用，那么應(yīng)該選擇Parquet。

（2）  原則二：數(shù)據(jù)量龐大，希望獲得最強(qiáng)的查詢性能，選擇ORC

ORC針對HDFS進(jìn)行了針對性的優(yōu)化，當(dāng)數(shù)據(jù)非常龐大且需對查詢性能有要求時(shí)，務(wù)必選擇ORC格式。ORC在大數(shù)據(jù)量下的性能一定強(qiáng)于Parquet，大量的實(shí)驗(yàn)證明了這一點(diǎn)。因此本書后續(xù)的性能比較都是基于ORC格式的Hive。

ORC的設(shè)計(jì)原則和ClickHouse類似，都是存儲服務(wù)于計(jì)算的典范。這也提現(xiàn)了性能和通用性不可兼得。再次強(qiáng)調(diào)，架構(gòu)設(shè)計(jì)沒有銀彈，有得必有失。不要試圖設(shè)計(jì)各方面都優(yōu)秀的架構(gòu)，即使是Parquet，也為了通用性放棄了性能。

二、Hive的存儲系統(tǒng)

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

三、Hive計(jì)算引擎與ClickHouse計(jì)算引擎的差異

Hive本身并不提供計(jì)算引擎，而是使用Hadoop生態(tài)的MapReduce或Spark實(shí)現(xiàn)計(jì)算。由于Spark更高層次的抽象，使得Spark的計(jì)算引擎的性能遠(yuǎn)高于MapReduce。兩者之間的區(qū)別如下：

1、運(yùn)行模式不同

ClickHouse是MPP架構(gòu)，強(qiáng)調(diào)充分發(fā)揮單機(jī)性能，沒有真正的分布式表，ClickHouse的分布式表只是本地表的代理，對分布式表的查詢都會被轉(zhuǎn)換為對本地表的查詢。這導(dǎo)致ClickHouse在執(zhí)行部分大表join時(shí)可能出現(xiàn)資源不足的情況。

Hive的數(shù)據(jù)存儲于分布式文件系統(tǒng)，因此Hive的計(jì)算引擎Spark在執(zhí)行計(jì)算任務(wù)時(shí)，需要依據(jù)數(shù)據(jù)分布進(jìn)行調(diào)度。在必要時(shí)，Spark可以通過CBO將數(shù)據(jù)重新排序后再分散到多臺機(jī)器執(zhí)行，以實(shí)現(xiàn)復(fù)雜的查詢。

ClickHouse適合簡單的DW之上的即席查詢。而Spark由于其分布式特性，導(dǎo)致其任務(wù)啟動(dòng)時(shí)間很長，因此不適合實(shí)現(xiàn)即席查詢，但是對于大數(shù)據(jù)量的join等復(fù)雜查詢時(shí)具備非常大的優(yōu)勢。

2、優(yōu)化重點(diǎn)不同

ClickHouse的優(yōu)化重點(diǎn)在如何提高單機(jī)的處理能力，而Spark的優(yōu)化重點(diǎn)在于如何提高分布式的協(xié)作效率。

四、ClickHouse比Hive快的原因

需要再次強(qiáng)調(diào)的是，ClickHouse只是在DW即席查詢場景下比Hive快，并沒有在所有場景都比Spark快，詳細(xì)的分析請參考第5章。本節(jié)對比的是，當(dāng)ClickHouse和Hive都進(jìn)行即席查詢，ClickHouse比Hive快的原因。

1、嚴(yán)格數(shù)據(jù)組織更適合做分析

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

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

2、更簡單的調(diào)度

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

關(guān)于作者：陳峰，資深大數(shù)據(jù)專家和架構(gòu)師，ClickHouse技術(shù)專家，滴普科技（2B領(lǐng)域獨(dú)角獸）合伙人兼首席架構(gòu)師?！禖lickHouse性能之巔：從架構(gòu)設(shè)計(jì)解讀性能之謎》作者。