1、效率低

傳統(tǒng)的數(shù)倉大多構建在Hadoop之上。這位傳統(tǒng)的數(shù)倉帶來了近乎無限的橫向擴展能力，同時也造成了傳統(tǒng)的數(shù)倉技術效率低的缺陷。效率低主要體現(xiàn)在以下幾個方面。

部署效率低：在部署Hive/HBase/Kylin之前，必須部署好Hadoop集群。和傳統(tǒng)數(shù)據(jù)庫相比，這個部署效率是非常低效的。

運維效率低：Hive/HBase/Kylin基于Hadoop，Hadoop生態(tài)會帶來一個非常嚴重的單點故障問題，即Hadoop體系中任何一個組件出現(xiàn)問題，都可能引起整個系統(tǒng)的不可用。使用傳統(tǒng)的數(shù)倉對運維的要求非常高。

計算效率低：主要體現(xiàn)在Hive和Kylin上，這兩個數(shù)倉沒有自己的存儲引擎和計算引擎，這導致Hive和Kylin只能依靠堆機器實現(xiàn)復雜查詢，而無法從數(shù)據(jù)本身下手。在大數(shù)據(jù)后期，一些以數(shù)據(jù)快速查詢?yōu)槟繕硕厥庠O計的數(shù)據(jù)存儲格式成為標準，這個現(xiàn)象才有所改觀。而HBase的優(yōu)化核心就是重新設計的存儲引擎，使得HBase可以對數(shù)據(jù)本身進行查詢速度的優(yōu)化。

2、延遲高

構建在Hadoop之上的數(shù)倉引擎，除了效率低的缺點之外，還面臨著高延遲的挑戰(zhàn)。高延遲主要體現(xiàn)在以下幾個方面。

查詢延遲高：使用Hive作為數(shù)倉，受限于HDFS的性能瓶頸，Hive的查詢速度比較慢，難以支撐低延遲場景，無法應用在實時計算的場景中。

寫入數(shù)據(jù)延遲高：同樣受限于HDFS，Hive的數(shù)據(jù)寫入延遲也很高，這意味著數(shù)據(jù)無法實時寫入Hive，從而無法支撐實時分析場景。

3、成本高

傳統(tǒng)的數(shù)倉數(shù)倉引擎還會帶來成本高的挑戰(zhàn)，主要體現(xiàn)在以下幾個方面.

部署成本高：由于Hadoop的計算邏輯是通過堆計算資源的方式來攤銷復雜查詢的時間，因此如果需要達到一個比較理想的性能，必須要求集群中節(jié)點的數(shù)量達到一定的規(guī)模，否則因為計算效率低的特點，單機很容易成為性能瓶頸。這導致了Hive等基于Hadoop的數(shù)倉部署成本高的缺陷。

運維成本高：集群服務器達到一定規(guī)模后，運維成本會指數(shù)級上升。同時，由于Hadoop中組件太多，任何一個組件的失效都有可能導致整個服務的不可用，因此運維團隊必須包含所有組件的運維人員，否則運維團隊有可能很好地執(zhí)行任務。這也極大地提高了運維團隊的人力成本。

存儲成本高：Hadoop的HDFS為了避免集群中服務器故障從而導致的不可用的情況，默認使用三副本策略存儲數(shù)據(jù)，即數(shù)據(jù)會保存三份。這會極大地提高存儲成本。即使是新一代的Hadoop采用了EC糾刪碼技術降低了副本數(shù)量，但使用場景有限只適合在冷數(shù)據(jù)存儲中使用，對于經(jīng)常需要查詢的熱數(shù)據(jù)，并不適合采用該方案。

決策成本高：傳統(tǒng)的大數(shù)據(jù)由于部署成本高，導致企業(yè)在做決策時面臨比較大的決策成本，一方面是前期投入太大，短期內看不到效果，長期以來效果如何也很難說清楚。另一方面是即使企業(yè)下定決心來建設數(shù)倉，昂貴的基礎設施和專業(yè)技術人員的缺乏也會造成很長的建設周期，長的建設周期又會帶來很多不可預知的變數(shù)，最終影響企業(yè)的決策。

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

關于作者：陳峰，資深大數(shù)據(jù)專家和架構師，ClickHouse技術專家，滴普科技（2B領域獨角獸）合伙人兼首席架構師。《ClickHouse性能之巔：從架構設計解讀性能之謎》作者。