40% 降本：多点 DMALL x StarRocks 的湖仓升级实战

小编导读：

多点 DMALL 成立于2015年，持续深耕零售业，为企业提供一站式全渠道数字零售解决方案 DMALL OS。作为 DMALL OS 数字化能力的技术底座，大数据平台历经多次迭代平稳支撑了公司 To B 业务的快速开展。随着国家产业升级和云原生技术的成熟，平台架构也从存算一体逐步转向存算分离。本文将以 StarRocks 的升级演进为例，分享这一过程中的探索与实践。

通过引入 StarRocks 的存算分离架构、Lakehouse （ Apache Iceberg 外表查询）与 StarRocks on Kubernetes 等特性，多点 DMALL 大数据平台取得了显著成效：

• 计算资源使用率提高 20%，存储成本降低 40%。
• 数据建模工作减少，开发效率提升 20%。
• 新集群部署时间缩短至 1 小时内。

背景

架构1.0

2021 年，多点 DMALL 开始采用 StarRocks 作为统一的大数据 OLAP 引擎。关于当时架构 1.0 版本的背景与使用细节，已在《多点 DMALL x StarRocks：实现存储引擎的收敛，保障高查询并发及低延迟要求》中详细讲述，本文不再赘述。

简而言之，“数据湖+数据仓库”分层架构虽然能够满足业务需求，但在计算资源利用、存储效率及可靠性方面存在以下问题：

• 计算资源浪费：潮汐现象导致资源利用率低，按峰值申请的计算资源经常闲置。
• 存储数据冗余：数据需额外同步，多副本存储加剧浪费。
• 可靠性挑战：数据同步复杂，扩容延迟影响用户体验。

架构2.0

在“降本增效”的大背景下，多点 DMALL 大数据部门于 2023 年完成了以“数据湖”为核心的大数据平台升级（详见 [1]），引入云原生、存算分离和湖仓一体等新技术。升级后的平台架构如下图所示：

经过存算分离改造后，大数据平台与 StarRocks 的部署架构和数据链路已升级为如下所示：

2023 年中，StarRocks 发布 3.x 版本，新增存算分离、External Catalog 和 Kubernetes 部署等核心特性。在充分调研与验证后，我们利用 3.x 版本对“仓”进行了改造，并经过半年改造与测试，最终形成如下架构：

• 降低计算成本：StarRocks 计算负载的高峰期集中在白天，Apache Spark 等离线计算负载的高峰期集中在晚上，从宏观上看，可共享同一批资源。按需分配资源显著提升了整体利用率，降低了计算成本。
• 降低存储成本：StarRocks 支持将内部表存储在兼容 S3 协议的对象存储中，以按需付费模式大幅降低存储成本。此外，可直接读取 Apache Hive 和 Apache Iceberg 中的数据，减少冗余存储，进一步节省成本。
• 保证查询性能：通过本地磁盘缓存，StarRocks 在存储分离架构下的查询性能媲美存算一体。同时，基于 Kubernetes 的 HPA 机制，动态调整资源分配，优化用户体验。

应用场景

在完成数据平台架构升级后，我们对增量和部分存量业务进行了改造适配。

多点的数据分析场景主要分为离线 T+1 更新分析和实时更新分析两类。在这两类场景中，我们均采用了新架构进行改造和适配。

T+1 更新分析场景

以 “高维业务报表” 为例，固定维度的分析场景主要针对固化的、标准的业务场景进行分析，帮助企业及时掌握各个维度的业绩情况，助力经营管理层及时进行精细化经营决策。该场景的技术实现主要借助 StarRocks 的 External Catalog 的功能，无需手动建内表，通过自定义 Catalog 直接查询 Iceberg 数据源里的数据。

在充分利用本地 SSD 缓存、自定义刷新缓存逻辑、以及 Kubernetes HPA 弹性扩容的基础上，StarRocks 存算分离模式的查询速率可以达到存算一体的效果，个别大 SQL 在 StarRocks 集群弹性增加 Computer Node Pod 之后，查询速度甚至比存算一体要快一些。以下是“存算一体+内表”和“存算分离+外表” 真实业务场景的对比测试结果（横坐标为查询 SQL，纵坐标为响应时长）

