从 Aerospike 迁移到 Bigtable

本文档将引导您完成将数据从 Aerospike 迁移到 Bigtable 的过程。本文介绍了如何使用适配器库等开源工具执行迁移。

在开始迁移之前，请先熟悉面向 Aerospike 用户的 Bigtable。

迁移概览

您可以将数据从 Aerospike 迁移到 Bigtable，并且停机时间极短或为零。

下图概述了迁移步骤：

从 Aerospike 迁移到 Bigtable 的过程。
图 1.从 Aerospike 迁移到 Bigtable 的过程（点击可放大）。.
  1. 流式传输持续发生的更改：使用 Aerospike Kafka 源（出站）连接器和 Kafka Connect Bigtable 接收器连接器将 Aerospike 中持续发生的更新复制到 Bigtable。
  2. 导入备份：创建 Aerospike 备份，并使用 AerospikeBackupToBigtable Dataflow 作业将其导入 Bigtable。
  3. 执行割接：将应用流量迁移到 Bigtable。

迁移范围和兼容性

由于 Bigtable 处理的是原始字节，而不是类型化容器，因此迁移过程涉及将 Aerospike 功能和特性映射到兼容的 Bigtable 结构。适配器库提供了实现结构兼容性和弥合差距（例如对象序列化）所需的工具。不过，由于系统之间存在根本性差异，因此某些功能（例如用户定义的函数 [UDF]）无法迁移。

下表总结了迁移过程如何处理 Aerospike 功能。

功能 支持 说明
Aerospike 混合内存架构 (HMA) 支持 迁移到 SSD 存储层或内存中层。Bigtable 企业 Plus 版提供对内存中存储空间的访问权限，适用于对延迟时间敏感的工作负载，这些工作负载需要亚毫秒级响应时间，与 Aerospike 性能相当。
标量（Int、Float、String、Bool） 支持 迁移到 Bigtable 单元格。
列表和地图 支持 映射必须具有字符串键。列表和映射由适配器库序列化为单独的列。
二级索引 部分支持 不会直接迁移。必须重新实现为异步二级索引。
记录级存留时间 (TTL) 支持 在列族级层配置，或在 Bigtable 中按单元进行模拟。
UDF 不支持 自定义服务器端逻辑必须移至客户端应用。
HyperLogLog 不支持 迁移过程中不支持。
GeoJSON 不支持 迁移过程中不支持。
记录键 不支持 记录密钥不会直接迁移。相反，迁移使用记录摘要作为行键。

准备工作

在开始迁移之前，请完成以下准备步骤，以降低风险并确保顺利过渡：

  • 验证数据：确认 Aerospike 部署不依赖于不受支持的数据类型、二级索引或 UDF。为确保安全，您可以将具有代表性的部分数据导入 Bigtable，并验证架构设计。
  • 预配基础设施：设置迁移流水线所需的各项服务：Bigtable、Kafka 和 Kafka Connect。
    • 容量规划：为 Bigtable 预配足够的容量来处理预期工作负载。选择靠近现有 Aerospike 集群的区域。如需有关估算所需资源的指南，请参阅了解 Bigtable 的性能。
    • 存储层：对于需要亚毫秒级响应时间的工作负载，请考虑使用 Bigtable 内存中层。此层级将数据存储在 RAM 中，以便为读取密集型或对延迟时间敏感的应用提供最高性能。如需了解详情，请参阅内存中层概览。
  • 配置访问权限和网络：分配适当的 Identity and Access Management (IAM) 角色，并确保网络连接。
  • 启用监控和错误报告：为新环境配置可观测性，包括日志记录、指标和提醒。
  • 基准性能基准：记录当前系统性能，以便在迁移后进行验证。
  • 创建备份：创建完整的 Aerospike 数据备份。
  • 运行测试迁移：在尝试生产迁移之前，先在预演环境中验证设置。

迁移数据

完成以下步骤，将数据从 Aerospike 迁移到 Bigtable。

启动变更数据流

启用 Aerospike 变更数据流后，Aerospike Kafka 源（出站）连接器会开始将 Aerospike 记录更新发布到 Kafka 主题。确保 Kafka 有足够的存储容量来缓冲更改，并将连接器配置为以 JSON 格式输出数据。

以下是 Kafka 连接器配置示例：


  service:
    port: <port_to_run_on>

  producer-props:
    bootstrap.servers:
      - <kafka_host>

  format:
    mode: json
    metadata-key: metadata

  routing:
    mode: static
    destination: <kafka_topic>

