1?、Hive

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

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

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

提高了Hadoop的使用效率。

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

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

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

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

受限于底層計(jì)算引擎：計(jì)算效率太低，延遲高無(wú)法支撐即席查詢(xún)等。

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

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

2、HBase

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

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

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

彌補(bǔ)了Hive無(wú)法支持實(shí)時(shí)場(chǎng)景的缺陷。

填補(bǔ)了大數(shù)據(jù)系統(tǒng)即席查詢(xún)的空白，擴(kuò)充了大數(shù)據(jù)的應(yīng)用場(chǎng)景.

3、Kylin

Kylin是一個(gè)多維OLAP數(shù)倉(cāng)。前文提到Hive的查詢(xún)延遲很高，尤其在復(fù)雜的多維分析中顯得格外明顯，難以滿足某些實(shí)時(shí)場(chǎng)景下的查詢(xún)需求。Hbase雖然可以解決一部分場(chǎng)景下的高延遲問(wèn)題，但因?yàn)椴恢С諷QL特性，所以也無(wú)法支持復(fù)雜的多維分析。

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

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

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

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

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

4、其他數(shù)倉(cāng)

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

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