【.com快译】数据是数据平台最重要的资源，企业需要设计和规划如何将数据摄取到新的数据平台。本文将讨论变更数据捕获（CDC）解决方案，如何基于Debezium等开源工具设计标准的复制解决方案，以及为什么CDC可以帮助企业迁移到新的数据平台。WhatisChangeDataCapture(CDC)ChangeDataCapture(CDC)是一个软件过程，它捕获在源数据库中所做的更改（DDL和DML）以同步另一个数据存储，例如数据库、内存缓存、数据仓库或数据湖.CDC用于本文未讨论的其他补充用例，例如：CQRS模式：其中一种实现涉及具有单独的写入（命令）和读取（查询）数据库和数据模型。写层支持插入、更新、删除操作，读层支持查询数据操作。CDC允许将命令操作从写入数据库复制到读取数据库。分析微服务：提供变更事件流以跟踪发生变更的时间和内容，并分析行为模式。CDC解决方案由三个主要组件组成：源连接器：它从数据库中捕获更改并生成包含这些更改详细信息的事件。通道：它是数据存储库，源连接器将这些事件和更改放在一起。SinkConnector：从通道读取事件并处理特定于应用程序的逻辑，以将数据集成到目标系统或用于其他目的（例如分析警报过程）。CDC的实现方式有很多种，比如基于日志的、基于触发器的或者基于SQL脚本的。本文将重点介绍基于日志的方法，因为它是一种更高效的方法，下面将介绍这种方法的优点。源连接器发布的事件包含同步远程数据存储库所需的所有信息。它由以下部分组成：元数据：提供表名、操作类型（插入、删除等）、事务标识符、源连接器进行或捕获更改时的时间戳等信息。前值：变化前的数据值。后值：改变后的数据值。JSON{"table":"stock""operation":"update","ts_ms":"1627817475","transaction_id":2,"before":{"id":"0001","item":"T-Shirt","quantity":"10"},"after":{"id":"0001","item":"T-Shirt","quantity":"5"}}并非所有连接器都有相同的行为。有些连接器（例如官方MongoDB连接器）不提供“先前值”。在数据复制的情况下，这些事件由接收器连接器使用并合并到目标数据库中。企业必须按照事件的生成顺序使用事件，以确保流程弹性。如果事件未排序，则无法保证复制过程的弹性。以下是一些可能发生的场景的示例：在基于事件驱动模式的复制以外的场景中，当您想要对特定事件做出反应时，使用事件的顺序并不重要。基于日志的CDC优势与其他CDC方法或ETL复制过程相比，基于日志的CDC具有以下一些优势：性能：通过读取文件从事务日志文件中检索所有更改。与ETL等其他方法相比，此操作对数据库性能的影响更小。ETL方式基于SQL查询，需要不断优化（索引、分区等），因此会消耗大量的计算资源。解耦提取：它提供了一个解耦提取计算层，与其余工作负载隔离。此解决方案仅允许在CDC解决方案上进行垂直和水平缩放。触发CDC方式使用的是数据库计算层，这个复制过程可能会影响数据库的性能。近乎实时：低计算影响可实现近乎实时的事件更改，而不会给源数据库带来风险。检测有序文件中的更改比在表上执行查询轮询过程更容易和更快。捕获所有更改：事务日志以准确的顺序提供所有数据更改，包括删除操作。ETL过程忽略ETL执行之间发生的中间数据更改。其他方法（ETL，基于CDC触发器，CDCSQL）可用于识别需要创建表来注册此操作的删除操作，以及确保数据弹性的特定逻辑。无数据模型和应用程序影响：这不需要更改数据模型或源应用程序。ETL和其他CDC解决方案需要创建触发器和表或向表添加时间戳。需要考虑的一些重要细节：无日志事务操作：所有操作都不会在事务日志中注册。目录级操作常用于数据仓库，例如在目标表和暂存表之间移动分区。这种类型的操作取决于每个数据库版本以及团队的工作方式。商业工具：每个数据库供应商都提供特定于CDC的工具，通常带有附加许可证。在复杂的多供应商环境中，企业使用不同的CDC工具复制数据会增加运营成本。开源工具：它们是一个不错的选择。更新数据库供应商发布的新功能通常需要更多时间。有时对故障排除或错误解决的支持更为复杂。反模式：在某些情况下，必须将特定源数据库复制到多个目标数据库。有时团队会配置多个CDC复制，所有这些都从同一个事务日志中读取。这是一个危险的反模式。影响小不代表没有影响，CDC会增加I/O操作，所以从同一个文件读取多个CDC会增加大量的I/O操作，造成I/O性能问题。相反，使用中心辐射型模式是一种更好的方法。中心辐射型CDC模型（DataHub）中心辐射型架构是最常见的数据集成架构模式之一。这种架构允许一次从数据库中捕获更改并多次交付它们。这种模式与ApacheKafka和其他流媒体平台使用的发布和订阅模式非常相似，具有一些好处，例如：(1)可重用性：更改事件从使用的源中读取一次。(2)减少集成次数：与源数据库只有一次集成。(3)标准接口：为所有消费者提供相同的接口。在这种情况下，接收器连接器会复制共享同一接口的目标数据库中的数据。根据通道的特点，允许提供DataHub的一些功能。数据保留是DataHub的一项基本功能。如果无法存储所有历史数据甚至每个文档或行的最后状态，用户将不得不使用其他工具和流程来补充解决方案。常见CDC场景CDC是一个很好的解决方案，有四种常见场景：OLAP数据库迁移：在企业将其全部或部分工作负载从当前数据仓库迁移到新的OLAP解决方案的情况下，CDC允许将相同数据复制到另一个系统并使迁移更容易。如今，许多企业正在将工作负载从本地数据库迁移到数据云解决方案。CopyinformationfromOLTPdatabasetoOLAPdatabase：将数据从操作数据库复制到数据仓库或数据湖。数据库即服务：沙盒或提供数据库副本以供分析。从单体应用程序迁移到微服务：应用程序杀手模式逐渐将单体应用程序迁移到微服务。在第一阶段，复制两个应用程序共存所需的一些数据集。企业CDC解决方案下图描述了CDC流程的行为方式以及构成它的组件。基于此，提出了以下解决方案架构：Debezium作为源连接器：这部分将负责从源数据库引擎读取更改并将它们发送到通道。它将作为连接器部署在KafkaConnect集群中。Kafka作为通道：它提供中间存储以及用于事件生产/消费的广泛API，以及可以部署在KafkaConnect或其他平台上的大型连接器生态系统。KafkaSinkJDBC（由Confluent提供）和EventflatteringSMT（由Debezium提供）作为Sink连接器：该连接器允许用户使用一些配置参数在目标数据库上执行复制。作为通用解决方案，这是一个不错的选择。在其他情况下，例如Snowflake或其他云服务，JDBC连接器的成本效益和性能低于供应商自己提供的其他策略。评估切换到供应商自己提供的连接器而不是使用通用JDBC的成本效益很重要。KafkaConnectasConnectorPlatform：它提供了一个框架，可以基于简单的配置将连接器部署为插件，并与Kafka完全集成。这是一个很好的选择，因为它允许企业标准化接收器/源连接器管理，例如Debezium复制操作和JDBC接收器连接器。1.DebeziumDebezium是一个开源解决方案，它提供了非常有趣的功能来捕获数据库中的变化。Debezium架构提供了一些优势，例如：与特定的数据库供应商解决方案相比，事件规范化是使用Debezium等产品的重要优势之一。通常，每个供应商解决方案都有不同的事件规范，因为这些解决方案主要设计用于复制来自同一供应商的数据库。在多个数据库产品之间复制处理的场景中，具有多个事件规范会增加解决方案的操作、可维护和编码复杂性。Debezium提供了一个通用、清晰和简单的事件规范，有助于与其他第三方产品（如KafkaConnect接收器连接器）集成。这是一个示例事件（为便于阅读而调整）：JSON{"after":{"field_id":1,"field_1":"Value1"},"before":null,"op":"c","source":{"connector":"mysql","db":"inventory","name":"mysqldb","snapshot":"false","table":"product","ts_ms":1627489969029,"version":"1.6.1.Final",(...othersourcevendorfields...)},"transaction":null,"ts_ms":1627489969200}之后：包含表列及其值的文档。它的值可以为空，例如在删除操作中。before：包含表列及其值的文档。它的值可以为空，例如在创建（插入）操作中。op：要在数据库上运行的操作，例如更新、插入或删除。来源：事件的元数据。该文档具有公共信息，但它有多个字段，具体取决于源数据库（Oracle、SqlServer、MySQL或PostgreSQL）。tsource.ts_ms：表示数据库发生变化的时间。ts_ms：Debezium处理事件的时间戳，与source.ts_ms不同。通过比较这些值，可以确定源数据库更新和Debezium之间的延迟。Debezium与Kafka生态系统完全集成。源连接器使用KafkaAPI发布更改事件，但也可以部署为Kafka连接器。它可以使用RESTAPI部署在KafkaConnet集群中，以简化新CDC源连接器的部署和管理。JSON{"name":"debezium-postgres-inventory-connector","config":{"connector.class":"io.debezium.connector.postgresql.PostgresConnector","tasks.max":"1","database.hostname":"postgres","database.port":"5432","database.user":"postgres","database.password":"postgres","database.dbname":"postgres","database.server.name":"postgresdb","schema.include":"inventory","table.include.list":"inventory.product"}}在此示例中，部署了一个新的PostgreSQL数据库Debezium源连接器为库存架构中的产品表启用更改捕获。连接器读取更改并将事件推送到Kafka主题“postgres.inventory.product”。尽管每个Debezium数据库连接器都有特定的配置、属性和选项，但也有通用的连接属性。作为一个常见的选项，您可以首次配置数据库快照到Kafka或禁用它。这些通用的配置属性加入了Kafka连接器API，提供了一个标准的管理源连接器层，简化了解决方案的操作。需要考虑的事项：虽然有多种Debezium连接器，但并非所有连接器都提供相同的功能：MongoDBMySQLPostgreSQLOracle等在做出决定之前检查每个连接器很重要，因为在某些情况下，使用可能更好提供者连接器，例如：DebeziumMongoDB源连接器：目前无法发送文档的当前状态，只能以幂等格式进行操作。DebeziumSQLServerSourceConnector：它不是基于日志的连接器，而是基于触发器的连接器，需要安装触发器过程并创建阶段表。2.KafkaKafka是提供通道功能的一个很好的选择，因为它提供了几个重要的特性，例如：可扩展的事件流平台：高度可配置以提供高可用性、低延迟、高性能、多重交付和持久性保证。发布/订阅模式：它促进了一次发布和多次消费的机制，提供了一个良好的系统，每个用户都可以或按需要的速度工作。大型生态系统：如今被数千家公司使用。有许多用于数据管道、流分析和数据集成的开源和商业工具。无限存储和保留：提供具有无限存储和保留的集中式平台。Confluent最近的一些功能使用户能够拥有一个更具成本效益的存储层，将存储和计算资源分离。DebeziumCDC事件发布在Kafka主题中。一个Kafka事件由三部分组成：Key：用于确定消息将附加到的分区。具有相同事件键的事件被写入相同的分区。Kafka保证分区的事件将被任何消费者以与写入事件完全相同的顺序读取。值：它包含事件本身。标头：它是与Kafka记录关联的元数据，并提供有关键/值对的附加信息。作为键，Debezium包含表的键字段。这允许用户按照它们在数据库中发生的顺序处理更改事件。(1)主题策略活动发布有两种策略：每个表有一个主题。每个数据库一个主题或每个数据库和模式对一个主题。最佳策略取决于环境的特征，两种解决方案都有利有弊。“每表一个主题”策略的主要问题是所需的主题和分区数量。Kafka对每个集群都有分区限制，因此当您有许多包含数百或数千张表的数据库时，不建议使用此策略。(2)Representation在这个解决方案中有两个级别的并行性：基于目标数据库的数量。特定目标数据库的吞吐量。Kafka提供了一种发布/订阅模式，它允许用户部署多个接收器连接器来处理事件并将信息从主题并行复制到多个目标数据库。为了增加每个接收器连接器的吞吐量，需要结合两个组件：主题分区的数量。Kafka消费者组中的消费者数量。每个接收器连接器都与一组特定且唯一的消费者相关联。在Kafka连接器的情况下，消费者连续体就像一个线程或任务。资源组的成员划分分区，使分区仅供组的消费者使用，并且该消费者将按顺序读取键的事件。基于此，KafkaConnect可用于处理影响每个键的事件，将状态复制到另一个目标数据库，例如具有简单配置的数据仓库，例如：JSON{"name":"jdbc-sink","配置":{"connector.class":"io.confluent.connect.jdbc.JdbcSinkConnector","tasks.max":"1","topics":"postgres.inventory.product","connection.url":"jdbc:dwhdriver://connection","transforms":"unwrap","transforms.unwrap.type":"io.debezium.transforms.ExtractNewRecordState","transforms.unwrap.drop.tombstones":"false","auto.create":"true","insert.mode":"upsert","delete.enabled":"true","pk.fields":"id","pk.mode":"record_key"}连接器可以读取多个主题，并且可以在作为用户组工作的任务中扩展。使用此配置中定义的属性，可以执行源的副本，或者可能只是将事件附加为历史演变以执行某些分析过程。(3)DataRetentionKafka的数据保留是在topic级别进行管理的，有不同的策略：TimeRetention：当超过时间时，Kafkabroker会周期性的删除旧的events。大小保留：当超过主题大小时，Kafka代理会定期删除旧事件。无限。作为一项有趣的新功能，Confluent提供了分层存储：可以将热数据发送到具有成本效益的对象存储，并且仅在需要更多计算资源时才进行扩展。在某些情况下，数据可能需要无限期地存储。按时间或大小保留并不是Kafka定义清理策略的唯一能力。用户可以定义一个紧凑的策略，Kafka代理定期删除事件，只保留每个键的最后一个事件，如果最后一个事件为null作为s值，则删除该键。压缩策略是CDC解决方案的一个非常有趣的特性。它允许用户保留一行或文档的最后一个事件。这意味着用户拥有最后合并的值，但丢失了更改历史记录。紧凑型清理策略是一个昂贵的操作，但它允许用户清理旧事件，保持数据库的最后状态，优点是如果一年后需要新的消费者，则不需要今年发生的事件待处理。结论在数据量大、技术多样的复杂环境中，为新的数据平台提供数据是一个巨大的挑战。但真正的挑战是提供这些数据，同时确保企业做出有价值的决策所需的质量。准确性、一致性、唯一性、及时性是衡量数据质量的一些指标。CDC替代其他解决方案，使用户能够以相对简单的方式标准化数据摄取并确保数据质量。标准化和自动化是提高任何流程质量的关键。原标题：数据平台：构建企业CDC解决方案，作者：MiguelGarcia、DarioCazasPernas
