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

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

• 概述
  • 大数据与OLAP系统的演进
    • Hadoop
      • 基于廉价机器的存算分离的大规模分布式处理系统
    • OLAP(Online Analytical Processing)
      • 对业务数据进行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能(BI)应用程序背后的技术。
    • OLAP VS MapReduce
      • MapReduce代表了抽象的物理执行模型，使用门槛较高
      • 与MapReduce Job相比，OLAP引擎常通过SQL的形式，为数据分析、数据开发人员提供统一的逻辑描述语言，实际的物理执行由具体的引擎进行转换和优化。
    • OLAP核心概念
      • 维度
      • 度量
    • 常见的OLAP引擎
      • 预计算引擎
        • Kylin
        • Druid
      • 批式处理引擎
        • Hive
        • Spark
      • 流式处理引擎
        • Flink
      • 交互式处理引擎
        • Presto
        • ClickHouse
        • Doris
  • Presto设计思想
    • Presto最初是由Facebook研发的构建于Hadoop/HDFS系统之上的PB级交互式分析引擎，其具有如下的特点
      • 多租户任务的管理和调度
      • 多数据源联邦查询
      • 支持内存化计算
      • Pipeline式数据处理
• Presto基础原理和概念
  • 基础概念
    • 服务相关
      • Coordinator
        • 解析SQL语句
        • 生成执行计划
        • 分发执行任务给Worker节点
      • Worker
        • 执行Task处理数据
        • 与其他Worker交互传输数据
    • 数据源相关
      • Connector
        • 一个Connector代表一种数据源。可以认为Connector是由Presto提供的适配多数据源的统一接口
      • Catalog
        • 管理元信息与实际数据的映射关系
    • Query相关
      • Query
        • 基于SQL parser后获得的执行计划
      • Stage
        • 根据是否需要Shuffle将Query拆分到不同的Task，每一个subplan便是一个stage
      • Fragment
        • 基本等价于Stage，属于在不同阶段的称呼，在本门课程可以认为两者等价
      • Task
        • 单个Worker节点上的最小资源管理单元
        • 在一个节点上，一个Stage只有一个Task，一个Query可能有多个Task
      • Pipeline
        • Stage按照LocalExchange切分为若干个Operator集合，每个Operator集合定义一个Pipeline
      • Driver
        • Pipeline的可执行实体，Pipeline和Driver的关系可类比程序和进程，是最小的执行单元，通过火山迭代模型执行每一个Operator
      • Split
        • 输入数据描述(数据实体是Page)，数量上和Driver一一对应，不仅代表实际数据源Split，也嗲表了不同Stage间传输的数据
      • Operator
        • 最小的物理算子
    • 数据传输相关
      • Exchange
        • 表示不同Stage间的数据传输，大多数意义下等价于Shuffle
      • LocalExchange
        • Stage内的rehash操作，常用于提高并行处理数据的能力(Task在Presto中只是最小的容器，而不是最小的执行单元)
  • 核心组件架构
    • 服务发现
      • Worker配置文件配置服务发现地址
      • Worker节点启动后会向服务发现注册
      • Coordinator从服务发现获取Worker的地址
    • 通信机制
      • Presto Client/JDBC Client与Server间通信
        • http
      • Coordinator与Worker间通信
        • Thrift/http
      • Worker与Worker间通信
        • Thrift/http
      • Thrift vs http1.1
        • Thrift拥有更好的数据编码能力，具有更好的数据压缩率
        • http1.1不支持头部信息的压缩
      • 节点状态
        • ACTIVE
        • INACTIVE
        • SHUTDOWN
          • Graceful Shutdown(优雅的扩缩容)
          • 原本的任务还会处理
• Presto重要机制
  • 多租户资源管理
    • Resource Group
      • 类似Yarn多级队列的资源管理方式
      • 基于CPU、MEMORY、SQL执行数进行资源使用量限制
      • 优点
        • 轻量的Query级别的多级别队列资源管理模式
      • 缺点
        • 存在一定的滞后性，只会对Group中正在运行的SQL进行判断
  • 多租户下的任务调度
    • 物理计划生成
      • Antlr4解析生成AST
      • 转换成Logical Plan
      • 按照是否存在Shuffle(Exchange),切分成不同的Stage(Fragment)
    • Stage调度
      • AllAtOnceExecutionPolicy
        • 同时调度
        • 延迟低，会存在任务空跑
      • PhasedExecutionPolicy
        • 分阶段调度
        • 不代表每个Stage都分开调度
        • 有一定延迟、节省部分资源
      • 典型的应用场景(join查询)
        • Build端
          • 右表构建用户join的hashtable
        • Probe端
          • 对用户左表数据进行探查，需要等待build端完成
        • Build端构建hashtable端时，probe端是一直在空跑的
    • Task调度
      • Task的数量是如何确定
        • Source
          • 根据数据meta决定分配多少节点
        • Fixed
          • hash partition count确定，如集群节点数量
        • Sink
          • 汇聚结果，一台机器
        • Scaled
          • 无分区限制，可拓展，如write数据
        • Coordinator_only
          • 只需要Coordinator参与
      • 选择什么样的节点(调度方式有那些)
        • HARD_AFFINITY
          • 计算、存储local模式，保障计算与存储在同一个节点，减少数据传输
        • SOFT_AFFINITY
          • 基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证相似的Task调度到同一个Worker
        • NO_PREFERENCE
          • 随机选取，常用于普通的纯计算Task
    • Split调度
      • FIFO
        • 顺序执行，绝对公平
      • 优先级调度
        • 快速响应
        • 1. 按照固定的时间片，轮询Split处理数据，处理1s
        • 2. Split间存在优先级
          • MultilevelSplitQueue
            • 5个优先级level理论上分配的时间占比为16:8:4:2:1(2-based)
            • 优势
              • 优先保证小query快速执行
              • 保障大queue存在固定比例的时间片，不会被完全饿死
  • 内存计算
    • pipeline化的数据处理
      • pipeline的引入更好的实现算子间的并行
      • 语义上保证了每个task内的数据流式处理
    • Back Pressure Mechanism
      • 控制split生成流程
        • targetConcurrency auto-scale-out
          • 定时检查，如果OutPutBuffers使用率低于0.5(下游消费较快，需要提高生产速度)，并发度+1
      • 控制operator的执行
        • sink.max-buffer-size写入buffer的大小控制
          • exchange.max-buffer-size读取buffer的大小控制
          • 达到最大值时operator会进入阻塞状态
  • 多数据源联邦查询
    • 将各个数据源进行统一的抽象，最后由presto server进行统一的物理执行
    • 局限性
      • 元数据管理与映射
        • 每个connector管理一套元数据服务
      • 谓词下推
      • 数据源分片
• 性能优化实战
  • 常用性能分析工具
    • Grafana
    • Arthas
    • Java指令
    • Flame Figure火焰图
    • Presto UI
  • 案例分析
  • 字节内部优化实践
    • multi coordinator
    • History Server
      • 原始的Presto UI存储在内存中，无法长时间报错
      • history server提供与Presto UI相同体验&持久化的数据存储
    • Support Remote UDF
      • 统一的UDF抽象，适配多引擎
      • 多租户的内核与网络隔离
    • RaptorX的多级缓存