当打造一款极速湖分析产品时，我们在想些什么

其实 StarRocks 早在 2.2 版本起，就引入了 Apache Hive（以下简称 Hive）/Iceberg/Hudi 外部表等特性，并在离线报表、即席查询等场景积累了成熟的用户案例。从一条 SQL 的生命周期来说，StarRocks 除了在查询规划阶段 FE 节点对 Hive metastore 发起元数据请求，以及执行查询计划时 BE 扫描对象存储以外，其他阶段可以实现高度的复用。这意味，一方面，得益于 CBO 和向量化执行引擎带来的特性，StarRocks 数据湖分析在内存计算阶段有明显的优势；另一方面，我们也意识到，元数据服务请求和 DFS/对象存储之上 Scan 等环节，在整个 SQL 生命周期里可能会成为影响用户查询体验的关键。

• Extreme performance：用极致查询性能赋能数据驱动的业务团队，让用户快速获得对数据的见解

• Out-of-box：需要提供更加开箱即用的数据接入体验，以及更加安全合规的数据接入模式

• Cost effective：为用户提供具有性价比的资源持有方案，成为 Price-performance 维度的技术选型最优解

• Uniformed platform：StarRocks 是带有自管数据的现代架构 MPP 数据库。当用户分析内部数据和外部数据时，如何带来一致的数据管理体验，也是致力于现代湖仓架构的 StarRocks 面临的核心挑战之一。

我们第一阶段目标是对标主流的查询引擎产品（例如 Presto/Trino），为数据湖上的查询负载带来 3-5 倍的性能提升。在团队向这一目标推进过程中，我们的产品也遭遇了场景差异性带来的挑战。不同于查询内表场景，对元数据服务以及分布式文件存储的响应波动的鲁棒性直接决定了用户侧的查询体验是否平稳。

在这里，我们以一条 Query on Hive 的生命周期来举例，说明不同阶段我们遇到的问题：

• 查询规划阶段：若用户查询历史明细数据，单条 Query 可能会同步触发大量 Table Partition 的元数据请求，Metastore 的抖动又会导致 CBO 等待超时，最终引发查询失败。这是一个 Adhoc 场景中最典型的案例。在查询规划阶段，如何在元信息拉取的全面性和时效性上做出体验最好的权衡？

• 资源调度阶段：Adhoc 场景下的系统负载有明显的峰谷差异，从资源成本角度出发，弹性扩缩容自然是一个查询组件在公有云场景需要具备的基础特性。而在 StarRocks 存算一体的架构里，BE 节点扩缩容过程伴随着数据重分布的代价。因此，如何才能为用户提供容器化部署以及水平伸缩的可能性？另一方面，在大规模用例里经常会出现多业务部门共享集群的场景，如何为运行在数据湖上的查询负载提供很好的隔离性，降低业务之间的影响？

• 查询计划生成阶段：查询数据湖时，目标数据的文件分布决定了 Scan 过程的 IO 开销，而文件分布一般又取决于上游写入习惯与文件合并策略。对于上游 CDC 入湖过程中里的大量小文件，如何设计灵活 Scan Policy 才能缓解 IO 带来的查询性能瓶颈？

• 查询执行阶段：我们都知道在生产环境中，HDFS 本身由于抖动带来访问延迟是很常见的现象，而这类抖动就直接给查询速度造成波动，很影响业务用户的分析体感。同时，Adhoc 场景本身的查询习惯（例如针对全量历史数据的一次聚合计算）决定了瓶颈并不在内存计算而是在 IO 上。如何让 Query 再快一点？想在外部存储上直接优化 IO 的问题，最直接的想法就是针对局部性较强的查询场景，提供针对远端存储的数据文件 Cache 能力。

相信关注 StarRocks 的读者中很大一部分是基础架构领域的从业人员。但凡和业务团队打过交道，都会感同身受：推动业务部门升级基础技术组件，成本非常的高。对公司 IT 治理来说，在每一次技术选型里，能否全面 cover 旧方案的基础用例、把控业务迁移里的 bad case 同样会影响选型成败。此时 StarRocks 就更需要站在工程师朋友的视角上，全面审视湖分析场景中“水桶的短板”到底在哪里。

• 数据安全：数据湖作为维护企业核心数据资产的基础设施，一般在企业内都会为其维护成熟的访问控制策略，例如，在传统 Hadoop 生态中基于 Kerberos 来定制统一认证，用 Ranger 做统一 ACL 管理；或者是接入云厂商托管的 IAM 服务。这些不同场景下数据治理的事实标准，均是考量数据湖分析产品成熟度的重要参考。

• 业务迁移：在尝试用 StarRocks 来帮助用户替换存量的 Presto/SparkSQL 查询负载的过程中，用户需要同步迁移原有的业务 SQL，甚至是 UDF。系统之间的语法糖差异越大，用户在迁移过程里进行 SQL 重写的成本就越高昂。面对引擎之间的语法差异，如何尽可能给用户带来平滑的迁移体感？

