标签：
2012年秋季Facebook启动了Presto，Presto的目的是在几百PB级别数据量上面进行准实时分析。在摒弃了一些外部项目以后，Facebook准备开发他们自己的分布式查询引擎。Presto的语法基于ANSI SQL，大多数分布式查询引擎需要用户去学习一种新的语法，有的语法类似SQL，但是没有一种是和真正的SQL一样被人们所熟悉，并且有详尽的文档。Facebook希望这个决定能够使得培训新用户变得更容易更快速。依赖于 ANSI SQL也让Presto能够利用的现存的第三方工具。
在内部， Presto基于流水线。当请求被分析，任务分配到适当节点以后，客户端从输出阶段拉取数据，输出阶段从更底层阶段里面拉取数据。Presto的执行模式是和Hive/MapReduce有着基础性的差异的。Hive把查询语句翻译为MapReduce任务的不同阶段，然后一个接着一个的执行。每个任务从磁盘读取输入，然后把中间结果写回到磁盘中。与之相反的是，Presto不是使用MapReduce，他使用大家所习惯的查询和执行引擎，它们有着设计好的支持SQL语法的操作符。比优化过的调度更进一步的是，全部处理过程都是在内存中，而且是在不同阶段之间通过网络交互进行流水线作业的。这规避了不必要的IO操作，和随之造成的过高的延迟。这种流水线化的执行模型可以在同一时间内运行不同的阶段，当数据可用以后，流数据就从一个阶段到另外一个阶段。对于很多类型查询来说，这就显著的减少了端到端的延迟。
Presto是使用Java写的一个可插拔的后端。对于很多数据源来说，例如Hive、Hbase或者Scribe，就需要一个数据连接器。这个连接器为Presto提供元数据、那些节点保持数据的信息，还提供了一种把数据当做流的办法。
在Facebook绝大多数查询场景中，Presto在时间消耗和cpu占用上面超过Hive/MapReduce十倍。Facebook仍然计划去进一步提升性能。一个计划是设计一种新的数据格式以减少当数据从一个阶段到另外一个阶段时候所需的数据转换量。Facebook还计划去掉一些目前设计中的限制：目前最主要的限制是join操作时候表的大小和unique 主键和group时候的基数的大小。目前系统缺乏把输出数据协会到表的能力，目前查询结果是回流到客户端的。
国内目前美团有大规模使用，见：http://tech.meituan.com/presto.html
目前Presto已经纳入到apache2.0中，其git地址：https://github.com/prestodb/presto
官方文档：https://prestodb.io/docs/current/overview/use-cases.html
标签：
原文地址：http://www.cnblogs.com/laodageblog/p/5608094.html
