Presto架构原理与优化介绍|青训营笔记

柏杨921
140 阅读8分钟

这是我参与「第四届青训营 」笔记创作活动的的第8天

一、概述

1.大数据与OLAP的演进

马丁·希尔伯特的总结：大数据其实是在2000年后，因为信息化的快速发展、信息交换、信息存储、信息处理三个方面能力的大幅增长而产生的数据。

image.png

  • 信息交换
    通信和网络带宽的大幅增长
  • 信息存储
    计算机存储量的大幅增长
  • 信息处理
    整理、转换、分析数据的能力大幅增长

Hadoop：基于廉价机器的存算分离的大规模分布式处理系统（cpu性能好的进行计算，差的进行存储）

1.谷歌在2003、2004年发布Google File System论文，Mapreduce论文

2.2008年，Hadoop成为apache顶级项目

OLAP对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能（BI）应用程序背后的技术。

OLAP VS MapReduce

  1. MapReduce代表了抽象的物理执行模型，使用门槛较高
  2. 与Mapreduce Job相比，OLAP引擎通过SQL的形式，为数据分析、数据开发人员提供统一的逻辑描述语言，实际的物理执行由具体的引擎进行转换和优化。

OLAP核心概念：维度、度量

image.png

常见的OLAP引擎：

  • 预计算引擎: Kylin,Druid 用空间换取时间
  • 批式处理引擎: Hive,Spark 注重吞吐量
  • 流式处理引擎: Flink 注重实时性
  • 交互式处理引擎: Presto,Clickhouse,Doris 解决查询时延，提升用户体验

2.Presto设计思想

Presto 最初是由Facebook研发的构建于Hadoop/HDFS系统上的PB级交互式分析引擎。

特点:

  • 多租户任务的管理与调度
  • 多数据源联邦查询
  • 支持内存化计算
  • Pipeline式数据处理

二、Presto基础原理与概念

1.基础概念介绍

基础概念介绍-服务相关

image.png 蓝色用户client提交query，通过绿色部分服务，查询黄色部分是数据源部分，产出结果。 基础概念介绍-服务相关

  • Coordinator（负责调度）：

    • 解析SQL语句
    • ⽣成执⾏计划
    • 分发执⾏任务给Worker节点执⾏

  • Worker

  • 在一个presto集群中，存在一个coordinator节点和多个worker节点，coordinator节点是管理节点，而worker节点就是工作节点，在每个worker节点上都会存在一个worker服务进程，该服务进程主要进行数据的处理以及task的执行，worker服务进程每隔一定的时间都会向coordinator上的服务发送心跳，接受调度。当客户端提交一个查询的时候，coordinator则会从当前存活的worker列表中选择出适合的worker节点去运行task，而worker在执行每个task的时候又会进一步对当前task读入的每个split进行一系列的操作和处理

基础概念介绍-数据源相关

image.png

  • Connector Presto通过Connector来支持多数据源，一个Connector代表一种数据源，Connector是适配器，用于Presto和数据源（如Hive、RDBMS）的连接，每个catalog都有一个特定的Connector，一个或多个catelog用同样的connector是访问同样的数据库。

  • Catalog 就是数据源。管理元信息与实际数据的映射关系。与每个数据源连接都有一个名字，一个Catalog可以包含多个Schema，大家可以通过show catalogs 命令看到Presto已连接的所有数据源。

  • schema 相当于一个数据库实例，一个Schema包含多张数据表。通过以下方式可列出catalog_name下的所有 Schema：show schemas from 'catalog_name'

  • Table 数据表，与RDBMS上的数据库表意义相同。通过以下方式可查看'catalog_name.schema_name'下的所有表：show tables from 'catalog_name.schema_name'

