EMR StarRocks 极速数据湖分析原理解析
简介：数据湖概念日益火热，本文由阿里云开源大数据 OLAP 团队和 StarRocks 数据湖分析团队共同为大家介绍“ StarRocks 极速数据湖分析 ”背后的原理。 【首月99元】EMR StarRocks 数据湖极速分析体验，试用火热进行中，快来申请吧 -> https://survey.aliyun.com/apps/zhiliao/Yns9d9Xxz
StarRocks 是一个强大的数据分析系统，主要宗旨是为用户提供极速、统一并且易用的数据分析能力，以帮助用户通过更小的使用成本来更快的洞察数据的价值。通过精简的架构、高效的向量化引擎以及全新设计的基于成本的优化器（CBO），StarRocks 的分析性能（尤其是多表 JOIN 查询）得以远超同类产品。
为了能够满足更多用户对于极速分析数据的需求，同时让 StarRocks 强大的分析能力应用在更加广泛的数据集上，阿里云开源大数据 OLAP 团队联合社区一起增强 StarRocks的数据湖分析能力。使其不仅能够分析存储在 StarRocks 本地的数据，还能够以同样出色的表现分析存储在 Apache Hive、Apache Iceberg 和 Apache Hudi 等开源数据湖或数据仓库的数据。
本文将重点介绍 StarRocks 极速数据湖分析能力背后的技术内幕，性能表现以及未来的规划。
一、整体架构
StarRocks 的架构非常简洁，整个系统的核心只有 FE（Frontend）、BE（Backend）两类进程，不依赖任何外部组件，方便部署与维护。其中 FE 主要负责解析查询语句（SQL），优化查询以及查询的调度，而 BE 则主要负责从数据湖中读取数据，并完成一系列的 Filter 和 Aggregate 等操作。
数据湖本身是一类技术概念的集合，常见的数据湖通常包含 Table Format、File Format 和 Storage 三大模块。其中 Table Format 是数据湖的“UI”，其主要作用是组织结构化、半结构化，甚至是非结构化的数据，使其得以存储在像 HDFS 这样的分布式文件系统或者像 OSS 和 S3 这样的对象存储中，并且对外暴露表结构的相关语义。Table Format 包含两大流派，一种是将元数据组织成一系列文件，并同实际数据一同存储在分布式文件系统或对象存储中，例如 Apache Iceberg、Apache Hudi 和 Delta Lake 都属于这种方式；还有一种是使用定制的 metadata service 来单独存放元数据，例如 StarRocks 本地表，Snowflake 和 Apache Hive 都是这种方式。
File Format 的主要作用是给数据单元提供一种便于高效检索和高效压缩的表达方式，目前常见的开源文件格式有列式的 Apache Parquet 和 Apache ORC，行式的 Apache Avro 等。
Storage 是数据湖存储数据的模块，目前数据湖最常使用的 Storage 主要是分布式文件系统 HDFS，对象存储 OSS 和 S3 等。
FE
- SQL Parse： 将 SQL 文本转换成一个 AST(抽象语法树)
- SQL Analyze：基于 AST 进行语法和语义分析
- SQL Logical Plan： 将 AST 转换成逻辑计划
- SQL Optimize：基于关系代数，统计信息，Cost 模型对 逻辑计划进行重写，转换，选择出 Cost “最低” 的物理执行计划
- 生成 Plan Fragment：将 Optimizer 选择的物理执行计划转换为 BE 可以直接执行的 Plan Fragment。
- 执行计划的调度
BE
StarRocks 的 BE 节点都是完全对等的，FE 按照一定策略将数据分配到对应的 BE 节点。在数据导入时，数据会直接写入到 BE 节点，不会通过FE中转，BE 负责将导入数据写成对应的格式以及生成相关索引。在执行 SQL 计算时，一条 SQL 语句首先会按照具体的语义规划成逻辑执行单元，然后再按照数据的分布情况拆分成具体的物理执行单元。物理执行单元会在数据存储的节点上进行执行，这样可以避免数据的传输与拷贝，从而能够得到极致的查询性能。
二、技术细节
StarRocks 为什么这么快
CBO 优化器
CBO 优化器好坏的关键之一是 Cost 估计是否准确，而 Cost 估计是否准确的关键点之一是统计信息是否收集及时，准确。 StarRocks 目前支持表级别和列级别的统计信息，支持自动收集和手动收集两种方式，无论自动还是手动，都支持全量和抽样收集两种方式。
MPP 执行
MPP (massively parallel processing) 是大规模并行计算的简称，核心做法是将查询 Plan 拆分成很多可以在单个节点上执行的计算实例，然后多个节点并行执行。 每个节点不共享 CPU，内存, 磁盘资源。MPP 数据库的查询性能可以随着集群的水平扩展而不断提升。
如上图所示，Shuffle （数据重分布）操作是 MPP 数据库查询性能可以随着集群的水平扩展而不断提升的关键，也是实现高基数聚合和大表 Join 的关键。
向量化执行引擎
向量化执行不仅仅是数据库所有算子的向量化和表达式的向量化，而是一项巨大和复杂的性能优化工程，包括数据在磁盘，内存，网络中的按列组织，数据结构和算法的重新设计，内存管理的重新设计，SIMD 指令优化，CPU Cache 优化，C++优化等。向量化执行相比之前的按行执行，整体性能提升了5到10倍。
StarRocks 如何优化数据湖分析
大数据分析领域，数据除了存储在数仓之外，也会存储在数据湖当中，传统的数据湖实现方案包括 Hive/HDFS。近几年比较火热的是 LakeHouse 概念，常见的实现方案包括 Iceberg/Hudi/Delta。那么 StarRocks 能否帮助用户更好地挖掘数据湖中的数据价值呢？答案是肯定的。
在前面的内容中我们介绍了 StarRocks 如何实现极速分析，如果将这些能力用于数据湖肯定会带来更好地数据湖分析体验。在这部分内容中，我们会介绍 StarRocks 是如何实现极速数据湖分析的。
我们先看一下全局的架构，StarRocks 和数据湖分析相关的主要几个模块如下图所示。其中 Data Management 由数据湖提供，Data Storage 由对象存储 OSS/S3，或者是分布式文件系统 HDFS 提供。
- 支持 Iceberg v1 表查询
- 支持 Hive 外表查询
- 支持 Hudi COW 表查询
接下来我们从查询优化和查询执行这几个方面来看一下，StarRocks 是如何实现将极速分析的能力赋予数据湖的。
查询优化
查询优化这部分主要是利用前面介绍的 CBO 优化器来实现，数据湖模块需要给优化器统计信息。基于这些统计信息，优化器会利用一系列策略来实现查询执行计划的最优化。接下来我们通过例子看一下几个常见的策略。
统计信息
我们看下面这个例子，生成的执行计划中，HdfsScanNode 包含了 cardunality、avgRowSize 等统计信息的展示。
MySQL [hive_test]> explain select l_quantity from lineitem; +-----------------------------+ | Explain String | +-----------------------------+ | PLAN FRAGMENT 0 | | OUTPUT EXPRS:5: l_quantity | | PARTITION: UNPARTITIONED | | | | RESULT SINK | | | | 1:EXCHANGE | | | | PLAN FRAGMENT 1 | | OUTPUT EXPRS: | | PARTITION: RANDOM | | | | STREAM DATA SINK | | EXCHANGE ID: 01 | | UNPARTITIONED | | | | 0:HdfsScanNode | | TABLE: lineitem | | partitions=1/1 | | cardinality=126059930 | | avgRowSize=8.0 | | numNodes=0 | +-----------------------------+
在正式进入到 CBO 优化器之前，这些统计信息都会计算好。比如针对 Hive 我们有 MetaData Cache 来缓存这些信息，针对 Iceberg 我们通过 Iceberg 的 manifest 信息来计算这些统计信息。获取到这些统计信息之后，对于后续的优化策略的效果有很大地提升。
分区裁剪
分区裁剪是只有当目标表为分区表时，才可以进行的一种优化方式。分区裁剪通过分析查询语句中的过滤条件，只选择可能满足条件的分区，不扫描匹配不上的分区，进而显著地减少计算的数据量。比如下面的例子，我们创建了一个以 ss_sold_date_sk 为分区列的外表。
create external table store_sales(
ss_sold_time_sk bigint
, ss_item_sk bigint
, ss_customer_sk bigint
, ss_coupon_amt decimal(7,2)
, ss_net_paid decimal(7,2)
, ss_net_paid_inc_tax decimal(7,2)
, ss_net_profit decimal(7,2)
, ss_sold_date_sk bigint
) ENGINE=HIVE
PROPERTIES (
"resource" = "hive_tpcds",
"database" = "tpcds",
"table" = "store_sales"
);
在执行如下查询的时候，分区2451911和2451941之间的数据才会被读取，其他分区的数据会被过滤掉，这可以节约很大一部分的网络 IO 的消耗。
select ss_sold_time_sk from store_sales where ss_sold_date_sk between 2451911 and 2451941 order ss_sold_time_sk;
Join Reorder
多个表的 Join 的查询效率和各个表参与 Join 的顺序有很大关系。如 select * from T0, T1, T2 where T0.a=T1.a and T2.a=T1.a，这个 SQL 中可能的执行顺序有下面两种情况：
- T0 和 T1 先做 Join，然后再和 T2 做 Join
- T1 和 T2 先做 Join，然后再和 T0 做 Join
根据 T0 和 T2 的数据量及数据分布，这两种执行顺序会有不同的性能表现。针对这个情况，StarRocks 在优化器中实现了基于 DP 和贪心的 Join Reorder 机制。目前针对 Hive的数据分析，已经支持了 Join Reorder，其他的数据源的支持也正在开发中。下面是一个例子：
MySQL [hive_test]> explain select * from T0, T1, T2 where T2.str=T0.str and T1.str=T0.str; +----------------------------------------------+ | Explain String | +----------------------------------------------+ | PLAN FRAGMENT 0 | | OUTPUT EXPRS:1: str | 2: str | 3: str | | PARTITION: UNPARTITIONED | | RESULT SINK | | 8:EXCHANGE | | PLAN FRAGMENT 1 | | OUTPUT EXPRS: | | PARTITION: HASH_PARTITIONED: 2: str | | STREAM DATA SINK | | EXCHANGE ID: 08 | | UNPARTITIONED | | 7:HASH JOIN | | | join op: INNER JOIN (BUCKET_SHUFFLE(S)) | | | hash predicates: | | | colocate: false, reason: | | | equal join conjunct: 1: str = 3: str | | |----6:EXCHANGE | | 4:HASH JOIN | | | join op: INNER JOIN (PARTITIONED) | | | hash predicates: | | | colocate: false, reason: | | | equal join conjunct: 2: str = 1: str | | |----3:EXCHANGE | | 1:EXCHANGE | | PLAN FRAGMENT 2 | | OUTPUT EXPRS: | | PARTITION: RANDOM | | STREAM DATA SINK | | EXCHANGE ID: 06 | | HASH_PARTITIONED: 3: str | | 5:HdfsScanNode | | TABLE: T2 | | partitions=1/1 | | cardinality=1 | | avgRowSize=16.0 | | numNodes=0 | | PLAN FRAGMENT 3 | | OUTPUT EXPRS: | | PARTITION: RANDOM | | STREAM DATA SINK | | EXCHANGE ID: 03 | | HASH_PARTITIONED: 1: str | | 2:HdfsScanNode | | TABLE: T0 | | partitions=1/1 | | cardinality=1 | | avgRowSize=16.0 | | numNodes=0 | | PLAN FRAGMENT 4 | | OUTPUT EXPRS: | | PARTITION: RANDOM | | STREAM DATA SINK | | EXCHANGE ID: 01 | | HASH_PARTITIONED: 2: str | | 0:HdfsScanNode | | TABLE: T1 | | partitions=1/1 | | cardinality=1 | | avgRowSize=16.0 | | numNodes=0 | +----------------------------------------------+
谓词下推
谓词下推将查询语句中的过滤表达式计算尽可能下推到距离数据源最近的地方，从而减少数据传输或计算的开销。针对数据湖场景，我们实现了将 Min/Max 等过滤条件下推到 Parquet 中，在读取 Parquet 文件的时候，能够快速地过滤掉不用的 Row Group。
比如，对于下面的查询，l_discount=1对应条件会下推到 Parquet 侧。
MySQL [hive_test]> explain select l_quantity from lineitem where l_discount=1; +----------------------------------------------------+ | Explain String | +----------------------------------------------------+ | PLAN FRAGMENT 0 | | OUTPUT EXPRS:5: l_quantity | | PARTITION: UNPARTITIONED | | | | RESULT SINK | | | | 2:EXCHANGE | | | | PLAN FRAGMENT 1 | | OUTPUT EXPRS: | | PARTITION: RANDOM | | | | STREAM DATA SINK | | EXCHANGE ID: 02 | | UNPARTITIONED | | | | 1:Project | | | <slot 5> : 5: l_quantity | | | | | 0:HdfsScanNode | | TABLE: lineitem | | NON-PARTITION PREDICATES: 7: l_discount = 1.0 | | partitions=1/1 | | cardinality=63029965 | | avgRowSize=16.0 | | numNodes=0 | +----------------------------------------------------+
其他策略
除了上面介绍的几种策略，针对数据湖分析，我们还适配了如 Limit 下推、TopN 下推、子查询优化等策略。能够进一步地优化查询性能。
查询执行
前面介绍了，StarRocks 的执行引擎是全向量化、MPP 架构的，这些无疑都会给我们分析数据湖的数据带来很大提升。接下来我们看一下 StarRocks 是如何调度和执行数据湖分析查询的。
查询调度
数据湖的数据一般都存储在如 HDFS、OSS 上，考虑到混部和非混部的情况。我们对 Fragment 的调度，实现了一套负载均衡的算法。
- 做完分区裁剪之后，得到要查询的所有 HDFS 文件 block
- 对每个 block 构造 THdfsScanRange，其中 hosts 包含 block 所有副本所在的 datanode 地址，最终得到 List
- Coordinator 维护一个所有 be 当前已经分配的 scan range 数目的 map，每个 datanode 上磁盘已分配的要读取 block 的数目的 map>，及每个 be 平均分配的 scan range 数目 numScanRangePerBe
- 如果 block 副本所在的 datanode 有be（混部）
- 每个 scan range 优先分配给副本所在的 be 中 scan range 数目最少的 be。如果 be 已经分配的 scan range 数目大于 numScanRangePerBe，则从远程 be 中选择 scan range 数目最小的
- 如果有多个 be 上 scan range 数目一样小，则考虑 be 上磁盘的情况，选择副本所在磁盘上已分配的要读取 block 数目小的 be
- 如果 block 副本所在的 datanode 机器没有 be（单独部署或者可以远程读）
- 选择 scan range 数目最小的 be
查询执行
在调度到 BE 端进行执行之后，整个执行过程都是向量化的。具体看下面 Iceberg 的例子，IcebergScanNode 对应的 BE 端目前是 HdfsScanNode 的向量化实现，其他算子也是类似，在 BE 端都是向量化的实现。
MySQL [external_db_snappy_yuzhou]> explain select c_customer_id customer_id
-> ,c_first_name customer_first_name
-> ,c_last_name customer_last_name
-> ,c_preferred_cust_flag customer_preferred_cust_flag
-> ,c_birth_country customer_birth_country
-> ,c_login customer_login
-> ,c_email_address customer_email_address
-> ,d_year dyear
-> ,'s' sale_type
-> from customer, store_sales, date_dim
-> where c_customer_sk = ss_customer_sk
-> and ss_sold_date_sk = d_date_sk;
+------------------------------------------------
| PLAN FRAGMENT 0
| OUTPUT EXPRS:2: c_customer_id | 9: c_first_name | 10: c_last_name | 11: c_preferred_cust_flag | 15: c_birth_country | 16: c_login | 17: c_email_address | 48: d_year | 70: expr |
| PARTITION: UNPARTITIONED
| RESULT SINK
| 9:EXCHANGE
| PLAN FRAGMENT 1
| OUTPUT EXPRS:
| PARTITION: RANDOM
| STREAM DATA SINK
| EXCHANGE ID: 09
| UNPARTITIONED
| 8:Project
| | <slot 2> : 2: c_customer_id
| | <slot 9> : 9: c_first_name
| | <slot 10> : 10: c_last_name
| | <slot 11> : 11: c_preferred_cust_flag
| | <slot 15> : 15: c_birth_country
| | <slot 16> : 16: c_login
| | <slot 17> : 17: c_email_address
| | <slot 48> : 48: d_year
| | <slot 70> : 's'
| 7:HASH JOIN
| | join op: INNER JOIN (BROADCAST)
| | hash predicates:
| | colocate: false, reason:
| | equal join conjunct: 21: ss_customer_sk = 1: c_customer_sk
| 4:Project
| | <slot 21> : 21: ss_customer_sk
| | <slot 48> : 48: d_year
| 3:HASH JOIN
| | join op: INNER JOIN (BROADCAST)
| | hash predicates:
| | colocate: false, reason:
| | equal join conjunct: 41: ss_sold_date_sk = 42: d_date_sk
| 0:IcebergScanNode
| TABLE: store_sales
| cardinality=28800991
| avgRowSize=1.4884362
| numNodes=0
| PLAN FRAGMENT 2
| OUTPUT EXPRS:
| PARTITION: RANDOM
| STREAM DATA SINK
| EXCHANGE ID: 06
| UNPARTITIONED
| 5:IcebergScanNode
| TABLE: customer
| cardinality=500000
| avgRowSize=36.93911
| numNodes=0
| PLAN FRAGMENT 3
| OUTPUT EXPRS:
| PARTITION: RANDOM
| STREAM DATA SINK
| EXCHANGE ID: 02
| UNPARTITIONED
| 1:IcebergScanNode
| TABLE: date_dim
| cardinality=73049
| avgRowSize=4.026941
| numNodes=0
三、基准测试
TPC-H 是美国交易处理效能委员会TPC（Transaction Processing Performance Council）组织制定的用来模拟决策支持类应用的测试集。 It consists of a suite of business oriented ad-hoc queries and concurrent data modifications.
TPC-H 根据真实的生产运行环境来建模，模拟了一套销售系统的数据仓库。该测试共包含8张表，数据量可设定从1 GB~3 TB不等。其基准测试共包含了22个查询，主要评价指标为各个查询的响应时间，即从提交查询到结果返回所需时间。
测试结论
在 TPCH 100G规模的数据集上进行对比测试，共22个查询，结果如下：
最终，StarRocks 本地存储查询总耗时为21s，StarRocks Hive 外表查询总耗时92s。Trino 查询总耗时307s。可以看到 StarRocks On Hive 在查询性能方面远远超过 Trino，但是对比本地存储查询还有不小的距离，主要的原因是访问远端存储增加了网络开销，以及远端存储的延时和 IOPS 通常都不如本地存储，后面的计划是通过 Cache 等机制弥补问题，进一步缩短 StarRocks 本地表和 StarRocks On Hive 的差距。
具体测试过程请参考：
四、未来规划
得益于全面向量化执行引擎，CBO 优化器以及 MPP 执行框架等核心技术，目前 StarRocks 已经实现了远超其他同类产品的极速数据湖分析能力。从长远来看， StarRocks 在数据湖分析方向的愿景是为用户提供极其简单、易用和高速的数据湖分析能力。为了能够实现这一目标，StarRocks 现在还有许多工作需要完成，其中包括：
- 集成 Pipeline 执行引擎，通过 Push Based 的流水线执行方式，进一步降低查询响应速度
- 自动的冷热数据分层存储，用户可以将频繁更新的热数据存储在 StarRocks 本地表上，StarRocks 会定期自动将冷数据从本地表迁移到数据湖
- 去掉显式建立外表的步骤，用户只需要建立数据湖对应的 resource 即可实现数据湖库表全自动同步
- 进一步完善 StarRocks 对于数据湖产品特性的支持，包括支持 Apache Hudi 的 MOR 表和 Apache Iceberg 的 v2 表；支持直接写数据湖；支持 Time Travel 查询，完善 Catalog 的支持度等
- 通过层级 Cache 来进一步提升数据湖分析的性能
五、更多信息
参考链接
[1]
[2]
[3]
[5]
本文为阿里云原创内容，未经允许不得转载。
【推荐】国内首个AI IDE，深度理解中文开发场景，立即下载体验Trae
【推荐】编程新体验，更懂你的AI，立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包，你的智能百科全书，全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell：AI 加持，快人一步
· DeepSeek 开源周回顾「GitHub 热点速览」
· 物流快递公司核心技术能力-地址解析分单基础技术分享
· .NET 10首个预览版发布：重大改进与新特性概览！
· AI与.NET技术实操系列（二）：开始使用ML.NET
· 单线程的Redis速度为什么快？
2021-03-29 埃森哲携手阿里云共建基于云原生的消费者运营中台解决方案
2021-03-29 如何做一场高质量的分享？
2021-03-29 阿里云云效技术专家：一文详解kubernetes下5种常见发布模式如何选择
2021-03-29 Knativa 基于流量的灰度发布和自动弹性实践
2021-03-29 面对不可避免的故障，我们造了一个“上帝视角”的控制台