Google后Hadoop时代的新“三驾马车”——Caffeine、Pregel、Dremel

Google后Hadoop时代的新“三驾马车”——Caffeine、Pregel、Dremel
https://www.csdn.net/article/2012-08-20/2808870

摘要：Google在2003年到2004年公布了关于GFS、MapReduce和BigTable三篇技术论文，这也成为后来云计算发展的重要基石，如今Google在后Hadoop时代的新“三驾马车”——Caffeine、Pregel、Dremel再一次影响着全球大数据技术的发展潮流。

Hadoop的火爆要得益于Google在2003年底和2004年公布的两篇研究论文，其中一份描述了GFS（Google File System），GFS是一个可扩展的大型数据密集型应用的分布式文件系统，该文件系统可在廉价的硬件上运行，并具有可靠的容错能力，该文件系统可为用户提供极高的计算性能，而同时具备最小的硬件投资和运营成本。

另外一篇则描述了MapReduce，MapReduce是一种处理大型及超大型数据集并生成相关执行的编程模型。其主要思想是从函数式编程语言里借来的，同时也包含了从矢量编程语言里借来的特性。基于MapReduce编写的程序是在成千上万的普通PC机上被并行分布式自动执行的。8年后，Hadoop已经被广泛使用在网络上，并涉及数据分析和各类数学运算任务。但Google却提出更好的技术。

在2009年，网络巨头开始使用新的技术取代GFS和MapReduce。Mike Olson表示“这些技术代表未来的趋势。如果你想知道大规模、高性能的数据处理基础设施的未来趋势如何，我建议你看看Google即将推出的研究论文”。

自Hadoop兴起以来，Google已经发布了三篇研究论文，主要阐述了基础设施如何支持庞大网络操作。其中一份详细描述了Caffeine，Caffeine主要为Google网络搜索引擎提供支持。

在Google采用Caffeine之前，Google使用MapReduce和分布式文件系统（如GFS）来构建搜索索引（从已知的Web页面索引中）。在2010年，Google搜索引擎发生了重大变革。Google将其搜索迁移到新的软件平台，他们称之为“Caffeine”。Caffeine是Google出自自身的设计，Caffeine使Google能够更迅速的添加新的链接（包括新闻报道以及博客文章等）到自身大规模的网站索引系统中，相比于以往的系统，新系统可提供“50%新生”的搜索结果。

在本质上Caffeine丢弃MapReduce转而将索引放置在由Google开发的分布式数据库BigTable上。作为Google继GFS和MapReduce两项创新后的又一项创新，其在设计用来针对海量数据处理情形下的管理结构型数据方面具有巨大的优势。这种海量数据可以定义为在云计算平台中数千台普通服务器上PB级的数据。

另一篇介绍了Pregel，Pregel主要绘制大量网上信息之间关系的“图形数据库”。而最吸引人的一篇论文要属被称之为Dremel的工具。

点击查看大图

专注于大型数据中心规模软件平台的加利福尼亚伯克利分校计算机科学教授Armando Fox表示“如果你事先告诉我Dremel可以做什么，那么我不会相信你可以把它开发出来”。

Dremel是一种分析信息的方式，Dremel可跨越数千台服务器运行，允许“查询”大量的数据，如Web文档集合或数字图书馆，甚至是数以百万计的垃圾信息的数据描述。这类似于使用结构化查询语言分析传统关系数据库，这种方式在过去几十年被广泛使用在世界各地。

Google基础设施负责人Urs Hölzle表示“使用Dremel就好比你拥有类似SQL的语言，并可以无需任何编程的情况下只需将请求输入命令行中就可以很容易的制定即席查询和重复查询”。

区别在于Dremel可以在极快的速度处理网络规模的海量数据。据Google提交的文件显示你可以在几秒的时间处理PB级的数据查询。

目前Hadoop已经提供了在庞大数据集上运行类似SQL的查询工具（如Hadoop生态圈中的项目Pig和Hive）。但其会有一些延迟，例如当部署任务时，可能需要几分钟的时间或者几小时的时间来执行任务，虽然可以得到查询结果，但相比于Pig和Hive，Dremel几乎是瞬时的。

Holzle表示Dremel可移执行多种查询，而同样的任务如果使用MapReduce来执行通差需要一个工作序列，但执行时间确实前者的一小部分。Dremel可在大约3秒钟时间里处理1PB的数据查询请求。

Armando Fox表示Dremel是史无前例的，Hadoop作为大数据运动的核心一直致力构建分析海量数据工具的生态圈。但就目前的大数据工具往往存在一个缺陷，与传统的数据分析或商业智能工具相比，Hadoop在数据分析的速度和精度上还无法相比。但目前Dremel做到了鱼和熊掌兼得。

Dremel做到了“不可能完成的任务”，Dremel设法将海量的数据分析于对数据的深入挖掘进行有机的结合。Dremel所处理的数据规模的速度实在令人印象深刻，你可以舒适的探索数据。在Dremel出现之前还没有类似的系统可以做的像Dremel这样出色。

