知名數倉技術及其核心思路，大盤點！

Hive是一個基於HDFS（Hadoop Distributed File System , Hadoop分散式檔案系統）的數倉系統，可以將儲存在HDFS之上的檔案進行結構化解析，並向使用者提供使用SQL操作Hadoop的能力。由於Hive構建在基於HDFS和Spark/MapReduce的系統之上，使得Hive具備了理論上近乎無限的大資料處理能力，因此Hive迅速在業界佔據主導地位，在其巔峰時期，Hive+SparkSQL就是大資料系統的標配。Hive使用的是中介軟體思路，構建在Hadoop的元件之上。

Hive本質是一個後設資料系統，由於自身沒有儲存和計算引擎，因此Hive無法單獨使用，必須配合HDFS+Spark/MapReduce，才能完成整個數倉的功能。甚至Hive的後設資料儲存都藉助了MySQL等關係型資料庫。這樣的架構設計使得Hive成為事實上的Hadoop中介軟體系統，在大資料早期階段存在著如下非常重要的意義。

• 降低了Hadoop的技術門檻。

• 提高了Hadoop的使用效率。

• 投入產出比高。

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

• 安裝運維困難：安裝Hive需要同時安裝更多的元件、易出現單點故障等。

• 受限於底層HDFS：小檔案問題、不支援更新等。

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

在ClickHouse技術尚未出現的年代，使用Hive需要同時配備非常龐大的大資料平臺，這使得傳統煙囪式資料開發模型由於成本原因無法在大資料時代早期廣泛應用，因此出現了資料中臺的概念。建設資料中臺的一個重要原因是技術的不成熟使得大資料應用成本非常高，企業沒有建設多個大資料平臺的動力，需要儘可能降低建設和維護成本，這就需要將所有資料整合到“大中臺小前臺”的架構中，並由此誕生了一大批資料中臺的公司，極大地推動了產業的發展和技術的應用。

煙囪式的資料開發模式在資料中臺時代被視為洪水猛獸，應該絕對避免。當然這個觀點在資料中臺時代是正確的。隨著大資料技術的成熟，使用全新技術的煙囪式資料開發模式其實也有著資料中臺無法比擬的優勢——成本低、研發快、架構靈活。這更體現出了電腦科學中的一個經典理論——沒有銀彈。作為架構師，應該理性平等地分析每個架構的優點和缺點來找到最合適的架構，而不是找到正確的架構。

和Hive類似，HBase也是建立在HDFS之上的NoSQL資料庫。和Hive不同的是，HBase實現了自己的儲存引擎，避開了HDFS低效能的缺陷，獲得了非常高的吞吐能力。由於HBase遠比Hive高的效能，因此在大資料的早期，部分場景也會將HBase當成資料倉儲來使用。

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

• 證明瞭基於低效的HDFS也能設計出相對高效能的系統。

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

• 填補了大資料系統即席查詢的空白，擴充了大資料的應用場景.

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

Kylin就是在這樣的背景下應運而生。Kylin的基本原理是複雜的多維分析查詢速度慢，那就提前計算好結果儲存到HBase中，即可在需要時快速得出結果。Kylin採用將複雜計算前置的思路，降低了複雜計算的延遲。從本質上看，可以認為Kylin也是一個大資料中介軟體。Kylin也面臨著如下一些挑戰。

• 維度爆炸：Kylin的本質上是將計算前置，由於很難事先預測需要組合維度，因此只能進行窮舉。這種窮舉的方式面臨著維度爆炸的風險。

• 資料實時性弱：由於Kylin存在預計算過程，新的資料必須經過預計算才能被檢索到，因此Kylin本質上只是解決了實時查詢的問題，沒有解決資料無法實時響應的缺陷。

• 資源浪費：由於預計算的結果並不一定會被使用，因此可能存在資源浪費的現象。

• 指標逃逸：所需的資料未被預計算，這種情況需要重新使用Spark/MapReduce進行計算。

  
  

  
  

以上介紹了三款常用的資料倉儲及其核心思路，這三種數倉分別採用了三種不同的思路來實現大資料下的資料倉儲。而其他的數倉，大多也是採用其中的一種或幾種思路，例如Greenplum採用的是Hive類似的中介軟體思路，只不過其底層資料庫是PostgreSQL而不是Hive的Hadoop。ClickHouse則是採用類似HBase的思路，以極限單機效能為目標，重新設計了儲存引擎和計算引擎。

本文摘編自《ClickHouse效能之巔：從架構設計解讀效能之謎》，經出版方授權釋出。（書號：9787111716587）轉載請保留文章出處。

推薦語：滴普合夥人兼首席架構師/資深ClickHouse專家撰寫，從架構剖析ClickHouse底層邏輯，總結大量效能調優方法。