💨概述
💨大数据与OLAP
🎈什么是大数据？
大数据其实是在2000年后，因 为信息化的快速发展。信息交换、信息 存储、信息处理三个方面能力的大幅增 长而产生的数据。
🎈Hadoop
基于廉价机器的存算分离的大规模分布式处理系统
🎈OLAP
OLAP 是 在线分析处理，顾名思义就是OLAP是 用于数据分析的；因此，它使我们能够同时分析来自多个数据库系统的信息。换句话说，我们可以说它是一种计算方法，可以让用户轻松提取所需的数据并查询数据，以便从不同的角度进行分析。OLAP(OnLine Analytical Processing对业务数据执行多维分析，并提供复杂计算，趋势分析和复杂 数据建模的能力。是许多商务智能(BI) 应用程序背后的技术。 🚩它基本上是基于庞大的数据，称为数据仓库；
🚩它从数据仓库中收集所需的数据并执行业务所需的分析，以在业务中做出一些决策，以提高利润、改善销售、改善品牌、改善营销等等。🚩因此，它在商业智能中用于趋势分析、销售预测、财务报告、计划目的、预算等方面的查询辅助。
🎈常见的OLAP引擎
🚩预计算引擎: Kylin, Druid🚩批式处理引擎: Hive, Spark🚩流式处理引擎: Flink🚩交互式处理引擎: Presto, Clickhouse, Doris
💨Presto设计思想
🎈Presto是什么
Presto是 Facebook 推出的一个开源的分布式SQL查询引擎，数据规模可以支持GB到PB级，主要应用于处理秒级查询的场景。
Presto 的设计和编写完全是为了解决像 Facebook 这样规模的商业数据仓库的 交互式分析和处理速度的问题。
🎈特点
🚩多租户任务的管理与调度🚩多数据源联邦查询🚩支持内存化计算🚩Pipeline式数据处理
💨Presto基础原理与概念
💨基础概念
🎈服务相关
Coordinator：①解析SQL语句②生成执行计划③分发执行任务给Worker节点Worker：①执行Task处理数据②与其他Worker交互传输数据
🎈数据源相关
🚩Connector:以个Connector代表种数据源。可以认为Connector是由Presto提供的适配多数据源的统一接口。🚩Catalog:管理元信息与实际数据的映射关系。
🎈Query相关
🚩Query：基于SQL parser后获得的执行计划🚩Stage：根据是否需要shufle将Query拆分成不同的subplan,每一个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中只是最小的容器，而不是最小的执行单元)，LocalExchange的默认数值是16。
如何衡量某个任务某个Stage的真实并行度?
在不同Pipeline下Split (Driver)的数目之和。
💨核心组件架构介绍
✔架构图
🎈服务发现
Discovery Service：🚩Worker配置文件配置Discovery Service地址🚩Worker节点启动后会向Discovery Service注册🚩Coordiantor从Discovery Service获取Worker的地址
🎈通信机制
🚩Presto Client / JDBC Client与Server间通信：Http🚩Coordinator与Worker间的通信：Thrift / Http🚩Worker与Worker间的通信：Thrift / Http
Thrift相比于Http具有更好的数据编码能力，Http 1.1还不支持头部信息的压缩，Thrift 具有更好的数据压缩率。
Presto 是一个运行在多台服务器上的分布式系统。完整安装包括一个 Coordinator 和多 个 Worker。由客户端提交查询，从 Presto 命令行 CLI 提交到 Coordinator。Coordinator 进行 解析，分析并执行查询计划，然后分发处理队列到 Worker 。
💨Presto重要机制
💨多租户资源管理
🎈Resource Group
🚩类似Yarn多级队列的资源管理方式🚩基于CPU、MEMORY、SQL 执行数进行资源使用量限制
优点：轻量的Query级别的多级队列资源管理模式
缺点：存在一定滞后性，只会对Group 中正在运行的SQL进行判断
💨多租户下的任务调度
🎈物理生成
🚩Antlr4解析生成AST🚩转换成Logical Plan🚩按照是否存在Shuffle (Exchange) ，切分成不同的Stage (Fragment)
🎈Stage调度
同时调度分阶段调度
🚩PhasedExecutionPolicy:不代表每个stage都分开调度
🍳典型的应用场景(join查询)
🚩Build 端:右表构建用户join的hashtable🚩Probe 端:对用户左表数据进行探查, 需要等待build端完成🚩Build 端构建hashtable端时，probe 端是一直在空跑的
🍳Stage的调度策略:
延迟点，会存在任务空跑有一定延迟、节省部分资源
🎈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.优先保证小Query快速执行 2.保障大Query存在固定比例的时间片，不会被完全饿死
💨内存计算
🎈Pipeline化的数据处理
Pipeline的引入更好的实现算子间的并行语义上保证了每个Task内的数据流式处理
🎈Back Pressure Mechanism
控制split生成流程控制operator的执行
💨多数据源联邦查询
将各个数据源进行统一的抽象， 最后由presto server进行统一的物理执行。
局限性:🚩元数据管理与映射(每个connector管理一套元数据服务)🚩谓词下推🚩数据源分片
- Presto 与 Hive 对比，都能够处理 PB 级别的海量数据分析，但 Presto 是基于内存运算，减少没必要的硬盘 IO，所以更快
- 能够连接多个数据源，跨数据源连表查，如从 Hive 查询大量网站访问记录，然后从 Mysql 中匹配出设备信息