实时更新分析场景

以 “全链路监控”为例，实时更新分析场景主要针对实时监控、实时报警等场景，帮助企业及时发现问题、解决问题。该场景的技术实现主要借助 StarRocks 的 Default Catalog 功能，通过 CDC 将实时业务数据写入 StarRocks 存算分离内表，目前我们采用主键模型进行构建。

从业务 TP 数据库写入数据到最终落入 StarRocks，平均时效性约为 10 秒。通过该方案实现业务数据的实时展示和异常报警，帮助企业及时发现并解决问题，提升运营效率。

收益

从最终效果来看，多点 DMALL 大数据平台引入 StarRocks 的存算分离架构、Lakehouse （外表查询）与 StarRocks on Kubernetes 等特性，在保证存量业务查询性能无影响的前提下，达到了如下收益：

• 机器成本降低：通过引入存算分离的特性，利用“数据持久化使用按需付费的对象存储”、“本地 SSD 盘只用于查询加速”、“计算节点弹性扩缩容” 等特性，整体计算资源使用率提高20%，存储成本降低超过40%；
• 开发效率提高： 通过采用 External Catalog 直接查询 Iceberg 数据源，数据工程师无需再手动建内表，减少了数据建模的工作量，开发效率提高了20%；
• 运维效率提高： 通过采用 StarRocks on Kubernetes 的特性，在部署维护新集群时，无需再手动部署，只需通过 YAML 文件配置即可实现集群的自动部署，提高了运维效率。目前客户私有化环境部署一套新集群，只需要准备好对象存储服务以及 Kubernetes 集群，可以在1小时内完成集群的部署交付。

实践经验

每次技术升级都伴随“阵痛”，架构变化和新特性使得升级过程像是重新学习新引擎，过程中遇到许多挑战，也积累了宝贵经验。本篇文章将秉持技术开源共享的精神，从 Lakehouse（存算分离外表）、Shared Data（存算分离内表）、StarRocks on Kubernetes（部署）等方面总结经验，与大家分享。

Lakehouse

StarRocks 自 2.3 版本起支持 Catalog（数据目录）功能，可在一套系统内同时维护内外部数据，便捷访问并查询各类外部数据源。在此基础上，我们根据自身场景需求进行了以下改造与增强。

1.1 统一数据湖鉴权

StarRocks on Kubernetes 原生支持对接 LDAP 登录及 Apache Ranger 的鉴权。但是为了提升鉴权效率与灵活性，在大数据集群进行升级时我们就已经重构了集群权限体系。

在使用 StarRocks on Kubernetes 之前，我们对 FE 中相关代码进行了调整，对接司内的登录和鉴权逻辑，达到了统一管控的效果。

• 添加自定义登录接口及实现类，对接司内 UniDATA 大数据平台统一登录，无需管理不同引擎的登录信息。
• 简化 StarRocks 的管理权限设计。根据过往司内使用经验，将除库表数据外的其它权限（建立 Catalog、删除 BE 节点、动态修改 FE 配置等）合并为统一的管理权限。并在集群建立时分配给单独的部门组织账户，用于日常管理维护。
• 将库表数据权限，不论外表还是内表，均对接 Ranger 的 Hadoop Table（Hive）模块进行管控。外表可直接对接，内表设计特殊权限数据结构进行对接。这样的做法不但降低权限管理复杂度，也使数据权限在数据湖层面达成了统一。

通过这种处理方式，数据权限与底层引擎实现了解耦。无论是 Spark、Flink 还是 StarRocks，其使用的数据权限在整个大数据集群内保持一致，提升用户一致性的体验，减轻集群运维压力。

1.2 统一查询入口

引入 StarRocks 的 Catalog 的特性之后，在查询数据的时候，可以使用 SET CATALOG  或者 SELECT * FROM .. 来切换 Catalog，进而实现查询 Default Catalog 内部表、External Catalog 外部表中的数据。

