1、效率低

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

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

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

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

2、延遲高

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

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

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

3、成本高

傳統的數倉數倉引擎還會帶來成本高的挑戰，主要體現在以下幾個方面.

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

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

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

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

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

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