Hadoop和Spark解決了哪些並行資料庫沒解決的問題？

01-04

哪些應用場景是並行資料庫解決不了的或者並行資料庫比較難解決的？

Spark比較好地解決了一體化數據流水線的問題。即用戶可以在Spark單一一個平台上，在單一一個應用內，通過組裝Spark的各種組件，高效完成多種範式的計算。例如可以用利用Spark Core做基本的清洗，利用Spark SQL做進一步的複雜ETL，再用MLlib做學習訓練。同時利用Spark SQL的DataFrame和外部數據源API可以融合各種存儲系統和存儲格式，進行混合計算後再以指定的格式寫入指定的存儲系統，或以DataFrame/RDD的形式作為下一步計算的輸入交給其他的Spark組件。

非結構化的數據處理，比如log的分析等。

如果數據變成結構化的，個人認為還是傳統資料庫更有吸引力。目前很多公司都對資料庫（postgres、mysql等）做了分散式化，性能相比分散式處理平台（Hive/HBase/Spark SQL）來說，要好。

軟體費用的問題

硬體費用的問題

無節操的壟斷大公司揩油和敷衍的問題

熟知內部不可讀的sql腳本掌故的老油條混日子的問題

技術上其實沒解決什麼問題，並行資料庫只要簡化簡化，把各種影響scale out的高級特性都去掉，就剩下group by，就是hadoop了。

簡而言之：典型場景類似lambda架構描述的那種，一邊有實時更新，一邊有adhoc查詢的場景。

現在dw很多是混合系統，就目前的來看，我也不明白spark要咋搞；

如果光論大數據量transformation或各種複雜的連接的性能，感覺還不如某些一體機；

那剩下的，能做啥呢，也許就是臨時分析玩玩，或者固定模式，或者就是非結構化數據的清理。

hadoop和spark不是一個組件，而mpp db（先縮小以教範圍, 分散式式db也有幾種）當前僅處理記錄數據（外表對半結構化數據一般很弱），所以只比較hd和spark的sql部分。解決了mpp db當前的問題: 1. 優化器太"智能"，db的產品型態對外提供標準sql, 對外盡量簡單，對於單機db來說沒有問題（或者說問題不明顯），但大數據量下，多節點，優化器優化規則就很複雜，一些時候，如果產品中設計不全，需要現場調優，而spark將rdd這層直接對外，應用對數據的處理更靈活。2.故障處理，db類的產品大多以單次查詢為恢復粒度，如果一次查詢要跑10小時，出故障後需要重新開始。3.生態，如果數據還需要ml, 可視化, 大多支持商用化產品, 跟進新產品慢