数据库|如何打造一款极速数据湖分析引擎( 四 ) 算法|CPU

Frontend

FE 的主要作用将 SQL 语句通过一系列转化和优化，最终转换成 BE 能够认识的一个个 Fragment 。一个不那么准确但易于理解的比喻，如果把 BE 集群当成一个分布式的线程池的话，那么 Fragment 就是线程池中的 Task 。从 SQL 文本到 Fragment ， FE 的主要工作包含以下几个步骤:
SQL Parse：将 SQL 文本转换成一个 AST(抽象语法树) Analyze：基于 AST 进行语法和语义分析 Logical Plan：将 AST 转换成逻辑计划 Optimize：基于关系代数，统计信息， Cost 模型对逻辑计划进行重写，转换，选择出 Cost “最低” 的物理执行计划生成 Fragment：将 Optimizer 选择的物理执行计划转换为 BE 可以直接执行的 Fragment Coordinate：将 Fragment 调度到合适的 BE 上执行 Backend

BE 是 StarRocks 的后端节点，负责接收 FE 传下来的 Fragment 执行并返回结果给 FE 。 StarRocks 的 BE 节点都是完全对等的， FE 按照一定策略将数据分配到对应的 BE 节点。常见的 Fragment 工作流程是读取数据湖中的部分文件，并调用对应的 Reader （例如，适配 Parquet 文件的 Parquet Reader 和适配 ORC 文件的 ORC Reader等）解析这些文件中的数据，使用向量化执行引擎进一步过滤和聚合解析后的数据后，返回给其他 BE 或 FE 。
总结本篇文章主要介绍了极速数据湖分析引擎的核心技术原理，从多个维度对比了不同技术实现方案。为方便接下来的深入探讨，进一步介绍了开源数据湖分析引擎 StarRocks 的系统架构设计。希望和各位同仁共同探讨、交流。
附录基准测试
本次测试采用的 TPCH 100G 的标准测试集，分别对比测试了 StarRocks 本地表， StarRocks On Hive 和 Trino（PrestoSQL） On Hive 三者之间的性能差距。
在TPCH 100G规模的数据集上进行对比测试，共22个查询，结果如下：

StarRocks 使用本地存储查询和 Hive 外表查询两种方式进行测试。其中， StarRocks On Hive 和 Trino On Hive 查询的是同一份数据，数据采用 ORC 格式存储，采用 zlib 格式压缩。测试环境使用阿里云 EMR 进行构建。
最终， StarRocks 本地存储查询总耗时为21s ， StarRocks Hive 外表查询总耗时92s 。 Trino 查询总耗时307s 。可以看到 StarRocks On Hive 在查询性能方面远远超过 Trino ，但是对比本地存储查询还有不小的距离，主要的原因是访问远端存储增加了网络开销，以及远端存储的延时和 IOPS 通常都不如本地存储，后面的计划是通过 Cache 等机制弥补问题，进一步缩短 StarRocks 本地表和 StarRocks On Hive 的差距。
参考资料 [1
GitHub - jordanlewis/exectoy
[2
DBMSs On A Modern Processor: Where Does Time Go?[3
Block oriented processing of Relational Database operations in modern Computer Architectures
[4
MonetDB/X100: Hyper-Pipelining Query Execution
[5
https://help.aliyun.com/document_detail/404790.html
作者：阿里云 EMR 开源大数据 OLAP 团队、StarRocks 社区数据湖分析团队
本文为阿里云原创内容，未经允许不得转载。