Apache Storm源碼閱讀筆記&OLAP在大資料時代的挑戰

自從建了Spark交流的QQ群之後，熱情加入的同學不少，大家不僅對Spark很熱衷對于Storm也是充滿好奇。大家都提到一個問題就是有關storm内部實作機理的資料比較少,了解起來非常費勁。

盡管自己也陸續對storm的源碼走讀發表了一些博文，當時寫的時候比較匆忙，有時候銜接的不是太好，此番做了一些整理，主要是針對TridentTopology部分，修改過的内容采用pdf格式釋出，友善列印。

文章中有些内容的了解得益于徐明明和fxjwind兩位的指點，非常感謝。

<a href="https://yq.aliyun.com/attachment/download/?spm=0.0.0.0.Tr8H2j&amp;filename=storm.pd...%5B%E8%AE%B8%E9%B9%8F%5D.1473672493.pdf">storm.pd...[許鵬].1473672493.pdf </a>

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

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

olap中存儲大量曆史資料，資料存儲成了olap中要解決的第一個也是首要問題，這個需求的解決方案有多種，可以是HDFS，也可以是NoSQL資料庫，也可以是Distributed RDBMS，當中的取舍要視具體情況而定。後面會涉及具體的考慮次元。

如何将資料從oltp遷移到olap，這個同步機制需要考慮資料一緻性，zero data-loss, 實時性要求等等。

在大量甚至是海量的曆史資料中如何快速定位到所要符合條件的記錄？ 資料量如果在TB級以上，就需要考慮使用solr或是elasticsearch

花了好多代價儲存下來的海量資料，隻是用了做簡單明細查詢，任何老闆都不能容忍，一定要在曆史的資料進行複雜的分析才行。這時候有一個好的分布式計算引擎就很有必要了。如spark/presto/impala

資料挖掘是一種比資料分析更為複雜的資料分析，呵呵，個人了解，有些繞。這個時候什麼算法啦，什麼機器學習啦，可以上場了。

資料分析中還需要考慮到另一個重要限制就是時間，如果希望分析結果愈快愈好，那麼就需要采用如druid這樣的系統。

如果資料規模在10TB以下，資料包含結構化和半結構化資料，明細查詢中條件比較固定，不存在全文搜尋。需要在比較短的時間内如秒級得到複雜分析結果，可以考慮使用distributed rdbms.

如果資料規模遠遠超過10TB，那麼就需要将資料存儲/資料查詢/資料分析交由不同的系統來處理，這個時候就需要組成一個技術棧來解決總量。如HDFS/solr or elasticsearch/Spark or Presto or Impala. 為了提升分析的效率，除了從distributed computing engine側進行優化之外，還需要從存儲側進行優化，采用先進的存儲格式如parquet/orc/carbondata将會極大的提升分析性能。