StarRocks 在金融科技行业的存算分离应用实践

小编导读：

自从 2023 年 4 月正式推出 3.0 版本的存算分离功能以来，目前已有包含芒果TV、聚水潭、网易邮箱、浪潮、天道金科等数十家用户完成测试，多家用户也已开始逐步将其应用于实际业务中。目前，StarRocks 存算分离上线的场景包含电商 ERP 订单分析系统、金融业务数据分析和制造业设备数据分析。由此可见，StarRocks 存算分离已达到生产可用的高标准。

在本文中，我们将向大家介绍一家已经成功上线存算分离架构的金融科技公司，重点阐述他们如何引入了 StarRocks 3.0 架构。目前，他们所使用的 StarRocks 3.1 存算分离版本已在线稳定运行。

随着互联网迅速演进，金融领域正经历着向智能化和数字化方向的持续转型。作为引领金融领域变革的先锋，金融科技（FinTech）正发挥着重要作用，而在这个变革过程中，大数据技术成为了不可或缺的关键环节。

在这背景下，某国内知名金融科技公司为了构建区域供应链金融科技平台，实现降本增效，做出了一项重大决策：将原有的 Hadoop 集群平滑迁移为 StarRocks。 经过深入的测试和调研，该公司成功地上线了 StarRocks 3.1 版本的存算分离架构。新架构的上线不仅显著提升了查询性能超过 10 倍，精细化了权限管控流程，实现了更实时的数据更新，还极大地减轻了维护工作的负担。

本文旨在详细介绍这家金融科技公司引入 StarRocks 存算分离架构的搭建过程和应用实践。通过深入探究，读者将更清晰地了解这一转型背后的考虑、实施以及取得的成果。

业务背景

数据团队是负责处理和管理企业海量数据的核心团队，为企业决策提供坚实的数据支持。为了推动大数据平台的建设和数据治理工作，我们在早期搭建了基于 Hadoop 的大数据平台，并将历史数据都迁移至 Hive 数仓中。

（旧有大数据架构）

如上图所示，我们的数据仓库 Hive 集成了阿里云 Jindo SDK，底层使用 OSS 存储海量数据。计算引擎我们采用了 Spark，通过在其上方构建了 Kyuubi 网关，实现了多租户和资源隔离，从而进一步优化了计算资源的利用；即席查询，我们选择了 Trino（原 Presto）作为执行引擎；主要的数据治理和开发工作则是使用了 SparkSql+UDF/UDAF。

业务痛点

1. 数据治理链路复杂

在数据治理整个链路上，数据团队通常先用 Presto 进行数据探查，探查完后再通过 SparkSQL+UDF 对数据进行加工，最后通过 DataX 和 SeaTunnel 将结果同步到 MySQL 和 Elasticsearch 中。Spark 任务和同步任务通过海豚调度（DolphinScheduler) T+1 执行。其他部门人员和客户即可在结果库进行数据查询分析。

然而，在数据治理的不同阶段，我们注意到不同部门和团队成员可能会对同一数据内容有不同的理解、计算规则或数据定义存在差异，导致最终在结果库中的数据呈现出不一致性。这可能引发数据口径不一致的情况，需要我们进行数据回溯和调整，以确保数据统计的准确性和一致性。

2. ODS 层数据合并效率太低

由于 Hive 表缺乏主键更新功能，我们在原有的 ODS 层增量数据合并流程中面临一些挑战，不得不针对每天单表几亿行数据，与数十万到几百万行的增量数据进行关联，对执行开窗去重操作并在数据量比对和检查后，采用 INSERT OVERWRITE 的方式来覆盖老数据，从而完成增量数据的合并。然而，这种流程效率较低，往往需要耗费长达两个多小时的时间来完成 ODS 层的增量数据合并工作。

3. 大数据量数据查询慢，产出时间长

由于集群的磁盘空间不足以存放几十 T 的数据量，为了解决这一问题，我们在大数据平台上引入了 JindoSDK 并将底层存储从 HDFS 切换到 OSS。尽管这种改变能为数据存储的扩展性带来一些好处，但在进行 Spark 批处理任务时，却导致了任务执行时间的显著延长。经常一个工作流需要几个小时完成，一旦修改调整一点加工逻辑，就需要从头开始加工计算，整体的数据产出时间很长。

4. 大数据集群稳定性差，维护成本高

