导读 在数字化转型的大潮中，企业面临的数据环境日益复杂多变。滴普科技的 FastData DCT 产品应运而生，专注于高效的数据集成和管理，以应对多样化的数据挑战。这款产品结合了流批一体和湖仓一体架构，提供了从数据集成、分析到价值实现的全链路服务，极大地提升了数据处理的时效性和灵活性。FastData DCT 凭借在异构数据源实时融合和数据仓库迁移方面的强大优势，有效提高了数据利用率和管理效率，减少了数据浪费。本次分享将深入探讨 FastData DCT 的架构演进和实际应用案例，展现其在推动各行业数字化转型升级中的重要作用。

下面的介绍分为六个部分：

1. 产品概述

2. 功能介绍

3. 技术架构演进

4. 应用场景

5. 成功案例

6. Q&A

分享嘉宾｜刘波 滴普科技 FastData产品线DataFacts产品负责人

编辑整理｜胡回

内容校对｜李瑶

出品社区｜DataFun

01产品概述

1. Data Fabric 数据架构

自 2019 年起，高德纳连续4年将数据编织(数据结构)列为年度数据和分析技术领域的十大趋势之一。高德纳认为"数据结构是数据管理的未来"。

数据架构是一种数据架构思想，包含 DataOps 数据工程，其中通过 AI、知识图谱等智能技术，实现主动元数据治理。

2. DCT 简介

DCT (Data Collection Transform，简称DCT)支持关系型数据库、NoSQL、数据仓库(OLAP)、数据湖(lceberg、Hudi)等数据源，可用于公有云之间、公有云与私有云之间的数据入湖入仓的结构迁移，存量数据同步和实时数据捕获同步。为企业实现数据流通，提供简单、安全和稳健的数据传输保障。

DCT 专注于数据的入湖入仓、出湖出仓场景，同时支持包括 PSC、Flink、Spark 在内的多引擎资源调度配置，支持批流一体以及故障转移等复杂的数据传输机制。在复杂的网络环境和业务背景下，DCT 提供了稳固的数据同步解决方案。

目前，DCT 已经发展到第四代。其第一代主要关注于参数配置；第二代引入了可视化界面，以简化任务配置过程；第三代实现了对读取与写入功能的组件化；而最新一代则新增了流批一体的任务类型，以进一步优化数据处理效率和弹性。

3. 产品定位：PB 级数据量下高效、稳定的数据传输高速公路

在大数据领域，特别是在 PB 级别的海量数据处理中，核心任务是确保数据传输的高效率和稳定性。DCT 的产品定位就是在PB级数据量下高效、稳定的数据传输高速公路。从源端到目标端，DCT 构建了一条能够灵活适应不同数据源的可组合数据链路。在这一过程中，涉及 13 种主流的数据源类型，包括关系型数据库、大规模并行处理系统（MPP）及数据湖和数据仓库等。

系统的核心技术能力集中在任务配置、组件管理以及运维维护等关键环节。这些能力共同支持了离线数据采集、实时数据采集以及批处理与流处理一体化等多样化的数据任务类型，确保了数据处理流程的灵活性和系统响应的及时性，满足了复杂数据操作的需求。

4. 产品价值

产品价值主要体现在三大方面：

• 异构数据源的实时融合
• 专注于实现不同数据源如 Oracle、MySQL、Kafka 和 Iceberg 等的实时数据融合。包括支持数据的增量捕获和异构数据的语义映射，以便实现数据的即时入湖。
• 整库入湖入仓，出湖出仓
• 支持 MySQL、Oracle 等数据源入湖入仓，出湖出仓。快速构建湖仓内数据，打通数据孤岛，实现数据的统一管理和高效利用，为数据开发工程师和数据分析人员可以快速建立数据模型、构建应用提供数据来源。
• 降本增效
• 降本：多种架构简化场景，简化软件架构设计，降低异构数据融合成本。通过拖拉拽实现同步链路的创建，低代码，降低学习和维护成本。
• 增效：无代码任务构建，提升数据集成敏捷性。支持组件自定义，提升客户业务创新效率。分布式引擎、组件级高可用保障，实时链路稳定高容错。

5. 产品优势

