+----------------------------------------------------+
其他策略
除了上面介绍的几种策略 ， 针对数据湖分析 ， 我们还适配了如 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