据Google提交的文件来看，Google从2006年就在内部使用这个平台，有“数千名”的Google员工使用Dremel来分析一切，从Google各种服务的软件崩溃报告到Google数据中心内的磁盘行为。这种工具有时会在数十台服务器上使用，有时则会在数以千计的服务器上使用。

Mike Olson表示尽管Hadoop取得的成功不容置疑，但构建Hadoop生态圈的公司和企业显然慢了，而同样的情况也出现在Dremel上，Google在2010年公布了Dremel的相关文档，但这个平台还没有被第三方企业充分利用起来，目前以色列的工程团队正在建设被称为OpenDremel的克隆平台。David Gruzman表示OpenDremel目前仅仅还在开始阶段，还需要很长时间进行完善。

换句话说即使你不是Google的工程师你同样可以使用Dremel。Google现在提供的BigQuery的服务就是基于Dremel。用户可通过在线API来使用这个平台。用户可以把数据上传到Google，并在Google基础设施中运行用户的查询服务。而这只是Google越来越多云服务的一部分。

早期用户通过Google App Engine构建、运行、并将应用托管在Google基础设施平台之上。而现今Google提供了包括BigQuery和Google Compute Engine等服务和基础设施，这些服务和基础设施可使用户瞬时接入虚拟服务器。

全球很多技术都落后于Google，而Google自身的技术也正在影响全球。

Caffeine 大规模实时增量索引

Our new search index: Caffeine 6/08/2010 05:00:00 PM (Cross-posted on the Webmaster Central Blog)

Today, we're announcing the completion of a new web indexing system called Caffeine. Caffeine provides 50 percent fresher results for web searches than our last index, and it's the largest collection of web content we've offered. Whether it's a news story, a blog or a forum post, you can now find links to relevant content much sooner after it is published than was possible ever before.