• 高性能多源异构数据采集
• 支持从关系型数据库、NoSQL、OLAP、数据湖等多样的数据源进行结构化迁移、离线同步以及实时同步。
• 批流一体化数据采集
• 采用统一的开发范式，同时实施大数据的流式和批量计算，确保数据处理的一致性，并简化了批流采集任务的配置流程。
• 高可靠性与时效性
• 通过变更数据捕获（CDC）机制，实现日志级别的数据监听，确保数据的时效性。同时，支持断点续传和故障转移，保障数据传输的高可靠性。
• 组件化插拔式管理
• 提供了组件插拔式管理，用户可以自定义组件进行扩展，并支持拖拉拽的任务配置方式，降低了代码编写的需求，使系统易于学习和维护。
• 低成本高效率运行
• 系统设计为单进程任务，最低仅需 1G 内存即可运行，降低了成本。同时，支持并行度设置，有效提高了数据传输效率。
• 云原生架构设计
• 系统采用云原生架构，无需调整现有架构，具有强大的兼容性。基于日志的设计对源业务无侵入，保障原有业务库的稳定运行。

02功能介绍

1. 产品功能架构图

在产品功能架构的设计上，专注于数据湖和数据仓的高效数据处理流程，包括数据的导入与导出操作。Delink、EMR、MRS 等平台能够得到良好的支持，系统对于数据湖或湖仓一体化平台有很好的兼容性。

• 基础服务层面
• 提供了数据源管理、资源组件管理等核心功能。
• 数据传输层面
• 数据传输过程中，任务类型被细分为离线、实时和流批一体三种模式。数据采集模式涵盖一对一、多对一和一对多三种类型。组件配置方面，将其划分为读取组件、转换组件和写入组件，数据映射时提供字段批量处理、整库处理和大批量处理等映射规则。数据安全管理方面，实施了严格的分类分级、加解密措施，并对任务管理进行了优化，包括前置检测、导入导出、断点续传和 DDL 变更等功能。
• 监控告警层面
• 系统支持故障转移，如通过检查频率来实现超时任务的故障迁移。任务执行过程中，监控大屏能够实时显示任务状态、数据同步量和资源消耗情况。为确保数据质量，系统支持与源端进行数据质量校验，并结合告警规则对超时任务和状态进行监控。此外，系统支持多种消息提醒方式，如短信、钉钉电话、Webhook 等，从而快速为下游应用提供必要的数据支撑。

2. 产品核心功能

• 资源管理
• 支持界面配置多种计算、调度、存储资源类型。
• 数据源管理
• 支持界面配置多种类型数据源，测试连通性。
• 组件管理
• 将 ETL 能力抽象为"组件"，支持界面管理读取、转换、写入组件。
• 任务配置
• 支持按项目空间 & 目录进行任务管理。
• 离线数据采集：支持根据源表生成目标表建表 SQL 等，快速创建目标表，支持按时间周期自动调度全量/增量数据采集。
• 实时数据采集：支持通过订阅数据源 Binlog 等方式，无侵入实现实时增量数据采集。
• 批流一体数据入湖：支持通过一个任务实现批流一体数据入 lceberg 等数据湖。
• 运维监控
• 实例日志：支持根据日志层级，分类查看日志信息，快速定位问题。
• 监控告警：支持钉钉、邮箱、短信、电话等多种告警方式。
• 数据质量：支持界面查看抽取总数、写入总数、运行时长等指标进行数据质量管理。

3. 多引擎调度

• DCT On Local
• 这种调度方法基于我们自主研发的 PSC 调度引擎，利用本地资源进行资源调度，其资源消耗极低。
• DCT On Yarn
• 这种调度方法通过队列机制实现资源隔离，保证了调度的效率和安全性。
• Spark On Yarn
• 这种调度方法采用 Spark 引擎。在这种情况下，任务实际上运行在 Yarn 集群中，确保了高效和稳定的运行环境。
• Delink
• 这种调度方式是基于我们自研的实时湖仓 Delink。这种方式的任务运行在 Yarn 或 K8S 中，通常适用于批流一体的数据湖场景。高效的特征配置能力，可以应对大量的特征需求。

4. 扩展性-自定义组件

DCT 统一了数据格式标准和组件开发规范，支持根据需求进行自定义组件开发，导入到管理界面后即可使用。

5. 构建任务-组件化配置、零代码开发

任务构建的过程也非常简便，采用了模块化的配置方法。用户只需通过直观的拖拽操作，将读取组件、转换组件和写入组件按需串联起来，即可完成任务配置。这种设计大大简化了任务构建流程，提高了操作的便捷性和效率。

