從分佈式分析引擎到分佈式存儲

事因偶然，開始了apache storm源碼的閱讀歷程，即而瞭解到apache spark一時風頭無兩，又一頭墜入到無比陌生的scala世界，開始了艱澀的spark源碼閱讀之路。

閱讀不是目的，用這些工具來解決實際中的問題纔是根本，剛好因爲通訊公司利潤降低，行業景氣度不如以前，人心思變，因而在沒作太多思量的狀況下，開始了真正的數據搬運工生涯。

分佈式分析引擎

因爲一開始只對spark和storm有所瞭解，因此用來作一些簡單的批處理分析和實時數據分析，仍是可以湊效的，可是一遇到規則複雜的業務系統，只用一個工具是遠遠不夠的，或者說在時延上很難知足需求。最簡單的一個例子，求某一個用戶在最近一小時內的登陸次數和關聯手機數，若是很是追求精確性，這個是難以進行預計算的，由於最近一小時是一個永遠在變的量。若是該用戶在過去一小時有操做還好，經過預計算能夠進行更新，若是沒有操做呢，原有的預計算值直接讀取出來的話是非零值，而其實是零值。

諸如上述的需求，即使用druid、flink也不能解決，由於沒有邏輯了進行expired elements的移除操做。

那麼針對這種，最爲精確的辦法就是在實際使用的時候再進行即時計算，那麼引起的問題是，在數據量很大的狀況下，如何在最短期內完成此類運算，另外一個若是同時有多種此類運算請求，系統可否依然保持相同水準的延遲。

這個時候就必定會涉及到存儲方案的選擇。

分佈式存儲

HDFS HDFS可以解決大數據的存儲問題，但不管和哪一種分析引擎結合，無論是hive、 spark、仍是presto都沒法在亞秒級完成比較複雜的聚合運算。

Elasticsearch ES和Solr在解決大數據存儲問題的同時，還能夠在亞秒級實際複雜的運算。但缺點是須要使用其獨特的DSL, 另外一個是在數據一致性上，不是嚴格一致。

NewSQL 以TIDB和Cockroack爲表明的NewSQL, 試圖解決利用有廣大用戶基礎的SQL語言來對大數據進行分析，同時提供很是良好的實時性支持。目前從已經發布的版原本看，TiDB在分佈式OLTP層面進展不小，但還須要作許多工做才能達到一款分佈式OLAP的目標。

HBASE 最後聊聊HBASE和Cassandra，這兩個成名已久，HBASE和Cassandra數據的實時寫入性能很是強，但在分析能力上比較弱，對於預先想到的分析場景，經過良好的設計能夠達到比較高的性能。可一旦碰到沒有事先料到的場景，就會拖累系統。另外Cassandra還有臭名昭著的tombstone問題。