vivo 大数据多维分析场景面临的挑战

在即席分析方面，我们的解决方案主要基于 Spark 和 Presto 两大计算引擎。作为 vivo 大数据研发治理平台的重要组成部分，即席分析模块因其高频率的使用而显得尤为关键。通过用户调研我们了解到，现有系统存在查询响应时间较长的问题，这直接影响了工作效率；同时，语法兼容性的不足也给用户带来了不便。因此，针对该模块进行优化，以提升查询速度和增强语法兼容性，已经成为我们团队工作的重中之重。

在敏捷 BI 方面，我们采用 Presto 作为数据查询引擎时，遇到了用户反映查询响应时间较长的问题，同时发现对这些查询进行性能优化存在较大挑战，找不到有效的方案。

在研效工具平台方面，早期数据规模较小时，该平台基于 MySQL 结合内存计算模式运行。然而，随着数据规模的增长，这一模式已无法满足业务需求。我们曾尝试采用 ClickHouse 作为解决方案，但在实践中遇到了诸多问题，最终未能落地。具体问题包括查询性能低、内存计算易发生内存溢出、数据清洗与加工时间过长（通常需要多个小时甚至一天），以及实时更新和删除流程复杂。计算逻辑较为繁琐，用户在构建报表时需要编写大量 Java 代码，消耗大量开发人力。这已成为一个常见的痛点。

此外，由于历史原因，我们在用户权限管理及计算资源分配方面长期缺乏有效的认证与管控机制。

1.Presto 相关痛点

在 Presto 方面，我们遇到的主要问题包括：

多级缓存能力较弱；
CBO（成本优化器）能力有限；
缺乏物化视图及表级加速方案；
无物理隔离机制；
Coordinator 采用单点部署，存在单点故障风险；
经过 JVM 调优及集群扩容后，仍会周期性地出现相同或类似的问题；
社区活跃度较低，性能优化方案较少。

2.ClickHouse 相关痛点

虽然 ClickHouse 在宽表应用场景中表现优异，但在湖仓一体架构下的加速能力有限，且数据导入期间的存储成本偏高，这成为用户特别关注的问题。另外，ClickHouse 在 Join 操作上的处理能力有所欠缺，包括 CBO（基于代价的优化）、Reorder（重排序）以及 Runtime Filter（运行时过滤）等关键优化措施迟迟未能落地，导致 SQL 调优时常需手动调整用户 SQL ，极大降低了用户体验。

与此同时，尽管 ClickHouse 提供了部分实时更新和删除的功能，但这些特性的性能并未得到根本性提升，进一步影响了用户体验。SQL 兼容性也仅达到一般水平，而集群扩缩容流程复杂，尤其是在执行节点扩展、缩减或副本调整时，故障机器的恢复与替换需要大量的人工介入。即使存在一些解决方案，这些问题依然显著影响运维效率，给用户体验带来了负面影响。

经过大量组件调研、功能与性能测试、行业案例分析以及 StarRocks 社区的技术指导，我们最终选择 StarRocks 作为新一代多维分析引擎，并确立其为湖仓加速的唯一标准。

3.StarRocks 优势

StarRocks 在湖仓加速方面具备显著优势，支持标准 SQL 并兼容 MySQL 协议。其强大的 Join 处理能力、默认启用的 CBO（成本优化器）优化规则、多级缓存机制，以及智能物化视图加速，使其在复杂查询场景下表现优异。此外，StarRocks 提供完整的资源隔离机制，最新的 3.3.5 版本更是引入了 CG Group CPU 硬隔离方案，进一步提升了资源管理的稳定性和可控性。

在运维方面，StarRocks 具备较高的易用性。无论是集群扩容还是缩容，仅需执行简单的命令并进行观察即可完成，极大降低了运维成本。可以看到，StarRocks 的诸多优势正好弥补了 Presto 和 ClickHouse 的短板，有效解决了我们在 OLAP 领域所面临的挑战和痛点。

此外，我们的 OLAP 团队经历了从 Druid、Kylin、Presto 到 ClickHouse 等多种组件的演进，且当前维护多个 OLAP 组件，研发人力分散。为提升研发效率，我们未来专注于 StarRocks 和 ClickHouse 的使用，每一位研发人员都需要深入学习并熟练掌握这两个核心组件。

StarRocks 服务建设落地的技术解决方案

上图展示了 vivo 大数据平台的整体架构，StarRocks 处在查询层和数据存储层，扮演着关键角色。

