从分布式分析引擎到分布式存储

事因偶然，开始了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问题。