为提升客户端使用数据模型的灵活性，我们在不改变原有 SQL 的前提下，实现了数据表存储引擎和 Catalog 的路由切换。在 StarRocks 与客户端之间，增加了自研查询代理引擎 MixDB Proxy。该引擎维护逻辑库与查询引擎、Catalog、物理库的映射信息，支持按需切换存储引擎、Catalog 和库。同时，MixDB Proxy 具备鉴权、限流、降级、资源统计、查询审计等功能，不仅大幅减少业务端切换存储引擎的工作量，还保障了查询服务的稳定性。

1.3 优化本地缓存

• 切换湖表及充分利用缓存

StarRocks 存算分离版本的核心特性之一是支持对 Apache Iceberg 等湖表的查询。升级前，BI 报表全部使用 StarRocks 内表；升级后，大部分数据查询切换为 Apache Iceberg 湖表。这一改进不仅减少了数据冗余，还省去了单独同步 StarRocks 的任务设置，显著降低了运维压力。不过，直接查询湖表的速度较内表慢，所幸新增的本地磁盘缓存特性大幅缩小了这一差距。

以下是缓存使用的核心配置：

Properties
# 启用缓存功能
datacache_enable = true
# 湖表元数据刷新频率，默认10min，这个参数也控制了湖表数据异步刷新的频率
background_refresh_metadata_interval_millis = 600000

• 定时刷新缓存

在升级过程中，我们从 v3.2.7 开始调试，并在正式上线前升级到 v3.3.2。新版本的缓存功能新增了异步填充等策略，进一步提升了用户体验。但在测试对接 BI 分析应用时，仍遇到首次查询报表速度较慢的问题。未配置定时预热时，每日首次查询主要访问 Apache Iceberg 中新的分区数据，大部分数据未被缓存。

尽管 StarRocks 提供了预热功能，但需要设置明确的库表和过滤条件。作为多点 DMALL 大数据基础层，我们面对几十个 StarRocks 集群，每个客户的需求各不相同，难以统一设计和管理这些预热任务。经过讨论，我们决定自研缓存刷新工具。该工具以 Kubernetes 上的 CronJob 作为载体，支持每日定时预刷新缓存，大幅提升了 BI 分析应用用户的使用体验。

缓存刷新工具每日从 AuditLoader Table 中获取最近一段时间的查询 SQL，进行统计和分析。通过解析、拆分与重组，初步整理出查询相关的库表和过滤条件。基于过往查询行为，工具采用统计学习的方法，预测下一日可能的查询数据范围，并据此改写和优化查询条件。

为应对缓存目录容量有限可能触发的 LRU 缓存淘汰问题，工具会根据查询频率对库表进行排序，将高频库表排在最后执行。最终，工具将优化后的查询条件转化为 SQL，并打上标签执行缓存刷新。

1.4 升级开发模式

之前采用 DataLake + Warehouse 分层架构（以 Apache Iceberg + StarRocks 为例）时，可以在对 Apache Iceberg 表的 Schema 或加工逻辑进行修改后，经过充分验证，再将结果数据同步至 StarRocks。在 Apache Iceberg 的逻辑调整及数据重跑过程中，StarRocks 的查询不受影响。

然而，在升级为 Lakehouse 架构后，若修改了 Apache Iceberg 的逻辑，并对原表执行 Insert Overwrite 操作，StarRocks 的查询将立即感知到数据变化。但在数据尚未经过充分验证的情况下，可能会引发数据质量问题。

由于我司采用 Apache Iceberg 作为数据湖的表结构，我们通过 Apache Iceberg 提供的 branch 特性有效解决了这一问题。具体而言，StarRocks 在通过 External Catalog 查询 Apache Iceberg 表时，默认访问的是 main branch。

当需要对现有 Apache Iceberg 表的加工逻辑进行修改时，我们基于现有的 main branch 新建了 audit-branch，在 audit-branch 进行迭代升级。验证通过后，将 audit-branch 的变更合并回 main branch。

最后，通过以下命令对 StarRocks 的本地 SSD 缓存进行强制更新。

