这是我参与「第四届青训营 」笔记创作活动的第2天 1.概述 大数据与olap系统的改进（信息交换，信息处理，信息存储三方面能力大幅度增长而产生的数据） 2.presto架构图
服务： 基础概念服务： coordinator worker
数据源： commentor catalog
query： query stage fragment task
数据传输： pipeline>driver>split>opertor>exchange^local exchange>local exchange
2.2coordinator与worker如何协调和工作 服务发现： worker配置文件配置discovery service地址 worker节点启动后会向discover service注册 connector 获得相应信息
通信机制 除了client和server通信除外，其他的通信都是支持两种以上的通信协议的 thrift具有更好的数据编码能力，HTTP暂时不支持头部信息的压缩
节点状态 active，inactive，shutdown（优雅的扩容，可以感受到状态，就是一个超时时间，worker就尽量让在跑的worker跑完）
3.presto重要机制 3.1多租户资源管理 resource group 类似yarn多级队列的资源管理方式 基于CPU，memory,SQL执行数进行资源使用量限制
优点：轻量的query级别的多级队列资源管理模式 缺点：存在一定滞后性，只对group中正在运行的SQL进行判断
物理计划生成 解析-转化成logical plan-按照是否存在shuffle，切分成不同的stage
3.2多租户下的任务调度 stage调度 同时调度 不代表每个stage都分开调度 build端，probe端，build端构建hashtable端时
allatonce延迟低会存在任务空跑 phase有一定延迟，节省部分资源
+分阶段调度
task调度 数量如何确定（source，fixed，sink,scaled,coordinator-only） 选择什么样的节点（hard：计算、存储local模式，soft：基于某些特定算法，nopreference：随机选取）
split调度 queryA大SQL先提交 queryB小SQL先提交 引出以下内容：split调度 FIFO:顺序执行，绝对公平 优先级调度：快速响应
优势： 优先保障小query快速执行 保障大query存在固定比例的时间片，不会被完全饿死
3.3内存计算 pipeline化的数据处理 按localexchange拆分
back pressure mechanism（反压机制） 控制split生成流程+控制operator的执行
3.4多数据源联邦查询 将各个数据源进行统一的抽象，最后由presto server进行统一的物理执行
局限性 元数据管理与映射 谓词下推 数据源分片
4.性能优化实战
4.1常用性能分析工具 grafana：埋点系统等 java相关指令：jstack查看java线程栈信息，jmx,jmap&gc日志等内存分析工具 线上问题排查工具：arthas, presto ui
4.2具体案例分析