基础概念介绍-Query相关

  • Query 当Presto解析一个语句时，它将其转换为一个查询，并创建一个分布式查询计划（多个互信连接的stage，运行在Worker上）。如果想获取Presto的查询情况，则获取每个组件（正在执行这语句的结点）的快照。查询和语句的区别是，语句是存SQL文本，而查询是配置和实例化的组件。

  • Stage 当Presto执行查询时，会将执行拆分为有层次结构的stage。例如，从hive中的10亿行数据中聚合数据，此时会创建一个用于聚合的根stage，用于聚合其他stage的数据。层次结构的stage类似一棵树。每个查询都由一个根stage，用于聚合其他stage的数据。stage是Coordinator的分布式查询计划（distributed query plan）的模型，stage不是在worker上运行。

  • Fragment 基本等价于Stage，属于在不同阶段的称呼，在本门课程可以认为两者等价

  • Task 每个Worker节点上的最小资源管理单元：在一个节点上，一个stage只有一个task，一个query可能有多个task。由于stage不是在worker上运行。stage又会被分为多个task，在不同的work上执行。Task是Presto结构里是“work horse”。一个分布式查询计划会被拆分为多个stage，并再转为task，然后task就运行或处理split。Task有输入和输出，一个stage可以分为多个并行执行的task，一个task可以分为多个并行执行的driver。

  • Pipeline Stage 按照 LocalExchange 切分为若干 Operator 集合, 每个 Operator 集合定义一个 Pipeline。

  • Driver Task包含一个或多个并行的driver。Driver在数据上处理，并生成输出，然后由Task聚合，最后传送给stage的其他task。一个driver是Operator的序列。driver是Presto最最低层的并行机制。一个driver有一个输出和一个输入。Pipeline的可执行实体，pipeline和driver的关系可类比程序和进行，是最小的执行单元，通过火山迭代模型执行每一个operator。

  • Split Task运行在split上。split是一个大数据集合中的一块。是输入数据描述，数量上和driver一一对应，不仅代表实际数据源split，也代表了不同stage间传输的数据。分布式查询计划最底层的stage是通过split从connector上获取数据，分布式查询计划中间层或顶层则是从它们下层的stage获取数据。

  • Operator Operator消费，传送和生产数据。最小的物理算子。如一个Operator从connector中扫表获取数据，然后生产数据给其他Operator消费。一个过滤Operator消费数据，并应用谓词，最后生产出子集数据。

基础概念介绍-数据传输相关

  • Exchange Exchange在Presto结点的不同stage之间传送数据。Task生产和消费数据是通过Exchange客户端，表示不同 Stage 间的数据传输，大多数意义下等价于 Shuffle。

  • LocalExchange Stage内的 rehash 操作，常用于提高并行处理数据的能力。（Task在presto中只是最小的容器，而不是最小的执行单元）

多租户下的任务调度-数据传输相关

如何衡量某个任务某个stage的真实并行度？ 在不同pipeline下split（driver）的数目之和。

2.核心组件架构介绍

image.png

服务发现

image.png Discovery Service

  1. Worker配置文件配置Discovery Service
  2. Worker节点启动后会向Discovery Service注册
  3. Coordiantor从Discovery Service获取Worker的地址，从而达到集群管理

通信机制

  1. Presto Client/JDBC Client与Sever间通信：http
  2. Coordinator与worker间的通信：Thrift/Http
  3. Worker与Worker间的通信：Thrift/Http Thrift具有更好的数据编码能力，具有更好的数据压缩率

节点状态：

  • ACTIVE
  • INACTIVE
  • SHUTDOWN

三、Presto重要机制

1.多租户资源管理

Resource Group

  • 类似于Yarn多级队列的资源管理方式
  • 基于CPU、MEMORY、SQL执行数进行资源使用量限制

优点:  轻量的Query级别的多级队列资源管理模式

缺点:  存在一定的滞后性，只会对Group中正在运行的SQL进行判断

2.多租户下任务调度

1.Antlr4解析生成AST

2.转换成Logical Plan

3.按照是否存在Shuffle，切分成不同的Stage

image.png Stage的调度策略

  • AllAtOnceExecutionPolicy：同时调度，延迟低，会存在任务空跑
  • PhasedExecutionPolicy：分阶段调度，有一定延迟、节省部分资源

PhasedExecutionPolicy

  • 不代表每个Stage都分开调度

典型的应用场景（join查询）

  • Build端：右表构建用户join的hashtable
  • Probe端口：对用户左表数据进行探查，需要等待build端完成
  • Build端构建hashtable端时，probe端是一只在跑空的

image.png

  • Task的数量如何确定
  • 选择什么样的节点（调度方式有哪些）

Task的数量如何确定：

  • Source：根据数据meta决定分配多少个节点
  • Fixed：hash partition count确定，如集群节点数量
  • Sink：汇聚结构，一台机器
  • Scaled：无分区限制，可拓展，如write数据
  • Coordinator_Only：只需要coordinator参与

image.png

选择什么样的节点：

  • HARD_AFFINITY: 计算、存储Local模式，保障计算与存储在同一个节点，减少数据传输
  • SOFT_AFFINITY: 基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证相似的Task调度到同一个Worker
  • NO_PREFERENCE: 随机选取，常用于普通的纯计算Task
avatar
文章
阅读
粉丝