码迷,mamicode.com
首页 > 其他好文 > 详细

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

时间:2017-12-28 16:08:32      阅读:159      评论:0      收藏:0      [点我收藏+]

标签:精确   pre   tom   pos   了解   sql语言   时延   实时   源码阅读   

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

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

标签:精确   pre   tom   pos   了解   sql语言   时延   实时   源码阅读   

原文地址:https://www.cnblogs.com/hseagle/p/8135695.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!