REFRESH EXTERNAL TABLE [external\_catalog.][db\_name.] [PARTITION ('partition\_name', ...)]

存算分离 Shared Data

在 StarRocks 存算分离架构中，数据存储在成本更低且更可靠的远程存储系统中。针对数据实时更新的场景，我们采用了StarRocks 内表的方式进行存储，在使用过程中，遇到了以下问题并进行调优。

2.1 云原生主键索引

• 主键索引带来的磁盘压力

在接入部分实时表到 StarRocks 后，我们发现主键索引带来的磁盘压力成为无法忽视的巨大隐患。彼时使用的 v3.3.0中，主键索引与缓存一起写在 PV 上，且由于云厂商提供的 StorageClass 不支持自动扩展，需要手动重装整个集群。随着事实表数据的不断增加，预估主键索引所需的磁盘容量成为了我们面临的第一个难题。

幸运的是， StarRocks v3.3.2 版本支持将主键索引写入对象存储，同时利用缓存进行索引预热。通过将集群升级到 v3.3.2，并对主键的列数和长度进行了优化，选用了占用内存较少的数据类型（如 INT、BIGINT 等），我们有效缓解了磁盘容量压力问题。

具体来看，在升级前，当我们搭建集群并接入仅有100张内表时，配备5个 CN节点，每个节点挂载60GB的云磁盘，集群的磁盘容量已经面临严重瓶颈。而在升级到 v3.3.2 后，我们将每个节点的磁盘容量缩小至20GB，将大量的主键索引写入对象存储，节省了约 80% 的存储成本。更重要的是，后续接入新的内表时，我们无需担心磁盘压力或额外申请资源。在通过适当的参数调优后，集群运行更加稳定，极大地释放了运维压力。

Properties
# 修改表的属性，支持基于对象存储上的持久化索引
"enable_persistent_index" = "true",
"persistent_index_type" = "CLOUD_NATIVE" 

2.2 Compaction 调优

• Compaction 临时文件带来的磁盘压力

集群稳定运行了一段时间后，某天 CN Pod 突然崩溃并多次重启，导致实时任务写入失败并触发报警。经过深入分析，我们发现问题的根本原因是业务量激增，实时任务的写入数据量急剧增加，导致 compaction 临时文件清理不及时，并与缓存争抢资源，最终引发了磁盘容量不足，导致 CN Pod重启。

在集群搭建时，考虑到写多读少的场景，且加速要求不高、缓存需求量较小，为了控制成本，我们将每个 CN 节点的磁盘容量限制在 20GB。然而，当写入数据量增加时，compaction 和缓存争抢资源的问题变得尤为突出。

为了解决这一问题，我们首先尝试了调整缓存和 compaction 相关的参数，包括控制缓存占用的磁盘容量、提高 compaction 的并发度和执行效率，并增加单磁盘 compaction 线程的数量。这些调整暂时稳定了集群，但在 CN 节点扩缩容的过程中，我们仍然遇到临时文件过大导致磁盘崩溃的问题。

经过进一步分析和社区帮助，我们意识到有些参数仅适用于存算一体的场景，而我们的集群是基于存算分离架构 的。最终，通过设置 enable\_light\_pk\_compaction\_publish 参数，彻底终结了“磁盘争夺战”。

# 关闭轻量级主键表compaction的设置，关闭后，compaction临时crm文件不会再写入/cn/storage/tmp，这对于我们这样的小磁盘环境非常重要
enable_light_pk_compaction_publish = false
# 允许vertical compaction时将临时数据写到磁盘。
lake_enable_vertical_compaction_fill_data_cache = true
# 主键表单次compaction可以合并的最大数据比例。调大比例，提升总体速度。
update_compaction_ratio_threshold = 0.8
# compaction时远程读Buffer的大小，默认1M，扩大该值，提升总体速度
lake_compaction_stream_buffer_size_bytes = 5242880

StarRocks on Kubernetes

StarRocks 采用 StarRocks Operator 的方式在 Kubernetes 中自动化部署和管理集群，我们在此基础上，按照自己的场景需求做了以下改造和增强。

