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

一、概述

1、大数据与OLAP的演进

（1）大数据

我们参考马丁.希尔伯特的总结:大数据其实是在2000年后，因为信息化的快速发展。信息交换通信和网络带宽的大幅增长、信息存储计算机存储量的大幅增长、信息处理整理、转换、分析数据的能力大幅增长三个方面能力的大幅增长而产生的数据。

（2）Hadoop基于廉价机器的存储分离的大规模分布式处理系统

存储分离：不需要存储结点、计算结点在同一台物理主机上。这样可以降低成为，例如可以在CPU性能好的机器上进行计算，在CPU性能差但是磁盘大的机器上负责存储。

• 谷歌在2003、2004年发布Google File System论文介绍分布式存储，MapReduce论文。
• 2008年Hadoop成为Apache顶级项目。

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

（4）OLAP VS MapReduce

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

（5）OLAP核心概念

• 维度：表中电子产品、上海、四月等。
• 度量：某种东西某段时间在某地区的销量。

（6）常见引擎

• 预计算引擎：Kylin，Druid 预计算：空间换实践，假设要计算一年的量，把天聚合成月后直接加十二个月即可
• 批式处理引擎注重吞吐量模型：Hive、Spark
• 流式处理引擎注重实时性、产生数据、用户体验（多久输出结果）：Flink
• 交互式处理引擎查询时延，做数据分析。提升用户体验：Presto、Clickhouse、Doris

2、Presto设计思想

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

（1）特点

• 多租户任务的管理与调度。
• 多数据源联邦查询。联邦查询：支持多个数据源join做联合分析
• 支持内存化计算。
• Pipeline式数据处理。

下层数据源，上层数据报表把结果展示给用户。

（2）二次研发

• Prestodb：github.com/prestodb/pr…
• Trino:github.com/trinodb/tri…
• Openlookeng:github.com/openlookeng…

二、Presto基础原理与概念

1、基础概念

（1）服务相关（架构图）

黄色是数据源，绿色是Presto服务。可以看到一个Presto服务对应一个数据源

• Coordinator负责调度：解析SQL语句、生成执行计划、分发计划任务给worker节点。

• Worker:执行Task处理数据、与其他worker交互传输数据。

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

• Discovery Service（将coordinator和woker结合到一起的服务）:下面有介绍

  • Worker节点启动后向Discovery Server服务注册
  • Coordinator从Discovery Server获得Worker节点

所有的worker都把自己注册到Discovery Server上，Discovery Server是一个发现服务的service，Discovery Server发现服务之后，coordinator便知道在集群中有多少个worker能够工作，分配工作到worker时便有了根据。

（2）数据源相关

• Connector:代表数据源，可以认为是由Presto提供的适配多数据源的统一接口。

• Catalog:针对不同的数据源，Connector和Catalog是一一对象应的，Catalog包含了Schema和Data Source管理员信息与实际数据的映射关系。

（3）Query相关

• Query：基于SQL Parser后获得的执行计划。

• Stage：根据是否需要Shuffle将QUery拆分成不同的subplan，每一个subplan便是一个stage。

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

• Task：单个Worker节点上的最小资源管理单元，在一个节点上，一个Stage只有一个Task。一个Query可能有多个Task。

• Pipeline：Stage按照LocalExchange切分成若干OPerator集合，每个集合定义一个Pipeline。一组数据顺序处理

• Diver：Pileline的可执行实体，Pipeline和Driver的关系可类比程序和进程，是最小的执行单元，通过火山迭代模型执行每一个Operator。

• Split：输入数据描述（数据实体是Page）数量上和Driver一一对应，不仅代表实际数据源Split，也代表了不同Stage间传输的数据。

• Operator：最小的物理算子。

（4）数据传输相关

• Exchange：表示不同Stage间的数据传输，大多数意义下等价于Shuffle。

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

（5）多租户下的任务调度--数据传输相关 Q:如何衡量某个任务某个Stage的真实并行度？

A:在不同Pipeline下Split（Driver）的数目之和。work并行度=work数x16+Pipeline

2、Presto核心组件架构

（1）服务发现

Discovery Service：1、worker配置Discovery Service地址。2、Worker节点启动后会向DS注册。3、Coordiantor从Discovery Service获取Worker的地址。

（2）通信机制

• Presto Client/JDBC Client与Server间通信--Http
• Coordiator与Worker间的通信--Thrift/Http
• Worker与Worker间的通信--Thrift/Http

Thrift是RPC框架，具有更好的数据编码能力，Http1.1还不支持头部信息的压缩，Thrift具有更好的数据压缩率。