在 Spark shuffle 过程中，大量的中间数据需要被写入磁盘，导致 ECS 的磁盘 I/O 经常打满。使用 Spark 初期，集群因为各种问题报错，以及机器磁盘被打满，平台每天都要重启集群 2-3 次，严重影响了生产环境可用性。另外，由于大数据集群中涵盖了众多组件，需要每天检查外加每周定时巡检。在数据治理的同时还需要大量时间去维护整个集群，这对开发和运维人员造成了不小的负担。

原有集群：

（CDH 集群监控）

（CDH 物理节点监控）

针对现有大数据架构上面提到的各种问题，我们大数据团队积极寻找各种解决方案，希望使用更先进的架构来取代老的大数据体系。经过详尽的调研，最终我们将目光锁定在 StarRocks。StarRocks 作为新一代云原生湖仓一体架构的数据分析平台，其具有性能优异、场景丰富和运维简单等优点，是我们内部统一数据处理架构的理想选择。

同时，考虑到我们一直采用存算分离架构来处理大数据，我们也希望 StarRocks 能具备存算分离架构以节约成本并减轻运维负担。调研之时，我们也恰巧赶上社区推出了 3.0 版本，我们毫不犹豫第一时间进行了测试和体验，并体会到其性能的优越（详细的测试报告请见：https://forum.mirrorship.cn/t/topic/7075）。测评后，我们立刻上线了 StarRocks 3.0 存算分离版本，随后立即升级使用 3.1.0 版本，并运行在存算分离模式。整个集群由 3 个前端节点（FE）和 8 个后端节点（BE）组成，其中 FE 为 3 台 32G 的 ECS 组成高可用，而 BE 部分则采用了32C 128G 2T 磁盘的 ECS。所有业务数据都存储在 OSS 中。

自今年 3 月开始内测存算分离，目前上线存算分离已有两个月。我们已成功完成对整个 ODS 层业务数据的迁移，总数据量已达到 4TB。接下来，我们将详细介绍一下 StarRocks 3.0 存算分离版本所具备的优势，以及它为我们带来的显著价值：

StarRocks存算分离优势

1. 优势一：性能提升 10 倍以上

过去，我们使用 Spark 进行批处理任务时，任务速度缓慢，导致开发效率低下。然而，通过采用 StarRocks 存算分离的新架构，尽管数据仍然存储在 OSS 中，但任务的执行速度相较于 Spark 任务提升了 10 倍以上。 这一巨大的性能提升缩短了任务执行时间，从而显著增加了开发效率。

（性能测试数据）

测试结果显示，即使关闭了 Cache，相比 Spark SQL 等最高也有近百倍的性能提升，让我们在享受存算分离便利的同时还能拥有之前未曾体验的极速性能。

2. 优势二：权限管控流程更加简单和精细化

在 CDH 平台中，权限管控一直是一个复杂而繁琐的问题。原先我们使用 Kerberos 认证，但无法实现对库级别和表级别权限的细化控制。这意味着开发、运营和算法团队都能够访问所有数据，导致数据的安全性受到了很大的影响。

与之相比，StarRocks 采用了基于角色的访问控制（RBAC）权限模型，大大简化了权限管理流程。我们能够实现库级别和表级别权限的细粒度控制，这在适应多业务线的场景中尤为重要。用户与角色的分配也更加灵活。对非公开的财务数据，我们能够为个别用户单独授权访问某个库或特定表的权限，从而极大地提升了数据的安全性。 这正是我们急需的功能，为数据安全提供了坚实保障。

3. 优势三：支持主键模型，数据更新更实时

StarRocks 3.1 版本的存算分离架构已经引入了主键模型表的支持。 通过主键模型的应用，我们成功地克服了老架构中每天只能合并百万级增量数据的限制。通过简单的 update 语句，我们能够轻松将增量数据同步至 StarRocks。内部通过高效的数据更新策略，我们能够迅速完成数据更新操作。 目前，线上大多数表都已经使用了主键模型稳定运行着。

4. 优势四：支持部分列更新，大幅降低维护工作

在 Hive 数仓中，更新单条数据或部分列的操作是相对复杂的，只能通过创建临时表进行 insert into 或是 insert overwrite 整表覆盖。这对于需要频繁更新单条数据或部分列的财务非公开数据而言，维护工作非常繁琐。

然而，一旦我们将财务非公开数据迁移到了 StarRocks 的存算分离架构下，就能够轻松实现对单个企业的财务数据进行单条数据的更新，或是在财务统计口径变化时对整表进行部分列的更新。 这种方式维护起来非常方便，大大提高了数据的加工效率。

5. 优势五：架构简单易运维

