当前位置：首页 > news >正文

制作英文网站费用wordpress绑定域名

news 2025/11/15 12:45:53

制作英文网站费用,wordpress绑定域名,企业网站建设公司多米,域名注册免费1.Calcite介绍 Calcite是一个动态数据库管理框架#xff0c;具备数据库管理系统的功能 Calcite具备SQL解析、校验、优化、生成、连接查询等功能 Calcite能够为不同平台和数据源提供统一的查询引擎 2.Calcite能力比如#xff0c;对于HBase而言#xff0c;没有SQL查询的能力…1.Calcite介绍 Calcite是一个动态数据库管理框架具备数据库管理系统的功能 Calcite具备SQL解析、校验、优化、生成、连接查询等功能 Calcite能够为不同平台和数据源提供统一的查询引擎 2.Calcite能力比如对于HBase而言没有SQL查询的能力但是具备数据管理和数据存储的能力对于ES而言它也不具备SQL查询的能力但是具备数据管理和数据存储的能力也就是说对于常见的数据库管理系统都会具备上图中灰色部分数据管理和数据存储的能力可能不具备SQL查询的能力。可以通过Calcite为它们赋予SQL查询的能力Calcite具备上图中绿色部分查询语言、查询优化、查询执行的能力。 Calcite在设计之初就确定了只关注和实现上图中绿色部分而把灰色部分留给了各个外部的存储引擎和计算引擎。由于数据的多样性通常灰色部分是比较复杂的Calcite抛弃了灰色部分更加专注地实现上层通用的模块。 3.Calcite核心功能完整的数据库管理系统分为查询语言、查询优化、查询执行、数据管理、数据存储 5个模块 Calcite专注于实现上层3个通用模块 Calcite功能模块的划分足够合理、独立使用时不需要完整集成3个模块可以单独引用某一个模块 4.Calcite集成上图展示了不同大数据框架对Calcite的引用情况对Hive而言Hive的 JDBC Driver 和 SQL Parser and Validator 都是自己实现的只用到了Calcite的优化模块 Relational Algebra 对Flink而言FlinkSQL的 JDBC Driver、SQL Parser and Validator、 Relational Algebra 都使用了Calcite进行实现 5.Calcite特性支持标准SQL语言可以通过自定义语法兼容多种特殊引擎语法通过适配器可以支持连接任何数据源支持对SQL进行解析并进行优化支持物化视图支持流式查询 6.SQL引擎之旅提交一条SQL查询后SQL会经历怎样的处理流程呢会经历解析 - 校验 - 优化 - 执行 ParserCalcite通过 Java CC 将 SQL 解析成未校验的抽象语法树AST Validate检验Parser产生的抽象语法树是否合法如验证结构Schema、字段Field、函数是否存在、格式是否正确验证完成之后生成逻辑执行计划RelNode树 Optimize优化逻辑执行计划RelNode树优化主要分为两类RBO和CBO优化后将其转换为物理执行计划 Execute将物理执行计划转换成为特定平台的执行程序 7.Calcite相关组件 Catalog定义SQL语义相关的元数据和命名空间其实就是表和字段的一些元数据信息 SQL Parser 解析器解析SQL将其转换为抽象语法树AST SQL Validator 校验器通过Catalog里面存储的元数据信息来校验抽象语法树AST验证抽象语法树所查询的表、字段是不是存在 Query Optimizer 优化器将抽象语法树转换为逻辑执行计划并对其进行优化 SQL Generator 生成器反向将执行计划转换为SQL语句或其他执行程序 8.Calcite架构图 Operator Expressions — Query Optimizer接受原始的查询计划输出优化后的查询计划 Metadata Providers提供元数据元数据就是一些Catalog信息。提供的不是校验SQL需要的库、表、字段、Schema信息而是是针对优化规则所需要用到的统计信息比如表里面有多少个分区表数据有多少个行表的数据量有多少 Pluggable Rules优化规则根据统计信息和优化规则运用关系代数关系演算这些等价关系进行执行计划的优化虚线Calcite可以扩展的部分可以与外部系统进行连接桔色框可以理解为外部系统桔色框与蓝色框有虚线的连接也就是说桔色框可以扩展三个蓝色框能够为优化器提供更加准确的元数据信息更加符合的优化规则来利用Calcite优化器产生最优的查询计划以Hive为例Hive只用了Calcite的优化能力Hive MetaStore作为元数据的提供方Hive为Calcite优化器提供了自己外部的元数据优化规则以及生成的Operator Expressions 这张架构图从上往下就可以与SQL的处理流程关联起来用户通过JDBC Client提交一条SQLCalcite首先对SQL进行解析和验证将SQL转换为抽象语法树将抽象语法树转换为逻辑执行计划在图中表现为Operator Expressions优化器根据生成的逻辑执行计划和外部提供的统计信息、优化规则对逻辑执行计划进行优化生成性能比较好的逻辑执行计划转换为物理执行计划从图中可以看出Calcite最核心的部分就是优化器优化器需要三部分的输入分别为优化前的逻辑执行计划、统计信息、优化的匹配规则 Calcite内置了上百种优化规则来对关系表达式进行优化同时也支持自定义一些优化规则 9. Calcite集成 Calcite的使用非常灵活可以使用Calcite的全部功能也可以使用Calcite的部分功能。比如可以只使用Calcite的解析功能或者只使用Calcite的优化功能所以对于Calcite的使用一般有这两种场景使用Calcite的全部功能在这张图中Calcite作为独立运行的进程后台通过适配器与外部存储系统进行连接前台通过JDBC接口使用SQL语言和用户进行交互在这个场景中Calcite作为一个中间件为一些没有或缺乏SQL查询语言的存储系统比如HBaseKafkaESRedis等提供SQL查询语言 Calcite可以在内部将用户提交的查询进行优化运行在自己的进程里面在优化的过程中将用户的查询转换成对应数据存储所需要的查询下推到对应的数据系统进行查询查询完成之后再将查询结果返回给用户使用Calcite的部分功能 Calcite作为一个嵌入式的组件运行在查询引擎里可以看到图中中间是一个数据处理系统它只应用了Calcite的一个或两个核心功能查询引擎自己连接后台的数据源使用自己的集群用分布式的形式去进行查询也就是说查询引擎能够自己获取数据和执行查询它只需要Calcite来提供查询语言和优化查询的能力比如Hive、Spark、Flink等等以Flink为例Flink有多种算子可以连接多种异构的数据源用于数据的获取Flink自己就是一个计算引擎能够自己去读取数据计算数据Flink有丰富的算子可以将数据进行过滤放大缩小变形等用于各种各样的计算需求但是它需要一种对用户友好的对于流批数据语义统一的查询语言便于用户来编写查询所以引入了Calcite通过Calcite将SQL转换成执行计划转换成Flink的作业图让用户的SQL以最小的代价运行在Flink的集群中这种场景是Calcite最受欢迎最擅长的场景。相比于连接数据源Calcite更擅长的是制造查询语言解析查询查询优化上图就是在第二种集成场景下Calcite和Data processing System的交互过程用户提交一条SQLSQL经过Calcite进行处理生成逻辑执行计划对执行计划进行优化优化就要依赖于计算引擎提供的一些信息包括新算子替换、优化规则、元数据通过这三类数据结合Calcite本身的优化能力产出优化后的逻辑执行计划转换为计算引擎支持的查询步骤对数据进行查询计算引擎只引用了Calcite对SQL处理的能力 10. SQL解析 SQL解析包含三个过程词法分析、语法分析、输出抽象语法树 SQL解析是将一个输入的字符串变换成描述这个字符串的“结构体”这个结构体是能够准确被计算机识别的词法分析词法分析就是按照定义好的词法将输入的字符集转换为单词先对待解析的格式进行初始的定义比如abc认定为标识符abc’认定为字符串123认定为数值select、from认定为关键字根据规定好的初始定义将SQL转换成对应的词法语法分析经过词法解析得到了一系列的单词得到单词后就可以进行语法分析了也就是说词法分析的结果作为语法分析的输入语法分析在词法分析的基础之上来判断用户输入的单词是不是符合语法的逻辑语法分析之后得到抽象语法树抽象语法树是用户输入SQL语句的树形表现形式树上的每一个节点都是词法分析的一个单词树的结构体现了语法抽象语法树是随语法分析过程构造的当语法分析正常结束以后语法分析器就会输出一颗抽象语法树用户的输入和抽象语法树的结构是一一对应的自此用户输入的SQL也就会变成一个结构体也就是抽象语法树如下图所示语义分析接下来就可以根据生成的抽象语法树来理解SQL想要干什么语义分析是SQL解析当中最为复杂最有难度的一步涉及到SQL的标准、SQL的优化等等。如果想要转换为MapReduce程序还需要理解MapReduce相关的概念 SQL的语义分析分为两大块逻辑分析物理分析逻辑分析基本上是一个纯代数的分析过程与底层的分布式环境无关物理分析是将逻辑分析的结果进行一些变换与底层的执行环境有密切的关系 SQL执行顺序面试常见如图所示按照标号顺序执行逻辑执行计划 SQL算子是SQL执行时不可拆分的单位语义分析会根据抽象语法树及元信息构建 RelNode 树也就是最初版本的逻辑查询计划 RelNode树就是逻辑查询计划。RelNode树是由一系列RelNode节点组成的树状结构每个RelNode节点表示一个逻辑操作如扫描表、投影、过滤等。RelNode树描述了查询的逻辑结构一个逻辑查询计划实际上就是由这些查询算子组成的有向无环图。在这个有向无环图中每一个算子都描述了SQL操作中的不同动作由算子组成的有向无环图描述了数据流的方向 11.SQL优化优化逻辑执行计划优化方式分类 RBO基于规则优化。基于已经制定好的优化规则对关系表达式进行转换生成最优的执行计划。是一种经验式的优化方法 CBO基于代价优化。根据优化规则对关系表达式进行转换生成多个执行计划根据统计信息和代价模型计算出每个执行计划的代价从中挑选代价最小的执行计划作为最终的执行计划 CBO明显优于RBO因为RBO只认规则对于数据并不敏感。在实际中数据的量级会严重影响同样SQL的性能所以仅仅通过RBO生成的执行计划很有可能不是最优的而CBO依赖于统计信息和代价模型统计信息的准确与否代价模型是否合理都会影响CBO选择最优的执行计划新的优化方式动态CBO在执行计划生成的过程当中根据下一步代价动态优化随着大数据技术的发展静态CBO没有办法满足优化的需要了因为静态的统计信息没有办法提供准确的参考。在执行计划生成的过程当中动态地进行统计才能得到最优的执行计划优化规则无论RBO还是CBO实际上都是对逻辑执行计划应用一些优化规则。通过优化规则对关系表达式进行等价转换寻找最优的执行计划常见的CBO优化规则有列裁剪、投影消除、最大最小消除、谓词下推等逻辑算子从上图可以看到涉及到三个逻辑算子分别是Projection、Selection、DataSource DataSource数据源也就是SQL语句中的表 Selection选择where后的过滤条件 Projection投影指搜索的列 Join连接inner join、left join、right join等 Sort排序无序的数据通过这个算子处理后输出有序的数据 Aggregation聚合按照某些列进行分组进行一些聚合操作物理算子有逻辑算子肯定就有物理算子对应的就是物理执行计划物理算子和逻辑算子的不同在于一个逻辑算子可能对应多种物理算子比如Join的物理算子有Hash Join、MergeSort Join等。DataSource可以扫描全表也可以利用索引读取数据。都对应着多个物理算子数据查询慢需要加索引要确保逻辑查询计划所对应的物理查询计划要走我们加的索引这样才能提高查询速度。也就是说DataSource逻辑算子生成物理执行计划的时候对应的物理算子要走索引才行 12.RBO优化规则列裁剪对于没有用到的列没有必要读取它们的数据去浪费IO。列裁剪通过只读取需要的数据减少IO操作来达到优化的目的列裁剪的算法就是自顶向下遍历一遍所有的算子某个算子需要用到的列自己需要的列父节点需要的列这样就可以得到整个SQL语句需要的列读取数据的时候只读取需要的列即可投影消除投影消除是把不必要的Projection给消除掉 Projection算子投影的列跟子节点的输出列一样那么这个投影操作就可以消除例select a,b from t1 如果t1中只有a,b两列也就是如果DataSource的输出和它上层的Projection算子需要投影的列是一样的执行TableSCAN之后就没有必要再做一次Projection操作了上层的Projection是可以被消除掉的如果Projection的子节点还是Projection那么可以被消除例select a from(select a,b,c from t1)t2 这条语句有两个Projection分别是最上层的Projection只含有a一列它的子节点Projection含有a,b,c三列 Projection a,b,c就是一个废操作可以被消除掉常量折叠和常量传播常量折叠编译优化时能够计算出结果的表达式替换为常量例select * from t1 where a35 35可以由常量进行替换替换成a8 常量传播编译优化时将能够计算出结果的变量替换为常量常量折叠处理不了变量被多次赋值的情况例where a5 and a4 我们一眼就能看出来上述情况不存在但没有经过优化的SQL会进行全表的扫描所以需要对它进行处理对a5和a4进行条件常量传播消除无用的节点判断是否存在结果谓词下推将外层查询where子句中的谓词移入到所包含的较低层次的查询块提前进行数据过滤更好的使用索引例 select * from t1,t2 where t1.a 3 and t2.b 5假设t1表和t2表都有100条数据如果不进行谓词下推就需要把t1表和t2表做笛卡尔积再根据条件进行过滤。如果进行谓词下推则是先过滤数据再做笛卡尔积尽量把过滤条件下推到子节点上这样可以避免访问很多的数据达到优化效果对于DataSource算子就直接将过滤条件推给各个DataSource算子。对于Join算子收集连接的条件区分出哪些是来自于左节点哪些是来自右节点将这些条件分别向左右节点进行下推谓词下推也是有边界的不能一直对谓词进行下推不能推过limit节点。先Selection后limit n 和先limit n后Selection的结果是不一样的 13.SQL优化执行过程 RBO执行过程 Transformation遍历关系表达式满足特定的优化规则进行转换 Build Physical Plan把优化过的逻辑执行计划转换成物理执行计划 CBO执行过程 Exploration根据优化规则进行等价转换生成多个逻辑执行计划 Build Physical Plan生成多个物理执行计划 Find Best Plan计算各个物理执行计划的Cost选出Cost最小的执行计划动态CBO CBO先生成执行计划后统计代价动态CBO边生成执行计划边统计代价 14.CBO核心步骤采集数据源的基本信息包括表级别指标和列级别指标每个节点输出的数据大小、数据条数、数据类型、数据分布这是表级别指标列的类型以及每一列的最大值最小值每一列的长度这是列级别指标通过采集这些指标来计算每个算子的代价去评估到底需要耗费多少资源支持CBO的系统一般都实现了相关信息统计的方法如Hive Matastore 如orc列式存储格式也存储了统计信息定义核心算子的基数推导规则根据统计信息预估节点代价推导规则是在当前子节点的统计信息基础之上来计算父节点相关统计信息对于不同的算子推导规则肯定是不一样的。根据表级别的指标和列级别的指标做一个预估进行代价的计算核心算子实际代价计算从 CPU Cost 和 IO Cost 两方面分析实际代价根据统计信息和推导规则所预估出的数据的条数数据的大小数据的分布等来计算出各个执行计划执行的成本执行成本就从CPU和IO两个维度进行体现选择最优的执行路径根据计算代价选择最优的执行路径实际选择的并不一定是代价最小的执行路径原因是可执行的执行路径太多了如果把所有的路径都计算一遍需要耗费大量的时间SQL的优化也就没有意义了 CBO就是选择一条相对稳定而且代价较小的执行路径这样就能在很短的时间内达到SQL的优化目的

查看全文

http://www.zqtcl.cn/news/159185/