1?、Hive

Hive是一個基于HDFS（Hadoop Distributed File System , Hadoop分布式文件系統(tǒng)）的數(shù)倉系統(tǒng)，可以將存儲在HDFS之上的文件進行結(jié)構(gòu)化解析，并向用戶提供使用SQL操作Hadoop的能力。由于Hive構(gòu)建在基于HDFS和Spark/MapReduce的系統(tǒng)之上，使得Hive具備了理論上近乎無限的大數(shù)據(jù)處理能力，因此Hive迅速在業(yè)界占據(jù)主導(dǎo)地位，在其巔峰時期，Hive+SparkSQL就是大數(shù)據(jù)系統(tǒng)的標(biāo)配。Hive使用的是中間件思路，構(gòu)建在Hadoop的組件之上。

Hive本質(zhì)是一個元數(shù)據(jù)系統(tǒng)，由于自身沒有存儲和計算引擎，因此Hive無法單獨使用，必須配合HDFS+Spark/MapReduce，才能完成整個數(shù)倉的功能。甚至Hive的元數(shù)據(jù)存儲都借助了MySQL等關(guān)系型數(shù)據(jù)庫。這樣的架構(gòu)設(shè)計使得Hive成為事實上的Hadoop中間件系統(tǒng)，在大數(shù)據(jù)早期階段存在著如下非常重要的意義。

降低了Hadoop的技術(shù)門檻。

提高了Hadoop的使用效率。

投入產(chǎn)出比高。?

隨著技術(shù)的進步，Hadoop本身的問題越來越突出，使得Hive成為整個系統(tǒng)的瓶頸，這時候Hive的一些問題也隨之暴露，主要體現(xiàn)在以下幾點。

安裝運維困難：安裝Hive需要同時安裝更多的組件、易出現(xiàn)單點故障等。

受限于底層HDFS：小文件問題、不支持更新等。

受限于底層計算引擎：計算效率太低，延遲高無法支撐即席查詢等。

在ClickHouse技術(shù)尚未出現(xiàn)的年代，使用Hive需要同時配備非常龐大的大數(shù)據(jù)平臺，這使得傳統(tǒng)煙囪式數(shù)據(jù)開發(fā)模型由于成本原因無法在大數(shù)據(jù)時代早期廣泛應(yīng)用，因此出現(xiàn)了數(shù)據(jù)中臺的概念。建設(shè)數(shù)據(jù)中臺的一個重要原因是技術(shù)的不成熟使得大數(shù)據(jù)應(yīng)用成本非常高，企業(yè)沒有建設(shè)多個大數(shù)據(jù)平臺的動力，需要盡可能降低建設(shè)和維護成本，這就需要將所有數(shù)據(jù)整合到“大中臺小前臺”的架構(gòu)中，并由此誕生了一大批數(shù)據(jù)中臺的公司，極大地推動了產(chǎn)業(yè)的發(fā)展和技術(shù)的應(yīng)用。

煙囪式的數(shù)據(jù)開發(fā)模式在數(shù)據(jù)中臺時代被視為洪水猛獸，應(yīng)該絕對避免。當(dāng)然這個觀點在數(shù)據(jù)中臺時代是正確的。隨著大數(shù)據(jù)技術(shù)的成熟，使用全新技術(shù)的煙囪式數(shù)據(jù)開發(fā)模式其實也有著數(shù)據(jù)中臺無法比擬的優(yōu)勢——成本低、研發(fā)快、架構(gòu)靈活。這更體現(xiàn)出了計算機科學(xué)中的一個經(jīng)典理論——沒有銀彈。作為架構(gòu)師，應(yīng)該理性平等地分析每個架構(gòu)的優(yōu)點和缺點來找到最合適的架構(gòu)，而不是找到正確的架構(gòu)。

2、HBase

和Hive類似，HBase也是建立在HDFS之上的NoSQL數(shù)據(jù)庫。和Hive不同的是，HBase實現(xiàn)了自己的存儲引擎，避開了HDFS低性能的缺陷，獲得了非常高的吞吐能力。由于HBase遠比Hive高的性能，因此在大數(shù)據(jù)的早期，部分場景也會將HBase當(dāng)成數(shù)據(jù)倉庫來使用。

HBase采用重新設(shè)計的存儲引擎解決了一些數(shù)倉的技術(shù)瓶頸。HBase的存儲引擎是面向NoSQL設(shè)計的，由于無法真正完整地實現(xiàn)SQL的能力，因此除了少部分不需要強大SQL能力的場景之外，HBase的使用非常有限。HBase的出現(xiàn)也有著非常重要的意義。

證明了基于低效的HDFS也能設(shè)計出相對高性能的系統(tǒng)。

彌補了Hive無法支持實時場景的缺陷。

填補了大數(shù)據(jù)系統(tǒng)即席查詢的空白，擴充了大數(shù)據(jù)的應(yīng)用場景.

3、Kylin

Kylin是一個多維OLAP數(shù)倉。前文提到Hive的查詢延遲很高，尤其在復(fù)雜的多維分析中顯得格外明顯，難以滿足某些實時場景下的查詢需求。Hbase雖然可以解決一部分場景下的高延遲問題，但因為不支持SQL特性，所以也無法支持復(fù)雜的多維分析。

Kylin就是在這樣的背景下應(yīng)運而生。Kylin的基本原理是復(fù)雜的多維分析查詢速度慢，那就提前計算好結(jié)果保存到HBase中，即可在需要時快速得出結(jié)果。Kylin采用將復(fù)雜計算前置的思路，降低了復(fù)雜計算的延遲。從本質(zhì)上看，可以認(rèn)為Kylin也是一個大數(shù)據(jù)中間件。Kylin也面臨著如下一些挑戰(zhàn)。

維度爆炸：Kylin的本質(zhì)上是將計算前置，由于很難事先預(yù)測需要組合維度，因此只能進行窮舉。這種窮舉的方式面臨著維度爆炸的風(fēng)險。

數(shù)據(jù)實時性弱：由于Kylin存在預(yù)計算過程，新的數(shù)據(jù)必須經(jīng)過預(yù)計算才能被檢索到，因此Kylin本質(zhì)上只是解決了實時查詢的問題，沒有解決數(shù)據(jù)無法實時響應(yīng)的缺陷。

資源浪費：由于預(yù)計算的結(jié)果并不一定會被使用，因此可能存在資源浪費的現(xiàn)象。

?指標(biāo)逃逸：所需的數(shù)據(jù)未被預(yù)計算，這種情況需要重新使用Spark/MapReduce進行計算。

4、其他數(shù)倉

以上介紹了三款常用的數(shù)據(jù)倉庫及其核心思路，這三種數(shù)倉分別采用了三種不同的思路來實現(xiàn)大數(shù)據(jù)下的數(shù)據(jù)倉庫。而其他的數(shù)倉，大多也是采用其中的一種或幾種思路，例如Greenplum采用的是Hive類似的中間件思路，只不過其底層數(shù)據(jù)庫是PostgreSQL而不是Hive的Hadoop。ClickHouse則是采用類似HBase的思路，以極限單機性能為目標(biāo)，重新設(shè)計了存儲引擎和計算引擎。

本文摘編自《ClickHouse性能之巔：從架構(gòu)設(shè)計解讀性能之謎》，經(jīng)出版方授權(quán)發(fā)布。（書號：9787111716587）轉(zhuǎn)載請保留文章出處。