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

前言

个人大数据小白，目前技术漏洞很多也对很多技术名词陌生，这篇用于补充以下基本概念。

基础技术

1. 流计算

基本理念：数据的价值随直接的流逝而降低；因此需要及时处理而不是缓存等待。主要产品：用于低延时，可扩展，高可靠的处理引擎，如STORM，Flink

2. 批量计算

对静态数据的批量处理，主要用于数据挖掘和验证业务模型主要产品：MapReduce，spark， hive

Hadoop MapReduce: 用于大规模数据集的并行运算，核心思想：映射和归约 spark：具有Hoop MapReduce的优点，但其中间输出结果可以保存在内存中 hive：基于Hadoop的数据仓库工具，用于数据提取，转换和加载。

3. 分布式协调系统

解决分布式环境中多个线程间的同步控制，有序的访问临界资源，防止脏数据；主要产品：Zookeeper， eureka，consul

4. 集群管理及调度

硬件资源对于不同计算任务的分配

5. 文件存储

以文件的形式进行管理，用于分布式文件存储的并行能力。

6. 对象存储

基于对象的存储，每个数据存储单元称为对象的离散单元，对象类似：pdf，音频，图像等；对象存储中没有文件夹的层次，包含：对象数据，元数据和全局唯一标识。采用分布式架构，容量和处理能力弹性扩展

二、云引擎

云计算概述：
基本特征-按需自助，广泛网络访问，快速可伸缩，资源池化和可计量的服务云计算 -> 云 + 计算 -> 通过网络进行数据的计算云计算为一个抽象的计算机，以用户的请求作为数据输入，对外提供按需计量的服务

相关云厂商：火山引擎，阿里云，腾讯云，华为云， Microsoft Azure 基础服务：计算，存储，网络，安全，容器，数据库等方面的产品和服务

2.1 火山引擎

无损RDMA网络，大幅加速AI高密度计算效率。同时，火山引擎自研的智能运维平台，则全力保障了数据中心百万台服务器的稳定运行。
自研的DPU硬件和虚拟交换机软件

三、关系代数基础

对比SQL，选择运算类似获取行元素，投影运算获取某一列；
重命名类似as，对返回的结果进行更名
自然连接（join）运算主要是将某些选择跟笛卡尔积运算合并在一起表示，它会将两个关系模式中都出现的属性上的相等性进行选择，最后还要去除重复属性

四、编译原理基础

4.1 词法分析

主要分析源程序中的字符流是否组成正确的单词
从左至右对源代码进行扫描，将字符串形式的源程序改为单词符号串形式的中间程序，作为或许语法分析的基础。
词法分析器：将输入的源程序输出为单词符号（如高级程序语言中的保留字，标识符，常数，运算符）。

为每一种单词符号以整数形式(token)进行表示

if(r>=20) c=2*pi*r

词法分析转换

(111,"if")
(201,"(")
(700,"r")
(214,">=")
(800,"2.0")
(202,")")
(700,"c")
(219,"=")
(400,"2")
(206,"*")
(700,"pi")
(206,"*")
(700,"r")

4.2 语法分析

五、分布式SQL引擎原理

执行流程

概述：词法分析，拆分字符串，获取关键字，常量数值等，称为token；利用token生成AST（抽象语法树）的node节点，然后构成AST。由分析器检查元数据信息，sql语法等然后将AST转换成执行计划（用来描述sql的执行过程）。

基于Sql的大数据分析，首先将sql转换为抽象语法树，对语法树分析生成执行计划。传统数据库会通过执行引擎直接将执行计划解析返回结果；
但是在分布式SQL分析中，将执行计划分为逻辑执行计划和物理执行计划，根据查询sql的特点切分逻辑计划，这样可以把分块的逻辑计划分配到更具扩展性的并行节点，最后根据逻辑执行计划转成物理执行计划进行查询。

执行流程：用户提交一条查询请求时，先通过解析器生成一棵抽象语法树，呈现树结构，由分析器进行绑定元素，并进行节点优化，最后对抽象语法树（AST）进行逻辑分段，生成分布式SQL的逻辑执行计划。

SQL优化的基本思路为基于规则和基于代价；基于规则是传统数据库积累的一套经验，指定一些规则，然后遍历逻辑执行树模式符合规则时则等价转换(AST转换)进行优化，比如谓词下推(Predicate Pushdown)，常量累加(Constant Folding)等；而基于代价是计算所有执行路径的代价，并挑选代价最小的执行路径，这种思路当前针对分布式的执行引擎很流行但目前都做的都还不够好

优化的目的：找到正确方法形成代价最小的物理执行计划。

逻辑执行计划分段（Plan Fragment）的目的：以分片的方式运输和执行在分布式节点上。不同的执行片段会参照数据亲和性加入到相同的物理节点，避免跨节点交流导致效率下降。（Optimizer需要感知数据的分布，利用数据的亲和性）

数据库优化器

在涉及多表操作的时候执行的顺序可能与定义的数据发生不同，底层会由优化器根据策略进行调整。但是当表数量过多时，需要幂级的有穷查找因此占据了大量的搜索空间。

一些解决算法：

left-deep-tree 所有的右子树必须是一个实体表，如下图三张表的关联

优点：左边的表不断与右边的表进行关联，大部分情况下都会使用HashJoin。如果能够使得左边的result set一直很小，从而建立的Hash表能一直存放在内存中的话，对于全部右子树的表，只要进行一次全表扫描，即可得到最终结果。因此，右子树的table order就不是特别影响运行时间了缺点：不能执行多个Join，每次只能有两张表进行关联

SQL执行流程

对于客户端发来的SQL语句，首先由连接管理模块处理接受请求，将请求转发到线程模块，调用用户模块进行鉴权，然后判断连接池是否由空闲线程处理请求，如果没有创建一个新的连接。
判断查询缓存是否完全匹配当前SQL语句，如果成功直接返回
缓存失败执行解析器（Parser)，通过词法解析和语法解析生成抽象语法树，对语法树进行语法和权限上的检查
通过优化器进行语法树的优化，然后生成执行计划。
通过访问控制模块判断是否有访问该表和字段的权限，在通过表管理模块检查table cache中是否有表信息，如果没有在查找表文件
根据表的元数据信息调用对应的存储引擎进行处理
过程中的数据变化会通过日志的形式进行记录。
最后将结果集返回给线程模块，然后完成后续的清理工作

RBO基于规则优化的几种方式

列裁剪：对于无用的列不需要获取，避免无效的IO；通过读取必要的数据减少IO操作
谓词下推：将过滤表达式尽可能移动至靠近数据源的位置，以使真正执行时能直接跳过无关的数据。（利用小表的列对大表数据先进行过滤，然后在关联，减少无效数据同行的其他数据列IO）； where后的条件可以称为谓词；将where的过滤时机尽量提前（这里将FILTER的谓词下推到WHERE之后）
传递闭包：利用关系代数的传递性
Runtime Filter

min-max的不足：可能由于数据不均导致过滤不合理；
in-list: 将存在的列数据单独记录，然后进行过滤；但是如果in-list过大，会导致网络的阻塞

RBO的缺点：基于经验，未必是最优的；

CBO：基于代价利用RBO的等价执行计划进行代价模型估算算子代价 -》推到出执行计划的代价

统计信息：列区分度，选择率，基数（算子需要处理的）

参考链接

数据库优化器：cloud.tencent.com/developer/n… MySQL架构与SQL执行流程 cloud.tencent.com/developer/a…

SQL优化器(Optimizer) | 青训营笔记

前言