• 元数据管理：StarRocks 作为具有自管数据的 OLAP 系统，如果同时接入外部湖上的数据，意味着需要统筹管理系统内部/外部的元数据，并通过 StarRocks 展示统一视图。系统外部元数据同步的数据一致性和开箱即用如何权衡？

历史上，Hive 在大数据生态中并不是产品力最出众的，正是其对计算引擎的包容普适性逐步造就了其不可替代的位置。StarRocks 站在 OLAP 查询层的角度也希望为社区用户构建一种普适性：于湖分析场景来说，任意数据源的接入需求，社区开发者都能够快速流畅地完成接入开发。优雅高度抽象的代码框架，理想中可以带来一种双赢的协作模式：用户的需求能够以社区互助的方式得到敏捷响应，产品能力也可以像滚雪球一样愈加丰满，伴随社区生态不断成长。

#03

思考和关键行动

—

支持 Hudi 的 MOR 表（2.5.0 发布）

StarRocks 在 2.4 版本就通过 Catalog 提供了 Hudi 数据的接入能力。在即将发布的 2.5.0 版本，StarRocks 将会支持以 Snapshot query 和 Read optimized query 两种查询模式来支持 Hudi 的 MOR 表。

借助该特性，在数据实时入湖场景（例如上游 Flink CDC 到 Hudi），StarRocks 就可以更好支持用户对实时落盘数据的分析需求。

支持 Delta Lake Catalog（2.5.0 发布）

在 2.5.0 版本中，StarRocks 将正式通过 Catalog 支持分析 Delta lake。目前支持以 Hive metastore 作为元数据服务，即将支持 AWS Glue。未来还将计划逐步对接 Databricks 原生的元数据存储。

通过这种方式，在 Spark 生态里批处理完成的数据，用户就可以无需重复拷贝，直接在 StarRock 进行交互式分析。

支持 Iceberg V2 表（在 2.5.X 即将发布）

StarRocks 在 2.4 版本就通过 Catalog 提供了 Iceberg V1 数据的接入能力。在未来的 2.5 小版本中，我们即将正式支持对接 Iceberg V2 格式，全面打通 Iceberg 与 StarRocks 的数据生态。

支持 Parquet/ORC 文件外表

在部分场景下，用户的数据文件直接由 Spark Job 或者其他方式写入 DFS 生成，并不具备一个存储在 Metastore 中的完整 Schema 信息。用户如果希望直接分析这些文件，按照以往只能全量导入 StarRocks 后再进行分析。在一些临时的数据分析场景下，这种全量导入的模式操作代价比较昂贵。

Multi-catalog (2.3.0已发布)

借助 External Catalog，用户无需创建外部表即可对湖中的数据进行分析，维护 StarRocks 的平台团队也无需维护两个系统之间的元数据一致性。

为了优化重 IO 场景下的查询场景，一方面降低热数据查询场景下，相同原始数据反复读取的 IO 代价，另一方面缓解 DFS 本身波动对查询性能带来的波动，StarRocks 在 2.5.0 即将正式发布 Block cache 特性。

在 StarRocks 里，Block 是对 DFS/对象存储中原始文件按照一定策略切分后的数据对象，也是 StarRocks 对原始数据文件进行缓存时的最小数据单元。当查询命中 DFS/对象存储中文件后，StarRocks 会对命中的 Block 进行本地缓存，支持内存+本地磁盘的混合存储介质方式，并分别配置 Cache 对内存和本地磁盘的占用空间上限。基于 LRU 策略对远端对象存储上的 Block 进行载入和淘汰。

通过这种方式，大幅度优化了 HDFS 本身抖动的问题，无需频繁访问 HDFS；同时对于热点数据上的交互式探查场景，大大提升了远端对象存储的数据拉取效率，用户分析体验得到极大提升。更重要的是，整个缓存机制没有引入任何的外部依赖，通过配置文件即可开启。

从 2.5.0 版本起，StarRocks 的 FE/BE 也基本完成了容器化部署的兼容。不久，社区官方 Operator 也即将发布，届时将会大大提升运维效率和生产力。

StarRocks 在 2.2 版本发布了资源隔离能力。在 2.3 版本支持了通过资源组来对数据湖上的查询负载进行隔离。通过这种软隔离的资源划分机制，能够让这些 Adhoc query 运行时在特定的 CPU 核数/内存范围之下，用户的大规模集群在同时支持多个部门的固定报表分析业务和 Adhoc 业务时，能够具有更好的隔离性，湖上的大查询相互之间可以优先保障稳定。

• 通过统一的 Access key/Secret key 来进行用户身份进行认证和鉴权
• 通过 IAM Role 搭配角色代理的机制，来实现不同角色身份的动态切换
• 借助 AWS EC2 的 Instance profile 中自带的身份信息进行认证

在未来的 V2.5.X 小版本里，StarRocks 数据湖分析将会对上述几种公有云场景用户常用的认证方式进行完备的兼容。未来 StarRocks 在公有云上的数据访问管理将会更加省心省力，数据安全不再成为企业云上 OLAP 技术选型的顾虑。