时间序列数据库的数据集成策略

译文
大数据
时序数据带来了额外的复杂性。从本质上讲,每个时序数据点的值会随着时间的推移而减少,因为数据的粒度会随着数据过时而失去相关性。因此,团队必须仔细规划数据集成到时间序列数据库 (TSDB) 中的策略,以确保分析近乎实时地反映趋势和情况。

随着数字化转型进入更多行业,产生的数据量呈指数级增长。因此,以不同的格式和结构,从不同来源收集如此大量数据的数据集成策略,是当今数据工程团队的主要关注点。传统的数据集成方法主要侧重于将高度结构化的数据整理到数据仓库中,难以处理新数据集的数量和异构性。

另一方面,时序数据带来了额外的复杂性。从本质上讲,每个时序数据点的值会随着时间的推移而减少,因为数据的粒度会随着数据过时而失去相关性。因此,团队必须仔细规划数据集成到时间序列数据库 (TSDB) 中的策略,以确保分析近乎实时地反映趋势和情况。

在本文中,我们将研究一些最流行的 TSDB 数据集成方法:

  • ETL​(提取、转换、加载)
  • ELT​(提取、加载、转换)
  • 使用 CDC 实现数据流

鉴于对时间序列数据的实时洞察需求,大多数现代事件驱动架构都使用 CDC 实现数据流。为了说明它在实践中是如何工作的,我们将通过QuestDB(快速TSDB)的参考实现来展示CDC如何灵活地处理时间序列数据源的需求。

提取、转换、加载 (ETL)

ETL 是一种传统且流行的数据集成策略,它涉及将数据加载到目标系统(通常是数据仓库)之前首先将数据转换为预定结构。

ETL 的主要优点之一是它提供了最高程度的定制。由于数据首先被提取到暂存区域,在那里它被转换为干净的标准化格式,ETL 系统可以处理各种格式和结构。此外,将数据加载到数据仓库后,数据科学团队可以运行高效的查询和分析。最后,鉴于ETL生态系统的成熟,有大量的企业级工具可供选择。

另一方面,ETL 的维护需要大量资源和时间。清理和转换数据的逻辑可能很复杂,计算成本很高。这就是为什么大多数ETL系统通常是面向批处理的,只定期将数据加载到仓库中。随着数据量和数据来源的增长,这可能会成为瓶颈。

鉴于这些特性,ETL 系统最常用于在分析之前需要复杂转换逻辑的数据集。它也适用于不需要实时分析的数据集,并且可以存储以进行长期趋势分析。

提取、加载、转换 (ELT)

顾名思义,ELT 首先将数据加载到目标系统(通常是数据湖)中,然后在系统本身内执行转换。鉴于目标系统负责处理快速加载和转换,ELT 管道通常利用基于云的现代数据湖来处理要求。

与 ETL 管道相比,ELT 系统可以提供更实时的数据分析,因为原始数据是动态摄取和转换的。大多数基于云的数据湖都提供 SDK 或端点,以微批量高效摄取数据,并提供几乎无限的可扩展性。然而,ELT并非没有缺点。由于转换由目标系统完成,因此,此类操作受到数据湖支持的功能的限制。如果需要更复杂的转换逻辑,可能需要执行其他步骤来重新提取数据并以更友好的格式存储数据。

对于大多数用例,ELT 是比 ETL 更有效的数据集成策略。如果您的应用程序可以利用基于云的工具并且不需要复杂的处理,那么 ELT 可能是近乎实时地处理大量数据的绝佳选择。

变更数据捕获 (CDC)

对于新项目,团队可以计划将 TSDB 用作 ETL 或 ELT 管道中的目标系统之一。但是,对于现有项目,迁移到 TSDB 或将 TSDB 添加到组合中可能是一个挑战。首先,可能需要修改或使用新的驱动程序/SDK 将数据流式传输到 TSDB。即使支持相同的驱动程序,数据格式也可能需要更改以充分利用 TSDB 功能。CDC工具可用于弥补这一差距。

CDC 原则上很简单:Debezium 等 CDC 工具会持续监控源系统中的更改,并在发生更改时通知数据管道。导致更改的应用程序通常甚至不知道有一个 CDC 进程在监听更改。这使得 CDC 非常适合将新的实时数据管道集成到现有架构中,因为它需要对现有应用程序进行少量更改或无需更改。因此,CDC 可以与 ETL 或 ELT 管道结合使用。例如,源系统可以是SQL RDBMS(例如MySQL,PostgreSQL等)或NoSQL DB(例如MongoDB,Casandra),其中一个目标系统可以是TSDB以及其他数据湖或仓库。

使用 CDC 进行数据集成的主要优点是它提供实时数据复制。与使用批处理的传统 ETL 和 ELT 系统不同,对源系统的更改会连续流式传输到一个或多个目标系统中。这对于近乎实时地跨多个数据库复制子集或整个数据非常有用。目标数据库甚至可能位于不同的地理区域或用于不同的目的(即长期存储与实时分析)。对于值随时间的变化通常最有用的时序数据,CDC 可以有效地捕获该增量以获得实时见解。

CDC 的参考实施

Java Spring 应用程序将股票价格信息发布到 PostgreSQL 中。然后,Debezium Connector 从 PostgreSQL 读取更改,并将其发布到 Kafka 上。另一方面,QuestDB的Kafka连接器从Kafka主题中读取并将它们流式传输到QuestDB。

在这个参考架构中,Java Spring 应用程序正在将数据转换并加载到 PostgreSQL 上,然后再复制到 TSDB 进行进一步分析。如果需要更像ELT的管道,来自另一个提供商的原始数据可以直接加载到PostgreSQL上,并在以后的QuestDB中转换。

使用此架构需要注意的重要一点是,CDC 可以与现有系统无缝集成。从应用程序的角度来看,它可以保留PostgreSQL的事务保证,同时在管道中添加一个新的TSDB组件。

结论

对于使用 TSDB 存储和分析时序数据的组织来说,数据集成起着重要作用。在本文中,我们探讨了使用 ETL 或 ELT 的一些优点和缺点。我们还研究了如何将 CDC 与这些管道结合使用,以提供到 TSDB 的实时复制。

鉴于时间序列数据的特殊性,使用 TSDB 正确存储和分析它们非常重要。如果是要从头开始构建,请考虑构建 ELT 管道以将数据流式传输到 TSDB。要与现有系统集成,请考虑利用 CDC 工具来限制对当前架构的中断。

 

责任编辑:赵立京
相关推荐

2018-12-17 12:12:43

Netflix数据库存储

2021-01-06 08:14:21

时间序列数据库数据库

2022-11-14 07:52:14

时间序列数据库CPU

2023-05-22 11:20:27

数据库MySQL关系数据

2022-03-22 09:00:00

数据库SingleStor技术

2023-07-24 09:00:00

数据库

2018-07-30 10:34:14

时间序列数据库

2024-07-16 08:22:09

2012-12-10 10:57:04

IBMdW

2017-03-14 14:09:08

数据库Oracle备份

2019-06-12 08:23:21

数据库时间序列开源

2010-11-29 10:11:05

Sybase数据库死锁

2010-11-15 16:13:24

Oracle数据库性能

2010-05-06 12:44:47

Oracle数据库

2013-03-12 09:51:02

2011-04-18 11:27:49

空间时间数据库设计

2011-08-03 13:11:10

Oracle数据库序列

2023-09-01 15:34:34

数据库开发

2009-04-17 11:28:16

Oracle备份恢复

2011-05-26 13:36:40

Oracle数据库时间处理
点赞
收藏

51CTO技术栈公众号