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

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