演讲人：宋晓峰 洋钱罐大数据运维总监

十年破壁：从数据筑基到智能生态的全链路实践

一、数据筑基——自建大数据集群的攻坚与突破

背景介绍

瓴岳科技（Fintopia）是以大数据和人工智能为基础的数字科技集团，为全球用户提供卓越的金融体验。2015 年成立至今，瓴岳科技始终聚焦消费金融，业务遍布中国大陆、东南亚、拉丁美洲和非洲等；集团旗下拥有洋钱罐、Easycash 等知名品牌，截至 2025 年，服务全球金融机构超过 114 家，全球注册用户超过 1.81 亿，全球累计交易额超过 5400 亿元。在公司发展的过程中，我们大数据部门为智能风控、精准营销、产品创新三大核心业务提供数据支撑，整合多源数据，利用机器学习算法实时识别欺诈风险，构建全流程风控体系，基于用户行为、偏好等数据，定制个性化金融服务推荐，通过分析市场趋势与用户需求数据，为产品开发提供精准方向，助力瓴岳科技全球化业务布局。

大数据技术栈迭代与升级路径

过去十年，洋钱罐的大数据技术栈经历了多次迭代。

2018 年，面对数据孤岛问题及传统 MySQL 数据库无法有效支持复杂分析任务的挑战，我们自建了首个基于十多个节点的 Hadoop 大数据集群。当时用户规模约 2000 万，每日新增数据量约 300GB。

随着业务需求的增长，特别是在 2018 年至 2021 年间，原有的 MapReduce 框架因处理延迟较高而难以满足日益增长的数据处理时效性要求。因此，在 2021 年，我们将离线数据处理引擎由 MapReduce 迁移至 Apache spark 2.x，并同步升级了 Hive 版本至 3.x 以提升数据仓库性能。彼时，系统每天运行约 3,000 个批处理作业。

为进一步提高数据处理效率并响应业务对数据实时性的更高期待，2022 年我们引入了数据湖技术 Apache Hudi，从而将原本的日全量数据抽取转变为增量更新模式，显著提升了数据的新鲜度至小时级别。

此外，为了更好地支持交互式查询场景，在 2023 年我们采用 StarRocks 作为新的 Ad-hoc 查询引擎，取代了之前依赖于 Spark Thrift Server 实现的方法。截至目前，Ad-hoc 日均 SQL 查询请求量超过 8,000，P95 响应时间控制在 60 秒以内。鉴于全球化布局带来的弹性资源、业务稳定性和成本优化要求，我们在 2024 年对整个集群架构进行了重大升级，将自建集群迁移至阿里云 EMR Serverless 平台，Yarn 节点规模超过一千台，在此过程中，我们也将 spark 2.x 升级到了 spark 3.x。

当前，我们集群的整体存储能力已经达到单副本 10PB 的规模，每日新增数据量约为 30TB。核心业务报表数量超过 3000 份，而调度工作流数量已突破 15000 个。在 StarRocks 集群方面，我们同时采用了存算一体化架构与存算分离架构，并根据不同的业务线进行了划分，因此目前拥有超过 30 个独立的 StarRocks 集群实例。左侧展示的是我们的调度能力和 Ad-hoc 查询能力，YARN 日执行 job 量超过 4 万。

从稳定性到效率：自建集群的困境解析

在自建大数据集群的过程中，我们遇到了诸多挑战，主要集中在稳定性、弹性资源管理和运维效率三个方面。

首先，在稳定性方面，我们面临的主要问题是业务 SLA 破线。这种情况往往源于底层 NodeManager 因网络带宽限制或 shuffle 量大而导致任务失败率上升。此外，在使用开源组件过程中，也存在一些 bug 或者性能问题，比如我们在使用 Hive3.x 开源版本时，在高并发的场景下会出现进程卡死等问题，从而影响业务稳定性，无法满足生产环境的要求。

其次，在弹性资源管理上，自建集群缺乏快速扩展的能力以应对突发流量需求。例如，在凌晨遇到紧急情况时，希望迅速增加计算资源来解决问题变得不可行。同时，即使进行了物理服务器的扩容，在 YARN 的容量调度策略下，也难以有效平衡不同队列之间的负载分布，导致部分队列利用率过高而其他队列则相对空闲，整体上降低了集群资源利用效率。

最后，关于运维效率的问题，大数据集群的维护工作相当复杂且耗时。从硬件采购到最终完成配置并投入使用，整个过程通常需要两至三天时间。此外，开发人员还需投入大量精力进行性能调优、故障排除及日常巡检等任务，这不仅增加了人力成本，也影响了团队的工作效率。

Spark 引擎核心痛点解析

