本篇笔记对于字节跳动青训营7.23日周东炎老师讲授的 SQL 查询优化器的内容做一个复习总结。
首先是大数据体系和 SQL ,大数据体系自底向上分为了:
- 基础设施(例如ECS、存储、虚拟私有云等等)
- 基础设施由存储系统管理(例如 HDFS 或者数据湖)【湖仓一体】
- 负责资源调度的资源管理器( Hadoop-YARN、kubernetes【K8S:容器引擎,部署和管理微服务架构应用】)
- 分析引擎(批处理的Spark、Hive、MR;流处理的 Flink【第二节课有讲Flink流批一体】;交互分析的 clickhouse【OLAP型数据库】、Presto、Doris)
- 权限控制(访问策略的权限控制模型 Apache Ranger;欧盟通用数据保护条例 GDBR)
- 数据开发中提到了DAG(有向无环图),其中Airflow是Airbnb开源的机遇DAG的任务管理系统
- 最顶层是业务应用(BI报表、营销分析、精准推荐等等应用)
- 当然,还有处理消息流的消息队列(Kafka、pulsar和基于go语言的NSQ)
SQL执行的基本流程如图:
解析器经过语法、语义分析将SQL语句字符串转化为AST抽象语法树,经分析器转化为逻辑计划,经查询优化器优化得到一个物理执行计划(最小化网络数据传输目标)。【explain可以用于查看执行计划并调整之】
第二部分就是执行流程中最重要的一环查询优化器
- 自上往下(输出开始)的Top-down Optimizer(可以剪枝)和自下往上Bottom-up Optimizer
- 基于规则的优化器 RBO 和基于代价的优化器 CBO
RBO 会根据关系代数重写查询,不涉及数据本身,根据表的元信息和启发式规则优化。通常来说主流的 RBO 会有几百条这样的优化规则,优化简单高效但是不保证最优。
RBO 的基本原则包括了更少的I/O读写;更少的网络传输开销,更少的数据处理( CPU & Memory ),基本的优化规则包括了:
- 列裁剪:不再扫描全表,只扫描要用的列
- 谓词下推:先 where 再表连接 join
- 传递闭包:例如谓词性质传递给连接的表
- Runtime Filter:min-max、in-list、布隆过滤器
CBO通过代价模型估算并选择代价最小的计划(贪心或动态规划)计算所有算子的执行代价和。
通常的步骤是先统计原始表的信息比如行数,行平均大小、列非空数、NDV(num distinct value)等等;再推导统计信息。相对而言我们更需要做到如何把信息收集得更准确,更有效,需要考虑到数据间的关系而非盲目地使用模型。
社区开源实践
主流的查询优化器都包括了 RBO 和 CBO , clickhouse轻量级仅有少量的RBO,Hive 和 Flink 都是基于Apache Calcite的,属于volcano/Cascade架构。
Apache Calcite 解析 SQL 并优化,得到执行计划,具体的数据处理和执行并不参与,所以模块化程度高,适用性强,支持异构数据模型(关系型、半结构化、流氏、地理空间数据),可以广泛对接不同系统(Hive、Flink等)
Apache Calcite 的 RBO 通过 Rule 来匹配并等价变换表达式子树,有100+优化规则,会依次遍历。Apache Calcite 的 CBO 基于 volcano/cascade 寻找成本最优,Memo 记录候选计划,一个 Memo 用多个 group 的形式来表示所有等价的计划,等价的计划共享了一个子树能够减少内存开销,我们去记录 group winner 找到局部最优解从而计算总体计划的最优代价。它可以通过剪枝减少开销,大于当前的上限就不必再考虑了
前沿趋势
- 引擎架构的变化:存算一体(没法单独扩容存储or计算)->存算分离(网络开销现在相对 CPU 开销并并不大);
HTAP:混合事务(同时支持 OLTP 和 OLAP )(TiDB)
HSAP:服务分析混合负载的分布式数据系统
HTSAP:为 HSAP 数据库增加事务能力,或选择在 HTAP 数据库的基础上增强 Serving 能力(TiDB × Flink)
- 云原生:K8S等,动态根据流量扩缩计算节点,降低成本
- 湖仓一体:数仓丢失原始数据,数据湖又太过于不规则,难以管理。湖仓一体,其含义是指将数据湖的语义灵活性与数据仓库的生产优化和交付相结合。主要的是消费性和使用价值的提升。
- DATA + AI
AI4DB:自配置(调参)、自诊断、自优化(统计信息、代价估计、学习型优化器、索引/视图推荐)
DB4AI:内嵌人工智能算法(MLSQL , SQLFlow)、内嵌机器学习框架(SparkML , Alink , dl-on-flink )
这节课程比较高屋建瓴地帮助我看到了大数据的整体体系,其中每一个部分是如何运作以及如何发展的。对于SQL查询优化器,应该在数据库的时候有学到但是没有讲到这么深刻。收获颇多,但是又让我产生了新的疑惑,就像因为对非事务性分析的需求出现了列级的OLAP,数仓和数据湖的缺点出现了湖仓一体,再进化架构方向还有哪些可以改进的呢?老师有提到SIGMOD会议2022多是关于AI的文章,可能跟近来发文都跟AI挂钩有些关联,但是AI终究是算法这个部分能做的。至于想要了解前沿的探索,还是需要多看论文多学习啊。