微商怎么做自己的网站,旅游网站首页设计大概图,微电商平台,做网站收获了什么目录
前言
一、Doris简介
二、SQL解析简介
2.1 词法分析
2.2 语法分析
2.3 逻辑计划
2.4 物理计划
三、Doris SQL解析的总体架构
四、Parse阶段
五、Analyze阶段
六、SinglePlan阶段#xff08;生成单机逻辑Plan阶段#xff09;
七、DistributedPlan计划#xf…目录
前言
一、Doris简介
二、SQL解析简介
2.1 词法分析
2.2 语法分析
2.3 逻辑计划
2.4 物理计划
三、Doris SQL解析的总体架构
四、Parse阶段
五、Analyze阶段
六、SinglePlan阶段生成单机逻辑Plan阶段
七、DistributedPlan计划生成分布式逻辑阶段
7.1 DistributedPlan 概述
7.2 四种join算法
7.2.1 Broadcast Join
7.2.2 Shuffle Join
7.2.3 Bucket Shuffle Join
7.2.4 Colocate Join
7.3 分布式逻辑计划的核心流程
7.3.1 PlanNode
7.3.2 ScanNode
7.3.3 HashJoinNode
八、Schedule阶段
8.1 prepare阶段
8.2 computeScanRangeAssignment阶段
8.3 computeFragmentExecParams阶段
8.4 create result receiver阶段
8.5 to thrift阶段
九、总结
前言 下文主要介绍了Doris SQL解析的原理。阐述了词法分析语法分析生成单机逻辑计划生成分布式逻辑计划生成分布式物理计划的过程。对应代码实现是Parse, Analyze, SinglePlan, DistributedPlan, Schedule这五个部分。
一、Doris简介 Apache Doris是一个基于MPP架构的高性能、实时的分析型数据库能够较好的满足报表分析、即席查询、统一数仓构建等使用场景。Doris整体架构非常简单只有FE和BE两类进程。FE主要负责用户请求的接入、查询解析规划、元数据的管理、节点管理相关工作。BE主要负责数据存储、查询计划的执行。 在 Doris 的存储引擎中用户数据被水平划分为若干个数据分片Tablet也称作数据分桶。每个Tablet 包含若干数据行。多个 Tablet 在逻辑上归属于不同的分区Partition。一个 Tablet 只属于一个 Partition。而一个 Partition 包含若干个 Tablet。Tablet 是数据移动、复制等操作的最小物理存储单元。 官网链接指路
Doris 介绍 - Apache Doris
二、SQL解析简介 sql解析指的是一条sql语句经过一系列的解析最后生成一个完整的物理执行计划的过程。解析过程主要包括以下四个步骤词法分析语法分析生成逻辑计划生成物理计划。
词法分析解析原始SQL文本拆分token语法分析将token转换成抽象语法树AST逻辑查询计划 单机逻辑查询计划对AST经过一系列优化比如谓词下推等成查询计划提高执行性能和效率分布式逻辑查询计划根据分布式环境数据分布信息、连接信息、join算法等将单机逻辑查询计划转换成分布式 物理查询计划在逻辑查询计划的基础上根据数据的存储方式和机器的分布情况生成实际的执行计划
Doris SQL 解析架构具体介绍如下 2.1 词法分析 词法分析主要负责将字符串形式的sql识别成一个个token为语法分析做准备。 select ...... from ...... where ....... group by ..... order by ......SQL的Token 可以分为如下几类关键字select、from、where操作符、-、开闭合标志(、CASE占位符?注释空格
2.2 语法分析 语法分析主要负责根据语法规则将词法分析生成的token转成抽象语法树Abstract Syntax Tree如图2所示。 2.3 逻辑计划 逻辑计划负责将抽象语法树转成代数关系。代数关系是一棵算子树每个节点代表一种对数据的计算方式整棵树代表了数据的计算方式以及流动方向
2.4 物理计划 物理计划是在逻辑计划的基础上根据机器的分布数据的分布决定去哪些机器上执行哪些计算操作。Doris系统的SQL解析也是采用这些步骤只不过根据Doris系统结构的特点和数据的存储方式进行了细化和优化最大化发挥机器的计算能力。 三、Doris SQL解析的总体架构 Doris SQL解析具体包括了五个步骤词法分析语法分析生成单机逻辑计划生成分布式逻辑计划生成物理执行计划。具体代码实现上包含以下五个步骤Parse, Analyze, SinglePlan, DistributedPlan, Schedule。 四、Parse阶段 Parse阶段主要涉及三部分工作
构建词法解析器词法分析将 doris sql中的关键词识别成一个个token进行语法解析将词法分析生成的token转成抽象语法树AST
五、Analyze阶段 SQL 语句被解析成AST之后会被交给 StmtExecutor进行一些前期的处理和语义分析为生成单机逻辑计划做准备大概会做下面的事情
元信息的识别和解析 识别和解析sql中涉及的 Cluster, Database, Table, Column 等元信息确定需要对哪个集群的哪个数据库的哪些表的哪些列进行计算。
SQL 的合法性检查 窗口函数不能 DISTINCT投影列是否有歧义where语句中不能含有grouping操作等。
SQL 重写 比如将 select * 扩展成 select 所有列count distinct转成bitmap或者hll函数等。 函数处理 检查sql中包含的函数和系统定义的函数是否一致包括参数类型参数个数等。
Table与Column别名处理类型检查和转换 例如二元表达式两边的类型不一致时需要对其中一个类型进行转换(bigint和decimal比较bigint类型需要转换成decimal) 总结对AST进行analyze后会再进行一次rewrite操作进行精简或者是转成统一的处理方式
六、SinglePlan阶段生成单机逻辑Plan阶段 此阶段主要是根据AST抽象语法树生成算子数。树上的每个节点都是一个算子。如下图所示ScanNode代表着对一个表的扫描操作将一个表的数据读出来。HashJoinNode代表着join操作将小表广播到大表所在的每个节点内存中构建哈希表然后遍历大表每条记录做关联。Project算子表示投影操作代表着最后需要输出的列下图中的sql表示只用输出citycode这一列。 SinglePlan阶段主要做了如下几项工作
Slot 物化指确定一个表达式对应的列需要 Scan 和计算比如聚合节点的聚合函数表达式和 Group By 表达式需要进行物化Slot计算槽是一个资源单位, 只有给 task 分配了一个 slot 之后, 这个task才可以运行投影下推BE在Scan 时只会Scan必须读取的列谓词下推在满足语义正确的前提下将过滤条件尽可能下推到Scan节点分区分桶裁剪根据过滤条件中的信息确定需要扫描哪些分区哪些桶的tabletJoin Reorder对于 Join操作, Doris会根据行数调整表的顺序将大表放在前面。在保证结果不变的情况通过规则计算最优最少资源join 操作 Sort Limit 优化成 TopN对于order by limit语句会转换成TopN的操作节点MaterializedView 选择会根据查询需要的列过滤排序和 Join 的列行数列数等因素选择最佳的物化视图 向量化执行引擎选择基于现代CPU的特点重新设计列式存储系统的SQL执行引擎从而提高了CPU在SQL执行时的效率提升了SQL查询的性能 Runtime Filter JoinDoris 在进行Hash Join 计算时会将小表广播到大表所在的各个节点上构建一个内存哈希表然后流式读出大表的数据进行Hash Join。而 RuntimeFilter是在右表生成哈希表的时候动态生成一个基于哈希表数据的过滤条件将该过滤条件下推到大表的数据扫描节点从而减少扫描的数据量避免不必要的I/O和网络传输。
七、DistributedPlan计划生成分布式逻辑阶段
7.1 DistributedPlan 概述 1 根据分布式环境将单机的PlanNode树planNode : 逻辑算子拆分成分布式PlanFragment树PlanFragment用来表示独立的执行单元 2每个 PlanFragment 由 PlanNodeTree 和 Data Sink 组成。Plan分布式化的方法是增加 ExchangeNodePlanNodeTree执行计划树会以 ExchangeNode为边界拆分为 PlanFragment。 ExchangeNode主要是用于BE之间的数据交换与共享类似 Spark 和 MR 中的 Shuffle。 3DistributedPlan阶段的主要目标是最大化并行度和数据本地化。主要方法是将能够并行执行的节点拆分出去单独建立一个PlanFragment用ExchangeNode代替被拆分出去的节点用来接收数据。拆分出去的节点增加一个DataSinkNode用来将计算之后数据传送到ExchangeNode中做进一步的处理。 4DistributedPlanner中最主要的工作是决定Join的分布式执行策略Broadcast JoinShuffle JoinBucket Shuffle JoinColocate Join以及增加 Aggregation 的 Merge 阶段。
7.2 四种join算法 对于查询操作来说join操作是最常见的一种操作。Doris目前支持4种join算法Broadcast JoinShuffle JoinBucket Shuffle JoinColocate Join。
7.2.1 Broadcast Join 小表进行条件过滤后将其广播到大表所在的各个节点上形成一个内存Hash 表然后流式读出大表的数据Hash Join。Doris会自动尝试进行 Broadcast Join如果预估小表过大则会自动切换至 Shuffle Join。
7.2.2 Shuffle Join 大表和大表join时一般采用hash partition join。它遍历表中的所有数据计算key的哈希值然后对集群数取模选到哪台机器就将数据发送到这台机器进行hash join操作。
7.2.3 Bucket Shuffle Join 当join列是左表的分桶列可以采用bucket shuffle join算法。下图中的hash(column) % n 中的n指的是左表的桶数,column代表的是join 列同时也是分桶列。这样左表数据不移动右表数据根据分区计算的结果发送到左表扫表的节点就可以完成Join的计算。即只需网络传输一份右表数据就可以了极大减少了数据的网络传输。 7.2.4 Colocate Join 两个表在创建的时候就指定了数据分布保持一致那么当两个表的join key与分桶的key一致时就会采用colocate join算法。由于两个表的数据分布是一样的那么hash join操作就相当于在本地不涉及到任何的数据传输极大提高查询性能。 总结上面这 4 种join方式灵活度是从高到低的它对这个数据分布的要求是越来越严格但 Join计算的性能也是越来越好的。
7.3 分布式逻辑计划的核心流程
7.3.1 PlanNode 如果是PlanNode 自底向上创建PlanFragment。
7.3.2 ScanNode 如果是ScanNode则直接创建一个PlanFragmentPlanFragment的RootPlanNode是这个ScanNode。
7.3.3 HashJoinNode 如果是HashJoinNode则首先计算下broadcastCost成本根据不同的条件判断选择哪种Join算法。 1如果使用colocate join由于join操作都在本地就不需要拆分。设置HashJoinNode的左子节点为leftFragment的RootPlanNode右子节点为rightFragment的RootPlanNode与leftFragment共用一个PlanFragment删除掉rightFragment。
2如果使用bucket shuffle join需要将右表的数据发送给左表。所以先创建了一个ExchangeNode设置HashJoinNode的左子节点为leftFragment的RootPlanNode右子节点为这个ExchangeNode与leftFragment共用一个PlanFragment并且指定rightFragment数据发送的目的地为这个ExchangeNode。
3如果使用broadcast join需要将右表的数据发送给左表。所以先创建了一个ExchangeNode设置HashJoinNode的左子节点为leftFragment的RootPlanNode右子节点为这个ExchangeNode与leftFragment共用一个PlanFragment并且指定rightFragment数据发送的目的地为这个ExchangeNode。
4如果使用hash partition join也就是shuffle joun左表和右边的数据都要切分需要将左右节点都拆分出去分别创建left ExchangeNode, right ExchangeNodeHashJoinNode指定左右节点为left ExchangeNode和 right ExchangeNode。单独创建一个PlanFragment指定RootPlanNode为这个HashJoinNode。最后指定leftFragment, rightFragment的数据发送目的地为left ExchangeNode, right ExchangeNode。 八、Schedule阶段 该阶段是根据分布式逻辑计划创建分布式物理计划。主要解决以下问题 哪个 BE 执行哪个 PlanFragment 每个Tablet选择哪个副本去查询 如何进行多实例并发 创建分布式物理计划的核心流程有
8.1 prepare阶段 给每个PlanFragment创建一个FragmentExecParams结构用来表示PlanFragment执行时所需的所有参数如果一个PlanFragment包含有DataSinkNode则找到数据发送的目的PlanFragment然后指定目的PlanFragment的FragmentExecParams的输入为该PlanFragment的FragmentExecParams。
8.2 computeScanRangeAssignment阶段 对fragment合理分配尽可能保证每个BE节点的请求都是平均针对不同类型的join进行不同的处理。 computeScanRangeAssignmentByColocate 针对colocate join 进行处理由于Join得两个表桶中的数据分布是一样的他们是基于桶的join操作所以在这里确定每个桶选择哪个host。在给host分配桶的时候尽量保证每个host分配到的桶基本平均。
computeScanRangeAssignmentByBucket 对bucket shuffle join进行处理也只是基于桶的操作所以在这里是确定每个桶选择哪个host。在给host分配桶时同样需要尽量保证每个host分配到的桶基本平均。
computeScanRangeAssignmentByScheduler 针对其他类型的join进行处理。确定每个scanNode读取tablet哪个副本。一个scanNode会读取多个tablet每个tablet有多个副本。为了使sca操作尽可能的分散到多台机器上去提高并发性能减少IO压力Doris 采用了Round-Robin算法使tablet的扫描尽可能分散到多台机器上去。例如100个tablet需要扫描每个tablet有3个副本假设集群有10台机器在分配时保障每台机器扫10个tablet。
8.3 computeFragmentExecParams阶段 处理Fragment执行参数这个阶段解决PlanFragment下发到哪个BE上执行 以及如何处理实例并发问题。
8.4 create result receiver阶段 result receiver是查询完成后最终数据需要输出的地方。
8.5 to thrift阶段 根据所有PlanFragment创建的rpc请求下发到BE端执行一个完整的SQL解析过程完成了。
综上所述 九、总结 本篇文章介绍了sql解析的通用流程词法分析语法分析生成逻辑计划生成物理计划。从总体上阐述了Doris在sql解析这块的总体架构从代码和算法层面上解析Parse, Analyze, SinglePlan, DistributedPlan, Schedule五步骤的内容。 Doris遵守了sql解析的常用方法根据底层存储架构以及分布式的特点在sql解析这块进行了大量的优化实现了最大化的计算并行度、最小化的数据网络传输最大化减少需扫描的数据量给sql执行层面减少了很多负担。 补充Hive SQL编译成MapReduce任务的过程 见文章
(02)Hive SQL编译成MapReduce任务的过程-CSDN博客文章浏览阅读1.4k次点赞30次收藏23次。Hive SQL编译成MapReduce的过程https://blog.csdn.net/SHWAITME/article/details/136103206?ops_request_misc%257B%2522request%255Fid%2522%253A%2522170813605316800182123993%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257Drequest_id170813605316800182123993biz_id0utm_mediumdistribute.pc_search_result.none-task-blog-2~blog~first_rank_ecpm_v1~rank_v31_ecpm-1-136103206-null-null.nonecaseutm_termmapreducespm1018.2226.3001.4450 参考文章
【Doris全面解析】Doris SQL 原理解析
聊聊分布式 SQL 数据库Doris(五)-腾讯云开发者社区-腾讯云
https://blog.csdn.net/qq_34635236/article/details/128114948?ops_request_miscrequest_idbiz_id102utm_termdoris%20sql%20%E6%BA%90%E7%A0%81utm_mediumdistribute.pc_search_result.none-task-blog-2~all~sobaiduweb~default-0-128114948.142%5Ev99%5Epc_search_result_base6spm1018.2226.3001.4187
