Presto:Facebook的分布式SQL查询引擎

标签: presto facebook sql | 发表时间:2013-11-10 06:25 | 作者:
分享到:
出处:http://news.cnblogs.com/

英文原文: Martin Traverso (Facebook)  

背景

Facebook 是一家数据驱动的公司。 数据处理和分析是 Facebook 为 10 亿多活跃用户开发和交付产品的核心所在。 我门拥有世界上最大的数据仓库之一,存储了大约 300PB 以上的数据。 这些数据被一系列不同种类的程序所使用, 包括传统的数据批处理程序、基于图论的数据分析[1]、机器学习、和实时性的数据分析。

分析人员、数据科学家和工程师需要处理数据、分析数据、不断地改善我们的产品, 对于这些人来说, 提高数据仓库的查询性能是非常重要的。在一定时间内能够运行更多的查询并且能够更快地获得查询结果能够提高他们的工作效率。

Facebook 数据仓库中的数据存储在几个大型的 Hadoop HDFS 的集群上。 Hadoop MapReduce[2]和 Hive 被设计为用于进行大规模、高可靠性的计算,而且这些技术都被优化为用来提高整体系统的吞吐量。但是当我们的数据仓库增长到 PB 级别,并且我们的需求进一步提升的时候, 我们就非常需要一个在数据仓库上工作的,能够提供低延迟的交互式查询系统。

在 2012 年秋天,Facebook 数据基础设施(Data Infrastructure)部门的一支团队开始为我们的数据仓库的用户解决这个问题。我们评估了一些外部项目, 发现这些项目或者是太不成熟,或者就是不能满足我们在灵活性和规模性上的要求。 所以我们决定开始搭建 Presto,一个崭新的能够在 PB 级别的数据上进行交互式查询的系统。

在这篇文章中,我们将简单地介绍 Presto 的架构、现状和前景。

架构

Presto 是一个分布式 SQL 查询引擎, 它被设计为用来专门进行高速、实时的数据分析。它支持标准的 ANSI SQL,包括复杂查询、聚合(aggregation)、连接(join)和窗口函数(window functions)。

下面的架构图中展现了简化的 Presto 系统架构。客户端(client)将 SQL 查询发送到 Presto 的协调员(coordinator)。协调员会进行语法检查、分析和规划查询计划。计划员(scheduler)将执行的管道组合在一起, 将任务分配给那些里数据最近的节点,然后监控执行过程。 客户端从输出段中将数据取出, 这些数据是从更底层的处理段中依次取出的。

Presto 的运行模型和 Hive 或 MapReduce 有着本质的区别。Hive 将查询翻译成多阶段的 MapReduce 任务, 一个接着一个地运行。 每一个任务从磁盘上读取输入数据并且将中间结果输出到磁盘上。 然而 Presto 引擎没有使用 MapReduce。它使用了一个定制的查询和执行引擎和响应的操作符来支持 SQL 的语法。除了改进的调度算法之外, 所有的数据处理都是在内存中进行的。 不同的处理端通过网络组成处理的流水线。 这样会避免不必要的磁盘读写和额外的延迟。 这种流水线式的执行模型会在同一时间运行多个数据处理段, 一旦数据可用的时候就会将数据从一个处理段传入到下一个处理段。 这样的方式会大大的减少各种查询的端到端响应时间。

Presto 系统是用 Java 来实现的, 主要原因是 Java 的开发效率高,且拥有非常好的生态环境, 并且很容易同 Facebook 数据基础设施的其他 Java 应用进行集成。Presto 会将查询计划中的一部分动态地编译成 JVM 字节代码,并让 JVM 优化和生成原生的机器代码。  通过谨慎地使用内存和数据结构,Presto 避免了通常 Java 程序会碰到的内存分配和垃圾收集(Java garbage collection)的问题。(在后一篇文章中, 我们会分享一些在开发高性能 Java 系统的时候的一些提示和技巧,以及我们在搭建 Presto 系统时的一些经验教训。)

扩展性是在设计 Presto 时的另一个要点。在项目的早期阶段, 我们就意识到出了 HDFS 之外,大量数据会被存储在很多其他类型的系统中。 其中一些是像 HBase 一类的为人熟知的系统,另一类则是象 Facebook New Feed 一样的定制的后台。Presto 设计了一个简单的数据存储的抽象层, 来满足在不同数据存储系统之上都可以使用 SQL 进行查询。存储插件(连接器,connector)只需要提供实现以下操作的接口, 包括对元数据(metadata)的提取,获得数据存储的位置,获取数据本身的操作等。除了我们主要使用的 Hive/HDFS 后台系统之外, 我们也开发了一些连接其他系统的 Presto 连接器,包括 HBase,Scribe 和定制开发的系统。

