[大数据] Presto架构及原理

小鱼儿 2022-05-19 14:15 263阅读 0赞

Presto 是 Facebook 推出的一个基于Java开发的大数据分布式 SQL 查询引擎，可对从数 G 到数 P 的大数据进行交互式的查询，查询的速度达到商业数据仓库的级别，据称该引擎的性能是 Hive 的 10 倍以上。Presto 可以查询包括 Hive、Cassandra 甚至是一些商业的数据存储产品，单个 Presto 查询可合并来自多个数据源的数据进行统一分析。Presto 的目标是在可期望的响应时间内返回查询结果，Facebook 在内部多个数据存储中使用 Presto 交互式查询，包括 300PB 的数据仓库，超过 1000 个 Facebook 员工每天在使用 Presto 运行超过 3 万个查询，每天扫描超过 1PB 的数据。

**目录：**

*  presto架构
 *  presto低延迟原理
 *  presto存储插件
 *  presto执行过程
 *  presto引擎对比

**Presto架构**

--------------------

*  **![1004194-20161105161906033-1520472358.png][]**
 *  Presto查询引擎是一个Master-Slave的架构，由下面三部分组成:
    
    1.  一个Coordinator节点
    2.  一个Discovery Server节点
    3.  多个Worker节点
 *  Coordinator: 负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行
 *  Discovery Server: 通常内嵌于Coordinator节点中
 *  Worker节点: 负责实际执行查询任务,负责与HDFS交互读取数据
 *  Worker节点启动后向Discovery Server服务注册，Coordinator从Discovery Server获得可以正常工作的Worker节点。如果配置了Hive Connector，需要配置一个Hive MetaStore服务为Presto提供Hive元信息
 *  更形象架构图如下：
 *  ![1004194-20161107083330108-1194426772.png][]

**Presto低延迟原理**

--------------------

*  完全基于内存的并行计算
 *  流水线式计算作业
 *  本地化计算
 *  动态编译执行计划
 *  GC控制

**Presto存储插件**

--------------------

*  Presto设计了一个简单的数据存储的抽象层， 来满足在不同数据存储系统之上都可以使用SQL进行查询。
 *  存储插件（连接器,connector）只需要提供实现以下操作的接口， 包括对元数据（metadata）的提取，获得数据存储的位置，获取数据本身的操作等。
 *  除了我们主要使用的Hive/HDFS后台系统之外， 我们也开发了一些连接其他系统的Presto 连接器，包括HBase，Scribe和定制开发的系统
 *  插件结构图如下：
 *  ![1004194-20161107084550842-1772079215.png][]

**presto执行过程**

--------------------

*  执行过程示意图：
 *  **![1004194-20161107110112639-678373869.png][]**
 *  **提交查询：**用户使用Presto Cli提交一个查询语句后，Cli使用HTTP协议与Coordinator通信，Coordinator收到查询请求后调用SqlParser解析SQL语句得到Statement对象，并将Statement封装成一个QueryStarter对象放入线程池中等待执行，如下图:示例SQL如下
    
     *  ![1004194-20161107083602124-1044495484.png][]
 *      select c1.rank, count(*) from dim.city c1 join dim.city c2 on c1.id = c2.id where c1.id > 10 group by c1.rank limit 10;
 *  逻辑执行过程示意图如下：
 *  ![1004194-20161107094837092-994073244.png][]
 *  上图逻辑执行计划图中的虚线就是Presto对逻辑执行计划的切分点，逻辑计划Plan生成的SubPlan分为四个部分，每一个SubPlan都会提交到一个或者多个Worker节点上执行
 *  SubPlan有几个重要的属性planDistribution、outputPartitioning、partitionBy属性整个执行过程的流程图如下：
    
    1.  PlanDistribution：表示一个查询阶段的分发方式，上图中的4个SubPlan共有3种不同的PlanDistribution方式
        
         *  Source：表示这个SubPlan是数据源，Source类型的任务会按照数据源大小确定分配多少个节点进行执行
         *  Fixed： 表示这个SubPlan会分配固定的节点数进行执行（Config配置中的query.initial-hash-partitions参数配置，默认是8）
         *  None： 表示这个SubPlan只分配到一个节点进行执行
    2.  OutputPartitioning：表示这个SubPlan的输出是否按照partitionBy的key值对数据进行Shuffle*（洗牌）*， 只有两个值HASH和NONE
 *  
 *  ![1004194-20161107100306295-1308269330.png][]
 *  在上图的执行计划中，SubPlan1和SubPlan0 PlanDistribution=Source，这两个SubPlan都是提供数据源的节点，SubPlan1所有节点的读取数据都会发向SubPlan0的每一个节点；SubPlan2分配8个节点执行最终的聚合操作；SubPlan3只负责输出最后计算完成的数据，如下图：
 *  ![1004194-20161107104024717-1623678070.png][]
 *  SubPlan1和SubPlan0 作为Source节点，它们读取HDFS文件数据的方式就是调用的HDFS InputSplit API，然后每个InputSplit分配一个Worker节点去执行，每个Worker节点分配的InputSplit数目上限是参数可配置的，Config中的query.max-pending-splits-per-node参数配置，默认是100
 *  SubPlan1的每个节点读取一个Split的数据并过滤后将数据分发给每个SubPlan0节点进行Join操作和Partial Aggr操作
 *  SubPlan0的每个节点计算完成后按GroupBy Key的Hash值将数据分发到不同的SubPlan2节点
 *  所有SubPlan2节点计算完成后将数据分发到SubPlan3节点
 *  SubPlan3节点计算完成后通知Coordinator结束查询，并将数据发送给Coordinator

**presto引擎对比**

--------------------

*  与hive、SparkSQL对比结果图
 *  ![1004194-20161107110246155-560444169.png][]

[1004194-20161105161906033-1520472358.png]: /images/20220519/b2398faed0f24970ba0eab353c73678d.png
[1004194-20161107083330108-1194426772.png]: /images/20220519/2804d615e97b4cc8ab9c08fa77636b4a.png
[1004194-20161107084550842-1772079215.png]: /images/20220519/2b5512b68ddc417ca4cad24058eebdc3.png
[1004194-20161107110112639-678373869.png]: /images/20220519/c6f6f653eef849baa39852ccf199e313.png
[1004194-20161107083602124-1044495484.png]: /images/20220519/23c1cf7a88bd4d56b0d70f575550163a.png
[1004194-20161107094837092-994073244.png]: /images/20220519/164f51f7e6754312ac9cbb3a9b464e08.png
[1004194-20161107100306295-1308269330.png]: /images/20220519/879fc534aa174f92b14c7e5dbe3ca1f1.png
[1004194-20161107104024717-1623678070.png]: /images/20220519/f28724dbe9e5492f8f737a61379f2cd4.png
[1004194-20161107110246155-560444169.png]: /images/20220519/405158f3de1848d9b66235e67e05096c.png