这是我参与「第四届青训营」笔记创作活动的的第7天
presto概述
大数据与OLAP
- OLAP (OnLine Analytical Processing) 对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂数据建模的能力。是许多商务智能（BI）应用程序背后的技术。现如今OLAP已经发展为基于数据库通过SQL对外提供分析能力。
- OLAP核心概念：维度、度量
presto设计思路
Presto最初是由facebook研发的构建于Hadoop/HDFS系统之上的PB级交互式分析引擎，其具有如下的特点：
- 多租户任务的管理与调度
- 多数据源联邦查询
- 支持内存化计算
- pipeline式数据处理
presto二次开发项目：prestodb、trino、openlookeng
presto基础原理
presto架构图
服务相关概念
- coordinator：解析SQL语句；生成执行计划；分发执行任务给worker节点
- worker：执行task处理数据，与其他worker交互传输数据
数据源相关概念
- connector：代表数据源。connector是由presto提供的适配多数据源的统一接口
- catalog：管理元信息与实际数据的映射关系
query相关概念
query：基于SQL parser后获得的执行计划 stage：根据是否需要shuffle将query拆分成不同的subplan，每一个subplan便是stage fragment：基本等价于stage，只是不同阶段 task：单个worker节点上的最小资源管理单元，其中在一个节点上，一个stage只有一个task，一个query可能有多个task
数据传输相关
- exchange:表示不同stage间的数据传输，大致等价于shuffle
- localExchange：stage内的rehash操作，用于提高并行处理数据的能力，默认数值为16
- 某个任务某个stage的真实并行度为不同pipeline下driver的数目之和
通信机制
http通用，coordinator与worker、worker与worker间的通信可thrift/http。
Http 1.1 vs Thrift
Thrift具有更好的数据编码能力，Http 1.1还不支持头部信息的压缩，Thrift具有更好的数据压缩率
节点状态
active inactive shutdowm
presto重要机制
Presto用户多租户隔离的手段是什么？
- 通过Resource Group对不同的用户创建不同Group从而实现不同租户，不同场景的资源管理。
- Resource Group类似yarn多级队列的资源管理方式，基于CPU、memory、SQL执行数进行资源使用量限制
- 优点：轻量的query级别的多级队列资源管理方式
- 缺点：滞后性，只会对group中正在运行的SQL进行判断
Presto是从哪几个方面实现了多租户的任务调度
- Stage调度策略
- Task的节点选择策略
- Split调度策略
Presto Stage调度的方式有哪些？
- AllAtOnceExecutionPolicy 同时调度，会存在任务空跑
- PhasedExecutionPolicy 分阶段调度，有一定的延迟，节省部分资源
Presto 进行 Task 调度时，有哪些调度方式？
- HARD_AFFINITY： 计算、存储 Local 模式，保障计算与存储在同一个节点，减少数据传输
- SOFT_AFFINITY：基于某些特定算法，如一致性HASH函数，常用于缓存场景，保证相似的 Task 调度到同一个 Worker
- NO_PREFERENCE：随机选取，常用于普通的纯计算 Task
内存计算
- pipeline化的数据处理：按localexchange拆分，更好地实现算子间的并行，保证了每个task内的数据流式处理
- back pressure mechanism：控制split生成流程，控制operator的执行
多数据源联邦查询
将各个数据源进行统一的抽象，最后由presto server进行统一的物理执行
- 优点：支持多数据源的联邦查询
- 缺点：针对不同数据源，还存在许多问题需要解决
- 谓词下推
- 每个数据源都需要单独的一套catalog管理
- 如何针对数据源进行分片操作
性能优化
常见性能优化工具
grafana
埋点、系统指标等的可视化界面，时序化的数据展示
线上问题排查工具：arthas
- watch：监控每个函数入参、返回参数、异常等信息
- trace：统计函数内每一步的执行时间
线上问题排查工具：flame figure火焰图
用于分析热点代码占用大量CPU，从而导致服务性能下降的情况。自底向上为调用关系，上层宽度越宽表示当前函数CPU耗时越久。
java相关指令
- jstack查看java线程栈信息，排查有无死锁或异常线程
- java management extensions，为应用程序植入管理功能的框架，用于监控指标的统计收集
- JMAP/GC日志，内存分析工具
案例
减少 hadoop 配置构建时间
对于具有大量分区的表，创建hadoop配置会消耗大量的cpu时间。特别是“hdfs-site.xml”和“core-site.xml”文件很大。
描述
数据：tpcds 1T
表：store_returns（约2000个分区）
sql：select count(*) from store_returns
查询执行时间：约3-4s
问题
发现函数'ConfigurationUtil.copy'消耗了cpu时间。
因为复制功能会遍历旧配置，然后设置为新配置，这会导致map rehash操作和其他cpu消耗操作。
解决方案
- 配置支持由其他配置构建。所以我们不需要使用 ConfigurationUtil.copy 函数。
- 对底层数据直接clone
- 通过优化配置构建流程，查询运行时间从4秒缩短到1秒
SQL执行缓慢，某几个节点CPU负载特别高
- 正则表达式不可中断，阻塞了split的优先级调度；与正则表达式匹配的实际数据不可控
- 解决思路：实现一个可中断的正则表达式；
优化实践
multi coordinator
- 针对coordinator 单节点稳定性差
- 不可用时间大幅减少，实现高可用的效果；实现coordinator多活，压力分担
History server
提供与presto UI相同体验与持久化的数据存储，解决SQL历史长期的查询问题，持久化体验
support remote UDF
- 统一的UDF抽象，适配多引擎
- 多租户的内核与网络隔离
