事因偶然，開始了apache storm原始碼的閱讀歷程，即而了解到apache spark一時風頭無兩，又一頭墜入到無比陌生的scala世界，開始了艱澀的spark原始碼閱讀之路。
閱讀不是目的，用這些工具來解決實際中的問題才是根本，恰好由於通訊公司利潤下降，行業景氣度不如之前，人心思變，於是在沒做太多思量的情況下，開始了真正的資料搬運工生涯。
由於一開始只對spark和storm有所了解，所以用來做一些簡單的批處理分析和實時資料分析，還是能夠湊效的，但是一遇到規則複雜的業務系統，只用乙個工具是遠遠不夠的，或者說在時延上很難滿足需求。最簡單的乙個例子，求某乙個使用者在最近一小時內的登入次數和關聯手機數，如果非常追求精確性，這個是難以進行預計算的，因為最近一小時是乙個永遠在變的量。如果該使用者在過去一小時有操作還好，通過預計算可以進行更新，如果沒有操作呢，原有的預計算值直接讀取出來的話是非零值，而實際上是零值。
諸如上述的需求，即便用druid、flink也不能解決，因為沒有邏輯了進行expired elements的移除操作。
那麼針對這種，最為精確的辦法就是在實際使用的時候再進行即時計算，那麼引發的問題是，在資料量很大的情況下，如何在最短時間內完成此類運算，另乙個如果同時有多種此類運算請求，系統能否依然保持相同水準的延遲。
這個時候就一定會涉及到儲存方案的選擇。
hdfshdfs能夠解決大資料的儲存問題，但無論和哪種分析引擎結合，不管是hive、 spark、還是presto都無法在亞秒級完成比較複雜的聚合運算。
elasticsearches和solr在解決大資料儲存問題的同時，還可以在亞秒級實際複雜的運算。但缺點是需要使用其獨特的dsl, 另乙個是在資料一致性上，不是嚴格一致。
newsql以tidb和cockroack為代表的newsql, 試**決利用有廣大使用者基礎的sql語言來對大資料進行分析，同時提供非常良好的實時性支援。目前從已經發布的版本來看，tidb在分布式oltp層面進展不小，但還需要做許多任務作才能達到一款分布式olap的目標。
hbase最後聊聊hbase和cassandra，這兩個成名已久，hbase和cassandra資料的實時寫入效能非常強，但在分析能力上比較弱，對於預先想到的分析場景，通過良好的設計可以達到比較高的效能。可一旦碰到沒有事先料到的場景，就會拖累系統。另外cassandra還有臭名昭著的tombstone問題。
從分布式分析引擎到分布式儲存
事因偶然，開始了apache storm原始碼的閱讀歷程，即而了解到apache spark一時風頭無兩，又一頭墜入到無比陌生的scala世界，開始了艱澀的spark原始碼閱讀之路。閱讀不是目的，用這些工具來解決實際中的問題才是根本，恰好由於通訊公司利潤下降，行業景氣度不如之前，人心思變，於是在沒做...
分布式儲存
塊儲存，檔案儲存，物件儲存區別 分布式儲存的應用場景相對於其儲存介面，現在流行分為三種 物件儲存 也就是通常意義的鍵值儲存，其介面就是簡單的get put del和其他擴充套件，如七牛 又拍 swift s3 塊儲存 這種介面通常以qemu driver或者kernel module的方式存在，這種...
分布式儲存
普通儲存 das 直連式儲存。nas 連線式儲存。san 儲存網路。大檔案分布儲存 gfs google file system google檔案系統 hdfs hadoop distributed file system hadoop分布式檔案系統 小檔案分布儲存 adfs ali distrib...