6. 离线同步(全量&增量)

全量同步：指源表中所有数据都传输。

增量同步：全量同步过程中或同步完成之后，源库产生的增量数据，支持通过自定义 SQL 引用变量获取。

7. 实时同步

采用基于日志的增量数据秒级获取技术（CDC），为数据仓库、大数据平台提供实时、准确的数据变化，从而使得客户可以根据最新的数据进行运营管理与决策制定。

• MySQL，通过 Binlog 方式获取准确的数据，支持 5.x 及以上多版本，支持只读库权限的同步；支持断点续传。
• PostgreSQL，支持逻辑流复制，通过 wal2json 解析日志获取准确的数据；支持断点续传。
• Oracle，支持 LogMiner 读取数据库日志获取准确的数据；支持断点续传。

8. 批流一体

使用同一套开发范式来实现大数据的流计算和批计算，进而保证处理过程与结果的一致性。降低批流采集任务配置复杂度，一次配置，程序自动进行批和流的数据采集，便于任务管理；批流自动切换，可降低资源消耗。

9. 丰富的监控运维

系统提供了全面的监控功能，包括对每个实例的输入和输出数据量进行实时监控。这不仅限于单个实例，还涵盖了平台级和项目级的任务。监控内容包括数据同步趋势、资源消耗等关键指标，所有这些监控数据都通过一个可视化界面展现。这种可视化监控系统使监控过程更加直观和全面，支持实例级的输入、输出条数记录，平台级和项目级任务状态监控、数据同步趋势监控以及资源消耗监控。

通过这种直观的方式呈现监控数据，监控人员能够更清晰地理解和分析监控场景，及时发现和响应任何异常情况，从而保证系统的高效和稳定运行。

10. 智能调度

新一代分布式任务调度平台，提供定时、任务编排、分布式跑批等功能，具有高可靠、海量任务、秒级调度及可运维等能力。

• 工作流调度方面，平台支持可视化工作流进行任务编排，以及支持 Cron 表达式和 API。
• 资源调度方面，平台能够监控和分配 CPU、内存和 IO 资源，同时设置任务的优先级，以智能方式分配任务资源。
• 分布式跑批方面，主要应用于离线场景，通过数据分片和将任务分配到不同的工作节点运行，以提高数据任务传输的效率。
• 任务监控方面，包括监控任务状态、执行结果，并支持任务的重跑设置。通过这些功能，平台确保了任务的高效、稳定执行，同时提升了数据处理的效率和可靠性。

11. 断点续传

基于 WAL 架构，通过定期保存 CKP 的设计，即使出现断网情况，当网络恢复，也可基于断网的定期保存检查点实现断点续传，保证数据传输的稳定性。

当出现故障，数据传输中断，可基于 CKP 快速恢复传输任务的数据，高效解决数据质量问题。当然这有一个前提就是需要数据源支持断点续传机制。

03技术架构演进

1. DCT 1.0 技术架构

DCT 1.0 的核心功能包括：

• 支持离线和实时数据同步；
• 读写组件插件化；
• 命令行的方式，单进程运行；
• 支持 MySQL、 Oracle、 SQLServer、Kafka、Hive 等数据源。

2. DCT 2.0 技术架构

DCT 2.0 架构在 1.0 的基础之上，进行了如下提升：

• 任务创建和配置支持界面化操作，以拖拉拽的方式进行任务开发；
• 支持数据源管理、读写组件和转换组件的上传与下载；
• 支持多任务并行运行。

3. DCT 3.0 技术架构

DCT 3.0 架构介绍

• Manger 管理端
• 控制创建任务以及启动停止；
• 可实时监控 MasterNode 是否在线。
• MasterNode 主节点
• 负责 WorkNode 注册上线，监控，状态维护；对提交的任务进行节点分配，任务下发，状态监控。
• WorkNode 工作节点
• 负责 MasterNode 上报所在服务器节点的资源相关信息，接收来自 MasterNode 下发的任务；
• 负责 PSC 启动，监控上报，结束、异常处理等整个完整生命周期。
• PSC 可编程调度容器
• 执行数据同步任务的最小管理单元，包含读取、转换、写入组件，共同组成一个同步任务；
• 由 WorkNode 负责管理整个任务的生命周期。
• DCT 3.0 架构先进性
• 支持分布式部署，Manager 节点和 WorkNode 节点实现了无状态化，能够独立的横向扩展，支持高可用和弹性扩缩容；
• 实时查看 CPU、内存、I/O 等资源使用情况；
• 设定任务优先级，智能分配资源；
• 优化 PSC，使得能快速地支持自定义组件扩展。