3.1 按场景拆分小集群

在以往的 StarRocks 使用中，许多部门和应用的数据集中在一个统一的大集群中，这种模式不仅导致了资源相互挤占和影响，还带来了全手工部署和多样化调优需求的运维压力。在此次升级中，我们针对这些痛点进行了优化：

• 场景拆分，按需部署小集群：

大数据基座部门承担起类“DBA”的职责，根据需求为每个部门或使用场景快速拉起专属的 StarRocks 小集群。小集群间通过 Kubernetes Namespace 实现资源隔离，每个集群可以根据特定场景进行自定义配置。即使某个集群出现突发状况，也不会对其他集群的正常使用造成影响。

• 共享湖表，统一查询结果：

每个小集群持有各自的内表，但共享一份 Apache Iceberg 湖表。无论用户从哪个小集群查询 Apache Iceberg 湖表，结果始终一致。

• 自助运维与统一管理结合：

每个集群设有专属的“集群管理员”角色，支持部门自助进行集群内的管理操作。与此同时，大数据基座部门作为“超级管理员”，统一掌控底层资源和权限，在需要时提供支撑服务。这种分工设计减轻了单点运维压力，提高了整体效率。

3.2 元数据备份与恢复

为了解决 StarRocks 在 Kubernetes 部署中 FE 元数据可能丢失的风险，我们设计了 FE 元数据自动备份工具。该工具通过 Kubernetes 的 SideCar 容器运行，利用 AWS S3 CLI 的 sync 命令，将 FE 节点的元数据按照固定频率（如每10分钟）增量备份到对象存储中。S3 的 sync 命令会自动比对文件大小和更新时间，，同时支持来源目录删除时目标目录同步删除。这种方式资源占用极低，对 FE 容器的正常运行完全没有影响。

如果出现 Kubernetes 机器重启等极端异常情况导致的 FE 元数据丢失，备份数据就派上用场了。恢复工具以 Kubernetes 的 Init Container 为载体，根据配置信息在 FE Container 正式启动前，恢复备份元数据到元数据目录， FE 启动后可正常使用集群。

虽然该工具的设计初衷是应对 Kubernetes 集群异常导致的 FE 元数据丢失，但上线后更多地被应用在实际的迁移或重装场景，如 CRD 限制导致无法修改配置或集群迁移等。

3.3 自定义弹性扩缩容

测试过程中我们发现，CN Pod 的启动速度较慢，即使 PVC 已提前申请，从 HPA 触发扩容到启动完成仍需约 10秒。作为毫秒级查询引擎，这样的启动速度难以支撑高并发的用户查询，影响用户体验。同时，StarRocks 的 MPP 架构特点使得 CN Pod 频繁变动会导致本地缓存命中率降低，进一步影响查询性能。

为了解决这一问题，我们基于 Kubernetes 的特性设置 CronJob 来解决这个问题。通过分析历史监控日志数据，我们制定了以下方案：

• 白天扩容：在用户高峰期到来之前，CronJob 会自动调整 CN Pod 的最小数量，提前完成扩容，全天保持这一最小 Pod 数，支撑大部分 BI 分析查询。
• 夜间缩容：在用户使用量锐减后，CronJob 会将 CN Pod 的最小数量下调，HPA 逐步触发缩容，释放资源供夜间的入湖、数据同步、数仓构建等离线任务使用。

3.4 解决数据写入与 HPA 的冲突

当 CN Pod 因为 HPA 缩容时，正在实时写入 StarRocks on Kubernetes 的任务会报错，提示无法找到目标 CN Pod。

这一问题的根本原因在于 CN Pod 的关闭流程顺序：通知 FE Pod 的步骤被放在了后面，而此时 Kubernetes 已将 CN Pod 标记为 Terminating 状态，导致无法正常接收请求。

Prologorg.apache.http.conn.HttpHostConnectException: Connect to http://starrocks-cn-3.starrocks-cn-search.starrocks-system.sv... [http://starrocks-cn-3.starrocks-cn-search.starrocks-system.sv...] failed: Connection refused (Connection refused)