在使用 Apache Spark 引擎的过程中，我们遇到了几个核心痛点，这些问题主要集中在资源管理、性能与稳定性、版本升级以及成本控制等方面。

首先，在资源管理方面，我们面临的主要问题之一是峰值资源的优化。例如，在凌晨执行大规模任务时，该任务可能会占用队列中 90%以上的资源，而其他较小的任务虽然只占用了剩余 10%左右的资源，但其完成时间却可能更长。这表明了当前资源分配机制存在不合理之处，需要更加精细地调整以提高整体效率。另一个问题是谷值期间资源利用率低下。特别是在非高峰时段（如午夜过后），集群的整体资源利用率往往只能达到 30%左右，导致大量计算能力被闲置。

其次，在性能与稳定性方面也存在问题。当我们使用自建的大数据集群部署 Spark 时，采用的是开源版的 Shuffle Service 作为 NodeManager 组件。然而，在高负载情况下，这种服务的表现并不理想，容易成为瓶颈，并且当单个 NodeManager 出现问题时，会严重影响到整个集群上运行任务的稳定性和性能。

第三点关于引擎版本固化的问题也非常突出。比如将 spark 2.x 迁移到 spark 3.x，不仅耗时较长，还需要充分考虑新旧版本之间的兼容性问题、系统稳定性测试以及对现有业务流程的影响评估等多方面因素。

最后，在成本控制方面同样存在着挑战。由于不同业务线之间可能存在交叉需求，比如风控场景下的离线数据仓库处理与 Adhoc 查询同时进行，这就使得很难按照单一业务维度来精确划分和管理相关费用。因此，如何有效地衡量并优化跨部门使用的 Spark 资源成本，成为了我们需要解决的重要课题之一。

StarRocks 问题解析

在使用 StarRocks 的过程中，我们也遇到了一些挑战，主要集中在数据导入、资源隔离及系统稳定性三个方面。

首先，在数据导入方面，StreamLoad 导入速度慢，支持的数据量有限，当提高数据导入频率时，可能会触发 FE 内存问题，会出现 MVC 相关报错。Broker Load 虽然导入速度快，但是软性资源隔离策略会影响读性能，最后我们还是要依赖 Spark 集群的 Spark Load 解决大数据量导入问题

其次，关于资源隔离的问题，虽然开源版 StarRocks 提供了基本的资源隔离功能，但它是软隔离，而非硬性隔离，数据导入与查询操作之间存在竞争关系，尤其是大规模查询请求可能会影响其他小型查询请求的响应时间。

最后，在系统运维与稳定性保障方面，开源版本没有自带的管控页面，运维人员不得不自行开发一系列脚本来完成扩缩容等请求，增加了运维难度。此外，在面对版本升级时，升级耗时长，还需额外进行业务回归测试以验证新版本兼容性和系统稳定性。

以上因素共同构成了 StarRocks 在实际应用中面临的主要技术挑战。

二、云帆起航——迁移阿里云 EMR 的全链路实践

面对上述挑战，我们对大数据架构进行了全面升级，全面切换至阿里云生态组件。此次升级的核心在于构建了一个符合数据湖理念的全新平台架构，该架构不仅满足了当前业务需求，还为公司未来向数据湖方向的发展奠定了坚实基础。此次升级主要对两个计算引擎进行了重大改造。

首先，我们将 Hive SQL 完全迁移至 Spark SQL。因为相较于 Hive SQL，Spark SQL 展现出更优的执行效率，这也是业界共识。整体迁移过程非常丝滑，在性能与兼容性方面，EMR Serverless Spark 表现亮眼，还支持丰富的开源生态，如 Kyuubi、Livy 等。

其次，我们将 StarRocks 存算一体版本切换为了存算分离版本，这也顺应了 Serverless 架构的发展趋势。

基于计算引擎升级，我们在上层构建了自己的数据应用产品，如一站式开发平台、标签系统、实时开发平台、数据质量监控系统、Ad-hoc 查询等。

我们还将底层存储从传统 HDFS 切换为阿里云 OSS-HDFS，消除了原生 Hadoop 文件系统中存在的单点故障问题。相比自建集群成本，新架构成本仅为其十分之一左右。

EMR Serverless Spark：一站式数据平台服务

EMR Serverless Spark 提供了一站式的数据平台服务，包括任务开发、调试、调度和运维等，极大地简化了数据处理和模型训练的全流程。内置 SQLEditor、Notebook 开发环境，提供版本管理，工作流调度，以及运维诊断能力。 版本管理功能使得用户能轻松切换 Spark 版本，只需确保 SQL 语句能正常运行，数据能正常处理即可，无需考虑底层基础设施的复杂性。