节点状态：Active、Inactive、ShutdownST想关闭但是可以处理数据。优点：不会再调度Task，设置超时时间，work再时间内把Task处理完，超时后，强行关闭。

三、Presto重要机制

1、多租户资源管理

• Presto用户多租户隔离手段是什么？

presto通过Resource Group对不同的用户创建不同的Group从而实现不同租户，不同场景的资源管理。

（1）Case介绍

根据顾客类型选择表内平均花销数据中排序后前十名。

（2）Resource Group类似于YARN多级队列的资源管理方式，基于CPU、Memory、SQL执行数进行资源使用量限制

• 优点：支持通配符的形式，对不同租户不同提交场景下的用户进行限制。
• 缺点：资源的管理和判断是以当前用户正在运行的SQL资源使用量为基准，对于低频大SQL场景不太适用。

• handConCurrencyLimit：并行度限制。
• 最后一个group是默认组，没有匹配项信息都可以选他。

轻量：基于通配符，和信息自动生成队列，没有新增数据，

2、多租户下的任务调度

（1）物理计划生成

• Aggregation（partial）Node：局部聚合。
• Aggregation（final）Node：最终聚合。
• TopN：局部排序减少数据，假设十万个数据，分十组每组一万个数据，依次分组，最后再每组100个里面取前十。

（2）Stage调度

• AllAtOnceExecutionPolicy：同时调度优点：开始Stage启动，上游data可边分析边传下游，无需等待。延迟低，会出现任务空跑调度方式
• PhasedExecutionPolicy：分阶段调度不是每个Stage都能分开调度有延迟，节省部分资源调度方式

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

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

（3）Task调度

黄色数据汇总前十个，从下往上看

• Coordinator_Only:知道元数据结果就无需计算了

1、选择什么样的节点调度方式

• Hard_Affinty:计算存储Local模式，保障计算与存储再同一个节点，减少数据传输。
• Soft_Affinty:基于某些特定算法，如一致性Hash函数，常用于缓存场景，保证相似的Task调度到同一个Worker。
• No_preference:随机选取，常用于普通的纯计算Task。根据work复杂状态随机选取work调度作业，90%应用此节点

（4）Split调度

Query A大SQL先提交，但可能提交完之后集群复杂就满了。如何先提交小的呢？怎么排下序呢？

3、内存计算

（1）Pipeline化数据处理

• 分为两层：一层用于Task内LogcalExchange拆分不同并行度成不同的Pipeline。一层用于Stage调度。
• 它的引入更好的实现算子间的并行，语义上保证了每个Task内的数据流式处理。

（2）Back Pressure Mechanism实现方式

4、多数据源联邦查询

• 将各个数据源进行统一的抽象，最后由Presto server进行统一的物理执行。

（1）局限性：

• 元数据管理与映射（每个connector管理一套元数据服务），每个数据源都需要单独的一套Catalog管理，
• 谓词下推
• 如何针对数据源进行分片操作

Presto流数据（数据处理模式不是生产）处理再Stage里，边执行边传输。OLAP和流区别在于生产端和消费端

四、性能优化实践

1、常用性能分析工具

（1）Grafana

（2）Java指令相关

• Jstack:查看Java线程栈信息，排查是否有死锁，或者异常线程存在。

• JMX（Java Management Extensions）：一个为应用程序植入管理功能的框架，常用来一些监控指标的统计收集。

• JMAP&GC日志等等内存分析工具

（3）线上问题排查工具

阿里Artha

• Watch：监控每个函数入参、返回参数、异常的信息。

• Trace ：统计函数内每一步的执行时间找到异常点前提是大体知道异常出现在哪里

• Flame Figure火焰图分析性能瓶颈用于分析热点代码占有大量CPU，从而导致服务性能下降的情况。入栈出栈CPU占比，按函数关系往上走，上层越宽表示当前CPU耗时越久，我们关注最宽的函数调用

（4）Presto UI

2、案例分析

（1）Case 1：

Clone不需要rehash，减少时间消耗。 分析：

（2）Case 2：

正则表达式耗时，以天危级别可能触发，远程资源无限扩展。

（3）字节内部优化

• MUlti Coordinator

不可用时间从几分钟到3s内

• History Server

• Support Remote UDF

• Raptor X的多级缓存

五、课后自测

1. 能否区分task、pipline、split、driver等worker侧的概念

2. 本节课讲授的Presto重要机制有哪些？

3. 能否完整的描述一遍Presto多租户调度中的相关流程？

4. Pipeline化数据处理是否等价于流式计算？

5. 能否实现可中断的正则表达式，性能与普通正则表达式相比如何？