数据集成产品的技术演进与实际应用-FastData DCT

导读 在数字化转型的大潮中，企业面临的数据环境日益复杂多变。滴普科技的 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。

06

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

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

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

分享嘉宾

INTRODUCTION

刘波

滴普科技

FastData产品线DataFacts产品负责人

刘波，滴普科技 FastData 产品线 DataFacts 产品负责人，从事大数据开发 10 年 +，在滴普科技负责 30+ 个数据项目的架构设计与落地，先后主导了 TOP 级新零售企业的数据智能平台与互联网医疗企业的数据湖建设，目前负责一站式数据智能开发与治理平台的研发工作，聚焦湖仓一体和流批一体的架构设计及实践。

往期推荐

OLAP 的技术研发与思考–ClickHouse 2023 总结和 2024 展望

滴滴大数据成本治理实践

阿里云湖仓存储系统设计剖析和性能优化

重新定义流计算：第三代流处理系统 RisingWave 的 2024 年展望

当图模型算法搭上推荐系统，百度是这样应用的

百度推荐排序技术的思考与实践

蚂蚁营销推荐场景上的因果纠偏方法

数据产品经理应对B端用户增长方法论

腾讯欧拉平台产品经理：如何做一款好的数据平台？

使用 OpenLLM 构建和部署大模型应用

肖仰华：走向千行百业的大模型

阿里云MaxCompute半结构化数据思考与创新

Shuffle Size 降低40%，阿里云Spark+Celeborn新一代大数据服务

OPPO 广告召回算法实践与探索

点个在看你最好看