使用 Aerospike Kafka 源（出站）连接器与 Kafka 进行通信需要 Aerospike 跨数据中心复制 (XDR)，该功能可通过高延迟链接异步复制集群更改。XDR 仅在 Aerospike 企业版中提供。如果您使用的是 Aerospike Community 版，请改用 Enterprise 版，或仅使用 AerospikeBackupToBigtable Dataflow 作业执行离线迁移。

Aerospike 中 XDR 的配置示例如下：


  xdr {
      dc aerospike-kafka-source {
              connector true
              node-address-port <aerospike_connect_host> <aerospike_connect_port>
              namespace <your_namespace_to_replicate> {
              }
      }
  }

从 Aerospike 导出数据

启动更改数据流后，生成现有 Aerospike 数据集的备份。使用 asbackup 命令行工具从 Aerospike 数据库集群创建备份。部分更新可能会同时显示在备份和变更数据流中，这是正常现象，不会影响迁移。如需在恢复期间允许并行导入，请将备份拆分为多个文件。

将数据导入到 Bigtable

如需将备份的数据导入到 Bigtable，请执行以下操作：

  1. 将备份上传到 Cloud Storage 存储桶。
  2. 运行 AerospikeBackupToBigtable Dataflow 作业，将备份导入到 Bigtable 中。如果备份拆分为多个文件，作业会并行处理这些文件。为了处理增加的写入负载并保持最佳吞吐量，请预配额外的 Bigtable 资源。

将记录更新应用到 Bigtable

将备份导入 Bigtable 后，使用 Kafka Connect Bigtable 接收器连接器将 Kafka 中的缓冲记录更新应用到 Bigtable。

将消息转换为兼容格式

Aerospike 迁移工具包括在 Kafka Connect 中运行的 Replicator SMT。复制器会将 Aerospike Kafka 源（出站）连接器发布的消息转换为与将记录写入 Bigtable 的目标接收器兼容的格式。之所以需要进行转换，是因为接收器需要特定格式的数据，而 Aerospike 流的变更方式与此不同。

下表可帮助您估算实现给定吞吐量所需的机器资源：

记录结构 吞吐量 p99 延迟时间
扁平式 每个 vCPU 每秒最多 3,700 条记录 300 毫秒
嵌套 每个 vCPU 每秒最多 2,600 条记录 300 毫秒

这些估计值假设 JSON 序列化记录的大小为 1 KB。解析时间会随着消息结构的复杂性而增加，这意味着存储在 Aerospike 记录中的嵌套对象需要更长时间才能解析。

您可以使用 consumer_lag 指标来验证处理队列中有多少条消息，并衡量复制延迟时间。当接收器处理完主题上积压的消息后，消费者滞后时间会减少，直到稳定在接近零的水平，此时接收器会近乎实时地处理 Aerospike 更新，让您做好割接准备。您可以使用 sink-record-active-count 验证已处理的消息数量。

使用 Kafka Connect Bigtable sink 连接器注入消息

Kafka Connect Bigtable 接收器连接器可将消息从 Kafka 提取到 Bigtable。配置连接器时，请将 insert.mode 设置为 REPLACE_IF_NEWEST，以确保写入 Bigtable 中目标行的记录是最新的。如需了解详情，请参阅 Kafka Connect Bigtable sink 连接器配置。

下表提供了有关不同工作负载引入的延迟时间和所需计算资源的指南：

记录结构 吞吐量 p99 延迟时间
扁平式 每个 vCPU 每秒最多 3,700 条记录 74 毫秒
嵌套 每个 vCPU 每秒最多 3,700 条记录 100 毫秒

这些估计值假设 JSON 序列化记录的大小为 1 KB。报告的延迟时间是接收器中的处理时间。假设向 Bigtable 发送写入请求的额外开销约为 600 毫秒。

改用 Bigtable

将应用切换为使用 Bigtable 作为主要数据库。

为确保读己所写一致性，请暂时关闭应用，直到复制延迟时间达到零。这样可确保不会丢失任何突变，并且数据读取反映的是最新状态。

例如，在割接之前不久在 Aerospike 中应用的突变可能尚未复制到 Bigtable，从而导致过时数据读取。为避免出现这种情况，请在 consumer_lag 和 sink-record-active-count 指标达到 0 之前，让应用保持离线状态。所有待处理的更改传播完毕后，重新启动应用，并将 Bigtable 作为主数据库。