4. DCT 4.0 技术架构

DCT 4.0 架构更进一步：

• 优化掉了调度单点瓶颈的 MasterNode 节点，降低系统复杂度，提升了系统的可靠性；
• 自主研发基于 Manager 结合 PSC 作为资源调度引擎，实现任务分片调度；
• WorkNode 节点与 PSC 任务支持故障转移，使得系统具有更优的稳定性；
• DCT 支持多种资源调度模式，能和大数据集群共享调度资源，降低硬件成本。
• DCT-on-Local 模式：Local 模式支持以工作节点作为任务运行的资源，不需要依赖外部资源；
• DCT-on-Yarn 模式：支持在 Yarn 集群运行；
• DCT-on-Spark 模式：使用 Spark 引擎，以 Yarn 作为资源调度运行任务；
• DCT-on-DLink 模式：使用 DLink 湖仓引擎，以 Yarn 或 K8S 作为资源调度运行任务。

04应用场景

接下来将通过整库入湖场景，来介绍 DCT 的应用。

将业务库 MySQL 中的数据入湖，快速构建湖仓一体。仅需简单的四步，即可完成从基础配置到实例运维的全流程闭环。

1. 配置数据源

• 配置数据源
• 这一步骤相对简单，主要通过直观的拖拽操作来完成。用户需要填写相关的数据源连接信息，如数据库地址、端口、用户名和密码等。
• 连接验证和预检测
• 配置完数据源后，下一步是验证连接信息。包括检查提供的连接信息是否正确，以及验证相应的权限。系统会进行一系列预检测，确保数据源连接的有效性和安全性。

2. 配置资源

• 选择 DLink 资源作为采集的资源调度引擎。
• 湖内 Catalog 信息获取，作为目标端。
• 运维文件上传（CDC jar 上传）。

3. 新建入湖任务

• 选择读取组件，MySQL 作为采集源端，写入组件 Iceberg_DLink 作为目标端。
• 配置任务基础信息，例如：Flink 重启策略配置、Checkpoint、并行度、日志存储等。
• 分别配置批资源、流资源，实例运行自动切换。
• 可根据源表结构，自动生成目标表结构，支持预览、编辑、批量创建。
• 前置检测通过后，启动任务。

4. 实例运维

• 支持查看实例状态、同步数量、异常记录等。
• 通过查看实例配置，二次检验是否符合同步配置。

05成功案例

1. 某能源企业：集成滴普实时湖仓，油田数据服务时效性大幅提升

• 客户背景
• 某能源公司是以油气业务、工程技术服务、石油工程建设、石油装备制造等为主营业务的综合性国际能源公司，是中国主要的油气生产商和供应商之一。勘探开发平台是国内油气行业首个智能云平台，其依托数据湖和 PaaS 技术实现勘探开发生产管理、协同研究、经营管理及决策的一体化运营，支撑勘探开发业务的数字化、自动化、可视化、智能化转型发展。
• 客户需求------由离线数仓升级为新一代实时湖仓
• 提升油田勘探开发数据的服务时效性，原有数据需要 T+1 才能从数据源端到达数据服务端。
• 全量油田数据入湖，油田边缘计算设备的时序数据需要实时上传入湖，原有离线数仓不支持数据快速去重能力，导致时序入湖性能达不到要求。
• 滴普服务
• 统一数据集成工具：滴普 DCT 提供统一的多源异构数据库实时同步+离线同步工具，支持结构化数据、半结构化数据实时汇聚。
• 实时湖仓架构升级：滴普 DLink 实时湖仓引擎集成到勘探开发云平台，提供数据实时计算、联邦查询等高级特性。
• 解决方案
• 数据源分类：项目涵盖了 11 大类油田数据源，这些数据源多样化，涉及油气行业的多个关键领域。
• 数据同步和调度：所有这些数据源通过 DCT 进行统一调度和集成。DCT 在这里起到了核心的数据同步和集成工具的作用，确保了不同数据源之间的有效对接。
• 数据同步至开发云平台：通过 DCT 工具，数据被同步到一个专门的开发云平台。这个平台作为数据处理和分析的核心，支持大规模数据集的处理和分析。
• 数据量和应用场景：这个项目处理了大约 5PB 的数据量，这一规模体现了其处理大数据的强大能力。最终，这些数据用于支持 8 大油气数据应用场景，提供实时的数据服务。