原先的大数据平台涵盖了许多组件，如 Spark、Yarn、Hive、Trino、Zookeeper 和 HDFS 等，复杂的架构加上人力的紧张，整个系统的维护变得异常复杂和繁琐，令人应接不暇。然而，引入 StarRocks 后，整个架构得到了显著简化。StarRocks 仅包括 FE 和 BE 这两个核心组件，并且在存算分离版本中，只依赖一个外部对象存储服务（例如 OSS）。相比存算一体架构，存算分离架构也并未引入额外的组件，运维起来极其方便。

6. 优势六：社区活跃

自从 StarRocks 3.0 版本推出后我们就开始着手测试，从测试到上线只用了短短 3 个月的时间。值得一提的是，社区在问题响应方面的速度非常迅速。我们遇到问题后，通常只需在社区群里提问，基本上当天就能得到解决方案并修复问题。令人惊喜的是，我们还发现社区在存算分离的功能和性能方面迭代速度极快。从 3.0 版本刚推出到 3.1 版本的主键模型基本成熟，每个版本都为我们带来了惊喜。因此，接下来我们也计划密切跟进社区的迭代步伐，以便为业务带来更大的价值。

StarRocks 存算分离实践

借由引入 StarRocks，我们成功地取代了原有的大数据集群，以 StarRocks 统一了整个大数据平台。通过存算分离业务数据仍然存储在低成本的对象存储中，计算节点则可以根据业务需求随意进行扩容和缩容。

（StarRocks 存算分离版本&配置信息）

1. 历史数据迁移

首先，我们在 StarRocks 创建主键模型表，并设定按天动态分区。为了完成 ODS、DWD、DWS 和 ADS 层的历史数据迁移，我们通过 Broker Load 任务直接从 OSS 读取 ORC 文件并同步到 StarRocks 中。Broker Load 任务导入速度十分惊人，多次导入操作的平均速度达到约每秒 70 万条数据。

导入样例–生产 Broker Load：
导入一张 3.2 亿数据量的业务表，耗时 433 秒。

2. 增量数据更新

针对增量数据，我们以前是创建 Hive 的 JSON 格式表，并将 FTP 中 T+1 增量的 JSON 直接传输到 OSS 中。目前，我们通过 Python 代码实现了将每个表的增量 JSON 文件通过 Stream Load 事务接口写入 StarRocks 的主键模型表。当遇到 JSON 文件过大时，我们会提前切割 JSON 文件再写入，确保每个文件大小不超过 10GB。我们同时运用了 4 个并发的 Stream Load 任务，导入的平均速度大约是每秒 6 到 7 万条数据。

导入样例–生产 Stream Load：
下图所示，我们导入了一个 3.3GB 的 JSON 文件，总数据量 244 万条，导入耗时 37.4 秒。

3. ETL 任务转化

由于 StarRocks 兼容 MySQL 协议，我们将原有的 SparkSQL 改造成类 MySQL 语法，关联查询再以 insert overwrite 的方式从全表操作转变为只涉及 T+1 分区数据进行关联写入目标表。在 Dbeaver 中使用 MySQL 驱动即可查询 StarRocks 中的存算分离表，加工逻辑准备好后放入调度平台 T+1 执行即可。我们还使用异步物化视图来替代一些临时表，以加速查询过程。

4. 大数据量查询写入优化

**算子落盘+分区裁剪优化：**在大数据量查询中，初期数据量太大经常导致 BE 因为 OOM 失败。通过开启新版本的算子落盘功能，同时进行分区的裁剪优化，有效缩小了数据查询范围，原来的大查询再也不会出现问题了。
**物化视图加速查询：**对于数据治理过程中需要使用的临时表，或者是那些查询频率高、耗时长的查询，可以构建异步物化视图，在关联查询中可以无感知进行查询加速。
**聚合模型优化指标统计：**明细数据经过轻量汇总统计写入聚合模型表，降低统计延时。原来需要小时级别聚合的指标降低到秒级聚合。

存算分离的三步规划

我们在 StarRocks 存算分离架构下按照三个步骤进行大数据架构的调整，其中第一和第二阶段皆已上线：

1. 第一阶段：

使用 StarRocks 来构建指标标签和企业画像系统（StarRocks 作为 ADS 层使用）。 我们的数据将被沉淀并展示在 BI 报表上。具体操作是将指标和标签数据通过 Hive Catalog 计算，然后将汇总数据写入 StarRocks，而明细数据则通过异步物化视图方式写入 StarRocks。最终，BI 报表将连接到 StarRocks 数据源来读取数据。此时，大数据集群与 StarRocks 共存。