Presto简介
不是什么
虽然Presto可以解析SQL，但它不是一个标准的数据库。不是MySQL、PostgreSQL或者Oracle的代替品，也不能用来处理在线事务（OLTP）
是什么
Presto通过使用分布式查询，可以快速高效的完成海量数据的查询。作为Hive和Pig的补充，Presto不仅能访问HDFS，也能访问不同的数据源，包括：RDBMS和其他数据源（如Cassandra）。
架构
图中各个组件的概念及作用会在下文讲述。
Presto中SQL运行过程：MapReduce vs Presto
使用内存计算，减少与硬盘交互。
优点
- Presto与hive对比，都能够处理PB级别的海量数据分析，但Presto是基于内存运算，减少没必要的硬盘IO，所以更快。
- 能够连接多个数据源，跨数据源连表查，如从hive查询大量网站访问记录，然后从mysql中匹配出设备信息。
- 部署也比hive简单，因为hive是基于HDFS的，需要先部署HDFS。
缺点
- 虽然能够处理PB级别的海量数据分析，但不是代表Presto把PB级别都放在内存中计算的。而是根据场景，如count，avg等聚合运算，是边读数据边计算，再清内存，再读数据再计算，这种耗的内存并不高。但是连表查，就可能产生大量的临时数据，因此速度会变慢，反而hive此时会更擅长。
- 为了达到实时查询，可能会想到用它直连MySQL来操作查询，这效率并不会提升，瓶颈依然在MySQL，此时还引入网络瓶颈，所以会比原本直接操作数据库要慢。
Presto概念
服务器类型（Server Types）
Presto有两类服务器：coordinator和worker。
Coordinator
Coordinator服务器是用来解析语句，执行计划分析和管理Presto的worker结点。Presto安装必须有一个Coordinator和多个worker。如果用于开发环境和测试，则一个Presto实例可以同时担任这两个角色。
Coordinator跟踪每个work的活动情况并协调查询语句的执行。 Coordinator为每个查询建立模型，模型包含多个stage，每个stage再转为task分发到不同的worker上执行。
Coordinator与Worker、client通信是通过REST API。
Worker
Worker是负责执行任务和处理数据。Worker从connector获取数据。Worker之间会交换中间数据。Coordinator是负责从Worker获取结果并返回最终结果给client。
当Worker启动时，会广播自己去发现 Coordinator，并告知 Coordinator它是可用，随时可以接受task。
Worker与Coordinator、Worker通信是通过REST API。
数据源
贯穿全文，你会看到一些术语：connector、catelog、schema和table。这些是Presto特定的数据源
Connector
Connector是适配器，用于Presto和数据源（如Hive、RDBMS）的连接。你可以认为类似JDBC那样，但却是Presto的SPI的实现，使用标准的API来与不同的数据源交互。
Presto有几个内建Connector：JMX的Connector、System Connector（用于访问内建的System table）、Hive的Connector、TPCH（用于TPC-H基准数据）。还有很多第三方的Connector，所以Presto可以访问不同数据源的数据。
每个catalog都有一个特定的Connector。如果你使用catelog配置文件，你会发现每个文件都必须包含connector.name属性，用于指定catelog管理器（创建特定的Connector使用）。一个或多个catelog用同样的connector是访问同样的数据库。例如，你有两个Hive集群。你可以在一个Presto集群上配置两个catelog，两个catelog都是用Hive Connector，从而达到可以查询两个Hive集群。
Catelog
一个Catelog包含Schema和Connector。例如，你配置JMX的catelog，通过JXM Connector访问JXM信息。当你执行一条SQL语句时，可以同时运行在多个catelog。
Presto处理table时，是通过表的完全限定（fully-qualified）名来找到catelog。例如，一个表的权限定名是hive.test_data.test，则test是表名，test_data是schema，hive是catelog。
Catelog的定义文件是在Presto的配置目录中。
Schema
Schema是用于组织table。把catelog好schema结合在一起来包含一组的表。当通过Presto访问hive或Mysq时，一个schema会同时转为hive和mysql的同等概念。
Table
Table跟关系型的表定义一样，但数据和表的映射是交给Connector。
执行查询的模型（Query Execution Model）
语句（Statement）
Presto执行ANSI兼容的SQL语句。当Presto提起语句时，指的就是ANSI标准的SQL语句，包含着列名、表达式和谓词。
之所以要把语句和查询分开说，是因为Presto里，语句只是简单的文本SQL语句。而当语句执行时，Presto则会创建查询和分布式查询计划并在Worker上运行。
查询（Query）
当Presto解析一个语句时，它将其转换为一个查询，并创建一个分布式查询计划（多个互信连接的stage，运行在Worker上）。如果想获取Presto的查询情况，则获取每个组件（正在执行这语句的结点）的快照。
查询和语句的区别是，语句是存SQL文本，而查询是配置和实例化的组件。一个查询包含：stage、task、split、connector、其他组件和数据源。
Stage
当Presto执行查询时，会将执行拆分为有层次结构的stage。例如，从hive中的10亿行数据中聚合数据，此时会创建一个用于聚合的根stage，用于聚合其他stage的数据。
层次结构的stage类似一棵树。每个查询都由一个根stage，用于聚合其他stage的数据。stage是Coordinator的分布式查询计划（distributed query plan）的模型，stage不是在worker上运行。
Task
由于stage不是在worker上运行。stage又会被分为多个task，在不同的work上执行。
Task是Presto结构里是“work horse”。一个分布式查询计划会被拆分为多个stage，并再转为task，然后task就运行或处理split。Task有输入和输出，一个stage可以分为多个并行执行的task，一个task可以分为多个并行执行的driver。
Split
Task运行在split上。split是一个大数据集合中的一块。分布式查询计划最底层的stage是通过split从connector上获取数据，分布式查询计划中间层或顶层则是从它们下层的stage获取数据。
Presto调度查询，coordinator跟踪每个机器运行什么任务，那些split正在被处理。
Driver
Task包含一个或多个并行的driver。Driver在数据上处理，并生成输出，然后由Task聚合，最后传送给stage的其他task。一个driver是Operator的序列。driver是Presto最最低层的并行机制。一个driver有一个输出和一个输入。
Operator
Operator用来消费，传送和生产数据。如一个Operator从connector中扫表获取数据，然后生产数据给其他Operator消费。一个过滤Operator消费数据，并应用谓词，最后生产出子集数据。
Exchange
Exchange在Presto结点的不同stage之间传送数据。Task生产和消费数据是通过Exchange客户端。