(译者注:Scribe 是 Facebook 的开源项目,可以实时的将大量服务器产生的日志文件汇总到文件系统中, 详见: https://github.com/facebook/scribe

(译者注: 从目前的信息来看,Presto 的架构在分布式处理数据的方式和基于 MapReduce 2.0 的 HorntonWorks 的 Stinger 有着很大的不同,可能会比较接近于 Google 的 Dremel 或者 Cloudera 的 Impala。 )

现状

正如上面所介绍的, Presto 的开发是从 2012 年的秋天开始的。 在 2013 年早期的时候我门的第一个生产系统开始运行。 在 2013 年春天的时候这个系统推广到了 Facebook 的整个公司。从那是起, Presto 成为了公司内在数据仓库上进行交互式分析的主要系统。 它被部署到了多个不同的地区,而且我们成功地将一个集群扩展到了 1000 个节点。 超过 1000 名以上的员工在日常工作中使用这个系统, 他们每天在一个 PB 的数据上会运行超过 30,000 个查询。

Presto 在 CPU 的性能和主要的查询性能上比 Hive/MapReduce 要好 10 倍以上。它目前支持 ANSI SQL 的大部分操作, 包括连接、 左/右外连接、 子查询、以及通用的聚合和标量函数, 同时也包含了一些近似的去重(使用了 HyperLogLog)和近似的百分数(基于 quantile digest 算法,)计算。目前阶段的主要限制是在表连接时候的大小限制以及唯一键值和群组的基数(cardinality of unique keys/groups)。目前系统没有能力将查询结果回写到特定的表中(目前查询结果会直接通过流输出的方式返回给客户端)。

(译者注:对大数据进行特定操作的时候会用到一些使用统计方法的近似算法。HyperLogLog 算法时用来估计大量数据中特定值出现次数的,具体可以看 这篇博文。Quantile Digest 算法及具体应用可以看 这篇博文。)

展望

我们在积极努力地扩展 Presto 的功能以及提供性能。 在接下来的几个月中,我们会去除查询中连接和聚合的大小限制,同时我们将提供将查询结果写入输出表的功能。 我们同时在开发一个查询加速器。主要是设计一种为查询处理优化的新的数据格式来避免不必要的数据转换。 这些新的特性会将后台数据仓库中经常使用的数据集合缓存起来, 系统会有效地使用这些缓存数据来加速查询的速度,而不需要让用户知道缓存机制的存在。 我们同时也在开发一个高性能的 HBase 连接器(HBase connector)。

开源

2013 年 6 月的 Analytics @ WebScale 大会上, 我们第一次介绍了 Presto。在那之后,它吸引了许多外界对它的关注。在最近的几个月中, 我们已经将 Presto 的源代码和可执行包发布给了一些外界的公司。他们已经在他们自己的环境中成功地进行了部署和测试的工作, 并且给了我们很好的反馈。

今天我们非常高兴宣布我们将 Presto 变成开源项目。 你可以在以下的网站上找到源代码和文档。 我将非常乐意从你这里了解到你的用例,以及 Presto 可以怎样帮到你的交互式分析。

Preston 官网: http://prestodb.io/

Preston Github 主页: https://github.com/facebook/presto

Facebook 数据基础设施的 Presto 团队由以下成员组成, Martin Traverso, Dain Sundstrom, David Phillips, Eric Hwang, Nileema Shingte 以及 Ravi Murthy.

链接

[1] Scaling Apache Giraph to a trillion edges.  https://www.facebook.com/notes/facebook-engineering/scaling-apache-giraph-to-a-trillion-edges/10151617006153920

[2] Under the hood: Scheduling MapReduce jobs more efficiently with Corona https://www.facebook.com/notes/facebook-engineering/under-the-hood-scheduling-mapreduce-jobs-more-efficiently-with-corona/10151142560538920

[3] Video of Presto talk at Analytics@Webscale conference, June 2013 https://www.facebook.com/photo.php?v=10202463462128185

本文链接

相关 [presto facebook sql] 推荐:

Presto:Facebook的分布式SQL查询引擎

- - 博客园_新闻
英文原文: Martin Traverso (Facebook)  . Facebook 是一家数据驱动的公司. 数据处理和分析是 Facebook 为 10 亿多活跃用户开发和交付产品的核心所在. 我门拥有世界上最大的数据仓库之一,存储了大约 300PB 以上的数据. 这些数据被一系列不同种类的程序所使用, 包括传统的数据批处理程序、基于图论的数据分析[1]、机器学习、和实时性的数据分析.

facebook presto安装与配置 CDH4.4

- - CSDN博客云计算推荐文章
下载:  http://search.maven.org/remotecontent?filepath=com/facebook/presto/presto-server/0.52/presto-server-0.52.tar.gz. 重命名:mv presto-cli-0.52-executable.jar presto.

Presto 来自Facebook的开源分布式查询引擎

- - 标点符
PrestoDB 来自Facebook的开源分布式查询引擎. Presto是一个分布式SQL查询引擎, 它被设计为用来专门进行高速、实时的数据分析. 它支持标准的ANSI SQL,包括复杂查询、聚合(aggregation)、连接(join)和窗口函数(window functions). 下图中展现了简化的Presto系统架构.

安装和部署Presto

- - JavaChen's Blog
操作系统:CentOs6.5. Hadoop 集群:CDH5.3. JDK 版本:jdk1.8.0_31. 为了测试简单,我是将 Presto 的 coordinator 和 worker 都部署在 cdh1 节点上,并且该节点上部署了 hive-metastore 服务. 下面的安装和部署过程参考自 http://prestodb.io/docs/current/installation.html.

Presto实现原理和美团的使用实践

- - 美团技术团队
Facebook的数据仓库存储在少量大型Hadoop/HDFS集群. Hive是Facebook在几年前专为Hadoop打造的一款数据仓库工具. 在以前,Facebook的科学家和分析师一直依靠Hive来做数据分析. 但Hive使用MapReduce作为底层计算框架,是专为批处理设计的. 但随着数据越来越多,使用Hive进行一个简单的数据查询可能要花费几分到几小时,显然不能满足交互式查询的需求.

PL/SQL动态SQL(原创)

- - ITeye博客
使用动态SQL是在编写PL/SQL过程时经常使用的方法之一. 很多情况下,比如根据业务的需要,如果输入不同查询条件,则生成不同的执行SQL查询语句,对于这种情况需要使用动态SQL来完成. 再比如,对于分页的情况,对于不同的表,必定存在不同的字段,因此使用静态SQL则只能针对某几个特定的表来形成分页.

#数据技术选型#即席查询Shib+Presto,集群任务调度HUE+Oozie

- - ITeye博客
郑昀 创建于2014/10/30 最后更新于2014/10/31. 一)选型:Shib+Presto. 应用场景:即席查询(Ad-hoc Query). 使用者是产品/运营/销售运营的数据分析师;. 要求数据分析师掌握查询SQL查询脚本编写技巧,掌握不同业务的数据存储在不同的数据集市里;. 不管他们的计算任务是提交给 数据库 还是 Hadoop,计算时间都可能会很长,不可能在线等待;.

SQL Server--索引

- - CSDN博客推荐文章
         1,概念:  数据库索引是对数据表中一个或多个列的值进行排序的结构,就像一本书的目录一样,索引提供了在行中快速查询特定行的能力..             2.1优点:  1,大大加快搜索数据的速度,这是引入索引的主要原因..                             2,创建唯一性索引,保证数据库表中每一行数据的唯一性..

Derby SQL 分页

- - ITeye博客
    之前在网上看到有人问 Derby SQL 分页实现的问题,网上有人给出这样的解决方案,SQL 如下:. 其实,这样的分页查询,性能不理想,我试过在 300W 数据量中采用这种分页方式,需要 20~30秒之久;其实 Derby 10.6 以上版本有更好的分页支持,直接给出 SQL 实现如下:.

birt动态SQL

- - ITeye博客
birt动态SQL实现有三种方式:拼接SQL、绑定变量和让应用程序拼接,birt得到返回结果集方式. 在数据集中写SQL,如下:. 选中数据集,点script方式,在beforeOpen事件中写如下SQL:. 然后就可以了,当然,也可以不写第一步,直接所有的SQL都在beforeOpen中拼接. 但是,拼接SQL方式不仅复杂容易错,还会导致SQL注入风险.