从分布式分析引擎到分布式存储
source link: http://www.cnblogs.com/hseagle/p/8135695.html?amp%3Butm_medium=referral
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
事因偶然，开始了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问题。
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK