作者:柳下
随着企业规模和数据量的增长,数据的价值越来越受到重视。数据的变化和更新变得更加频繁和复杂,因此及时捕获和处理这些变化变得至关重要。为了满足这一需求,数据库 CDC(Change Data Capture)技术应运而生。然而,从 ETL 架构的角度来看,CDC 仅满足了数据的提取(Extract)能力。
为了实现完整的 ETL 架构,并完成高效、实时的数据集成、处理和同步,阿里云 Serverless 函数计算(FC)与数据库 CDC 技术深度融合。助力企业构建完整的 ETL 架构,实现数据的提取、转换和加载。通过将 CDC 作为事件驱动的数据源,将数据变化作为事件触发 Serverless 函数的执行,可以实现实时的数据处理和同步,有助于提升业务决策和分析的准确性和效率。
下面将从 ETL 模型入手,逐步讲述 FC + CDC 如何适配符合 ETL 模型的业务。
在大数据领域,承载数据流转、加工业务的系统架构都可抽象为 ETL 模型,它由三个主要步骤组成:提取(Extract)、转换(Transform)和加载(Load)。
此架构应用广泛,帮助企业管理和利用数据,实现数据驱动的决策和业务转型。
CDC 和 Extract(E) 是数据处理的两个概念,前者目的是捕获数据库中的变化数据,后者目的是从数据源中提取特定的数据集合。但回归业务本身,两者均是从数据源获取业务所需的数据,因此 CDC 和 ETL 的结合也是必然结果。两者的结合可构建更完整高效的数据处理流程,实现实时增量数据抽取和处理。相比传统的定期批量抽取方式,CDC 可更及时地捕获数据变化,使目标系统中的数据更加实时和准确。
在阿里云数据库产品体系中,数据传输服务 DTS(Data Transmission Service)扮演了 CDC 的角色,作为实时数据流传输服务,它能够捕获上游数据库的变更信息,并将这些变更推送给下游服务。当下游服务是函数计算时,可以利用函数计算的自定义代码能力,对数据进行自定义加工(T)和投递(L)。如下图所示,FC 和 DTS 的深度集成构建了完整的 ETL 体系,为业务系统的快速搭建提供了帮助。
针对上文提到的 DTS + FC 架构,下面将剖析内部细节,深入理解系统的运行方式。
DTS 在数据采集和数据传输上提供了完备的能力,DTS 系统可抽象为如下三大模块:
FC 和 DTS 的深度集成保证了 FC 可以接收 DTS 采集的数据库数据,并根据用户自定义代码实现数据加工和数据投递功能,具体如下:
从上图可以看到,您仅需关注数据加工和投递的业务逻辑,并通过简单代码片段完成实现,FC 后端会自动伸缩计算节点执行代码,您无需关注系统的基础设施建设、资源运维、伸缩、监控、报警等一系列繁琐工作,极大提升开发效率。同时 FC 作为 Serverless 应用,支持按量付费,避免长期预留机器资源带来的资源低效问题。
什么是 OLTP 和 OLAP?
从上面描述看,OLTP 和 OLAP 是两种不同的数据处理服务,用于满足不同的业务需求。OLTP 系统适用于处理实时的交易和业务操作,而 OLAP 系统适用于从大量数据中进行分析和决策支持。在实际应用中,OLAP 的数据来源就是不同的 OLTP 数据库,所以 OLAP 本身不产生数据,通过 ETL 从 OLTP 抽取数据到 OLAP 数据库即数据仓库中做整合清洗达到可分析的数据标准。而 DTS + FC 恰好可以连接两类服务,打通数据通路。
什么是事件和事件驱动?
CDC 因用于捕获数据库中的数据变化,常被当做事件驱动后续流程的执行,常见的场景如下:
CDC 和 Serverless 函数计算的结合,可以实现实时的数据处理和响应,同时减少对基础设施的依赖和管理。 在实际应用中,可将 CDC 作为事件驱动的数据源,将数据变化作为事件触发 Serverless 函数的执行。这样可以实现实时的数据处理和分发,同时利用 Serverless 函数计算的弹性扩展能力,根据实际负载动态分配计算资源。总而言之,DTS 和 Serverless 函数计算的集成为企业提供了更高效、灵活和可靠的数据处理解决方案。未来函数计算将探索更多的数据源(Oracle、PolarDB PostgreSQL、PolarDB MySQL 等),满足更多的业务需求。更多信息或需求请钉钉与我们联系,官方钉钉群号:11721331。