在查询层，主要涉及即席分析、BI 报表、湖仓一体等应用，同时涵盖基础建设和业务系统。目前，查询引擎包括 Spark、ClickHouse、Druid、Presto 和 StarRocks，未来 StarRocks 将完全替代 Presto。
在数据加工层，离线计算采用 Spark，实时计算则基于 Flink。数据存储方面，涉及 Hive、Paimon、ClickHouse、StarRocks、Druid 和 HBase。其中，Druid 目前仅用于基础设施监控及部分广告业务，后续计划逐步将相关场景迁移至 StarRocks 或 ClickHouse。
数据介质层主要包括 HDFS、自研对象存储，以及 HDD 和 SSD 文件系统。右侧则是公司自研的服务平台，涵盖数据开发、任务调度、实时计算等功能，并负责 StarRocks 的建库、建表及物化视图管理等操作。

1.湖仓查询加速架构

上图展示了最新的湖仓查询加速架构。

在数据仓库方面，我们主要采用 Hive，其中 90% 以上的表使用 ORC 格式，约 7%–8% 为 Text 格式。目前，我们正在推进 Text 表向 ORC 格式的迁移，目标是使 Hive 数仓中 99% 的表采用 Apache ORC。

Paimon 建设已持续约一年，目前 100% 采用 ORC 格式。在查询加速层面，我们引入了 StarRocks 作为核心引擎。

在引入 StarRocks 过程中，ORC 格式的性能优化是首要任务。此前，StarRocks 在湖仓查询加速（尤其是 Hive 查询加速）方面的优化主要基于 Parquet 格式，但在 ORC 方面的优化相对较少。因此，我们针对 ORC 格式进行了专项优化，以提升查询性能，使其更适用于现有的数据架构。

1.1 ORC 性能优化

当前使用 StarRocks 的用户，Hive 数据格式基本上是 Parquet ，因此 StarRocks 在 Parquet 格式的优化上非常成熟，而对于 ORC 格式的支持相对较少。为了解决这一问题，我们与社区团队紧密合作，共同解决了大量的性能和功能方面的问题，极大地提升了 ORC 格式 Hive 表的查询性能。我们通过修改相关代码并重放了数十万条线上SQL，确保所有修改既准确又高效。

修复 ORC 数据多读问题：优化了数据读取逻辑，减少了不必要的数据读取，显著提升了查询性能。
优化 ORC 延迟物化性能：通过延迟物化技术，减少了内存占用和计算开销，进一步提升了查询效率。
优化 ORC tiny stripe 处理：改进了 tiny stripe 的处理方式，提升了小文件的查询性能，特别是在处理大量小文件时表现优异。
支持使用 column id 下推 search argument 谓词：通过下推谓词，减少了不必要的数据扫描，提高了查询速度。
FE 打乱 scan range 顺序：优化了 scan range 的调度顺序，提升了探查 SQL 的性能，特别是在处理复杂查询时效果显著。
统一 Map Key 行为与 Presto 一致：调整了 Map Key 的行为，使其与 Presto 保持一致，确保了查询的一致性和稳定性。
优化 ORC is null/is not null 谓词下推能力：增强了对 is null 和 is not null 谓词的下推能力，减少了不必要的数据读取，提升了查询性能。
降低 DataCache cache miss 后从远端读取的 IOPS ：优化了 DataCache 的缓存机制，减少了 cache miss 后从远端读取的 IOPS ，降低了网络延迟，提升了整体性能。
Data Cache 异步填充：大幅降低缓存填充对数据读操作的影响。
压缩格式支持：vivo 数仓的Text格式占比：约10%，ORC 格式占比约90%,支持的压缩格式繁多，包括 NONE、SNAPPY、ZLIB 、LZ4、ZSTD、GZIP、BZIP2、LZO、DEFLATE 等，我们与社区团队紧密合作，共同解决了所有压缩格式的兼容性问题。
通过这些优化措施，我们与社区团队共同显著提升了 StarRocks 在处理 ORC 格式 Hive 表的性能和稳定性，为用户提供更加高效、流畅的查询体验。这些改进不仅解决了当前存在的问题，还为未来的性能提升奠定了坚实的基础。

1.2 Data Cache 性能优化

在数据缓存优化方面，我们最终选择了 NVME SSD 作为存储介质，磁盘使用率达到 95%。在当前 StarRocks 3.2.5 版本中，我们提前引入了 3.3.x 版本的异步缓存写入能力，并计划在未来升级至最新版本，以进一步利用 Data Cache 相关特性，提升查询性能。

