OLAP在大數據時代的挑戰

轉行作數據相關的工做有近兩年時間，除了具體技術，還有許多其它思考。

數據的價值

在涉及具體的技術前，先想想爲何須要OLAP這樣的系統，它有什麼價值或者說在公司或部門這是不可取代的麼？ 能夠帶來哪些價值，是直接變現仍是間接變現。 若是不能回答或回答不了，那麼就是一個很大的問題，這其實意味着數據的質量存在問題。沒有質量的數據，體量再大也毫無價值。

數據存儲

假設已經有很好的oltp系統，那麼oltp系統在數據量不大的狀況下，繼續扮演olap角色也還能夠。一旦業務紅火，那麼oltp中的analyze部分勢必會分離出來，也就是olap和oltp相互單獨存在。

olap中存儲大量歷史數據，數據存儲成了olap中要解決的第一個也是首要問題，這個需求的解決方案有多種，能夠是HDFS，也能夠是NoSQL數據庫，也能夠是Distributed RDBMS，當中的取捨要視具體狀況而定。後面會涉及具體的考慮維度。

數據同步和ETL

如何將數據從oltp遷移到olap，這個同步機制須要考慮數據一致性，zero data-loss, 實時性要求等等。

數據查詢

在大量甚至是海量的歷史數據中如何快速定位到所要符合條件的記錄？ 數據量若是在TB級以上，就須要考慮使用solr或是elasticsearch

數據分析

花了好多代價保存下來的海量數據，只是用了作簡單明細查詢，任何老闆都不能容忍，必定要在歷史的數據進行復雜的分析才行。這時候有一個好的分佈式計算引擎就頗有必要了。如spark/presto/impala

數據挖掘

數據挖掘是一種比數據分析更爲複雜的數據分析，呵呵，我的理解，有些繞。這個時候什麼算法啦，什麼機器學習啦，能夠上場了。

big data or fast data

數據分析中還須要考慮到另外一個重要約束就是時間，若是但願分析結果愈快愈好，那麼就須要採用如druid這樣的系統。

結果

若是數據規模在10TB如下，數據包含結構化和半結構化數據，明細查詢中條件比較固定，不存在全文搜索。須要在比較短的時間內如秒級獲得複雜分析結果，能夠考慮使用distributed rdbms.

若是數據規模遠遠超過10TB，那麼就須要將數據存儲/數據查詢/數據分析交由不一樣的系統來處理，這個時候就須要組成一個技術棧來解決總量。如HDFS/solr or elasticsearch/Spark or Presto or Impala. 爲了提高分析的效率，除了從distributed computing engine側進行優化以外，還須要從存儲側進行優化，採用先進的存儲格式如parquet/orc/carbondata將會極大的提高分析性能。