5.4　实现模式

数据迁移服务包含4个关键模块：接入模块、转换模块、合规模块和验证模块。本章重点介绍实现接入模块和转换模块的模式。合规模块和验证模块的模式是通用构件，分别在第9章和第18章中介绍。对应于现有的接入和转换的任务图，数据迁移服务的自动化程度有三个级别（如图5-3所示）。

5.4.1　批处理接入模式

批处理接入是大数据发展早期流行的一种传统模式，它既适用于一次性数据迁移，也适用于计划性数据迁移。批处理指的是将源数据上的更新打包在一起，然后定期迁移到目标数据中。批处理通常用于大型数据源的数据迁移，而不需要实时更新。批处理过程通常每6～24小时调度一次。

批处理接入模式分为三个阶段（如图5-4所示）。

1. 分区阶段

要拷贝的源表在逻辑上被分割成更小的块，以并行化数据迁移。

2. map阶段

每个块被分配给一个mapper（MapReduce中的术语）。mapper触发查询，从源表读取数据并复制到目标表。使用更多mapper将产生更多的并发数据传输任务，从而可以更快地完成作业。但是，这会增加数据库上的负载，可能会影响源数据的性能。对于增量表拷贝，mapper会处理自上次更新以来对源表的插入、更新和删除。

3. reduce阶段

mapper的输出被存储为staging文件，并由reducer合并为目标数据存储上的单个具体化视图。reducer还可以实现转换功能。

批处理接入模式的一个流行示例是Apache Sqoop（https://oreil.ly/iqArX），Sqoop用于批量数据迁移，通常在关系型数据库和文件系统到HDFS和Apache Hive之间迁移数据。它是以客户端-服务器模型实现的：客户端安装在源数据和目标数据存储中，数据迁移任务由客户端的Sqoop服务器以MapReduce作业的形式调度。用于连接数据存储的特定技术适配器安装在客户端上（在较新的Sqoop 2版本中，驱动程序安装在服务器上）。数据迁移是一个MapReduce作业，其中源客户端上的mapper将从源数据存储传输数据，而目标客户端上的reducer将复制和转换数据。Sqoop支持全表刷新和基于高水印的增量表复制。

批处理接入模式的优点：

• 它是一种传统的数据迁移模式，适用于各种源数据和目标数据存储。数据源所有者在使用、管理和维护其源数据存储时只需付出极小的成本。
• 它支持扩展到每天数以千计的计划性数据迁移，还利用MapReduce实现故障恢复。
• 它内置了对复制后数据验证的特性。

批处理接入模式的缺点：

• 它不支持近实时的数据刷新。
• 它可能会潜在地影响源数据存储的性能。此外，用于连接源数据存储的JDBC连接存在潜在的合规问题，而这些数据存储是符合监管规定的。
• 它对使用硬删除的增量表刷新和数据转换功能的支持有限。

批处理是团队在大数据旅程早期的一个良好起点。根据分析团队的成熟度，面向批处理可能就足够用了。数据工程团队通常使用这种模式来快速覆盖可用的数据源。

5.4.2　变更数据捕获接入模式

随着团队逐渐成熟，团队不再采用批处理方式，开始转向变更数据捕获（Change Data Capture，CDC）模式。它适用于正在进行的数据迁移，在这种情况下，源数据更新需要以低延迟（以秒或分钟为单位）在目标数据上可用。CDC意味着捕获源数据上的每个变更事件（更新、删除、插入），并将更新应用到目标数据上。这种模式通常与批处理接入结合使用，批处理用于源表的完整副本初始化，而连续更新则使用CDC模式完成。

CDC接入模式分为三个阶段（如图5-5所示）。

1. 产生CDC事件

在源数据库上安装和配置CDC适配器，该适配器是一种特定于源数据存储的软件，用于跟踪对用户指定表的插入、更新和删除操作。

2. 发布CDC到事件总线

CDC发布在事件总线上，可以被一个或多个分析用例使用。总线上的事件是持久化的，在出现故障时可以重新回放。

3. 事件合并

每个事件（插入、删除、更新）都应用于目标数据上的表。最终的结果是一个具体化的表视图，这个表视图相对于源表延迟较小。在数据目录中更新与目标表对应的元数据，以反映刷新时间戳和其他属性。

CDC接入模式有一种变体，可以直接使用事件，而不是通过合并步骤（即去掉图5-5中的步骤3）。这通常适用于将原始CDC事件转换为特定业务事件的场景。另一种变体是将CDC事件存储为基于时间的日志，这通常适用于风险和欺诈检测分析。

