大数据第一节课前学习|青训营笔记

276 阅读7分钟

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

哈喽大家好,虽然本人所学专业和大数据相关,但目前也仅局限于对“大数据”这个词的概念认知,根据老师发的课前内容,让我们一起来学习吧!
第一节呢是SQL的查询优化器浅析,课前我们需要了解大数据体系和SQL、常见的查询优化器、查询优化器的社区开源实践和SQL相关的前沿趋势。

大数据体系和 SQL

1、生产系统中的大数据体系

大数据系统体系:数据采集、数据计算、数据服务、数据应用
批计算、流计算请移步https://blog.csdn.net/qq_22473611/article/details/122908715

2、SQL 的基本用法和关系代数基础知识

由于本人了解此方法切过于简单就不贴解析咯

3、编译原理相关的基础知识

词法分析

在百度百科里是这样解释的:
词法分析是计算机科学中将字符序列转换为单词序列的过程。进行词法分析的程序或者函数叫作词法分析器
词法分析阶段是编译过程的第一个阶段,是编译的基础。这个阶段的任务是从左到右一个字符一个字符地读入源程序,即对构成源程序的字符流进行扫描然后根据构词规则识别单词。词法分析程序实现这个任务。词法分析程序可以使用Lex等工具自动生成。\

语法分析

在百度百科里是这样解释的:
语法分析是编译过程的一个逻辑阶段。语法分析的任务是在词法分的基础上将单词序列组合成各类语法短语,如“程序”,“语句”,“表达式”等等.语法分析程序判断源程序在结构上是否正确.源程序的结构由上下文无关文法描述.语法分析程序可以用YACC等工具自动生成。

抽象语法树

在百度百科里是这样解释的:
之所以说语法是“抽象”的,是因为这里的语法并不会表示出真实语法中出现的每个细节。比如,嵌套括号被隐含在树的结构中,并没有以节点的形式呈现;而类似于if-condition-then这样的条件跳转语句,可以使用带有两个分支的节点来表示。

3、了解SQL里的执行计划

这方面的相关解释有些太过于专业,我查询了csdn等一些内容,找到了比较简单明了的一个SparkSQL(Catalys)整体流程介绍: 无论是使用 SQL语句还是直接使用 DataFrame 或者 DataSet 算子,都会经过Catalyst一系列的分析和优化,最终转换成高效的RDD的操作,主要流程如下:\

  1. sqlParser 解析 SQL,生成 Unresolved Logical Plan(未解析的逻辑计划)

  2. 由 Analyzer 结合 Catalog 信息生成 Resolved Logical Plan(解析的逻辑计划)

  3. Optimizer根据预先定义好的规则(RBO),对 Resolved Logical Plan 进行优化并生成 Optimized Logical Plan(优化后的逻辑计划)

  4. Query Planner 将 Optimized Logical Plan 转换成多个 Physical Plan(物理计划)。然后由CBO 根据 Cost Model 算出每个 Physical Plan 的代价并选取代价最小的 Physical Plan 作为最终的 Physical Plan(最终执行的物理计划)

  5. Spark运行物理计划,先是对物理计划再进行进一步的优化,最终映射到RDD的操作上,和Spark Core一样,以DAG图的方式执行SQL语句。 在最新的Spark3.0版本中,还增加了Adaptive Query Execution功能,会根据运行时信息动态调整执行计划从而得到更高的执行效率

     原文链接:https://blog.csdn.net/zc19921215/article/details/119155403
    

4、SQL 执行的基本流程

sql 执行流程为: sql语句 -> 查询缓存 -> 解析器 -> 优化器 -> 执行器。

5、分布式系统中 shuffle 的实现方式

shuffle被称为数据混洗。shuffle最简单的实现方式就是对数据做某种策略上的切分,然后可以选择切分之后的数据直接传输或者将数据持久化供容错,我们比较一下这两种方式。
1、直接传输:当数据切分之后马上传输,会不经过磁盘,直接从内存中向另一个节点的内存中传输。
2、持久化之后传输虽然慢,但你的容错有保障。

    原文链接:https://blog.csdn.net/egraldloi/article/details/38311195

6、SQL 中 group-by 和 join 的执行方式

由于本人了解此方法切过于简单也不贴解析咯

常见的查询优化器

1、Top-down Optimizer

它的设计参考了 Columbia 优化器,其内部并非是一个简单的递归函数,而是用栈 tasks 模拟了整个 top-down 的过程。
整个优化过程由下面的循环驱动:不断从栈顶取出 Task 执行,Task 执行中又会产生新的 Task,重复这一过程直到栈为空。本质上这和递归没什么区别。
Top-down 方法是将一个复杂的问题或算法分解成很多个小的单元,每个单元称为一个模块 (module)。这些模块会被进一步分解成更小更基本的单元,直到这些小单元已经足够简单、很容易被理解,或者可以转化为已经解决的问题,此时即可以停止进一步分解。

2、Bottom-up Optimizer

Bottom-up 方法的原理刚好与Top-down 方法相反。最开始的时候,它会设计一个个最基本的功能构件,然后将这些基础构件结合到一起形成更高层次的模块。这个将子模块合并形成高层模块的过程反复发生,直到最终的设计目标得以实现。

3、Rule-based Optimizer,RBO

“RBO: Rule-Based Optimization”也即“基于规则的优化器”,该优化器按照硬编码在数据库中的一系列规则来决定SQL的执行计划。
以Oracle数据库为例,RBO根据Oracle指定的优先顺序规则,对指定的表进行执行计划的选择。比如在规则中:索引的优先级大于全表扫描。
通过Oracle的这个例子我们可以感受到,在RBO中,有着一套严格的使用规则,只要你按照规则去写SQL语句,无论数据表中的内容怎样,也不会影响到你的“执行计划”,也就是说RBO对数据不“敏感”。这就要求开发人员非常了解RBO的各项细则,不熟悉规则的开发人员写出来的SQL性能可能非常差。
但在实际的过程中,数据的量级会严重影响同样SQL的性能,这也是RBO的缺陷所在。毕竟规则是死的,数据是变化的,所以RBO生成的执行计划往往是不可靠的,不是最优的。

4、Cost-based Optimizer,CBO

“CBO: Cost-Based Optimization"也即“基于代价的优化器”,该优化器通过根据优化规则对关系表达式进行转换,生成多个执行计划,然后CBO会通过根据统计信息(Statistics)和代价模型(Cost Model)计算各种可能“执行计划”的“代价”,即COST,从中选用COST最低的执行方案,作为实际运行方案。
CBO依赖数据库对象的统计信息,统计信息的准确与否会影响CBO做出最优的选择。
以Oracle数据库为例,统计信息包括SQL执行路径的I/O、网络资源、CPU的使用情况。
目前各大数据库和大数据计算引擎都倾向于使用CBO。

SQL 相关的前沿趋势

1、存储和计算分离

原文链接:https://zhuanlan.zhihu.com/p/441534428

2、HSAP, HTAP, HTSAP

原文链接:https://www.infoq.cn/article/PRs186MyBXAZVbQRW1rC

3、Cloud Native, Serverless

原文链接:https://blog.csdn.net/torrentliu/article/details/106506760

4、数据仓库,数据湖,湖仓一体,联邦查询

原文链接:https://zhuanlan.zhihu.com/p/436394483

5、 智能化:AI4DB,DB4AI

原文链接:https://bbs.huaweicloud.com/blogs/354523

好了,各位小伙伴们,今天的学习就到这里了,下次有机会再见哦!