在完成 ORC 格式的性能优化并准备正式上线时，我们在回放测试中发现查询性能未达预期。进一步分析后，问题的复杂性在于回放过程中慢查询的 SQL 特征并不固定，每次出现的慢 SQL 都有所不同，增加了问题定位的难度。

1.3 HDFS 慢节点性能优化

在优化过程中，我们回溯查询日志，深入分析 BE 的 HDFS 访问日志，最终发现大量 HDFS 超时问题。由于公司内部 HDFS 负载高，Spark、Flink 以及各种查询任务都会对其造成较大压力，从而影响查询性能。

针对这一问题，我们尝试调整超时时间，从 60 秒依次降低至 10 秒、5 秒、2 秒，并观察性能变化。结果显示，2 秒的超时时间在性能和稳定性方面表现最佳，但也导致少量失败情况。进一步分析发现，部分 HDFS 数据节点（DataNode）存在较为普遍的慢节点问题，即使经过多次重试仍可能失败。

为解决该问题，我们自研了动态重试机制，即：

首次重试：5 秒
第二次重试：10 秒
后续重试递增

这一优化方案有效解决了 HDFS 慢节点导致的超时问题，确保了系统的稳定性和查询效率。完成该优化后，我们顺利完成 StarRocks 的正式上线，并实现了查询性能的最大化提升。本次优化带来的价值与收益见下文。

1.4 元数据缓存和性能优化

StarRocks 上线后，我们发现了一个新的性能瓶颈，即元数据缓存导致的查询延迟与结果一致性问题。我们的即席分析用户主要是数据开发人员，他们在数据导入完成后，希望能够立即查询最新数据，但却发现数据未能实时更新。

经过分析，我们发现开源版本的元数据缓存刷新周期较长，支持库表级别和分区级别的定期刷新，但该刷新周期可能长达 1-3 小时，导致数据更新滞后。此外，范围查找缓存机制影响了精确查找的查询效率，使部分查询无法及时获取最新数据。

针对这一问题，我们自研了一套优化后的元数据缓存方案，并计划通过配置开关的方式贡献至社区。优化后的方案大幅缩短了元数据的刷新时间至 5 分钟内，确保数据能够更快更新。同时，我们调整了查询缓存策略，使范围查找和精确查找（为空）不再缓存，以保证查询结果的准确性。此外，在 get_partitions_by_names 方法的优化上，我们采用了多线程查询，有效提升了大跨度查询的性能。

该优化方案上线后，成功解决了元数据查询的性能问题，同时确保了查询结果的一致性。

1.5 语法兼容

在语法兼容性方面，我们采用了一套自研解决方案，目前 Presto 语法兼容性已达到 100%，确保用户可以无缝迁移。对于 Spark 语法，我们的目标是实现 90% 以上的兼容性，目前已达到 85%，仍在持续优化中，以进一步提升兼容能力。

在 Paimon 兼容优化方面，我们在 StarRocks 3.2.5 版本中，将 Paimon 0.7.0 客户端升级至 0.9.0，引入了 Caching Catalog 机制。升级后，Paimon 在并发查询和单次查询场景下，性能均提升 5 倍，大幅优化了查询效率和系统稳定性。

2.内表&异步物化视图工作

在高性能多表 JOIN 查询场景下，ClickHouse 无法满足我们的需求，同时我们还需要支持低时延数据摄入，频繁的数据更新与删除，以及物化视图的多层 ETL 清洗和加工。此外，我们希望实现湖仓表与内表的联邦查询，以提升查询效率并优化数据处理流程。

在研发工作方面，我们主要开展了三项关键优化：

首先，我们将 StarRocks 从 3.2.5 版本升级至 3.3.5，解决了库锁和死锁问题，并优化了物化视图的刷新逻辑，使其支持多事实表刷新。此优化上线后，成功解决了某业务场景中的长期问题，系统现已稳定运行。此外，我们修复了部分物化视图改写问题，并引导用户使用分区刷新策略，降低刷新频率，以提高系统整体性能。

其次，我们基于 3.3.5 版本，构建了物化视图测试方案，并整理了相关的使用样例与指导手册，帮助用户更高效地利用物化视图功能。

3.StarRocks 组件建设

StarRocks 组件建设共分为三个阶段：基础能力建设、稳定性建设和运营指标建设。

3.1 基础能力建设