CDC接入模式的一个流行的开源实现是Debezium（https://debezium.io）与Apache Kafka（https://oreil.ly/mH9yU）相结合。Debezium是一个低延迟的CDC适配器，在标准化事件模型中捕获提交到数据库的变更，并且与数据库技术无关。事件描述了在何时何地发生了什么变更。事件以一个或多个Kafka主题（通常每个数据库表有一个主题）的形式在Apache Kafka上发布。Kafka确保所有的事件都有副本且完全有序，并且允许许多用户独立地使用这些相同的数据变更事件，而几乎不影响上游系统。如果在合并过程中出现故障，可以完全从原地恢复。这些事件可以只传递一次或者至少传递一次——每个数据库/表的所有数据实现模式变更事件都按照它们在上游数据库中发生的相同顺序传递。

为了将CDC记录合并到一个具体化的目标表中，一般使用MapReduce面向批处理，或者使用Spark等技术面向流处理。两个流行的开源解决方案是Apache Gobblin（https://oreil.ly/8rvyX），它使用MapReduce（如图5-6所示），以及Uber的Marmaray（https://oreil.ly/Va_Vc），它使用Spark。Gobblin中的合并实现包括反序列化/提取、格式转换、质量验证和向目标写入。Gobblin和Marmaray都是为从任何源数据到任何目标数据的数据迁移而设计的。

CDC接入模式的优点：

• CDC模式是一种低延迟的解决方案，用于更新目标，且对源数据存储的性能影响最小。
• CDC适配器可用于主流的数据存储。
• 它支持在数据迁移过程中进行过滤和数据转换。
• 它支持使用增量方式接入大型表。

CDC接入模式的缺点：

• 考虑到选择CDC适配器的最佳配置选项需要较专业的经验，提高了使用的入门门槛。
• 使用Spark（而不是Hadoop MapReduce）的合并实现，在处理超大表（大约10亿行）时可能会有一些困难。
• 它需要一个带有CDC列的表来跟踪增量变更。
• 它仅能支持有限数据量的数据过滤或数据转换。

这种方法非常适合快速迁移大批量数据，是最受欢迎的方法之一。它要求源数据团队和数据工程团队之间配合顺畅，以确保准确无误地跟踪变更和大规模合并更新。

5.4.3　事件聚合模式

事件聚合模式是一种常见的聚合日志文件和应用程序事件的模式，该模式对事件进行持续实时聚合，以用于欺诈检测、告警、物联网等。随着Web访问日志、广告日志、审计日志和系统日志，以及传感器数据等日志和数据越来越多，该模式的适用性越来越强。

该模式涉及从多个源数据聚合，统一为一个单一的流，并将其用于批处理或流分析。该模式分为两个阶段（如图5-7所示）。

1. 事件转发

来自边缘节点、日志服务器、物联网传感器等的事件和日志被转发到聚合阶段。安装一个轻量级客户端来实时推送日志。

2. 事件聚合

来自多个源数据的事件被规范化、转换，并可用于一个或多个目标数据。聚合是基于数据流的，事件流被缓存并定期上传到目标数据存储。

该模式的一个流行实现是Apache Flume（https://oreil.ly/Dvyf_）。作为数据迁移的一部分，配置文件定义了事件源和数据聚合的目标。Flume的源数据组件从源数据中获取日志文件和事件，并将它们发送到聚合代理以进行数据处理。日志聚合处理存储在内存中，并通过流传输到目的地。

Flume最初设计用于快速可靠地将Web服务器生成的大量日志文件传输到Hadoop中。如今，它已经发展成处理事件数据的工具，处理包括来自Kafka代理、Facebook和Twitter等来源的数据。其他流行的实现有Fluent Bit（https://fluentbit.io）和Fluentd（https://oreil.ly/FjUAB），它们主要被用作日志收集器和日志聚合器。

事件聚合模式的优点：

• 它是针对日志和事件且被优化的实时解决方案，具有高可靠、高可用和高可伸缩（水平扩展）的特性。
• 它对源数据性能的影响极小。
• 它具有高可扩展性和高可定制性，并且开销最小。
• 它支持在数据迁移过程中进行过滤和数据转换。
• 它可扩展以支持处理大批量日志和事件数据。

事件聚合模式的缺点：

• 它不保证源事件数据有序。
• 消息可以至少传递一次（而不是只传递一次），要求目标数据处理重复事件。

总之，这种模式针对日志和事件数据进行了优化，虽然很容易入门，但它是为分析用例而设计的，可以处理无序以及重复的记录。