Some background for those of you who don't build search engines for a living like us: when you search Google, you're not searching the live web. Instead you're searching Google's index of the web which, like the list in the back of a book, helps you pinpoint exactly the information you need. (Here's a good explanation of how it all works.)

So why did we build a new search indexing system? Content on the web is blossoming. It's growing not just in size and numbers but with the advent of video, images, news and real-time updates, the average webpage is richer and more complex. In addition, people's expectations for search are higher than they used to be. Searchers want to find the latest relevant content and publishers expect to be found the instant they publish.

To keep up with the evolution of the web and to meet rising user expectations, we've built Caffeine. The image below illustrates how our old indexing system worked compared to Caffeine:

Our old index had several layers, some of which were refreshed at a faster rate than others; the main layer would update every couple of weeks. To refresh a layer of the old index, we would analyze the entire web, which meant there was a significant delay between when we found a page and made it available to you.

With Caffeine, we analyze the web in small portions and update our search index on a continuous basis, globally. As we find new pages, or new information on existing pages, we can add these straight to the index. That means you can find fresher information than ever before—no matter when or where it was published.

Caffeine lets us index web pages on an enormous scale. In fact, every second Caffeine processes hundreds of thousands of pages in parallel. If this were a pile of paper it would grow three miles taller every second. Caffeine takes up nearly 100 million gigabytes of storage in one database and adds new information at a rate of hundreds of thousands of gigabytes per day. You would need 625,000 of the largest iPods to store that much information; if these were stacked end-to-end they would go for more than 40 miles.

We've built Caffeine with the future in mind. Not only is it fresher, it's a robust foundation that makes it possible for us to build an even faster and comprehensive search engine that scales with the growth of information online, and delivers even more relevant search results to you. So stay tuned, and look for more improvements in the months to come.

Caffeine 谷歌推出的下一代搜索平台咖啡因

Google图算法引擎Pregel介绍

https://blog.csdn.net/qq_38265137/article/details/80547763

Pregel是一种基于BSP模型实现的并行图处理系统。

为了解决大型图的分布式计算问题，Pregel搭建了一套可扩展的、有容错机制的平台，该平台提供了一套非常灵活的API，可以描述各种各样的图计算。

Pregel作为分布式图计算的计算框架，主要用于图遍历、最短路径、PageRank计算等等。

图计算通用软件：

针对大型图的计算，目前通用的图计算软件主要包括两种：

第一种主要是基于遍历算法的、实时的图数据库，如Neo4j、OrientDB、DEX和 Infinite Graph。
第二种则是以图顶点为中心的、基于消息传递批处理的并行引擎，如GoldenOrb、Giraph、Pregel和Hama，这些图处理软件主要是基于BSP模型实现的并行图处理系统。

一次BSP(Bulk Synchronous Parallel Computing Model，块同步并行计算模型,又称“大同步”模型)计算过程包括一系列全局超步（所谓的超步就是计算中的一次迭代），每个超步主要包括三个组件：局部计算：每个参与的处理器都有自身的计算任务。
通讯：处理器群相互交换数据。
栅栏同步(Barrier Synchronization)：当一个处理器遇到“路障”（或栅栏），会等到其他所有处理器完成它们的计算步骤。

Google大数据引擎Dremel剖析

https://www.cnblogs.com/zhengran/p/4829048.html

[译者注]从头到尾读懂一篇国外经典技术论文！相信这是很多技术爱好者一直以来想干的事情。本系列译文的目标是满足广大技术爱好者对原始论文一窥究竟的需求，尽量对原文全量翻译。原始论文中不乏较晦涩的学术性语句，也可能会有您不感兴趣的段落，所以译者会添加【译者预读】【译者总结】等环节帮助大家选择性的阅读，或者帮助读者总结。根据译者的翻译过程，论文中也难免缺少细节的推导过程（Google的天才们总是把我们想的跟他们一样聪明），遂添加特殊的【译者YY】环节，根据译者的理解对较为复杂的内容进行解释和分析，此部分主观性很大难免有误，望读者矫正。所有非原文内容皆以蓝色文字显示。

废话不多说，大家一览为快吧！

【译者预读】此篇是伴随着Dremel神话横空出世的原始论文（不知道Dremel的读者可以立刻搜索感受一下Dremel的强大）。文章深入分析了Dremel是如何利用巧妙的数据存储结构+分布式并行计算，实现了3秒查询1PB的神话。

论文的前几部分是“abstract”、“introduction”、“background”，介绍性的文字较多，其核心意思是：面对海量数据的分析处理，MR（MapReduce）的优势不需多言，其劣势在于时效性较差不满足交互式查询的需求，比如3秒内完成对万亿数据的一次查询等，Dremel应此需求而生，与MR成为有效互补。

摘要

Dremel是一个用于分析只读嵌套数据的可伸缩、交互式ad-hoc查询系统。通过结合多层级树状执行过程和列状数据结构，它能做到几秒内完成万亿行数据之上的聚合查询。此系统可伸缩至成千上万的CPU和PB级别的数据，而且在google已有几千用户。在本篇论文中，我们将描述Dremel的架构和实现，解释它为何是MapReduce计算的有力互补。我们提供一种嵌套记录的列状存储结构，并且讨论在拥有几千个节点的系统上进行的实验。

[Apache Drill] == Google Dremel的开源版本

Apache Drill 调研学习

https://blog.csdn.net/weixin_39911113/article/details/78805272

六、6.1总结 drill优缺点对比

经过一天的调研与其他同类型技术的对比，drill给我的感觉，首先是实时交互式SQL分布式查询引擎。适用于实时的数据分析查询。

首先说说drill的优点：

支持自定义的嵌套数据集，数据灵活。 Hive一体化，完全支持hive包括hive的udf，并且支持自定义udf 低延迟的sql查询，与常用sql有些不同，不过学习成本较低支持多数据源性能较高。再来看看drill的缺点：

drill语法和常规sql有区别,一般是如“select from 插件名.表名”的形式。主要是因为drill查询不同数据源时需要切换不同的插件。下面分别是hive，hbase，文件系统三种数据源时候的查询sql。 a) hvie：select from hive.test01; b) hbase：select from hbase.test01; c) dfs：select from dfs./home/liking/test.csv;查出来之后是一列数据，若想对数据查询不同的列需要用columns[0]的形式来标记。 Select columns[0] from dfs./home/liking/test.csv。另外匹配的文件类型需要在插件的工作空间来配置，具体的配置请参考官方文档。 2．技术线太长，不容易切合到实际生产线上去。 3．国内使用较少，没有大型成功案例，不够大众化，出现问题可能维护起来比较困难。资料比较少。

六、6.2其他同类型技术简单介绍

Apache Kylin：核心思想是预计算，在查询之前建立好索引，以便提高查询速度。Kylin从数据仓库中最常用的Hive中读取源数据，使用 MapReduce作为Cube构建的引擎，并把预计算结果保存在HBase中，对外暴露Rest API/JDBC/ODBC的查询接口。因为Kylin支持标准的ANSI SQL，所以可以和常用分析工具（如Tableau、Excel等）进行无缝对接。

美团、京东、百度等互联网公司都有使用。e最大有8个维度，最大数据条数4亿，最大存储空间800G，30个Cube共占存储空间4T左右。查询性能上，当QPS在50左右，所有查询平均在200ms以内，当QPS在200左右，平均响应时间在1s以内。但从性能来讲没有问题，但他需要预计算，数十gb的文件大概需要几十分钟。对于实时性高的应用场景不能忍受。

Impala：基于hive的实时分布式查询引擎。与hive公用元数据库信息，但对udf的结合不够好，而且在嵌套数据的处理上也有问题。不过对于简单的查询来说效果可以。相比于drill，Impala需要定义模式。相对来说适合模式固定，查询条件简答的实时查询。

presto：京东，美团都有使用。缺点是学习成本较高，语法语义有问题。Facebook开源的没有权限控制，京东发布的版本有，但是不知道维护起来是否困难。有书可以参考。强类型不支持类型转换，京东版本做了类型转换，不过facebook没有接受京东的代码。所有处理都在内存中完成，本身是有内存限制的，但京东通过提高少量节点的内存，将大资源的任务的数据限制在高性能节点上来提高集群的性能瓶颈。

vieyahn2017 / repos