Spark是否能替代Hive
在實際生產環境中已經形成了離線以Hive為主，Spark為輔, 實時處理用Flink的大資料架構體系及Impala, Es，Kylin等應用查詢引擎
但是有很多學習Spark的程式員普遍認為Spark必然會替代Hive成為新的一代大資料倉庫標準
同時，培訓市場也出現了Hive已經落後，學習大資料只要學習Spark相關言論
但結合實際工作的情況來看，這類說法和實際情況並不相符，本文針對資料倉庫的幾個重要特徵做了對比，說明各種利弊，希望對大家有一定的幫助
希望後續的大家能夠去積極瞭解一些資料倉庫需要的配置元件及系統，避免人云亦云，面試的時候引起不必要的爭議
Hive VS Spark
由上表可以看出，Spark不適合作為資料倉庫主要有以下幾點：
1)Spark本身沒有自己的儲存與meta庫兩種最核心的東西，需要依賴HDFS和Hive的相關功能，而社群的發展趨勢也沒有往這邊開發的意思，故Spark是作為一個計算引擎的定位長期存在的；
2)RDD， DataSet、DataFrames的三種計算形式 由於計算過程中沒有一個持久化的計算元資料管理導致後續對於資料血緣的解析難度過大，無法滿足資料倉庫排程對於資料體系依賴分析及元資料管理相關要求，故不能作為資料倉庫的主要使用方式
3)SparkSql是最有潛力成為資料倉庫的主要形式，但目前來說仍然是以Hive meta庫作為元資料管理 hdfs作為資料儲存，由於本身的sql解析器不如Hive，一般情況下是用Hive的sql解析器來替換本身的解析器。本質來說SparkSql只是作為hive的計算速度強化版使用
4)在cpu密集任務及複雜計算任務上，它的效能及穩定性遠遠比不上Hive
5)Spark在執行過程中經常會出現記憶體錯誤
再看Hive，擁有一套完整的Hadoop生態元件：
1)Sqoop支援RDS到Hive(HDFS)的互相同步
2)Flume支援日誌採集到HDFS
3)擁有自己一套完整的meta庫支援元資料管理
4)語言以sql為準，非常方便後續資料倉庫的維護，比如資料血緣解析，過濾條件解析
5)Hive的穩定性是目前的Spark無法保證的，在資料倉庫做分層設計的情況下，底層的穩定性要求會遠高於速度（如果底層一個任務失敗，可能導致上層的幾千個任務無法執行）
基於上面所說的，所以Spark替代Hive成為資料倉庫的首選時間會比較漫長，而且隨著Hive的sql執行引擎逐步優化後，Spark的優勢會越來越低
就目前來說，SparkSql作為資料倉庫上層做加快查詢的定位相對合適點，並不適合作為整套資料倉庫的尤其是需要強穩定性的底層資料排程查詢
資料倉庫是一套系統性工程，如果單純以計算效能作為唯一選型標準，難免會陷入後續無盡的維護陷阱中
大家喜歡多多關注，你的關注是我最大的動力。