演讲人：宋晓峰 洋钱罐大数据运维总监
十年破壁：从数据筑基到智能生态的全链路实践
一、数据筑基------自建大数据集群的攻坚与突破
背景介绍
瓴岳科技（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模型库。 