（1）勘探开发云平台：勘探开发云平台新架构

• 数据集成：从各种业务系统中提取数据，通过 DCT 实现数据的统一集成。
• 数据入湖：采用批流一体的方式，具体是通过 Flink CDC 机制将数据同步到 Kafka 集群，然后再利用 Flink 将数据实时写入数据湖。同时，也支持使用联邦查询技术进行批处理数据的入湖。
• 实时计算与离线分析：数据入湖后，在数据湖内部进行实时计算及离线分析，实现数据的深度处理。
• 数据同步与调度：处理完成的数据通过调度策略，使用 Trinor 进行离线同步到 ClickHouse（CK）。
• 数据服务 API：最终，通过 API 将同步到 ClickHouse 的数据提供给下游应用，供进一步的业务应用和数据分析使用。

（2）成果：异构多模数据通过统一数据采集架构入湖，优化运维成本

新架构相较于原架构，实现了数据同步流程的简化和统一，并通过实时数据湖的引入，提升了数据处理的实时性和全面性，为更快速、更有效的数据分析提供了支持。

• 原架构特点：在原有的数据架构中，实时数据同步和离线数据同步是分开的，使用不同的工具链进行处理。
• 新架构优化：新架构通过 DCT 实现了数据采集的统一，将实时和离线数据同步集成在同一条数据链路中，优化了入湖过程。
• 数据湖转变：在原架构中，数据湖主要面向离线数据存储，而新架构升级为实时数据湖，提供了更高的时效性和全链路数据处理的能力。
• 时效性提升：新架构显著提高了数据处理的时效性，使得实时数据分析成为可能，同时还支持在实时数据湖中进行全链路的数据处理。

（3）成果：数据入湖、湖仓内模型处理速度大幅提升，时效升级为 T+0

• 原架构处理方式：原架构依赖于离线跑批处理数据，并将数据同步到数据集市（data mart）层，同样采用离线跑批的方法。
• 新架构的优化：新架构采用了流批一体的处理链路，从数据入湖到最终写入数据集市，整个应用层都采用了流处理和批处理的结合方式。
• 时效性提升：新架构将数据处理的时效性从原来的 T+1（次日处理）提升到了 T+0（实时处理），显著提高了数据处理的即时性。
• 资源消耗优化：新架构能够在资源消耗上实现显著节省，提高了整体的数据处理效率。
• 性能提升：在数据同步性能上，从原来的每秒同步 1100 条数据提升到实时入湖监测到的每秒 25000 条数据，性能提高了超过 20 倍。

2. 某零售企业：构建围绕"货""店"数据智能运营体系

• 技术应用：该零售企业采用了 FastData 平台，辅以数据集成工具，以优化其货店数据智能运营体系。
• 成本下降：通过这些技术的应用，企业的硬件成本降低了 25%。
• 数据量和性能提升：在数据链方面，企业管理着大约 2.5 到 3PB 的数据规模，每天数据新增量约为 500GB。数据查询性能提高了 30%。
• 架构升级：企业的数据处理架构从原来的批处理架构升级到了实时处理架构，时效性也随之提升到了 T+0 级别，即数据可以实时处理和分析。

（1）某零售企业：基于 FastData 湖仓一体架构优化成本，性能和效率

• 数据源集成：我们将内部及外部的多样化数据源通过 DCT 进行集成，整合到 FastData 平台。
• 数据处理与分析：在数据集成之后，在 FastData 的基础设施上进行了必要的数据处理和分析。
• 指标与模型：处理和分析的过程中涉及到指标标签的构建和应用模型分析。
• 业务闭环形成：通过这些步骤，实现了针对特定业务场景的闭环，从而支撑了数据驱动的决策过程。

（2）某零售企业：数据中台联合共创，全面提升业务效率