针对 Spark 和 Python 环境，用户可以根据具体业务需求进行配置，如调整 spark-defaults.conf 文件中的参数值，来优化特定应用场景下的性能表现。通过简单的 spark-submit 命令配合相关参数，即可快速切换到所需的运行时环境，极大提高了工作效率。

监控与诊断方面，EMR Serverless Spark 还提供完善的监控与诊断功能。提供工作空间、队列以及任务等各种维度的资源指标统计，方便用户更清晰地掌握作业运行情况。在 Spark 任务完成之后，收集和分析该任务的各种资源消耗指标，并根据这些指标给出合理的优化建议。

EMR Serverless Spark 还提供极致资源弹性与性能。首先，在弹性伸缩方面，支持 Driver/Executor 级别进程弹性，最低支持一核力度，容器拉起时间在 20 秒以内。资源供给方面，底层是 Iaas + 神龙资源池，提供海量供给，自迁移至 EMR Serverless Spark 以来，我们尚未遇到任何资源短缺问题。

此外，EMR Serverless Spark 采用类似于 YARN 的资源管理模式。Workspace/队列两层 Quota 管理支持用户根据业务特性选择合适的提交路径。平台提供了基于 Workspace/队列/作业的多维度、精确到天/时/分的多周期资源观测能力。

性能方面，EMR Serverless Spark 自研 Fusion 引擎，内置高性能向量化计算和 RSS 能力，相比开源版本性能大幅提升

EMR Serverless StarRocks：功能丰富、性能卓越

EMR Serverless StarRocks 在管控能力方面显著优于自建方案，提供实例管理功能，包括创建，扩容缩容，升降配，网络管理，白名单管理，操作任务管理，网关管理等。

此外，其管控平台提供实例健康报告与慢 SQL 诊断分析、可视化缓存管理、支持大/小版本主动触发滚动升级、支持全链路实例操作审计等功能。

值得一提的是，EMR Serverless StarRocks 实现了真正的存算分离架构，提供物理隔离能力，不同计算组作业负载相互独立，支持多计算组独立配置。在我们的实际应用场景下，存算分离内表查询较开源性能提升约 100%，数据湖查询较开源性能提升约 50%。

下图展示了基于 EMR Serverless StarRocks 的湖仓新范式，StarRocks 作为统一 Lakehouse，基于湖表进行自助分析查询。数据写入 StarRocks 提供极速分析；数据写入开放数据湖，使用 StarRocks 直接分析数据湖；在 DWD、DWS 以及 ADS 层，通过构建物化视图并实施分层建模策略，不仅能够有效支撑各类报表需求，同时也为 OLAP 提供了强有力的支持。

架构升级带来的关键价值

上述重大架构升级，带来了哪些关键价值呢？

首先，在成本优化方面，通过引入弹性资源，显著提高了资源利用率。

其次，从业务稳定性角度来看，EMR Serverless Spark 自带的高性能 Shuffle 服务，极大地增强了系统的稳定性和可靠性。此外，StarRocks 的性能优化也进一步提升了整体业务处理能力与响应速度。

关于业务敏捷性，新架构支持快速部署新业务场景所需的计算资源，从而大幅缩短了业务上线周期。

运维效率方面，得益于 EMR Serverless Spark 与 EMR Serverless StarRocks 丰富的管控能力，开发团队所需投入的日常维护工作量显著减少。同时，平台提供了全天候的技术支持服务，确保即使面对突发问题也能迅速获得解决方案，进一步保障了系统的连续可用性。

具体而言，在保持业务规模不变的前提下，与传统的自建方案相比，基于 EMR Serverless 构建的解决方案能够实现约 25.4%的成本节约。基于 EMR Serverless StarRocks 进行查询（如标签系统和用户圈选场景），SQL 查询执行时长缩短了 30%。此外，在相同成本情况下，EMR Serverless Spark 作业的执行时间也缩短了 30%以上。最值得注意的是运维效率方面的改进，实现了近 40%的大幅提升。

三、智创未来——未来基于阿里云的智能生态布局

在完成架构升级后，整体稳定性得到显著提升。展望未来，我们的目标是构建一个更加智能化的金融生态环境。为此，我们设想了四个主要发展方向：

首先，在数据处理方面，我们计划基于阿里云 EMR 及机器学习平台 PAI 来实现高效的数据协同架构。

其次，在业务流程优化上，通过整合阿里云的大规模模型能力，旨在创建一个既简化又高效的运营环境，涵盖预测式风控、自动化运营，大智能化监控等领域。

再者，在应用层面，致力于形成以数据为驱动并支持智能决策的完整业务闭环。

最后，在算法创新方面，我们将依托于阿里云机器学习平台 PAI，专注于开发适用于特定行业的专属 AI 模型库。