我们利用 Kubernetes 的 Lifecycle 特性，通过配置 PreStop Hook，在 CN Pod 进入 Terminating 状态之前，优先通知 FE Pod 删除该 CN Pod 的连接信息，再进行后续关闭步骤。

例子：

YAML
lifecycle:
  preStop:
    exec:
      command:
        - sh
        - '-c'
        - >-
          mysql -h$FE_SERVICE_NAME.$POD_NAMESPACE.svc.cluster.local -P9030 -uroot -ppwd -e "ALTER SYSTEM DROP COMPUTE NODE'$HOSTNAME.starrocks-cn-search.$POD_NAMESPACE.svc.cluster.local:9050'";
          sh /opt/starrocks/cn_prestop.sh

这个功能在实践中展现了更多价值。例如，云厂商对 StorageClass 的收费通常基于实际使用量，但即使 CN Pod 正常缩容后，遗留的 PV 仍然会保留缓存及临时数据，从而继续产生不必要的费用。然而，Kubernetes 提供的 Pod 缩容自动删除 PVC 和 PV 功能仍处于 Beta 阶段，尚未完全成熟，难以直接应用于生产环境。

于是我们又在 PreStop Hook 上添加了自动删除缓存和临时目录的操作。

总结

在 StarRocks 的升级之路中，我们曾尝试压缩单个 CN Pod 的内存，扩大 CN Pod 的数量，以提升 Kubernetes Node 的装箱率。但测试后发现，这种优化方式并不适用于 StarRocks。即使是在 Kubernetes 部署模式下，StarRocks 也需要配置较大内存和 CPU 的 Pod 来保证服务质量。

多点 DMALL 专注于 To B 业务，在“降本增效”的大背景下，客户对于成本和价值的敏感度更高。因此，在数据分析场景下，StarRocks 的存算分离架构、Lakehouse 外表查询和 StarRocks on Kubernetes 是我们的最佳选择，也是必然选择。整个升级过程也是在不断寻求性能、稳定性与成本之间的平衡，探索一条高性价比的 StarRocks 集群之路，为客户提供更加优质的服务。

后续规划

• StarRocks 引入 Serverless容器（如火山云 VCI/华为云 CCI/阿里云 ECI）支持 CN 弹性，充分利用  ResourcePolicy方 式，优先利用 Kubernetes 固定池资源，不足时使用弹性资源，真正实现按需付费和秒级弹性，避免固定节点规格难以提升装箱率；
• 增强 StarRocks 自身运营功能，如健康诊断、SQL 调优、资源成本报表等；
• 考虑如何更智能优化 StarRocks 异步物化视图（AutoMV），用于数据仓库构建等；
• 引入 Paimon 等新的湖仓格式，针对实时更新、实时查询的场景，考虑采用“仓冷沉湖”的方式接入湖表。

文章参考

[1]《多点 DMALL：大数据存算分离下的存储架构探索与实践》

https://juicefs.com/zh-cn/blog/user-stories/separation-of-sto...

关于作者：

任伟，多点 DMALL 资深大数据研发工程师，目前负责公司场景化大数据应用、统一数据模型、大数据实时分析引擎架构设计与落地。拥有丰富的场景化数据密集型应用设计经验，长期专注于大数据量实时查询、高性能分布式计算、数据仓库模型、智能算法模型建设与优化等技术。持续跟进多个开源项目 StarRocks、 ClickHouse、Transformers 等技术的企业级应用实践。

李铭，多点 DMALL 资深大数据研发工程师，目前负责公司大数据云原生架构设计与数据基座新特性研究；研究领域为大数据统一 SQL 网关、分布式文件存储、高性能计算、数据安全等。大数据开源社区爱好者，重点关注多个开源项目Apache Kyuubi、JuiceFS、Apache Celeborn、StarRocks 等在司内的适配和应用。

更多交流，联系我们：https://wx.focussend.com/weComLink/mobileQrCodeLink/33412/2b42f