在版本管理上，我们选择 3.2.5 作为集群版本，版本代码在 GitLab 中维护。认证与鉴权利用大数据研发治理平台的鉴权系统、公司的权限系统以及 Hive 鉴权，实现了统一的认证机制。
关于功能管理，相比 Presto ，StarRocks 拥有更强大的功能集。但在项目初期，我们选择仅开放查询功能，并对 DDL 和 DML 操作加以限制，以降低误操作对集群稳定性的影响。后续，将通过内部平台化的流程管理和逐步解禁这些功能。
我们的目标是在 SQL 兼容性支持上，构建围绕 StarRocks 、Trino 和 Spark 为核心的统一语法体系，从而实现更流畅的互操作性和更高的开发效率。

3.2 稳定性建设

采用 systemd 进行进程管理，确保进程异常退出后能够自动拉起，并配备监控脚本进行启停监测。系统可在进程崩溃时触发告警并自动恢复。同时，具备自动化 crash 监测与恢复能力，能够识别 BE 进程异常并进行分析和修复。目前 BE crash 发生率较低，但仍保持持续监测。
在监控告警体系中，依托主机级告警与 Grafana 监控，初期设定较低的告警阈值，以便及时发现潜在问题，并在优化过程中逐步调整至合理范围。

3.3 运营指标建设

注重平台化管理。研发人员及数据产品经理可通过统一平台完成建库、建表及物化视图创建等操作，以提升管理规范性。StarRocks 兼容内表、外表，并支持 Hive 和 Paimon。因此，对日报、周报、月报等运营指标进行分类管理，并定期（每周或每季度）进行分析和优化。
在审计日志管理上，我们基于开源审计日志框架进行了扩展，新增了记录用户查询唯一 ID、查询用户和查询属性等关键字段。系统自动保存慢查询的 Profile，并记录 HMS 接口调用（例如 getTable 、getPartition ）及其相关的性能指标。此外，我们还对存储数据的性能进行了统计分析，旨在发现可能的性能瓶颈并优化资源配置。所有成功落地的优化方案都会被归档，为后续 StarRocks 相关功能的推广提供支持。
此外，基于业务需求，我们开发了一些重要的自研功能。由于手机厂商对用户信息的高度安全性要求，所有内部数据都采用加密字段存储。为了让 StarRocks 能够替代 Presto 和 Spark 的部分能力，必须支持对加密数据的读取与处理。为此，我们在 BE 模块中对 Apache ORC 的版本进行了优化，使其能够通过密钥读取 Hive 中的加密字段。此功能的实现加快了 StarRocks 在数据分析场景下替代 Presto 的进度。

引入 StarRocks 的效果和收益‍

1.查即席分析切换历程‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

在介绍即席分析的收益之前，先回顾整个切换过程。

2024年1月：切换专项成立进行价值分析与目标讨论，明确即席分析切换的核心目标和工作计划。
2月-3月：性能攻关阶段

解决 ORC 格式 Hive 表的功能及性能问题。
进行 HDFS 慢节点分析与优化。
重放 SQL 快速测试能力建设。
解决结果一致性问题，并进行双跑测试。

4月：灰度 5% 阶段

使用 StarRocks 3.2.5 版本进行灰度测试。
处理兼容性问题，部分回滚至 Presto。
上线内部认证与鉴权方案。

5月：灰度 50% 阶段

ORC 解密上线。
成本账单方案上线。
查询性能优化，兼容性提升至 97%。

6月-7月：灰度 100% 阶段

Presto 正式下线，StarRocks 作为核心分析引擎。
解决 Spark 常用函数兼容问题。

8月至今：StarRocks 查询占比持续提升

查询占比从 40% 提升至约 70%-80%。
落地 HMS 元数据缓存优化方案。
资源隔离方案逐步实施。
解决 BE 内存熔断与查询超时问题。

2.即席分析引入 StarRocks 收益‍

在即席分析场景中，StarRocks 的使用占比已达到 70%，相较于 Spark（占比 30%），在查询性能和稳定性方面展现出显著优势。P50 耗时方面，StarRocks 取得了革命性的优化，从 7 月份的 63.77 秒缩短至 22.30 秒，效率提升 65.06%，整体查询速度提升了 3 倍。

目前，数据趋势呈下降态势，我们预计在 StarRocks 占比提升至 80% 后，P50 耗时将实现 4 至 5 倍的性能提升。此外，与 Presto 相比，StarRocks 在查询稳定性方面更具优势，查询成功率已接近 98%，显著减少了查询失败的情况。

