这是我参与「第四届青训营 」笔记创作活动的的第1天
大数据体系和sql
sql处理流程
Parser
把文本变成抽象语法树结构（String -> AST)
- 词法分析（拆分字符串，提取关键字，字符串，数值等token）
- 语法分析（把token按照定义的语法规则组装成抽象语法树结构AST）
实现方法：递归下降、Javacc、antlr
Analyzer
- 访问库/表元信息并绑定
- 判断 SQL 合法性检查，比如数据库，表和列名是否存在，列的数据类型是否正确
- AST -> Logical Plan 逻辑计划树（在某些系统中这个工作由一个 Converter 完成）
---逻辑计划树，可以理解为逻辑地描述一个 SQL 如何一步步地执行查询和计算，最终得到执行结果的一个分步骤地计划。树中每个节点是是一个算子，定义了对数据集合的计算操作（过滤，排序，聚合，连接），边代表了数据的流向，从孩子节点流向父节点。之所以称它为逻辑的，是因为算子定义的是逻辑的计算操作，没有指定实际的算法，比如对于逻辑的排序算子，逻辑计划树里没有指定使用快排还是堆排。
查询优化
- SQL 是一种声明式语言，用户只描述做什么，没有告诉数据库怎么做
- 查询优化的目标是为 SQL 找到一个正确的且执行代价最小的执行计划
- 一般 SQL 越复杂，Join 的表越多，数据量越大，查询优化的意义就越大，因为不同执行方式的性能差别可能有成百上千倍
常见的查询优化器
RBO（Rule-based Optimizer）
RBO是基于关系代数技术的查询优化，根据关系代数等价规则对逻辑计划进行变换。 同时RBO也是一个基于经验归纳规则的优化过滤。 主流 RBO 实现一般都有几百条基于经验归纳得到的优化规则。
实现时有
- Pattern：定义了特定结构的 Operator 子树（结构）
- Rule：定义了如何将其匹配的节点替换（Substitute）为新形态，从而生成新的、等价的Operator 树（原地替换）
- 优化器搜索过程被抽象为不断匹配 Pattern 然后应用 Rule 转换，直到没有可以匹配的 rul
RBO优化方式
- 列裁剪：把查询时用不到的列裁减掉，只查询用的到的列，是原本的查询数据量减少。
- 谓词下推：原本查询时先多表先join后再进行filter谓词查询。而谓词下推把filter下放到join之前，使谓词只队谓词所在的表查询，而不是对联合表查询，减少的查询数据量。
- 传递闭包：根据join的规则可以推算出同样需要查询的谓词，把该谓词与原来的谓词一同下推。
- Runtime Filter: 在查询时进行一个计算得出一个合适的数值域在谓词查询之前进行过滤数据，减少了数据量。
RBO的优点是实现简单和速度快，但因为它是基于经验的导致大多数时候得到的并不是最优执行计划。
CBO(Cost-based Optimizer)
CBO是使用一个模型估算执行计划的代价，选择代价最小的执行计划。它会根据所有算子的执行代价之和来确定执行计划的代价。对大数据的效率影响非常重要。具体计算比较复杂，啥的我也没听懂，不在赘述。
社区开源
- Apache Calcite
我的想法
大数据开营的第一课就讲了sql查询的优化，这说明了大数据分析的sql查询方式是多么的重要，在实际的工作中，人们更偏向用一句sql来解决复杂的查询代码，像hive的一句就能解决一整个mapreduce所实现的功能。而区别于普通sql查询就是大数据的sql查询的巨大数据量，在这种情况下，一点sql查询的优化都能使整个的效率大幅提升。这便是这节课给我的认识。
