您当前位置:资讯中心 >大数据 >浏览文章

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

来源:互联网 日期:2024/1/15 7:17:11 阅读量:(0)

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

一、产品概述

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 内存即可运行,降低了成本。同时,支持并行度设置,有效提高了数据传输效率。
  • 云原生架构设计
    系统采用云原生架构,无需调整现有架构,具有强大的兼容性。基于日志的设计对源业务无侵入,保障原有业务库的稳定运行。

二、功能介绍

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 快速恢复传输任务的数据,高效解决数据质量问题。当然这有一个前提就是需要数据源支持断点续传机制。

三、技术架构演进

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 作为资源调度运行任务。

四、应用场景

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

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

图片

1、配置数据源

图片

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

2、配置资源

图片

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

3、新建入湖任务

图片

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

4、实例运维

图片

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

五、成功案例

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。

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

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

关键字:
声明:我公司网站部分信息和资讯来自于网络,若涉及版权相关问题请致电(63937922)或在线提交留言告知,我们会第一时间屏蔽删除。
有价值
0% (0)
无价值
0% (10)

分享转发:

发表评论请先登录后发表评论。愿您的每句评论,都能给大家的生活添色彩,带来共鸣,带来思索,带来快乐。