• 问题
• 客户拥有多个业务系统，并使用多种数据库类型；底层需接入多个组件实现数据离线、实时同步，技术复杂度高，稳定性差，采购多套商业软件，费用高，资源消耗大。
• 价值
• 统一数据入湖工具可以降低数据集成过程的复杂度，减少维护成本，资源使用大幅减少。该工具采用集群架构，高可用，支持故障转移，能进一步提升容错性和可靠性。同时数据入湖速度、湖仓内模型处理速度大幅提升，数据服务时效从 T+1 升级为 T+0。
• 运行情况：
• DCT 任务 2000+，并发任务 500+，平日数据量约为 1亿+；峰值 3 万条/秒；
• DCT 生产环境运行 2 年，运行稳定，无数据丢失；
• DCT 扛住 618、双 11、双 12 的压力（数据量为平日 3-5 倍）， 无崩溃，无数据丢失，数据延迟 <2 秒；
• DCT 实时同步速率约 80MB/s，日最高承受数据量达 20TB。

06Q&A

Q1：DCT 数据集成是如何保证数据一致性的？

A1：实时任务同步的一致性保证：对于实时数据同步任务，我们采用了 checkpoint 机制。这一机制能够在任务因异常中断时创建保存点，以便在网络或系统恢复后，能够从上一个已知的良好状态重新开始数据同步。这样做的好处是，即使在出现故障的情况下，也能确保数据不会丢失，并且可以根据业务时间或数据偏移量进行精确地重置和消费。此外，如果目标端存在主键，我们还可以利用数据的幂等性质来避免重复，确保数据的一致性。

离线任务同步的一致性保证：在离线数据同步方面，特别是在处理大数据量场景下，我们同样实施了故障转移策略，并记录了数据的偏移量。当任务发生异常时，可以从记录的偏移量处开始重新同步。这种机制保证了即使在离线状态下，数据同步也能够在故障后继续进行，而不会造成数据的不一致。

综上，无论是实时同步还是离线同步，DCT 都通过先进的机制确保了数据的一致性和完整性，以支持企业的数据集成和分析需求。

Q2：DCT-on-Yarn 跟 DCT-on-Spark 有什么区别？他们的应用场景是什么？

A2：DCT-on-Yarn 是一种基于 Yarn 进行资源调度的数据集成工具。它能够高效地利用企业现有的 Yarn 集群资源，避免了在工作节点上部署额外的机器资源。这种方式适合于企业已经拥有大数据集群，并希望在现有集群中实现批处理和流处理相结合，或是实现数据湖与数据仓库一体化的任务调度。简而言之，DCT-on-Yarn 可以直接借用企业现有的资源来执行数据集成任务。

相比之下，DCT-on-Spark 专注于数据湖的入湖场景，特别是在使用企业自有的湖仓引擎时。DCT-on-Spark 采用了 SeaTunnel 引擎，旨在提升从源端到实时湖仓引擎 Dlink 的数据处理效率。虽然 Spark 引擎也运行在 Yarn 集群中，与 DCT-on-Yarn 在技术基础上有所相似，但 DCT-on-Spark 通过特定的数据处理引擎优化了入湖过程的性能。

总结来说，DCT-on-Yarn 更适合那些希望在现有大数据集群内优化资源利用的企业，而 DCT-on-Spark 则更适用于需要高效数据入湖处理的场景。两者虽然在技术实现上有所交叉，但都旨在提高企业数据处理的效率和效能。

Q3：数据大量入仓入湖后能用到业务端的数据占比有多少？另外怎么解决数据浪费的问题？

A3：业务应用占比：这个问题高度依赖于业务需求。一种常见的方法是自上而下的数据入湖，即先将企业内所有系统的数据库数据统一入湖，然后进行数据建模和治理。但这种方法可能导致一部分数据并不符合实际业务需求。因此，更推荐的做法是结合企业具体业务进行自下而上的数据分析，明确哪些数据需要入湖并加以加工，最终形成有用的主题域。这样做可以更好地对接业务需求，提升数据在业务端的应用率。

解决数据浪费问题：数据浪费主要集中在存储空间占用和计算资源上。对于存储来说，我们可以采用冷热数据分离的策略：对冷数据进行压缩和归档，以减少存储空间占用；而热数据则重点保存和加速处理，以便快速分析。在计算引擎方面，采用存算分离的架构既能提升性能，又能保证在不同场景下选择最合适的引擎，避免不必要的资源堆积和浪费。通过这种方式，可以灵活地调整或下架不再使用的计算引擎，进一步优化资源利用。

以上就是本次分享的内容，谢谢大家。