Presto介绍
一、Presto出现背景
Presto是Facebook在2012年开发的，是专为Hadoop打造的一款数据仓库工具。在早期Facebook依赖Hive做数据分析，Hive底层依赖MapReduce，随着数据量越来越大，使用Hive进行数据分析，时间可能需要分钟级到小时级别，不能满足交互式查询的数据分析场景。2012年秋季，Facebook开发Presto，目前该项目在Facebook中运行超过30000个查询，每日处理数据PB以上。Presto的查询速度是Hive的5-10倍。
综上，Presto是由Facebook2012年开发，基于内存、支持并行计算的分布式SQL交互式查询引擎，不是数据库，支持多种数据源，针对GB~PB数据查询可以达到秒级返回结果，主要用于秒级查询OLAP数据分析场景。
Presto官网地址：https://prestodb.io
二、Presto特点
- 多数据源
Presto可以支持MySQL、PostgreSQL、cassandra、Hive、Kafka等多种数据源查询。
- 支持SQL
Presto支持部分标准SQL对数据进行查询，并提供SQL shell进行SQL查询。但是Presto不支持存储过程，不适合大表Join操作，因为Presto是基于内存的，多张大表关联可能给内存带来压力。
- 扩展性
Presto有很好的扩展向，可以自定义开发特定数据源的Connector，使用SQL分析指定Connector中的数据。
- 混合计算
在Presto中可以根据业务需要使用特定类型的Connector来读取不同数据源的数据，进行join关联计算。
- 基于内存计算，高性能
Presto是基于内存计算的，减少磁盘IO,计算更快。Presto性能是Hive的10倍以上。Presto能够处理PB级别的数据，但Presto并不是把PB级别的数据一次性加载到内存中计算，而是根据处理方式，例如:聚合场景，边读取数据，聚合，再清空内存，再去读取数据加载内存，再聚合计算，再清空内存... 这种方式。如果使用Join查询，那么就会产生大量的中间数据，速度会变慢。
- 流水线
由于Presto是基于PipeLine进行设计的，因此在进行海量数据处理过程中，终端用户不用等到所有的数据都处理完成才能看到结果，而是可以向自来水管一样，一旦计算开始，就可以产生一部分结果数据，并且结果数据会一部分接一部分的返回到客户端。
三、Presto架构
Presto查询引擎是一个Master-Slave的架构，由一个Coordinator节点，一个Discovery Server节点，多个Worker节点组成，Discovery Server通常内嵌于Coordinator节点中。Presto架构图如下：
上图中各个角色功能如下：
- Presto Coordinator:
主要负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行。所有的Worker启动后都会注册给Discovery Server，Coordinator通过内嵌的Discovery Server来知道将任务发送给哪些个Worker节点。
- Presto Worker:
主要负责实际执行查询任务，Worker节点启动之后，向Discovery Server服务注册，Coordinator从Discovery Server获得可以正常工作的Worker节点。当Worker接收到task后，就会到对应的数据源通过各种Connnector将数据提取出来。
- Hive Metastore（配置Hive Connector才会有）
Presto通过Hive Connector读取Hive数据时，配置Hive Metastore服务为Presto提供Hive元数据信息，可以让Worker节点与HDFS交互读取数据。
