导读 本文介绍了火花思维教育科技有限公司在大数据架构上的一次重大转型：从 EMR 迁移到 Serverless 架构模式。文章首先回顾了 EMR 在公司的应用历程和遭遇的瓶颈，随后引出了 Serverless 技术的兴起及其优势。接着详细阐述了转型的策略、规划、实施细节和收益，并分享了转型过程中的经验与教训。此次转型旨在提升运营效率、节约成本并增强业务敏捷性。通过此次分享，希望能为面临类似挑战的企业提供有益的参考和启示。
1. 引言
2. 面临的问题与挑战
3. Serverless 技术简介
4. 方案与实施过程
5. 实践收益
6. 经验与教训
7. 总结与展望
分享嘉宾｜马云起 火花思维教育科技有限公司 大数据研发工程师
内容校对｜李瑶
出品社区｜DataFun
引言
1. 火花思维教育科技有限公司简介
火花思维是一家在线教育公司，主要面向 6-12 岁的儿童提供逻辑思维、中文素养等课程。随着公司业务的快速发展，数据量和计算需求也在不断增长，数据量和数据诉求呈现出爆炸式增长的态势，公司决定采用大数据自助的方式处理数据需求。在这样的背景下，火花思维决定采用 Serverless 架构来构建大数据处理平台，以提高系统的可扩展性、可靠性和效率。2. Athena 数据工厂简介
Athena 数据工厂是火花自研的一站式数据开发治理平台，主要为运营、BA、产品、研发、财务、技术支持等多样化角色提供任务开发、任务运维、提数分析、资源管理全方位的产品服务，帮助数据生产者和数据消费者专注于数据价值的挖掘和探索。详细介绍可以参阅 https://mp.weixin.qq.com/s/RJZTdEKCgB2SB3f6dBchXg面临的问题与挑战
1. 渴望弹性计算能力
火花思维的业务发展，数据量呈现出爆炸式增长的态势，大数据集群在不断地进行扩容。然而大数据处理和分析的负载是不均匀的，可能因数据量的激增、分析任务的复杂度提升或业务数据需求的突发增长而急剧变化。在月初、月末、大促期间数据需求会激增数倍，集群压力过大，资源相对不足，影响整体稳定性；在节假日、周末期间，计算量相对平稳，而导致资源利用率低。这种负载的差异，随着 2021 年火花进行大数据自助化运营以来，数据生产者的成倍增加，变的越来越明显。由于这样负载的变化，使我们很难在资源利用率和稳定性上找到一个很好的平衡点，导致我们对弹性计算的渴望越来越强烈。火花大数据历经自建 Hadoop 集群、EMR 集群两个时代，在自建 Hadoop 集群时代，缺乏弹性扩展能力 ，因此无法进行弹性扩容缩容。在火花大数据完成迁移至 EMR 集群后，虽然 EMR 产品在一定程度上提供了弹性扩展的能力，但仍存在一些限制。具体而言，EMR 产品无法根据任务数量自动触发弹性扩容，而需要预先设置固定的弹性规则，这些规则通常是在固定的时间点触发扩容，而无法根据实时的任务情况进行自动调整。另外，弹性扩容的过程通常需要较长的时间来完成，以我们在 2023 年的扩容操作为例，当时扩容 10 台 DN（Data Node，数据节点）通常需要半小时的等待时间，这种较长的扩容时间使得EMR弹性扩容很难应用到日常的调度场景中。随着数据工厂任务量的增加，迫切的需要一个更灵活的弹性计算引擎来支撑这些数据处理需求。2. 成本无法精确拆分核算
业务在不断的发展，公司一直在拓展产品业务线，但国内所有业务线的数据都在同一个 Hadoop 集群上，所有业务线的BI分析师也混用一个 OLAP 引擎，离线和实时也共用一个计算资源池，导致大数据成本无法进行详细的拆分核算，这给公司的财务管理和成本控制带来了一定的困难。随着集群存储数据以及数据任务的增加，大数据集群的成本呈不断上升趋势，然而，大数据部门无法精确提供每个业务线的具体成本数据，也无法按照每个业务线的要求来按量提供稳定的计算资源，导致大数据部门一直以来只能自行承担这部分成本。公司提出降本增效的要求以后，这个问题变得更为突出，一方面某些业务线计算量不断上涨需要扩大计算资源，而在公用的资源池里，大数据部门无法 100% 精确扩量至该业务线，其他业务线要求降本，大数据部门即使在降本方面做了很多工作，最终也无法精确体现到成本数据上。3. 资源竞抢影响整体稳定性
在 EMR 模式下，我们面临了严峻的资源调度挑战。具体来说，当单个大型任务执行时，它会占用队列集群的大量资源，导致其他任务被迫等待甚至无法提交。这种资源争夺现象不仅降低了任务的并行处理能力，还降低了整个系统的吞吐量和响应速度。此外，EMR-Presto 集群在任务高峰期（如月末、月初）也频繁达到算力上限，进一步加剧了资源调度的难度，引发了数据分析人员对大数据平台的大量投诉。为了应对这些挑战，我们不得不不断优化集群、调整参数，但这无疑增加了运维成本，且无法从根本上解决问题。4. 存储与计算资源耦合问题
EMR-Hadoop 模式下，存储和计算资源紧密耦合在一起，导致我们无法单独针对存储资源或者计算资源进行扩容缩容，在扩容时机的把握上也面临困难，如果从计算的角度进行资源扩容，扩容后则会造成存储空间利用率低；如果从存储的角度进行资源扩容，则计算资源一直吃紧，
影响稳定性。随着公司业务的增长和数据任务的增加，集群面临越来越大的压力，存储空间一度超过 80% 警戒线，任务高峰期 pendingCU 数量超过 3000，引用率高的数据所在 DataNode 机器会触及机器 IO 上限，造成任务延迟，降低了任务处理速度，影响稳定性。为了控制成本，我们往往被迫在不得不扩容的时候才进行 DataNode 的扩容，这无疑增加了稳定性保障的挑战。此外，由于存储和计算资源的耦合，也导致我们无法对它们进行独立的成本拆分。5. 运维门槛高、挑战大
大数据集群运维需要具备复杂与多样的专业技术能力，包括熟悉 Linux 操作系统的配置、管理及优化，能够独立排查及解决系统层的问题。同时，还需要熟悉大数据相关组件，对 Hadoop、HBase、Hive、Spark、Kafk a等开源大数据项目有深入的了解，能够进行安装与调试、升级扩容和优化、参数调优等操作。此外，还需需要熟知各个组件的依赖关系：大数据集群中通常包含多个框架和组件，如 Hadoop 生态系统中的分布式存储、分布式计算、NoSQL 系统、实时计算等。这些组件之间存在复杂的依赖关系，需要技术人员深入了解并掌握这些依赖关系，以确保集群的稳定性和性能。这些技术能力的要求，以及复杂的系统架构增加了维护大数据集群的技术难度，使得运维大数据集群的技术门槛相对较高。即使具备这些技术能力的要求后，在日常的运维工作中依然面临各种各样的风险，给运维工作带来较多挑战：Hadoop 生态系统中包含了 HDFS、YARN、Hive、HBase、Spark 等众多组件。每个组件都有各自的版本发布周期，不同版本之间可能存在 API 变更、性能优化或新特性的引入，这些变化可能导致组件间的不兼容。当大数据集群出现故障时，故障可能涉及多个组件和层面，排查故障需要综合考虑多种因素，故障排查难度大。对于关键业务系统，一旦出现故障，需要迅速恢复服务，以减少对业务的影响。这对技术人员的应急响应能力和故障恢复能力都提出了很高的要求。为了解决上述问题，让大数据平台更好的、更高效的服务用户，处理公司的数据需求，我们将目光投向了近年新兴发展的技术，Serverless。Serverless 技术简介
1. Serverless 概念及特点
Serverless，又名无服务器，所谓无服务器并非是说不需要依赖和依靠服务器等资源，而是开发者再也不用过多考虑服务器的问题,可以更专注在产品代码上。Serverless 技术以其按需使用、无需管理基础设施等特点，迅速在业界崭露头角。在 Serverless 模式下，开发者可以专注于业务逻辑的实现，而无需关注底层服务器的运维和管理。这种技术模式为大数据处理带来了新的思路。与传统的 Hadoop 架构相比，Serverless 技术具有更高的资源利用率、更低的运维成本和更快的响应速度。这些优势使得 Serverless 技术在大数据领域具有广泛的应用前景。 2. Serverless 的优势
- 自动扩展和收缩资源：Serverless 产品可以根据工作负载的需求自动扩展和收缩资源，从而提高资源利用率并降低成本，集群根据业务峰谷进行弹性伸缩，具有高灵活、高稳定性的特点，按 CU 使用量付费。
- 快速部署和启用：Serverless 产品可以快速部署和启用，无需预先配置和管理服务器，从而提高了开发和部署效率。
- 低成本：使用 Serverless 产品可以降低成本，因为它不需要购买和维护服务器，只需要按需支付计算的费用，精准控制成本投入。
- 易于管理和维护：Serverless 产品可以简化管理和维护工作，因为它不需要管理服务器、操作系统和数据库，只需要管理应用程序和数据。
- 快速响应变化：在大数据环境中，数据的产生和处理需求可能随着市场、用户行为等多种因素的变化而快速变化。使用 Serverless 架构的产品能够快速扩展或缩减底层资源，以响应这些变化，确保大数据处理的及时性和有效性。
- 提升系统可靠性：通过使用 Serverless 架构的产品，大数据系统可以更容易地应对突发的高负载情况，如促销活动、节假日等带来的数据峰值。产品自带的弹性扩展能力有助于提升系统的稳定性和可靠性，避免因负载过大而导致的系统崩溃或性能下降。
3. Serverless 存在的弊端
- 供应商锁定：由于 Serverless 架构依赖于特定的服务提供商，因此可能存在供应商锁定的风险。
- 冷启动时间：当 Serverless 服务在长时间未被调用后突然接收到请求时，会出现冷启动问题，导致第一个任务运行时长增加。
- 长时间运行的任务不适合：对于需要长时间运行的任务或服务，由于成本、Serverless 产品运行时长等因素，Serverless 架构可能并非最佳选择。
- 可观测性受限：Serverless 架构下，服务或者产品运行监控指标依赖于云厂商提供，云厂商仅暴露部分指标，无法拿到所有详细的运行数据，会影响可观测性建设。
4. 一种 Serverless 产品
腾讯云数据湖计算 DLC（Data Lake Compute，DLC）提供了敏捷高效的数据湖分析与计算服务。服务采用无服务器架构（Serverless），开箱即用。使用标准 SQL 语法即可完成数据处理、多源数据联合计算等数据工作，有效降低用户数据分析服务搭建成本及使用成本，提高企业数据敏捷度。产品特点：存算分离架构、弹性伸缩、统一元数据、数据湖计算、开箱即用、丰富的API功能支持：联邦查询支持外部数据源 COS 、EMR-COS、EMR-HDFS、EMR-CHDFS、Mysql、ElasticSearch 等。支持数据格式：CSV、Json、Parquet、Avro、ORC 等
DLC 整个任务链路分为 Treehole， EOS， Hybris 3 个组件，每个组件都以多实例方式通过 Kubernetes 进行部署。Treehole 服务：负责计费，底层 K8S 资源的申请，引擎生命周期管理，任务路由，
通过云 API 提供 DLC 相关的 API 接口，负责对接控制台，和 JDBC， 任务经由 Treehole 完成任务记录转发给 EOS 服务。EOS 服务：提供集群部署，自动启停， 任务监控，任务排队， 集群弹性，SQL 校验等能力。集群部署：引擎部署于腾讯云 EKS/TKE Serverless 服务，实现计算资源的随意伸缩。集群相关信息被保存在数据库中，收到任务或启动引擎请求时，EOS 按集群在数据库中的信息， 转换成 Kubernetes 部署信息，向 K8S 服务提交请求，在 K8S 启动对应的引擎部署，在收到集群挂起请求时，或者在引擎处于空闲一段时间后， EOS 会销毁在 K8S 的部署。EOS 支持 Spark 和 Presto 引擎的部署，同时会持续监控引擎的状态， 确保引擎处于正常运行状态。任务排队：Spark 原生引擎不支持任务排队， 在 SQL 并发度较高时，容易让 Spark Driver OOM， 排队能更好的避免引擎过载。任务发送到 EOS 服务后， EOS 会确认任务执行引擎处于可用状态，即该集群已经启动完成，
且负载处于可接受任务状态， 否则任务会进入 EOS 队列，只有当检测到引擎可用时，再将任务路由给后端引擎。允许用户配置集群弹性数量， 通过监控该集群的排队情况， 资源负载动态拉起同等规模的集群， 将任务分发给负载较低的弹性集群，
当集群负载处于低位一段时间， 将弹性集群进行缩容。在 SQL 发送的引擎前，EOS 会解析查询完成元数据校验以及权限校验，查询解析后， EOS 会向 Hybris 服务发送元数据校验请求，确保查询涉及到的表库的合法性。Hybris 多租户元数据服务提供了一套原生 Hive Metastore 访问接口和一套 REST 访问接口，旨在为 DLC EOS 服务和引擎提供多租户元数据管理能力。该服务支持多引擎元数据共享，实现了Spark 和 Presto 之间的元数据互通，使得在多引擎查询数据时，能够更好地利用元数据统计信息进行基于成本的查询优化（CBO）。此外，Hybris 服务对底层元数据存储库表结构和访问接口进行了特别优化，提供了比原生 Hive Metastore 更高效的元数据访问性能。方案与实施过程
1. 整体落地方案
Serverless 实践前后架构对比图
如上架构变更图所示，我们采用 DLC-Presto 替换原有的 EMR-presto 集群，采用 DLC-Spark-SQL 引擎替换原有的 EMR-Hive-Tez 引擎，采用流计算 Oceanus 替换原有的 EMR-Flink 引擎，存储则由对象存储（COS）替换原有的 HDFS，数据集成引擎由 Sqoop、DataX 切换至 Apache
Seatunnel。
在确定这一整体思路后，我们首先制定了整体升级顺序：计算引擎 Severless 化 -> 存储 Serverless 化->数据集成 Serverless 化，这样由上至下，先改造升级用户体感较强的服务，然后再升级底层服务。同时整个过程通过改造数据工厂使之能够新旧引擎同时双跑，以实现平滑升级改造。2. 计算引擎 Serverless 化
Presto 是火花思维数据分析的主要 OLAP 引擎之一，它贯穿了火花数仓的各个发展阶段，深受火花商业分析人员的喜爱。在火花，Presto 覆盖了数据服务、分析提数、数据下载、BI 看板、数据应用等多个场景，因此 Presto 与火花思维各个版本的 BI 工具和开发平台都存在依赖整合关系。为了更好地适应不同的业务场景和需求，我们将自建 Presto 集群切换至数据湖计算 DLC-Presto。DLC-Presto 采用无服务器架构（Serverless），开箱即用。使用标准 SQL 语法即可完成数据处理、多源数据联合计算等数据工作，有效降低用户数据分析服务搭建成本及使用成本，它可以根据实际的业务需求自动扩展和收缩资源，从而提高系统的灵活性和可扩展性。切换至 DLC Presto 主要是依据业务归属和使用场景，替换各个场景下的 API 和 SDK。由于在自建集群和 EMR 集群时代，Presto 引擎都是基于开源版构建的，虽然腾讯 DLC 产品提供了统一标准 SQL，但考虑到我们用户的编程习惯更习惯于原生语法，且数据分析师和BI平台有大量的历史 SQL 都是基于原生语法，因此我们与腾讯沟通，为我们开设了 Presto 原生语法 SQL 支持的功能。为了保证平滑迁移，我们按照具体使用场景，制定了如下的切换顺序，首先在数据工厂进行双跑验证，验证通过后依次进行下列场景的切换，BI 平台、数据消费平台、其他数据应用等。对比原 EMR-Presto 和 DLC-Presto 的版本，提前识别兼容性问题。
在 DLC-Presto 集群上创建与 EMR-Hive 数据源的连接，打通联邦查询路径，确保数据可以正确地读取。
语法验证：从数据工厂、BI 平台提取了常用的、不同特征的 SQL 提交至 DLC-Presto 集群，进行语法测试、双端结果比对验证、性能测试等。
在数据工厂的组件对接层增加 DLC-presto 引擎服务，与腾讯云 DLC-Presto 引擎进行对接，后端服务在 SQL 提交、获取结果、作业终止、数据下载、异常捕获和日志查询等各个环节进行接口适配。
双跑支持：在数据工厂，增加 DLC-Presto 队列管理功能，管理人员通过该管理界面新增、修改、删除、分配 DLC-Presto 队列，DLC-Presto 与原先的 EMR-Presto 队列共存，通过队列控制，将任务分发至不同的底层引擎，从而支持两种引擎双跑。
确定 DLC-Presto 引擎所属平台，以及平台内各成本独立计费的单元（项目、组织结构等），结合各端历史所需资源大小，定制化集群参数，我们通过这一步骤将原先 2 个 EMR 集群拆解为了 18 个 DLC-Presto 集群，根据业务需求和任务量、任务频率等特点，配置适合的 DLC-Presto 集群，包括计算资源规格（CU 数量），单集群最大任务并发数，集群弹性数量，是否自动挂起等。
不同的项目分配不同的 dlc-presto 队列，对接底层不同的 DLC-Presto 引擎，从而实现不项目间的 Presto 引擎物理隔离。
如上所述，我们在数据工厂通过用户检验平稳使用运行一段时间后，制定了针对其他 Presto 使用场景迁移计划，包括迁移改造的时间窗口、改造方式等；按照上述思路依次完成了 BI 平台、数据消费平台、数据应用的 Presto 引擎切换。Hive-Tez 一直是火花大数据处理离线数据的主要引擎之一，在自建 Hadoop 集群和 EMR 集群时代，Tez 引擎处理了火花数仓 90% 以上的离线 SQL 任务。随着离线任务量的不断增长，算力逐渐紧张，Yarn 队列之间的资源竞争日益激烈，导致每天的调度完成时间不断延迟。为了更好地适应不同的业务场景和需求，我们将离线计算引擎从 Hive-Tez 切换到数据湖计算（DLC-Spark-Sql）。DLC-Spark-Sql 是基于 SparkSql 构建的，继承了 Spark 的高性能计算能力，同时采用了无服务器架构（Serverless），即开即用，简化了集群管理和资源调配的复杂性。在资源管理方面，DLC-Spark-Sql 可以根据实际任务需求自动扩展和收缩集群资源，提高了资源利用率和响应速度，从而增强了系统的灵活性。这一特性对于处理大规模、高并发、复杂多变的离线 SQL 任务尤为重要，有效避免了资源浪费和任务调度延迟的问题。在我们的改造过程中，考虑到数据实际存储在 EMR 集群的 HDFS（Hadoop 分布式文件系统）中，我们首先利用 DLC 产品的联邦查询功能来计算处理 EMR-Hive 中的数据。这种联邦查询机制能够在不迁移数据的前提下，实现不同系统之间的无缝对接和协同计算，保证了业务的连续性和数据的安全性。随着存储 Serverless 化的推进，我们进一步实现了从 HDFS 到 COS（对象存储服务）的过渡，利用 DLC 联邦查询 COS 来高效处理存储在对象存储中的大数据。Hive 元数据则一直使用 EMR-HiveMetaStore，DLC 引擎会自动同步 Hive 的元数据信息。任务提交替代方案：Hive 作为大数据的核心组件，与之交互的周边工具众多。火花 Hive 任务的提交方式主要有 JDBC、Hive-client 和 Python-pyhive 等。针对使用 JDBC 与 Hive 交互的场景，我们使用 DLC-JDBC 进行替换；针对使用 Hive-client 和 Python-pyhive 的场景，统一使用 DLC-Python-SDK 进行了替换。任务粒度参数配置：在使用 Hive-Tez 时，支持在 SQL 语句中进行个性化参数设置。由于 Spark-SQL 无法在 SQL 语句中配置参数，因此我们在治理平台界面添加了单独的参数设置界面，并通过任务触发运行 API 提交至 DLC 集群。一致性检验：由于此次改造涉及两种引擎的语法差异，为了保证任务稳定性和改造后任务结果的准确性，我们根据原始任务 SQL 创建了 1 对 1 使用新引擎的测试任务，并通过比对两个任务的结果进行一致性检验。主要思路是对所有结果字段（剔除 etl 时间等字段）进行拼接取 md5 值，然后对比两张表的最终结果是否一致。如果存在不一致的数据，需要人工进行差异问题的排查。火花整体任务检验通过率约为 70%，剩余约 30% 存在语法差异，我们通过人工排查解决了不一致的问题。对比 Hive—Tez 和 Spark-Sql 两种引擎语法：提前识别语法差异问题。
确定 Hive 上层工具影响范围：包括 BI 工具、数据工厂、数据服务平台等，按照任务提交替代方案，进行适配改造。
梳理 Hive 在使用的 UDF：根据使用频率依次进行适配改造为 DLC-Spark-UDF。
创建测试任务：与原任务结果进行结果数据比对，做数据一致性检查。
确定迁移层级优先级：ads>dm>dws>dwd，最终把各层级的 SLA 任务迁移优先级置为最低。
配置 DLC-Spark-Sql 集群：根据每个项目的任务情况及算力要求，且根据不同的应用场景按需配置了不同规格的集群并设置相应参数，包括集群规格、是否弹性伸缩和弹性上限、单个集群任务量上限、排队时间上限等。例如，为数据分析师项目最大配置了 512CU，最大可扩展至 5 个（512CU）集群，有排队任务立即触发弹性扩容；为 HR 所在项目则配置了最小规模集群 16CU，且不进行扩容；为数据工厂配置了常驻集群，为一些页面元数据信息展示提供支持，设置 16CU，不自动挂起、不弹性伸缩。
迁移时间窗口：业务低谷期集中切换计算引擎。
双跑策略：在数据工厂新增一种 DLC-Spark-Sql 队列，原 EMR-Hive 队列与 DLC-Spark-Sql 队列在双跑期间同时存在，迁移完成并稳定运行后则下线原 EMR-Hive 队列。
我们根据上述思路完成了所有 HSQL 任务的引擎升级迁移工作。由于涉及到语法改动问题，所以此模块的工作难度较大。在整个 Serverless 实践中，火花在此模块中投入了最多的人力。如其他互联网公司一样，火花先后使用 SparkStreaming 、FLink 两种实时计算引擎，在完成迁移至 EMR 集群后，为了方便管理、迭代
，我们逐渐将 SparkStreaming 任务用 Flink 进行了重写。所以火花现存的实时任务主要有两种，FLink-SQL 、FLink-Jar。实时计算在火花的主要应用场景有实时数据接入、实时数据分析与报表、实时策略等。为了实现实时引擎的 Serverless 化，我们决定采用腾讯云的流计算 Oceanus 来实现。流计算 Oceanus 是腾讯云大数据产品生态体系的实时化分析利器，是基于 Apache
Flink 构建的具备一站开发、无缝连接、亚秒延时、低廉成本、安全稳定等特点的企业级实时大数据分析平台。同样支持按量计费的模式，按购买的 CU 数计费，1 个计算 CU 包含 1 核 CPU 与 4GB 内存，支持三种规格的计算单元：0.5CU、1CU、2CU。Oceanus 支持多种 connnector，并且支持自定义 Connctor，可以依托 Connector 连接多种上下游数据服务，快速实现实时数据汇聚及结果数据落地，基本覆盖了火花写 ES、Doris、mq、Kafka 等场景。在数据工厂新增队列类型，Oceanus 队列与腾讯云 Oceanus 引擎一一对应，从而支持 Oceanus 与原 EMR FLink 并存。
在实时计算引擎对接层进行代码适配，在原先功能的基础上新增与 Oceanus 引擎交互的功能，实现基于 Oceanus 的实时任务创建、修改、删除、触发执行、查询 log、访问 Flink UI 界面地址等功能，达成同时支持 EMR-Flink 和 Oceanus-Flink 双跑的目标。
根据任务的重要性分类，将任务分为了三个种类，分别是 P2 类任务、 P1 类任务 、P0 类任务 ，根据任务的重要程度（P2->P1->P0）制定了任务迁移顺序。
由实时引擎开发人员制定任务迁移方案，总结迁移事项注意点，初始化 Oceanus 环境，做好迁移实时任务的准备工作。
根据迁移方案，由数据工厂所有运营人员按照迁移顺序，进行任务迁移、验证、上线；在此过程中将实时任务的检查点存储位置变更，由 HDFS 切换至 COS 存储，如果是数据接入程序，则也需要将目标表修改至 COS 存储。
对于一些用户行为日志表，我们使用 DLC-Spark 引擎，将数据按照分区从 HDFS 迁移至 COS，历史数据迁移完成后，再将实时日志接入任务切换至 Oceanus，并从切换完成当天的零点重新消费 Kafka 的消息，保证数据的完整性。
3. 存储 Serverless 化
在传统的 Hadoop 架构中，DataNode 的数量决定了存储空间的大小，同时 DataNode 机器性能也决定了数据传输的性能。当存储空间不足时，需要增加 DataNode 来扩容；当存储空间过剩时，需要减少 DataNode 来缩容。这种扩容缩容的操作不仅繁琐，而且容易出错，给系统的稳定性和可靠性带来了很大的挑战。为提高存储系统的可扩展性、降低运营成本和简化管理，我们用对象存储替代了 Hadoop HDFS 系统，实现了存储与计算的完全分离。- 按需付费模式：不同于传统的 HDFS，对象存储是基于实际使用量进行计费的，因此存储成本更加灵活和透明。
- 无限扩展性：对象存储不再受 DataNode 数量的限制，存储空间可以无限扩展，满足大数据场景下的海量数据需求。
- 简化运维：对象存储无需管理和维护底层存储设备，大大降低了运维的复杂性。
存算分离的架构中，数据存储和计算分开部署在不同的节点或系统中。这种架构模式下，存储节点负责数据的存储和管理，而计算节点负责数据的处理和计算。由于数据需要在存储节点和计算节点之间频繁传输，因此数据传输速度直接决定了数据处理的效率和响应时间。在我们此次架构升级改造过程中，首先完成计算引擎 Serverless 化之后，由于数据仍然在 EMR 集群中，随着任务量的不断上涨，我们一度在调度任务高峰期触及 EMR 集群与 DLC 引擎集群间的传输上限，造成调度任务变慢，调度延迟，一方面促使我们立即进行了存储的 Serverless 化工作，也让我们意识到在存算分离的架构中，存储系统与计算系统的最大传输速率成为影响整体性能的关键因素。DLC 引擎没有带宽限制，而单个对象存储桶具有带宽上限，带宽不足会导致数据传输变慢，计算引擎等待数据的时间增加，从而延迟整体计算任务的完成时间。在调度任务高峰期，大规模数据处理需要并行操作，多个计算节点同时访问存储系统来处理不同的数据分片，带宽不足会导致这些并行请求之间的竞争，进一步降低整体效率。所以在新架构中对象存储桶带宽成为影响整体性能的关键因素。- 高频访问数据单独存储：将下游引用较多的数据库，如数仓的 DW、DIM 库等，单独放置在一个桶中，使用高速桶，具有较高的带宽上限，以提高这部分数据的吞吐速度。
- 低频访问数据共享存储：将类似 ADS 层等下游任务较少的数据表共享同一个存储桶，以优化资源使用。
经过自建集群和 EMR 集群两个时代的积累，火花大数据底层历史数据文件存在多个版本。为了统一底层文件版本，我们在此次存储迁移过程中进行了存储文件升级优化，具体包括以下三个方面：迁移方案采用 DLC-Spark-SQL 进行数据迁移和底层文件重写，即利用 SQL 语句将数据从 HDFS 存储表复制至 COS 存储表中，将迁移步骤封装在一个自动化脚本中，具体步骤包括：- 元数据切换：切换元数据引用至新表，完成数据迁移的最终步骤。
- 分区表迁移：针对分区表，按照分区拆分为多个迁移任务，逐个迁移各分区的数据。
迁移任务按照数仓分层进行，从上至下依次为：ADS 层、DM 层、DW 层和 ODS 层。为尽量减少迁移对正常业务的影响，我们选择在系统调度低谷期错峰进行数据迁移。整个迁移过程耗时约两个月。4. 数据集成 Serverless 化
火花大数据一直使用 Sqoop、DataX 作为底层数据集成工具。然而，Sqoop 作为大数据领域历史最悠久的数据集成工具，存在数据源支持不够丰富、缺乏一些重要功能特性的缺点，且社区已经不再活跃。而 DataX 则存在单机运行、会占用较多内存资源的缺点。因此，我们此次升级决定采用 Apache SeaTunnel 作为新的数据集成工具。Apache SeaTunnel 是一个非常易用的超高性能分布式数据集成产品，支持海量数据的离线及实时同步，每天可稳定高效同步万亿级数据，已应用于数百家企业生产，也是首个由国人主导贡献到 Apache 基金会的数据集成顶级项目。SeaTunnel 支持多种丰富的连接器，目前已有上百种连接器，完全覆盖火花 MySQL-Hive、Hive-Mysql、Hive-ES、Hive-Doris 等数据集成场景。为了实现数据集成的 Serverless 化，我们决定通过采用 DLC-Spark-Job 来部署运行数据集成任务。数据湖 DLC-Spark-Job 同样采用无服务器架构（Serverless），提供基于原生 Spark 的批处理计算能力，支持用户通过数据任务进行复杂的数据处理、ETL 等操作。DLC-Spark-Job 数据作业根据 CU 使用量进行计费，按量计费，创建作业后，触发拉起使用，作业运行完成后自动挂起不再产生费用，非常适合数据集成这样的周期性使用的场景。而 SeaTunnel 支持三种引擎模式（SeaTunnel Zeta、Flink、Spark），因此我们最终确立了基于 DLC-Spark-Job + SeaTunnel Spark 的新数据集成方案。在 Apache SeaTunnel 开源代码的基础上进行了二次开发，将 SeaTunnel-Spark 任务配置文件由读本地文件切换为读 COS 文件，优化组件（JDBC-source 、COS-sink），并针对 DLC-Spark-Job 的任务提交方式进行适配改造，使之能够通过 DLC-Spark-Job 部署、运行 SeaTunnel-Spark 数据集成任务。
Athena 数据工厂新增一种 dlc_spark_job 队列，通过该类队列与 DLC-Spark-Job 集群进行关联，一一对应，与原有的数据集成队列同时存在，实现新旧数据集成引擎双跑。
数据集成任务参数适配，配置 Spark 任务所需参数，如 executor 数量、executor 资源规格、driver 资源等信息。
通过数据治理平台的数据集成对接引擎与腾讯 DLC-Spark-Job 相关 API 进行交互，来进行 Spark-Job 定义、修改、删除、触发任务，取消运行、查询日志等操作。
根据项目、业务线和使用场景，建立多个 DLC-Spark-Job 引擎，并根据历史算力使用情况，定制化集群规格参数。
对比原 Sqoop、DataX 任务进行准确性、性能、运行时长测试。
确定迁移优先级，制定迁移计划，包括任务迁移的时间窗口、迁移方式等。
小文件控制，相比于 Sqoop ,Seatunnel 更容易产生小文件，需要通过合并分区来减少最终的文件数量。
并发控制，数据集成需要访问其他类型的数据源，读取或者写入其他类型的数据源，需要在配置任务的时候考虑对其他类型数据源的影响，避免大并发操作导致的机器负载过高。
5. 实施落地时间轴
实践收益
1. 成本效益
此次火花整体 Serverless 架构升级带来的成本收益具体如下：此外，在新的架构体系中，运维人员所需运维的服务器数量直接减少，各个组件独立存在，大幅降低了人工干预的需求。整体 ServerLess 架构所具备的弹性伸缩特性，使得我们无需再为资源的过度或不足而担忧，从而直接削减了运维成本与维护成本。2. 性能效益
如上调度任务迁移前后运行时长变化对数散点图，我们观测到迁移期间一直存续的 1402 个 HSQL 任务中，其中 1333 个任务是变快了，性能提升在 35% 左右，另外 69 个任务由于迁移期间数据扫描量增多、或者迭代了 SQL 逻辑而变慢了。
如上图所示，火花大数据在完成离线计算引擎切换后天调度整体运行时长缩减至原先的 2/3，天调度单任务运行时长中位数降低 56.57%。
此次 Serverless 架构升级改造为火花大数据带来了极其显著的稳定性提升。详细来看，诚如上述两张图示所示，火花经由此次 Serverless 升级改造，致使大数据 SLA 故障数大幅降低，数据缺陷数量也显著减少。用户体感方面，以往出现的数据卡顿、延迟等问题得到了极大改善，大数据部门没有再收到任何关于因算力争抢引发的投诉，用户在操作过程中能够更加流畅地处理数据，工作效率显著提高。其次，对于大数据运营团队来说，运营压力明显减轻。以往为了应对频繁的故障和缺陷，需要投入大量的人力和时间进行维护和修复，而现在可以将更多的精力投入到业务的优化和发展上。4. 架构收益
（1）Serverless 架构的弹性计算解决了原有平台算力瓶颈问题，显著地提升了整体算力和资源利用率Serverless 架构的弹性计算使得我们能够根据实际需求动态地分配计算资源，从而有效地应对峰值时期的算力需求。在采用弹性计算之前，火花算力峰值为 1600CU，但现在，通过 Serverless 架构的弹性计算优化，我们成功地将算力峰值提升至 7600CU，实现了超过四倍的提升。这意味着平台能够更好地应对高负载的计算任务，提供更快速和准确的计算结果，满足用户对高性能计算的需求，提升了平台的整体承载能力。除了提升峰值算力，Serverless 架构的弹性计算还带来了资源利用效率的提高。在低谷期，传统的计算平台往往会浪费大量的机器资源，而 Serverless 架构的弹性计算能够自动调整资源分配，将不需要的计算资源直接释放。这样不仅避免了机器资源的浪费，还降低了能耗和运营成本，提高了整体资源利用效率，实现了更绿色和可持续的计算方式。（2）对象存储解决了原有平台存储瓶颈问题和数据传输瓶颈迁移至对象存储后，存储空间不再受限于 DataNode 数量，无需再设置 80% 的安全水位线，也无需再考虑 DataNode 扩容缩容的问题。对象存储技术还支持几乎无限制的扩容，随着业务的增长，数据量可能会迅速增加，而该技术可以轻松应对这种情况，确保平台有足够的存储空间来存储和处理数据。集群数据传输也不再受限于集群机器硬件性能等因素的影响。通过合理的配置对象存储桶，设置相应的存储桶带宽，存储层可以更高效地与上层服务进行数据交互，提高数据的可用性和可扩展性，进一步满足业务需求。（3）数据处理引擎和数据存储介质的架构解耦，极大地提高了平台的健壮性和扩展性、稳定性原有的平台，大数据集群的计算和存储都强耦合的运行在 Hadoop 集群上。集群的任何一个模块出现问题，都可以导致集群的不可用，进而导致其他模块都不可用。例如：在 EMR-Hadoop 集群删除大量数据时，容易导致 NameNode 的 RpcServer 过载，影响 NameNode 请求处理效率，进而导致大面积实时任务挂掉，离线任务运行超时，整个集群处于几乎不可用的状态。新平台的解耦架构实现了计算引擎、存储介质的解耦，从根本上避免了此类问题。存储和计算实现分离解耦后，计算引擎可以根据项目的实际需要进行扩容缩容，不再受限于 DataNode 数量，各个项目之间实现了计算引擎层面的物理隔离，局部问题不会扩散至其他项目，有效避免了连锁反应。针对计算引擎的操作，如升级、维护或故障恢复，只会影响计算部分的功能，对存储部分没有任何影响。这种分离使得计算引擎的管理更加独立和灵活，可以进行独立的升级、维护和故障恢复操作，而不会对存储系统造成干扰，提升了系统的整体稳定性。存储介质采用对象存储技术，按实际使用量计费，平台人员只需关注存储内容的变化，日常针对存储的操作也只会影响存储层，不会再影响计算引擎的稳定性。新的架构减少了影响整个系统级别的运维操作，这降低了运维操作带来的风险，提高了系统的稳定性和可用性，这有助于减少系统故障时间。新的架构对升级十分友好，当引擎新功能需要上线时，可以先在小范围内进行试运行，试运行无问题再大范围应用；也可以实现计算引擎用户无感升级，当需要升级计算引擎时，可以根据每个引擎的实际使用量，在引擎挂起时间进行滚动升级，实现用户无感的情况下完成升级
，最大程度减少了因升级给用户带来的影响。新架构可以根据项目任务的具体情况，为不同类型的项目分配不同规模和配置的计算引擎集群。对于那些包含较多 SQL 复杂操作、数据扫描量较大的任务的项目，我们会分配高配置的集群，以确保其高效稳定地运行；而对于 SQL 简单、数据扫描量较少的项目，则会分配低配置的集群，以避免资源浪费。同时，我们还会根据项目内任务的数量、调度运行的峰值确定不同的弹性规则，对于任务较少、峰值低的项目，集群将不会进行弹性扩容，以保证资源的合理利用；而对于任务较多、峰值高的项目，集群将根据需求，设置弹性伸缩上限，进行弹性扩容，以满足项目的运行需求。新架构具有计算按量付费、存储按量付费的特点，因此可以针对不同的业务部门根据其项目算力与存储的实际使用情况进行财务成本的分摊核算。通过这种方式，可以更加准确地了解每个业务部门的资源使用情况，从而更好地进行成本控制和资源分配。同时，还可以通过对各个项目的成本核算，为企业的决策提供更加精确的数据支持。实现了对资源更为精细化的管理后，能够依据对象存储的实际使用量精确计算出每张表的存储成本，根据计算任务的计算耗时以及引擎规格精确计算出每个任务的计算成本，这为数据治理也提供了重要的依据。经验与教训
在整个 Serverless 架构的升级改造进程中，我们遭遇了诸多问题，以下是火花所积累的部分经验与教训。1. 集群冷启动时间
弹性集群由挂起转入运行状态时，需要 2 分钟左右的启动时间，用户在自助提数场景下，感受前后差异比较明显
，影响用户体验，一方面为在冷启动时做好提示给用户，另外一方面可以根据每个集群的使用特点及用户需求，定时提交简单查询触发集群运行，例如工作日时间每天 9 点 55 提前为 BI 分析师触发集群运行。2. 文件版本兼容性问题
离线计算引擎迁移完成后，存储迁移之前，我们在数据使用的过程中发现了数据文件兼容性问题：由于某张 Hive 表中同时存在了老的 hive-tez 引擎写入的数据和 DLC-Spark 引擎写入的数据， 两者由于文件 ORC 版本不一致，而 DLC-SparK 引擎未能配置兼容性参数，导致任务结果数据缺失了一部分，最终造成了上层数据结果部分数据不准确，影响了用数。大数据平台有很多历史数据文件历经自建集群、EMR 集群到现在的使用 DLC 集群进行计算，导致有些底层文件存在较大的版本差异，我们在迁移计算引擎的过程中未能充分考虑到这些复杂的历史原因，因此我们在后面存储迁移的过程中，通过重写数据统一升级了底层数据文件格式及版本。3. 存在资源不足风险
由于 DLC 产品是构建在底层容器化之上的，如果云厂商底层容器资源不足，会导致 DLC 集群无法顺利扩容，导致算力不足；在 2023 年 11 月份，我们遇到了此类情况，幸亏当时我们发现及时，DLC 相关支持人员也积极应对，才未造成影响。所以建议，当遇到业务高峰期、大促期间，需要和云厂商提前沟通，预留资源。4. DLC-Spark-SQL 引擎资源竞抢问题
我们在使用了 DLC-Spark-SQL 引擎一段时间后发现，有些任务调度运行时长变化特别大，从 1 分钟内波动到 8 分钟。经过与 DLC 产品支持人员沟通才知道原因：调度运行时在同一引擎提交多任务后发生资源竞抢，导致 job-stage 之间的时间间隙不一致，资源充足时，立刻进入下一个 stage,整体运行时长就短，如果资源不充足则需要等待资源，有资源后才能进入下个 stage，导致任务运行时长偏长。这种现象是由 DLC-Sparl-Sql 引擎自身的产品特点所导致的。尽管能够通过调整调度模型来对这类现象进行优化，但从中也可以看出，Serverless 产品在某些细微之处仍存在缺陷，产品仍需进一步迭代和优化。5. 注意不同环境任务隔离
我们在使用 Serverless 产品时，与底层引擎的操作都切换至了 Serverless 产品的 API，而且所有任务的操作都是通过 API 与云厂商产品进行交互，但云厂商 API 不区分测试环境、线上环境，因此在开发时需要注意测试环境与生产环境的隔离问题，需要尽可能的使用云厂商提供的空间、项目等概念进行环境隔离，如果 Serverless 产品也无上述概念，则可以考虑使用任务名等其他方式进行隔离。6. 自助提数与任务调度使用同一引擎问题
在日常的工作中，分析师常常需要提取数据来支持他们的分析工作。这一过程通常涉及到在特定的工作时间内频繁地启动计算引擎，但单个项目的任务密度与连续程度不能保证该项目的集群一直运行。任务调度所依赖的计算引擎，出于要同时兼顾同一项目下大型任务运行的考虑，往往可能采用了较大规格的计算引擎配置。这就导致了一种不太理想的情况出现，即分析师或许仅仅是为了执行一个简单的提数 SQL 语句，就得启动了一个规模较大的计算引擎。结果，简单的提数任务被分配到了大型的计算引擎上，从而造成了计算资源的不必要浪费。为了解决这一问题，一个可行的方案是将自助提数引擎与调度任务的计算引擎进行明确的分离，降低自助提数引擎的规格。通过这种分离，可以一定程度上减少自助提数场景下的资源浪费，提高资源的利用效率。然而，即使进行了这样的分离，分析师在日常提数时，仍然难以避免会用到复杂的 SQL 语句，需要使用大规格的计算引擎。如果期望从根本上解决这个问题，关键在于找到一种更适合自助提数场景的 Serverless 产品形态。这种产品形态能够根据任务的实际需求自动地分配和调整更细粒度地计算资源，从而最大程度地避免资源的浪费，同时为分析师提供更加便捷和高效的提数体验。7. 改造成本
现存非 Serverless 架构业务向 Serverless 架构转型，会涉及到较大成本的改造问题主要涉及到如下几个方面：双跑期间云成本：由于切换需要一定的过渡期，所以需要两套系统双跑一段时间；上层系统研发改造成本：涉及数据工厂、BI 平台等大数据相关服务需要进行功能改造适配；业务代码改造适配：版本不兼容等问题需要进行用户代码适配；时间成本：项目整体时间跨度较大，在保证支撑现有业务的前提下，团队不能持续投入在这一个项目上，火花共用了 1 年半的时间才完成整体 Serverless 改造；人力成本：火花在本次实践项目上先后投入的人力有， 前端 1 人、后端 1 人、引擎开发人员 3 人、测试人员 2 人、数仓人员 4 人， 运维人员 1 人；8. 如何确保升级迁移期间的业务连续性与稳定性
鉴于每个迁移升级步骤均牵涉到底层引擎的重大改造，对系统稳定性构成挑战，因此，为防止对现有业务产生影响，质量部门需全程监督、全程参与，并于重点场景开展性能测试及兼容性测试。与此同时，还需与大数据平台服务的用户进行充分交流，构建定期的信息同步机制，以利于及时同步项目进展情况，利于用户在改造过程中予以配合，对于用户提出的问题和意见，要及时响应和处理，形成良好的互动和合作关系，共同推动迁移升级项目的顺利完成。9. Serverless 产品支持人员在迁移升级过程中发挥着重要的作用
虽然 Serverless 产品已经出现了一段时间，但在实际的应用中，其迁移过程并非一帆风顺，会遇到各种各样的问题。Serverless 产品支持人员在此过程中扮演着至关重要的角色。他们不仅具备专业的技术知识，还拥有丰富的经验。能够深入理解 Serverless 架构的特点，包括其无服务器化、弹性扩展、按需付费等特性。凭借着深厚的技术功底，他们能够为用户提供准确的技术指导和建议。无论是在前期的规划阶段，还是在迁移过程中的具体操作环节，亦或是后期的优化和维护阶段，都能为企业提供全方位的支持，确保迁移升级过程的顺利进行。总结与展望
升级 Serverless 架构后，为整个大数据平台带来了全新的变化及潜在可能性，尤其在资源分配、弹性扩展和成本控制等方面，使大数据平台有了显著的改进。如何充分利用这些变化及潜能，需要大数据从业者展开进一步的思考，以使大数据平台创造更多价值，更好地服务企业。当前，各大云服务供应商纷纷推出了大数据领域的无服务器（Serverless）产品，例如阿里云的 Serverless Spark 、云器 Lakehouse 以及华为云的 DLF 等。每种产品皆具有独特的特性，在运用此类产品时，我们仍需依据各产品的特点，寻觅最契合自身场景的使用模式。随着市场中 Serverless 产品的不断增多，以及产品的持续更新迭代和功能优化，可以预见未来将会有越来越多的公司借助此类 Serverless 产品来构建自身的大数据服务。拥有多年大数据平台架构设计与开发实战经验，专注于构建企业级大数据基础设施，致力于挖掘和实现数据价值。
