GoogleDremel原理如何能3秒分析1PB..docxVIP

  1. 1、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
GoogleDremel原理如何能3秒分析1PB.

Google Dremel原理 - 如何能3秒分析1PB作者:?颜开?日期: 2012年08月23日发表评论?(14)查看评论简介Dremel是Google 的“交互式”数据分析系统。可以组建成规模上千的集群,处理PB级别的数据。MapReduce处理一个数据,需要分钟级的时间。作为MapReduce的发起人,Google开发了Dremel将处理时间缩短到秒级,作为MapReduce的有力补充。Dremel作为Google BigQuery的report引擎,获得了很大的成功。最近Apache计划推出Dremel的开源实现Drill,将Dremel的技术又推到了浪尖上。Google Dremel设计根据Google公开的论文《Dremel: Interactive Analysis of WebScaleDatasets》可以看到Dremel的设计原理。还有一些测试报告。论文写于2006年,公开于2010年,Google在处理大数据方面,果真有得天独厚的优势。下面的内容,很大部分来自这篇论文。随着Hadoop的流行,大规模的数据分析系统已经越来越普及。数据分析师需要一个能将数据“玩转”的交互式系统。如此,就可以非常方便快捷的浏览数据,建立分析模型。Dremel系统有下面几个主要的特点:Dremel是一个大规模系统。在一个PB级别的数据集上面,将任务缩短到秒级,无疑需要大量的并发。磁盘的顺序读速度在100MB/S上下,那么在1S内处理1TB数据,意味着至少需要有1万个磁盘的并发读! Google一向是用廉价机器办大事的好手。但是机器越多,出问题概率越大,如此大的集群规模,需要有足够的容错考虑,保证整个分析的速度不被集群中的个别慢(坏)节点影响。Dremel是MR交互式查询能力不足的补充。和MapReduce一样,Dremel也需要和数据运行在一起,将计算移动到数据上面。所以它需要GFS这样的文件系统作为存储层。在设计之初,Dremel并非是MapReduce的替代品,它只是可以执行非常快的分析,在使用的时候,常常用它来处理MapReduce的结果集或者用来建立分析原型。Dremel的数据模型是嵌套(nested)的。互联网数据常常是非关系型的。Dremel还需要有一个灵活的数据模型,这个数据模型至关重要。Dremel支持一个嵌套(nested)的数据模型,类似于Json。而传统的关系模型,由于不可避免的有大量的Join操作,在处理如此大规模的数据的时候,往往是有心无力的。Dremel中的数据是用列式存储的。使用列式存储,分析的时候,可以只扫描需要的那部分数据的时候,减少CPU和磁盘的访问量。同时列式存储是压缩友好的,使用压缩,可以综合CPU和磁盘,发挥最大的效能。对于关系型数据,如果使用列式存储,我们都很有经验。但是对于嵌套(nested)的结构,Dremel也可以用列存储,非常值得我们学习。Dremel结合了Web有哪些信誉好的足球投注网站?和并行DBMS的技术。首先,他借鉴了Web有哪些信誉好的足球投注网站中的“查询树”的概念,将一个相对巨大复杂的查询,分割成较小较简单的查询。大事化小,小事化了,能并发的在大量节点上跑。其次,和并行DBMS类似,Dremel可以提供了一个SQL-like的接口,就像Hive和Pig那样。Google Dremel应用场景设想一个使用场景。我们的美女数据分析师,她有一个新的想法要验证。要验证她的想法,需要在一个上亿条数据上面,跑一个查询,看看结果和她的想法是不是一样,她可不希望等太长时间,最好几秒钟结果就出来。当然她的想法不一定完善,还需要不断调整语句。然后她验证了想法,发现了数据中的价值。最后,她可以将这个语句完善成一个长期运行的任务。对于Google,数据一开始是放在GFS上的。可以通过MapReduce将数据导入到Dremel中去,在这些MapReduce中还可以做一些处理。然后分析师使用Dremel,轻松愉悦的分析数据,建立模型。最后可以编制成一个长期运行的MapReduce任务。这种处理方式,让笔者联想到Greenplum的Chorus. Chorus也可以为分析师提供快速的数据查询,不过解决方案是通过预处理,导入部分数据,减少数据集的大小。用的是三十六计,走为上计,避开的瞬时分析大数据的难题。Chorus最近即将开源,可以关注下。还有一点特别的就是按列存储的嵌套数据格式。如图所示,在按记录存储的模式中,一个记录的多列是连续的写在一起的。在按列存储中,可以将数据按列分开。也就是说,可以仅仅扫描A.B.C而不去读A.E或者A.B.C。难点在于,我们如何能同时高效地扫描若干列,并做一些分析。Google Dremel数据模型在Google, 用Protocol Buffer常常作为序列化的方案。其数据模型可以用数学方法严格的表示如

文档评论(0)

sa1fs5g1xc1I + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档