虽然实时迁移可以避免停机，但存在以下限制：

  • 在 Bigtable 中应用的变更不会复制回 Aerospike。
  • 源自 Aerospike 的突变可能会延迟出现在 Bigtable 中。
  • 来自 Aerospike 的延迟突变可能会覆盖 Bigtable 中较新的更新。

验证 Deployment

部署完成后，请查看错误率、延迟时间和费用等指标，验证应用性能。您还可以执行数据完整性检查。

监控和可观测性

在整个迁移过程中，请监控以下指标：

  • 总延迟时间：计算方式为 Kafka 使用方延迟时间加上 sink-record-active-count。这些指标表示 Bigtable 比 Aerospike 落后多少。在将流量重新路由到 Bigtable 之前，需要一个稳定的延迟值。
  • CPU 和内存利用率：监控所有变更数据流流水线组件的 CPU 和内存利用率。
  • Kafka 存储容量：监控自行管理的 Kafka 部署的容量。如果存储空间已满，则无法缓冲新事件，从而导致迁移失败。
  • 应用错误率：监控所有更改流流水线元素的错误率和错误输出。

限制

以下部分概述了将数据从 Aerospike 迁移到 Bigtable 时需要考虑的限制。

迁移期间的数据一致性

当您使用 asbackup 工具生成 Aerospike 备份时，备份过程中修改的记录可能会被排除，因为备份过程不支持原子备份。此限制不会影响正确性，因为所有更改都会显示在变更数据流中。

在将备份导入到 Bigtable 的过程中，每个写入的行都带有 0 的最后更新时间 (LUT) 时间戳。 来自变更数据流的更新会应用于导入的备份之上。从流写入的行使用 LUT 值作为 Bigtable 行时间戳。接收器配置使具有较新时间戳的更新覆盖较旧的更新。这可确保从数据流重放的任何更改都会覆盖相应的行。

使用 LUT

迁移过程使用 Aerospike XDR 复制更改，并依赖 LUT 进行冲突解决。由于 LUT 基于节点的系统时钟，因此它们可能不是严格单调的。因此，过时的记录有时可能会具有较新的 LUT，并覆盖较新的记录。 此外，Aerospike Kafka 源（出站）连接器在发布到 Kafka 时可能无法保留确切的消息顺序。因此，LUT 可作为权威的版本标记，确保只有具有最新 LUT 的记录才会应用于 Bigtable。

如果记录在您启动变更数据流后但在生成备份之前更新，则备份可能会捕获较新版本，而数据流包含较旧版本。此旧版本可能会暂时覆盖新版本。不过，当后续包含正确 LUT 的流事件到达时，系统会恢复到最新版本。为避免不一致，请等到复制稳定且流水线中最旧的未处理消息比备份新时再执行割接。

数据验证

迁移流水线不会对传输中的数据执行校验和计算。如果您需要进行端到端数据完整性检查，则必须实现验证。

问题排查

以下各部分介绍了迁移过程中可能出现的常见错误，并提供了有关如何解决这些错误的指南。

备份导入错误

在将 Aerospike 备份导入 Bigtable 的过程中，您可能会遇到以下错误：

错误类型 原因 解决方案
备份文件已损坏 备份文件无法读取或包含损坏的记录。导入作业失败。 检查受影响的文件是否存在完整性问题。如果无法恢复，请生成新的备份并重复执行导入操作。
Bigtable 写入失败 出现 Bigtable 连接或服务问题。导入不会失败。 失败的记录会以 JSON 格式导出到错误输出文件中。手动重新应用这些设置，或重试完整导入作业。
不支持的数据 备份包含无法导入到 Bigtable 中的条目。导入不会失败。 不支持的数据（例如 UDF）会在作业日志中报告为警告。查看日志以验证是否存在不受支持的条目。

在备份导入完成并解决无效记录问题后，您可以继续应用更改流。

变更数据流错误

在应用更改流期间，可能会在以下级别发生故障：

  • 复制器 SMT 错误：SMT 无法转换 Aerospike 生成的数据。
  • 接收器错误：事件无法应用于 Bigtable。

在这两种情况下，失败的事件都会重定向到专用 Kafka 主题。您可以记录这些事件以供审核，也可以使用自定义恢复逻辑来处理这些事件。

后续步骤