3.敏捷 BI 引入 StarRocks 收益

在敏捷 BI 领域，我们已完成 25% 的切换，月均查询成功数超过 25 万次，查询成功率稳定在 99% 以上。目前，StarRocks 已覆盖 12 个业务领域，支撑超过 600+ 用户，并大幅优化查询效率：

慢查询（>30 秒）从 2.99% 降低至 1.32%
P90 查询时长降至 5 秒以内，相比 Presto 的 16 秒，提升 75%，整体性能提升 4 倍

该优化仍在持续推进，我们预计随着 StarRocks 的进一步优化和应用，查询性能和稳定性将得到更大提升。

即席分析是我们在查询性能优化方面面临挑战最大的项目，而敏捷 BI 则是我们覆盖业务范围最广的项目。这两个项目的成功让我们更加坚定地推进 StarRocks 的应用，我们有信心将其它 Presto 相关项目全面迁移 StarRocks，进一步提升整体查询性能和系统稳定性。

4.研发工具平台引入 StarRocks 的收益‍‍‍‍‍‍‍‍‍‍‍‍‍

在研发工具平台中，我们成功构建了准实时业务库，使数据从写入到报表可见的时间缩短至 3 分钟以内，相比之前的数小时甚至 T+1 级别，数据可用性大幅提升。

我们基于物化视图实现了数据分层和加工逻辑，开发效率提升约 30%。这一数据是较为保守的估计，随着用户对流程的熟悉度提升，预计效率提升可达 50% 以上。过去，用户开发报表需要编写大量 Java 代码，而现在，仅需配置实时任务并创建物化视图，即可完成报表开发，极大降低了开发成本。

在数据处理方面，我们通过 Flink CDC 实现数据的准实时写入，所有需求任务的变更会实时同步至 StarRocks ODS 层基表，并通过多个物化视图逐步流转至 DW 层、DM 层、DA 层、ADS 层，最终为用户提供高效的报表查询能力。借助 StarRocks 的查询加速，P95 查询延迟降低至 400 毫秒。此外，Flink 与 StarRocks 的双链路融合进一步提升了准实时度量能力。

该项目在公司内部获得了高度认可。作为研发工具平台能力建设的重要组成部分，其成功落地有效推动了降本增效，进一步提升了企业数据基础设施的价值。

StarRocks 在 vivo 大数据平台的未来规划‍‍

1.Presto 集群切换规划‍‍‍‍‍‍

我们计划于 2024 年 12 月完成 Presto 至 StarRocks 迁移的 30%，目前已完成 25%。由于前期迁移涉及流程梳理和技术攻坚，进展较为缓慢，但后续预计会加速推进。2025 年 6 月，StarRocks 的迁移占比预计达到 80%，年底前完成 100% 迁移。

我们将在迁移过程中持续优化 StarRocks on K8s 的能力，并总结敏捷 BI 和即席分析的实践经验，推广至更广泛的业务场景。最终，我们计划将广告、AI、DMP 等业务的 Presto 集群逐步替换为 StarRocks。基于即席分析和敏捷 BI 项目的成功经验，我们对全面替换 Presto 充满信心。

2.研发工作规划

存算分离架构引入
当前架构仍采用存算一体模式，未来将逐步引入对象存储，并结合 K8s 相关部署优化。
兼容性开发
持续增强 SQL 兼容性，目标是 100% 兼容 Presto 语法、100% 兼容 Spark 函数、90% 兼容 Spark 语法，并弱化 SQL 方言差异，统一支持 StarRocks、Presto 和 Spark 语法。
综合资源隔离方案
现已在开源版本中引入大查询熔断、多资源组件软隔离等方案，后续将升级至 3.3.5 版本，利用 CG Group 硬隔离机制，同时探索 FE 路由多 BE 组群能力，实现更精细的集群资源隔离。
元数据综合方案
计划引入分布式缓存架构替代当前本地缓存，以提高 FE 的水平扩展能力，减少对 HMS 的并发压力。
异步物化视图
联合湖仓一体团队推动异步物化视图发展，并探索构建智能物化视图系统，实现自动创建、自动加速。
运维能力建设
优化运维平台，提升集群启停管理能力，同时增强集群稳定性，提高组件在企业内部的长期可用性。
开源贡献
持续向社区贡献自研特性，并积极参与社区优秀特性的功能开发，以更好地拥抱开源和回馈开源。

本文来自公众号：Starrocks