本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。 # 迁移至 Amazon Keyspaces（Apache Cassandra 兼容） 迁移到 Amazon Keyspaces（Apache Cassandra 兼容）可为企业和组织带来一系列引人注目的好处。以下是让 Amazon Keyspaces 成为数据库迁移极具吸引力的选择的一些关键优势： + **可扩展性** - Amazon Keyspaces 旨在处理海量工作负载并实现无缝扩展，以适应不断增长的数据量和流量。对于传统的 Cassandra，扩展不是按需进行的，需要为未来的峰值进行规划。借助 Amazon Keyspaces，您可以根据需求轻松地扩展或缩减数据库，从而确保您的应用程序能够在不影响性能的情况下，应对突然的流量激增。 + **出色的性能** - Amazon Keyspaces 提供低延迟的数据访问，使应用程序能够以超乎寻常的速度检索和处理数据。其分布式架构可确保读取和写入操作分布在多个节点上，即使在请求速率很高的情况下，也能提供稳定的个位数毫秒响应时间。 + **完全托管** - Amazon Keyspaces 是由 AWS提供的一项完全托管的服务。这意味着它 AWS 可以处理数据库管理的操作方面，包括配置、配置、修补、备份和扩展。这使您可以将更多的精力放在开发应用程序方面，同时减少您的数据库管理任务。 + **无服务器架构** - Amazon Keyspaces 采用无服务器模式。您只需为消耗的容量付费，无需预置容量。您无需管理服务器，也无需选择实例。这种 pay-per-request模式具有成本效益和最小的运营开销，因为您只需为消耗的资源付费，而无需预置和监控容量。 + **为架构提供 NoSQL 灵活性** - Amazon Keyspaces 采用 NoSQL 数据模型，为架构设计提供了灵活性。借助 Amazon Keyspaces，您可以存储结构化、半结构化和非结构化数据，使其非常适合处理各种不断变化的数据类型。此外，Amazon Keyspaces 会在写入时执行架构验证，从而实现数据模型的集中演进。这种灵活性可以缩短开发周期，更容易适应不断变化的业务需求。 + **高可用性和耐久性** — Amazon Keyspaces 在一个内的多个[可用区](https://aws.amazon.com/about-aws/global-infrastructure/regions_az/)中复制数据 AWS 区域，从而确保高可用性和数据持久性。它可以自动处理复制、失效转移和恢复，从而最大限度地降低数据丢失或服务中断的风险。Amazon Keyspaces 提供的可用性服务水平协议（SLA）高达 99.999%。为了获得更高的弹性和低延迟的本地读取，Amazon Keyspaces 提供了[多区域复制](multiRegion-replication.md)。 + **安全性与合规性**：Amazon Keyspaces 与 AWS Identity and Access Management 集成，可实现精细的访问控制。它可提供静态和传输中加密，有助于提升数据安全性。Amazon Keyspaces 已由第三方审计机构针对特定计划（包括 HIPAA、PCI DSS 和 SOC 等）评估安全性与合规性，让您能够满足监管要求。有关更多信息，请参阅 [Amazon Keyspaces（Apache Cassandra 兼容）的合规性验证](Keyspaces-compliance.md)。 + **与 AWS 生态系统集成** — 作为生态 AWS 系统的一部分，Amazon Keyspaces 与其他 AWS 服务系统（例如 AWS CloudFormation亚马逊 CloudWatch和）无缝集成。 AWS CloudTrail这种集成使您能够构建无服务器架构，利用基础设施即代码，并创建实时数据驱动型应用程序。有关更多信息，请参阅 [监控 Amazon Keyspaces（Apache Cassandra 兼容）](monitoring-overview.md)。 **Topics** + [创建从 Apache Cassandra 迁移到 Amazon Keyspaces 的迁移计划](migrating-cassandra.md) + [如何选择合适的工具将数据批量上传或迁移到 Amazon Keyspaces](migrating-tools.md) # 创建从 Apache Cassandra 迁移到 Amazon Keyspaces 的迁移计划 为了成功地从 Apache Cassandra 迁移到 Amazon Keyspaces，建议您查看适用的迁移概念和最佳实践，并比较可用选项。 本主题通过介绍几个关键概念以及可供您使用的工具和技术，来概括介绍迁移过程的工作原理。您可以评估不同的迁移策略，选择最能满足您需求的策略。 **Topics** + [功能兼容性](#migrating-cassandra-compatibility) + [估算 Amazon Keyspaces 定价](#migrating-cassandra-sizing) + [选择迁移策略](#migrating-cassandra-strategy) + [在线迁移到 Amazon Keyspaces：策略和最佳实践](migrating-online.md) + [离线迁移过程：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md) + [使用混合迁移解决方案：Apache Cassandra 到 Amazon Keyspaces](migrating-hybrid.md) ## 功能兼容性 在迁移之前，请仔细考虑 Apache Cassandra 和 Amazon Keyspaces 之间的功能差异。Amazon Keyspaces 支持所有常用的 Cassandra 数据面板操作，例如创建键空间和表、读取数据和写入数据。 但是，有些 Cassandra APIs 是 Amazon Keyspaces 不支持的。有关支持的更多信息 APIs，请参阅[支持 Cassandra APIs、操作、函数和数据类型](cassandra-apis.md)。有关 Apache Keyspaces 与 Apache Cassandra 之间所有功能差异的概述，请参阅[功能差异：Amazon Keyspaces 与 Apache Cassandra](functional-differences.md)。 要将您正在使用的 Cassandra APIs 和架构与 Amazon Keyspaces 中支持的功能进行比较，您可以在上运行亚马逊密钥空间工具包中提供的兼容性脚本。[GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py) **如何使用兼容性脚本** 1. 从下载兼容的 Python 脚本[GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/toolkit-compat-tool.py)并将其移动到可以访问现有 Apache Cassandra 集群的位置。 1. 兼容性脚本使用的参数与 `CQLSH` 类似。对于 `--host` 和 `--port`，输入用于连接集群中的一个 Cassandra 节点并对该节点运行查询的 IP 地址和端口。 如果您的 Cassandra 集群使用身份验证，则还需要提供 `-username` 和 `-password`。要运行兼容性脚本，您可以使用以下命令。 ``` python toolkit-compat-tool.py --host hostname or IP -u "username" -p "password" --port native transport port ``` ## 估算 Amazon Keyspaces 定价 本节概述了您需要从 Apache Cassandra 表中收集哪些信息来计算 Amazon Keyspaces 的估算成本。您的每个表都需要不同的数据类型，需要支持不同的 CQL 查询并保持独特的 read/write 流量。 根据表考虑您的需求，与 Amazon Keyspaces 表级资源隔离以及[读/写吞吐能力模式](ReadWriteCapacityMode.md)保持一致。借助 Amazon Keyspaces，您可以单独为表定义读/写容量和[自动扩缩策略](autoscaling.md)。 了解表的要求有助于您根据功能、成本和迁移工作量确定要迁移的表的优先级。 在迁移之前，请收集以下 Cassandra 表指标。这些信息有助于估算您在 Amazon Keyspaces 上的工作负载的成本。 + **表名** - 完全限定键空间的名称和表名。 + **描述** - 对表的描述，例如表的使用方式或其中存储的数据类型。 + **每秒平均读取数** - 在较长时间间隔内对表进行的协调器级平均读取数。 + **每秒平均写入数** - 在较长时间间隔内对表进行的协调器级平均写入数。 + **平均行大小（以字节为单位）**- 以字节为单位的平均行大小。 + **中的存储大小 GBs**-表的原始存储大小。 + **读取一致性明细** - 使用最终一致性（`LOCAL_ONE` 或 `ONE`）与强一致性（`LOCAL_QUORUM`）的读取百分比。 下表显示了计划迁移时需要汇总的表信息的示例。 **** | 表名 | 说明 | 每秒平均读取数 | 每秒平均写入数 | 平均行大小（字节） | 存储空间大小 GBs | 读取一致性细分 | | --- | --- | --- | --- | --- | --- | --- | | mykeyspace.mytable | 用于存储购物车历史记录 | 10000 | 5000 | 2,200 | 2000 | 100% `LOCAL_ONE` | | mykeyspace.mytable2 | 用于存储最新个人资料信息 | 20000 | 1000 | 850 | 1000 | 25% `LOCAL_QUORUM` 75% `LOCAL_ONE` | ### 如何收集表指标 本节提供了有关如何从现有 Cassandra 集群中收集必要的表指标的分步说明。这些指标包括行大小、表大小和每秒 read/write 请求数 (RPS)。通过这些信息，您可以评估 Amazon Keyspaces 表的吞吐能力要求并估算定价。 **如何在 Cassandra 源表上收集表指标** 1. 确定行大小 行大小对于确定 Amazon Keyspaces 中的读取容量和写入容量利用率非常重要。下图显示了 Cassandra 令牌范围内的典型数据分布。 ![\[使用 murmur3 分区程序显示 Cassandra 令牌范围内典型数据分布的示意图。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/migration-data-distribution.png) 您可以使用上提供的行大小采样器脚本[GitHub](https://github.com/aws-samples/amazon-keyspaces-toolkit/blob/master/bin/row-size-sampler.sh)来收集 Cassandra 集群中每个表的行大小指标。 该脚本使用 `cqlsh` 和 `awk` 从 Apache Cassandra 导出表数据，来基于一组可配置的表数据样本计算行大小的最小值、最大值、平均值以及标准差。行大小采样器将参数传递给 `cqlsh`，因此可以使用相同的参数来连接 Cassandra 集群并从中读取数据。 下面是一个示例语句。 ``` ./row-size-sampler.sh 10.22.33.44 9142 \\ -u "username" -p "password" --ssl ``` 有关如何在 Amazon Keyspaces 中计算行大小的更多信息，请参阅[估算 Amazon Keyspaces 中的行大小](calculating-row-size.md)。 1. 确定表大小 使用 Amazon Keyspaces，您无需提前预置存储空间。Amazon Keyspaces 会持续监控表的可计费大小，以确定存储费用。存储按 GB/月计费。Amazon Keyspaces 表大小基于单个副本的原始大小（未压缩）。 要监控 Amazon Keyspaces 中的表大小，您可以使用指标 `BillableTableSizeInBytes`，AWS 管理控制台中的每个表都有该指标。 要估算 Amazon Keyspaces 表的可计费大小，您可以使用以下两种方法之一： + 使用平均行大小，然后乘以行数。 您可以通过将平均行大小乘以 Cassandra 源表中的行数来估算 Amazon Keyspaces 表的大小。使用上一节中的行大小示例脚本来捕获平均行大小。要捕获行数，您可以使用诸如 `dsbulk count` 这样的工具来确定源表中的总行数。 + 使用 `nodetool` 收集表元数据。 `Nodetool` 是 Apache Cassandra 发行版中提供的管理工具，可让您深入了解 Cassandra 进程的状态并返回表元数据。您可以使用 `nodetool` 对有关表大小的元数据进行采样，并借此推断 Amazon Keyspaces 中的表大小。 要使用的命令是 `nodetool tablestats`。Tablestats 会返回表的大小和压缩比例。表的大小存储为表的 `tablelivespace`，您可以将其除以 `compression ratio`。然后将此大小值乘以节点数。最后除以复制因子（通常为 3）。 这是可用于评估表大小的完整计算公式。 ``` ((tablelivespace / compression ratio) * (total number of nodes))/ (replication factor) ``` 假设你的 Cassandra 集群有 12 个节点。运行 `nodetool tablestats` 命令会返回 200GB 的 `tablelivespace` 和 0.5 的 `compression ratio`。键空间的复制因子为 3。 这就是此示例的计算方式。 ``` (200 GB / 0.5) * (12 nodes)/ (replication factor of 3) = 4,800 GB / 3 = 1,600 GB is the table size estimate for Amazon Keyspaces ``` 1. 捕获读取和写入数 要确定 Amazon Keyspaces 表的容量和扩缩要求，请在迁移之前获取 Cassandra 表的读取和写入请求速率。 Amazon Keyspaces 采用无服务器模式，您只需按实际使用量付费。通常，Amazon Keyspaces 的 read/write 吞吐量价格取决于请求的数量和大小。 Amazon Keyspaces 中有两种容量模式： + [按需](ReadWriteCapacityMode.OnDemand.md) - 这是一种灵活的计费方式，可以每秒处理数千个请求而不需要进行容量规划。它为读取和写入请求提供 pay-per-request定价，因此您只需为实际用量付费。 + [预置](ReadWriteCapacityMode.Provisioned.md) – 如果您选择预置吞吐能力模式，则指定您的应用程序需要的每秒读取和写入数。这可以帮助您管理 Amazon Keyspaces 的使用情况，使其保持在或低于定义的请求速率，从而保持可预测性。 预置模式提供[自动扩缩](autoscaling.md)功能，可自动调整您的预置速率来进行纵向扩展或缩减，从而提高运营效率。有关管理无服务器资源的更多信息，请参阅[在 Amazon Keyspaces（Apache Cassandra 兼容）中管理无服务器资源](serverless_resource_management.md)。 由于您分别在 Amazon Keyspaces 中预置读取和写入吞吐能力，因此您需要单独衡量现有表中的读取和写入请求速率。 要从现有 Cassandra 集群中收集最准确的利用率指标，请针对在单个数据中心中所有节点上聚合的表，捕获较长一段时间内协调器级读取和写入操作的平均每秒请求数（RPS）。 捕获至少几周内的平均 RPS 可以捕捉流量模式中的峰值和低谷，如下图所示。 ![\[显示两周内每天平均每秒请求速率的示意图。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/migration-rps.png) 您可以通过两个选项来确定 Cassandra 表的读取和写入请求速率。 + 使用现有的 Cassandra 监控 您可以使用下表所示的指标来观察读/写请求。请注意，指标名称可能会因您使用的监控工具而有所差异。 **** [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/migrating-cassandra.html) + 使用 `nodetool` 使用 `nodetool tablestats` 和 `nodetool info` 捕获表中的平均读取和写入操作数。`tablestats` 会返回自节点启动之日起的读取和写入总数。`nodetool info` 则会提供节点的正常运行时间（以秒为单位）。 要获得每秒平均读取和写入数，请将读取和写入数量除以节点的正常运行时间（以秒为单位）。然后，对于读取，您可以除以一致性级别，而对于写入，则除以复制因子。这些计算用以下公式表示。 每秒平均读取数的公式： ``` ((number of reads * number of nodes in cluster) / read consistency quorum (2)) / uptime ``` 每秒平均写入数的公式： ``` ((number of writes * number of nodes in cluster) / replication factor of 3) / uptime ``` 假设我们有一个 12 个节点的集群已经运行了 4 周。`nodetool info` 会返回 2419200 秒的正常运行时间，`nodetool tablestats` 会返回 10 亿写入数量和 20 亿读取数量。此示例将得出以下计算。 ``` ((2 billion reads * 12 in cluster) / read consistency quorum (2)) / 2,419,200 seconds = 12 billion reads / 2,419,200 seconds = 4,960 read request per second ((1 billion writes * 12 in cluster) / replication factor of 3) / 2,419,200 seconds = 4 billion writes / 2,419,200 seconds = 1,653 write request per second ``` 1. 确定表的容量利用率 要估算平均容量利用率，请从平均请求速率以及 Cassandra 源表的平均行大小开始。 Amazon Keyspaces 使用*读取容量单位* (RCUs) 和*写入容量单位* (WCUs) 来衡量表读取和写入的预配置吞吐容量。在此估算中，我们使用这些单位来计算迁移后新 Amazon Keyspaces 表的读取和写入容量需求。 在本主题的后面部分，我们将讨论在预置容量模式和按需容量模式之间的选择会对计费会有怎样的影响。但是在此示例中，为了估算容量利用率，我们假设该表处于预置模式下。 + **读取** – 对于大小不超过 4 KB 的行，一个 RCU 代表一个 `LOCAL_QUORUM` 读取请求，或两个 `LOCAL_ONE` 读取请求。如果您需要读取大于 4 KB 的行，则读取操作会使用额外的 RCUs。 RCUs 所需的总数取决于行大小，以及您是要使用一致性`LOCAL_QUORUM`还是`LOCAL_ONE`读取一致性。 例如， RCUs 使用读取一致性读取 8 KB 的行需要 2 个，如果您选择`LOCAL_QUORUM``LOCAL_ONE`读取一致性，则需要 1 个 RCU。 + **写入** – 对于大小不超过 1 KB 的行，一个 WCU 代表一次写入。所有写入操作都使用`LOCAL_QUORUM`一致性，使用轻量级事务 (LWTs) 不收取额外费用。 WCUs 所需的总数取决于行大小。如果您需要写入大于 1 KB 的行，则写入操作会使用额外的 WCUs。例如，如果您的行大小为 2 KB，则需要有 2 KB WCUs 才能执行一个写入请求。 以下公式可用于估算所需的 RCUs 和 WCUs。 + **中的读取容量 RCUs**可以通过将每秒读取次数乘以每次读取的行数乘以平均行大小除以 4KB 并向上舍入到最接近的整数来确定。 + **中的写入容量 WCUs**可以通过将请求数乘以平均行大小除以 1KB 并向上舍入到最接近的整数来确定。 该示例通过以下公式表示。 ``` Read requests per second * ROUNDUP((Average Row Size)/4096 per unit) = RCUs per second Write requests per second * ROUNDUP(Average Row Size/1024 per unit) = WCUs per second ``` 例如，如果您要在 Cassandra 表上执行 4,960 个读取请求，行大小为 2.5KB，则在 Amazon Keyspaces 中需要 4,960 个读取请求。 RCUs 如果您目前在 Cassandra 表上每秒执行 1,653 个写入请求，行大小为 2.5KB，则亚马逊密钥空间中每秒需要执行 4,9 WCUs 59 个写入请求。 此示例用以下公式表示。 ``` 4,960 read requests per second * ROUNDUP( 2.5KB /4KB bytes per unit) = 4,960 read requests per second * 1 RCU = 4,960 RCUs 1,653 write requests per second * ROUNDUP(2.5KB/1KB per unit) = 1,653 requests per second * 3 WCUs = 4,959 WCUs ``` 使用 `eventual consistency`，您每个读取请求可以节省多达一半的吞吐能力。每次最终一致性读取最多可消耗 8KB。您可以通过将先前的计算结果乘以 0.5 来计算最终一致性读取数，如以下公式所示。 ``` 4,960 read requests per second * ROUNDUP( 2.5KB /4KB per unit) * .5 = 2,480 read request per second * 1 RCU = 2,480 RCUs ``` 1. 计算 Amazon Keyspaces 的每月价格估算 要根据 read/write 容量吞吐量估算表的每月账单，您可以使用不同的公式计算按需模式和预置模式的定价，并比较表的选项。 **预置模式** - 读取和写入容量消耗按小时费率计费，基于每秒的容量单位数。首先，将该费率除以 0.7，表示默认的自动扩缩目标利用率为 70%。然后乘以 30 个日历日、每天 24 小时以及区域费率定价。 此计算总结为以下公式。 ``` (read capacity per second / .7) * 24 hours * 30 days * regional rate (write capacity per second / .7) * 24 hours * 30 days * regional rate ``` **按需模式** - 读取和写入容量按每个请求的费率计费。首先，将请求费率乘以 30 个日历日以及每天 24 小时。然后除以 100 万个请求单位。最后，乘以区域费率。 此计算总结为以下公式。 ``` ((read capacity per second * 30 * 24 * 60 * 60) / 1 Million read request units) * regional rate ((write capacity per second * 30 * 24 * 60 * 60) / 1 Million write request units) * regional rate ``` ## 选择迁移策略 从 Apache Cassandra 迁移到 Amazon Keyspaces 时，您可以在以下迁移策略之间进行选择： + **联机** - 这是一种实时迁移，使用双重写入操作开始同时向 Amazon Keyspaces 和 Cassandra 集群写入新数据。对于迁移期间要求零停机时间以及要求写后读一致性的应用程序，建议使用此迁移类型。 有关如何规划和实施在线迁移策略的更多信息，请参阅[在线迁移到 Amazon Keyspaces：策略和最佳实践](migrating-online.md)。 + **离线** - 这种迁移技术是指在停机时间段内，将数据集从 Cassandra 复制到 Amazon Keyspaces。离线迁移可以简化迁移过程，因为它不需要更改应用程序，也不需要解决历史数据和新写入内容之间的冲突。 有关如何规划离线迁移的更多信息，请参阅[离线迁移过程：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。 + **混合** - 这种迁移技术可以通过近乎实时的方式将更改复制到 Amazon Keyspaces，但无需写后读一致性。 有关如何规划混合迁移的更多信息，请参阅[使用混合迁移解决方案：Apache Cassandra 到 Amazon Keyspaces](migrating-hybrid.md)。 在查看了本主题中讨论的迁移技术和最佳实践之后，您可以将可用选项放在决策树中，以便根据您的要求和可用资源设计迁移策略。 # 在线迁移到 Amazon Keyspaces：策略和最佳实践 如果您在从 Apache Cassandra 迁移到 Amazon Keyspaces 的过程中需要保持应用程序的可用性，则可以通过实施本主题中讨论的关键组件来准备自定义的在线迁移策略。通过遵循这些在线迁移的最佳实践，您可以确保在整个迁移过程中保持应用程序的可用性和 read-after-write一致性，从而最大限度地减少对用户的影响。 在设计从 Apache Cassandra 到 Amazon Keyspaces 的在线迁移策略时，您需要考虑以下关键步骤。 1. **写入新数据** + **用于亚马逊密钥空间迁移的 ZDM 双写代理** — 使用 Github [上](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md)提供的 ZDM 双写代理执行从 Apache Cassandra 到亚马逊密钥空间的零停机迁移。ZDM Proxy 无需重构现有应用程序即可执行双重写入，并执行双重读取以进行查询验证。 + 应用程序双重写入：您可以使用现有的 Cassandra 客户端库和驱动程序在应用程序中实现双重写入。将一个数据库指定为领导设备，将另一个数据库指定为跟随设备。跟随数据库的写入失败记录在[死信队列（DLQ）](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)中以供分析。 + 消息收发层双重写入：或者，您可以将现有消息收发平台配置为利用其他使用者向 Cassandra 和 Amazon Keyspaces 发送写入内容。这会在两个数据库之间创建最终一致的视图。 1. **迁移历史数据** + 复制历史数据：您可以使用 AWS Glue 或自定义提取、转换、加载（ETL）脚本将历史数据从 Cassandra 迁移到 Amazon Keyspaces。使用轻量级事务或时间戳等技术处理双重写入和批量加载之间的冲突解决方案。 + 使用 Time-To-Live (TTL)：为了缩短数据保留期，您可以在 Cassandra 和 Amazon Keyspaces 中使用 TTL，以避免上传不必要的历史数据。随着旧数据在 Cassandra 中过期，而新数据通过双重写入技术进行写入，Amazon Keyspaces 最终会赶上来，保持一致。 1. **验证数据** + 双重读取：实现对 Cassandra（主）数据库和 Amazon Keyspaces（辅助）数据库的双重读取，异步比较结果。差异会被记录下来或发送到 DLQ。 + 样本读取：使用 Λ 函数定期对两个系统的数据进行采样和比较，将所有差异记录到 DLQ 中。 1. **迁移应用程序** + 蓝绿策略：只需一个步骤即可将您的应用程序切换为将 Amazon Keyspaces 视为主数据存储，将 Cassandra 视为辅助数据存储。监控性能并在出现问题时进行回滚。 + 金丝雀部署：首先向部分用户逐步推出迁移，逐步增加流向作为主数据库的 Amazon Keyspaces 的流量，直到全部迁移。 1. **停用 Cassandra** 在您的应用程序完全迁移到 Amazon Keyspaces 并验证数据一致性后，您可以根据数据留存策略计划停用 Cassandra 集群。 通过使用这些组件规划在线迁移策略，您可以顺利过渡到完全托管的 Amazon Keyspaces 服务，同时最大限度地减少停机时间或中断。以下各节将更详细讨论每个组件。 **Topics** + [在线迁移期间写入新数据](migration-online-dw.md) + [在线迁移期间上传历史数据](migration-online-historical.md) + [在在线迁移期间验证数据一致性](migration-online-validation.md) + [在线迁移期间迁移应用程序](migration-online-app-migration.md) + [在线迁移后停用 Cassandra](migration-online-decommission.md) # 在线迁移期间写入新数据 在线迁移计划的第一步是，确保应用程序写入的任何新数据都存储在两个数据库中，即现有的 Cassandra 集群和 Amazon Keyspaces 中。目标是在两个数据存储中提供一致的视图。您可以通过将所有新的写入内容应用于两个数据库来实现此目的。要实现双写入，请考虑以下三个选项之一。 + **用于亚马逊密钥空间迁移的 ZDM 双写代理 — 使用 Github [上](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md)提供的适用于亚马逊密钥空间**的 ZDM 代理，您可以将 Apache Cassandra 工作负载迁移到亚马逊密钥空间，而无需应用程序停机。此增强型解决方案实施了AWS最佳实践，并扩展了官方 ZDM 代理功能。 + 在 Apache Cassandra 和 Amazon Keyspaces 之间进行在线迁移。 + 无需重构应用程序，即可同时向源表和目标表写入数据。 + 通过双读操作验证查询。 该解决方案为使用AWS和 Amazon Keyspaces 提供了以下增强功能。 + **容器部署** — 使用来自亚马逊弹性容器注册表 (Amazon ECR) Registry 的预先配置的 Docker 镜像进行可访问 VPC 的部署。 + **基础架构即代码** — 使用AWS CloudFormation模板进行部署以实现自动设置AWS Fargate。 + **Amazon Keyspaces 兼容性 — 访问带有针对亚马逊密钥空间**的自定义改编版的系统表。 该解决方案在带有 Fargate 的 Amazon ECS 上运行，可根据您的工作负载需求提供无服务器可扩展性。网络负载均衡器将传入的应用程序流量分配到多个 Amazon ECS 任务中，以实现高可用性。 ![\[实施 ZDM 双写代理，用于将数据从 Apache Cassandra 迁移到 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-zdm.png) + **应用程序双重写入** - 您可以使用现有的 Cassandra 客户端库和驱动程序实现双重写入，将对应用程序代码的更改降至最少。您可以在现有应用程序中实现双重写入，也可以在架构中创建新层来处理双重写入。有关更多信息以及展示如何在现有应用程序中实现双重写入的客户案例研究，请参阅 [Cassandra 迁移案例研究](https://aws.amazon.com/solutions/case-studies/intuit-apache-migration-case-study/)。 在实现双重写入时，可以将一个数据库指定领导设备，将另一个数据库指定为跟随设备。如此，您就可以继续写入原始源数据库或领导数据库，而不会让跟随数据库或目标数据库的写入失败中断应用程序的关键路径。 您可以使用 Amazon Simple Queue Service 在[死信队列（DLQ）](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)中记录失败的写入操作，而不必重试跟随设备的写入失败操作。DLQ 让您可以分析跟随设备的写入失败操作，并确定目标数据库中处理未成功的原因。 对于更复杂的双写入实现，您可以遵循AWS最佳实践，使用 s [aga 模式](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/saga.html)设计一系列本地事务。saga 模式可确保，如果事务失败，则 saga 将运行补偿事务，以恢复先前事务所做的数据库更改。 使用双重写入进行在线迁移时，可以按照 saga 模式配置双重写入，让每次写入都是本地事务，从而确保跨异构数据库使用原子操作。有关使用推荐的设计模式设计分布式应用程序的更多信息AWS 云，请参阅[云设计模式、架构和实现](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/introduction)。 ![\[从 Apache Cassandra 迁移到 Amazon Keyspaces 时，在应用程序层实现双重写入。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-dual-writes.png) + **消息收发层双重写入** - 您可以使用现有的消息收发层对 Cassandra 和 Amazon Keyspaces 执行双重写入操作，而不是在应用程序层实现双重写入。 为此，您可以为消息收发平台配置一个额外的使用者，以便向这两个数据存储都发送写入内容。这种方法提供了一种简单的低代码策略，使用消息收发层在两个数据库中创建两个最终会一致的视图。 # 在线迁移期间上传历史数据 在实现双重写入来确保将新数据实时写入这两个数据存储之后，迁移计划的下一步是，评估您需要将多少历史数据从 Cassandra 复制或批量上传到 Amazon Keyspaces。这样可以确保在迁移应用程序之前，新的 Amazon Keyspaces 数据库中既有新数据，也有历史数据。 根据您的数据留存要求，例如根据贵组织的政策需要保留多少历史数据，您可以考虑以下两个选项之一。 + **批量上传历史数据** — 可通过各种技术将历史数据从现有 Cassandra 部署迁移到 Amazon Keyspaces，例如AWS Glue使用或自定义脚本提取、转换和加载 (ETL) 数据。有关使用 AWS Glue 上传历史数据的更多信息，请参阅[离线迁移过程：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。 在计划批量上传历史数据时，您需要考虑如何解决新写入操作尝试更新正在上传的相同数据时可能发生的冲突。批量上传预计最终将保持一致，这意味着数据最终将到达所有节点。 如果由于新的写入操作而导致同时更新了相同的数据，则需要确保历史数据上传不会覆盖这些数据。为确保即使在批量导入期间也保留数据的最新更新，您必须将冲突解决方案添加到批量上传脚本或应用程序逻辑中来进行双重写入。 例如，您可以使用[轻量级事务](functional-differences.md#functional-differences.light-transactions)（LWT）来比较和设置操作。为此，您可以在数据模型中添加一个表示修改时间或状态的额外字段。 此外，Amazon Keyspaces 支持 Cassandra `WRITETIME` 时间戳功能。您可以使用 Amazon Keyspaces 客户端时间戳来保留源数据库的时间戳并实施冲突解决方案。 last-writer-wins有关更多信息，请参阅 [Amazon Keyspaces 中的客户端时间戳](client-side-timestamps.md)。 + **使用 Time-to-Live (TTL)**-对于短于 30、60 或 90 天的数据保留期，您可以在迁移期间在 Cassandra 和 Amazon Keyspaces 中使用 TTL，以避免将不必要的历史数据上传到亚马逊密钥空间。TTL 让您可以设置一个时间段，在此之后数据将自动从数据库中删除。 在迁移阶段，您无需将历史数据复制到 Amazon Keyspaces，而是可以配置 TTL 设置，让历史数据在旧系统（Cassandra）中自动过期，同时使用双重写入方法将新写入内容应用到 Amazon Keyspaces。久而久之，随着 Cassandra 集群中的旧数据不断过期，同时使用双重写入方法写入新数据，Amazon Keyspaces 会自动赶上来，最终包含与 Cassandra 相同的数据。 这种方法可以显著减少要迁移的数据量，从而提高迁移过程的效率和精简性。在处理具有不同数据留存要求的大型数据集时，可以考虑使用这种方法。有关 TTL 的更多信息，请参阅[使用 Amazon Keyspaces（Apache Cassandra 兼容）的生存时间（TTL）功能让数据过期](TTL.md)。 考虑以下使用 TTL 数据过期从 Cassandra 迁移到 Amazon Keyspaces 的示例。在此示例中，我们将两个数据库的 TTL 设置为 60 天，并显示 90 天内迁移过程的进展情况。在此期间，两个数据库都使用双重写入方法获得同样的新写入数据。我们将研究迁移的三个不同阶段，每个阶段为期 30 天。 下图显示了每个阶段的迁移过程的工作原理。 ![\[从 Apache Cassandra 迁移到 Amazon Keyspaces 时，使用 TTL 使历史数据过期。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-TTL.png) 1. 在最初的 30 天之后，Cassandra 集群和 Amazon Keyspaces 一直都在获得新的写入内容。Cassandra 集群还包含留存期尚未达到 60 天的历史数据，这些历史数据占集群中数据的 50%。 将使用 TTL 自动删除 Cassandra 集群中超过 60 天的数据。此时，Amazon Keyspaces 包含 Cassandra 集群中存储的数据的 50%，其中的数据构成是新写入数据减去历史数据。 1. 60 天后，Cassandra 集群和 Amazon Keyspaces 都包含了过去 60 天内写入的相同数据。 1. 在 90 天内，Cassandra 和 Amazon Keyspaces 都包含相同的数据，并且数据的过期进度也相同。 此示例说明了如何使用过期日期设置为 60 天的 TTL 来避免上传历史数据的步骤。 # 在在线迁移期间验证数据一致性 在线迁移过程的下一步是数据验证。双重写入会将新数据添加到您的 Amazon Keyspaces 数据库中，并且您已经使用批量上传或通过 TTL 让历史数据过期而完成了历史数据的迁移。 现在，您可以使用验证阶段来确认两个数据存储实际上包含相同的数据并返回相同的读取结果。您可以从以下两个选项中选择一个，来验证两个数据库是否包含相同数据。 + **双重读取** - 要验证源数据库和目标数据库是否包含相同的新写入数据和历史数据集，可以实现双重读取。为此，您可以像双重写入方法一样从主 Cassandra 数据库和辅助 Amazon Keyspaces 数据库中读取数据，然后异步比较结果。 主数据库的结果返回给客户端，辅助数据库的结果用于对照主结果集进行验证。发现的差异可以记录下来或发送到[死信队列（DLQ）](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)，以便日后进行协调。 在下图中，应用程序正在从 Cassandra（主数据存储）执行同步读取，并从 Amazon Keyspaces（辅助数据存储）执行异步读取。 ![\[在从 Apache Cassandra 在线迁移到 Amazon Keyspaces 的过程中，使用双重读取来验证数据一致性。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-dual-reads.png) + **样本读取** — 无需更改应用程序代码的替代解决方案是使用AWS Lambda函数定期随机采样源 Cassandra 集群和目标 Amazon Keyspaces 数据库的数据。 您可以将这些 Lambda 函数配置为定期运行。Lambda 函数从源系统和目标系统中随机检索一部分数据，然后对采样数据进行比较。可以记录两个数据集之间的任何差异或不匹配之处，并将其发送到专用的[死信队列（DLQ）](https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html)，以便日后进行协调。 此过程如下图所示。 ![\[在从 Apache Cassandra 在线迁移到 Amazon Keyspaces 的过程中，使用样本读取来验证数据一致性。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-sample-reads.png) # 在线迁移期间迁移应用程序 在线迁移的第四阶段，您将迁移应用程序并过渡到作为主数据存储的 Amazon Keyspaces。这表示您可以将应用程序切换为直接从 Amazon Keyspaces 读取数据和向其中写入数据。为确保最大限度地减少对用户的干扰，这应该是一个精心策划和协调的过程。 有两种不同的应用程序迁移推荐解决方案可供选择，蓝绿切换策略和金丝雀切换策略。以下各节对这两种策略进行了详述。 + **蓝绿策略** - 使用这种方法，您只需一步即可切换应用程序，将 Amazon Keyspaces 视为主数据存储，将 Cassandra 视为辅助数据存储。为此，您可以使用AWS AppConfig功能标志来控制应用程序实例中主数据存储和辅助数据存储的选择。有关特征标志更多信息，请参阅 [Creating a feature flag configuration profile in AWS AppConfig](https://docs.aws.amazon.com/appconfig/latest/userguide/appconfig-creating-configuration-and-profile-feature-flags.html)。 将 Amazon Keyspaces 设置为主数据存储后，您可以监控应用程序的行为和性能，确保 Amazon Keyspaces 满足您的要求并保证迁移成功。 例如，如果您对应用程序实现了双重读取，则在应用程序迁移阶段，您可以将主读取从 Cassandra 切换到 Amazon Keyspaces，将辅助读取从 Amazon Keyspaces 切换到 Cassandra。切换后，您可以继续按照[数据验证](migration-online-validation.md)部分所述监控和比较结果，确保在停用 Cassandra 之前两个数据库之间实现一致。 如果检测到任何问题，则可以通过恢复到作为主数据存储的 Cassandra 来快速回滚到之前的状态。只有当 Amazon Keyspaces 满足您对主数据存储的所有需求时，您再停止移。 ![\[使用蓝绿策略将应用程序从 Apache Cassandra 迁移到 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-switch.png) + **金丝雀策略** - 通过这种方法，您可以逐步向部分用户或流量推出迁移。最初，您的应用程序流量的一小部分（例如，所有流量的 5%）被路由到使用 Amazon Keyspaces 作为主数据存储的版本，而其余流量则继续使用 Cassandra 作为主数据存储。 这让您可以使用真实流量对迁移版本进行全面测试，并监控其性能、稳定性以及调查潜在的问题。如果您未发现任何问题，则可以逐步增加路由到 Amazon Keyspaces 的流量百分比，直到它成为所有用户和流量的主数据存储。 这种分阶段部署可最大限度地降低广泛服务中断的风险，并且可以对迁移过程进行更严格的控制。如果在金丝雀部署期间出现任何严重问题，则可以将 Cassandra 作为受影响流量段的主数据存储，来快速回滚到先前的版本。只有在您确认 Amazon Keyspaces 按预期处理所有用户和流量之后，您再停止迁移。 下图展示了金丝雀策略的各个步骤。 ![\[使用金丝雀策略将应用程序从 Apache Cassandra 迁移到 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/online-migration-canary.png) # 在线迁移后停用 Cassandra 应用程序迁移完成，即应用程序已完全在 Amazon Keyspaces 上运行且您已验证一段时间内的数据一致性后，便可以计划停用 Cassandra 集群了。在此阶段，您可以评估 Cassandra 集群中剩余的数据是否需要存档或是否可以删除。这取决于贵组织的数据处理和留存政策。 在计划从 Cassandra 到 Amazon Keyspaces 的在线迁移时，通过遵循此策略并考虑本主题中描述的推荐最佳实践，您可以确保无缝过渡到亚马逊密钥空间，同时 read-after-write保持应用程序的一致性和可用性。 从 Apache Cassandra 迁移到 Amazon Keyspaces 可以带来许多好处，包括减少运营开销、实现自动扩缩、提高安全性以及获得可协助您实现合规性目标的框架。通过规划涵盖双重写入、历史数据上传、数据验证和逐步部署的在线迁移策略，您可以确保平稳过渡，同时最大限度地减少对应用程序及其用户的干扰。 通过实现本主题中讨论的在线迁移策略，您可以验证迁移结果、发现及解决任何问题，并最终停用现有的 Cassandra 部署，转而使用完全托管的 Amazon Keyspaces 服务。 # 离线迁移过程：Apache Cassandra 到 Amazon Keyspaces 离线迁移适用于能够容忍停机一段时间来执行迁移的情况。在企业中，通常会有补丁维护时段、大型版本维护时段或需要停机一段时间来执行硬件升级或重大升级等。离线迁移可以利用此时段复制数据，并将应用程序流量从 Apache Cassandra 切换到 Amazon Keyspaces。 离线迁移可以减少对应用程序的修改，因为它不需要与 Cassandra 和 Amazon Keyspaces 进行通信。此外，暂停数据流后，无需保持变更即可复制确切的状态。 在本示例中，我们使用 Amazon Simple Storage Service（Amazon S3）作为离线迁移期间数据的暂存区域，以最大限度地减少停机时间。您可以使用 Spark Cassandra 连接器和 AWS Glue 将在 Amazon S3 中以 Parquet 格式存储的数据自动导入到 Amazon Keyspaces 表中。以下小节将简要概述此过程。您可以在 [Github](https://github.com/aws-samples/amazon-keyspaces-examples/tree/main/scala/datastax-v4/aws-glue) 上找到这个过程的代码示例。 使用 Amazon S3 从 Apache Cassandra 到 Amazon Keyspaces 的离线迁移过程AWS Glue需要以下任务。AWS Glue 1. 提取和转换 CQL 数据并将其存储在 Amazon S3 存储桶中的 ETL 作业。 1. 第二个作业是将存储桶中的数据导入到 Amazon Keyspaces。 1. 第三个作业是导入增量数据。 **如何在亚马逊虚拟私有云中从 EC2 在亚马逊上运行的 Cassandra 离线迁移到亚马逊密钥空间** 1. 首先AWS Glue，您可以使用从 Cassandra 以 Parquet 格式导出表格数据，然后将其保存到 Amazon S3 存储桶中。您需要使用指向运行 Cassandra 的 Amazon EC2 实例所在的 VPC 的AWS Glue连接器来运行AWS Glue作业。然后，使用 Amazon S3 私有端点，您可以将数据保存到 Amazon S3 存储桶。 下图说明了这些步骤。 ![\[使用将 Apache Cassandra 数据从在 VPC 中 EC2 运行的亚马逊迁移到亚马逊 S3 存储桶。AWS Glue\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/migration-export.png) 1. 对 Amazon S3 存储桶中的数据进行随机排序，以改善数据随机掩码。均匀导入的数据允许在目标表中分配更多的流量。 从具有大型分区（超过 1000 行的分区）的 Cassandra 导出数据时需要执行此步骤，以避免在将数据插入到 Amazon Keyspaces 时出现热键模式。热键问题会导致 Amazon Keyspaces 中出现 `WriteThrottleEvents` 并导致加载时间延长。 ![\[AWS Glue任务将数据从 Amazon S3 存储桶中洗牌，然后将其返回到另一个 Amazon S3 存储桶中。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/migration-shuffle.png) 1. 使用其他AWS Glue任务将数据从 Amazon S3 存储桶导入到 Amazon Keyspaces。Amazon S3 存储桶中经过随机排序的数据以 Parquet 格式存储。 ![\[AWS Glue导入任务从 Amazon S3 存储桶中提取经过洗牌的数据并将其移动到 Amazon Keyspaces 表中。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/migration-import.png) 有关离线迁移过程的更多信息，请参阅 [Amazon Key](https://catalog.workshops.aws/unlocking-amazonkeyspaces/en-US/keyspaces-with-glue) spaces with 研讨会 AWS Glue # 使用混合迁移解决方案：Apache Cassandra 到 Amazon Keyspaces 以下迁移解决方案可以被视为在线和离线迁移的混合体。使用这种混合迁移方法，可以近乎实时地将数据写入目标数据库，而无需提供写后读一致性。这意味着新写入的数据不会立即可用，会出现延迟。如果您需要写后读一致性，请参阅[在线迁移到 Amazon Keyspaces：策略和最佳实践](migrating-online.md)。 要实现近乎实时地从 Apache Cassandra 迁移到 Amazon Keyspaces，您可以在两种可用方法之间进行选择。 + **CQLReplicator**—（推荐） CQLReplicator 是 [Github](https://github.com/aws-samples/cql-replicator) 上提供的开源实用程序，可帮助您近乎实时地将数据从 Apache Cassandra 迁移到 Amazon Keyspaces。 要确定要传播到目标数据库的写入和更新，请 CQLReplicator扫描 Apache Cassandra 令牌范围，然后使用AWS Glue任务删除重复的事件，并将写入和更新直接应用于 Amazon Keyspaces。 + **更改数据捕获（CDC）**- 如果您熟悉 Cassandra CDC，那么 Apache Cassandra 内置的 CDC 特征允许通过将提交日志复制到单独的 CDC 目录来捕获更改，这是实现混合迁移的另一种选择。 为此，您可以将数据更改复制到 Amazon Keyspaces，让 CDC 成为数据迁移场景的替代方案。 如果您不需要连续写入后读取，则可以根据您的偏好和对工具的熟悉程度使用 CQLReplicator 或 CDC 管道将数据从 Apache Cassandra 迁移到 Amazon Keyspaces，并在每种解决方案中使用。AWS 服务使用这些方法近乎实时地迁移数据可以被视为一种混合迁移方法，其提供了在线迁移的替代方案。 此策略被视为一种混合方法，因为除了本主题中概述的选项外，您还必须执行在线迁移进度中的某些步骤，例如[在线迁移](migrating-online.md)主题中讨论的历史数据复制和应用程序迁移策略。 以下各节更详细地说明了混合迁移选项。 **Topics** + [使用迁移数据 CQLReplicator](migration-hybrid-cql-rep.md) + [使用更改数据捕获（CDC）迁移数据](migration-hybrid-cdc.md) # 使用迁移数据 CQLReplicator 使用 [CQLReplicator](https://github.com/aws-samples/cql-replicator)，您可以使用 CQL 查询智能扫描 Cassandra 令牌环，近乎实时地从 Apache Cassandra 读取数据。 CQLReplicator 不使用 Cassandra CDC，而是实施缓存策略来减少完整扫描的性能损失。 要减少对目标的写入次数，请 CQLReplicator 自动删除重复的复制事件。使用 CQLReplicator，您可以调整从源数据库到目标数据库的更改复制，从而实现从 Apache Cassandra 到 Amazon Keyspaces 的近乎实时的数据迁移。 下图显示了使用的 CQLReplicator 作业的典型架构AWS Glue。 1. **要允许访问在私有 VPC 中运行的 Apache Cassandra，请将AWS Glue连接类型配置为网络。** 1. 要删除重复项并启用 CQLReplicator 任务的密钥缓存，请配置亚马逊简单存储服务 (Amazon S3) Service。 1. CQLReplicator 任务流经过验证的源数据库将直接更改为 Amazon Keyspaces。 ![\[CQLReplicator 用于将数据从 Apache Cassandra 迁移到 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/hybrid-migration-CQLRep.png) 有关使用迁移过程的更多信息 CQLReplicator，请参阅AWS数据库博客 “使用将 Cassandra 工作负载[迁移到 Amazon Keyspaces” 上的以下文章以及 CQLReplicatorAWS使用将 Apache Cassandra 工作负载迁移到 Amazon Keyspac](https://aws.amazon.com/blogs/database/migrate-cassandra-workloads-to-amazon-keyspaces-using-cqlreplicator/) [es 的规范性指南](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-apache-cassandra-workloads-to-amazon-keyspaces-using-aws-glue.html)。AWS Glue # 使用更改数据捕获（CDC）迁移数据 如果您已经熟悉如何使用 [Debezium](https://debezium.io/) 配置更改数据捕获 (CDC) 管道，则可以使用此选项将数据迁移到 Amazon Keyspaces，以此作为替代使用。 CQLReplicatorDebezium 是 CDC 的开源分布式平台，旨在监控数据库并可靠地捕获行级更改。 [Debezium Connector for Apache Cassandra](https://debezium.io/documentation/reference/stable/connectors/cassandra.html) 将更改上传到 Amazon Managed Streaming for Apache Kafka（Amazon MSK），以便下游使用者可以使用和处理这些更改，而下游使用者反过来又可以将数据写入 Amazon Keyspaces。有关更多信息，请参阅 [Guidance for continuous data migration from Apache Cassandra to Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/)。 要解决任何潜在的数据一致性问题，您可以使用 Amazon MSK 实施一个流程，使用者在该流程中将 Cassandra 中的键或分区与 Amazon Keyspaces 中的键或分区进行比较。 要成功实施此解决方案，我们建议考虑以下几点。 + 如何解析 CDC 提交日志，例如，如何删除重复的事件。 + 如何维护 CDC 目录，例如，如何删除旧日志。 + 如何处理 Apache Cassandra 中的部分故障，例如，如果三个副本中只有一个副本的写入操作成功。 + 如何处理资源分配，例如增加实例的大小，以满足节点上的 CDC 进程对额外的 CPU、内存、磁盘和 IO 的要求。 这种模式将来自 Cassandra 的更改视为“暗示”，即密钥相比之前的状态可能发生了变化。要确定是否有更改要传播到目标数据库，您必须首先使用 `LOCAL_QUORUM` 操作从源 Cassandra 集群读取最新记录，然后将其写入 Amazon Keyspaces。 如果是范围删除或范围更新，则可能需要对整个分区进行比较，以确定哪些写入或更新事件需要写入到目标数据库。 如果写入并非幂等性的，则在写入 Amazon Keyspaces 之前，您还需要将写入内容与目标数据库中已有的内容进行比较。 下图显示了使用 Debezium 和 Amazon MSK 的 CDC 管道的典型架构。 ![\[使用更改数据捕获管道将数据从 Apache Cassandra 迁移到 Amazon Keyspaces。\]](http://docs.aws.amazon.com/zh_cn/keyspaces/latest/devguide/images/migration/hybrid-migration-CDC.png) # 如何选择合适的工具将数据批量上传或迁移到 Amazon Keyspaces 在本节中，您可以查看可用于将数据批量上传或迁移到 Amazon Keyspaces 的各种工具，并了解如何根据需要选择合适的工具。此外，本节还概述了演示如何将数据导入 Amazon Keyspaces 的可用 step-by-step教程和使用案例。 要查看将工作负载从 Apache Cassandra 迁移到 Amazon Keyspaces 的可用策略，请参阅[创建从 Apache Cassandra 迁移到 Amazon Keyspaces 的迁移计划](migrating-cassandra.md)。 + **迁移工具** + 借助 Github 上提供的[亚马逊密钥空间（适用于 Apache Cassandra）的定价计算器](https://aws-samples.github.io/sample-pricing-calculator-for-keyspaces/#cassandra)，您可以根据现有的 Apache Cassandra 工作负载估算亚马逊密钥空间的每月费用。输入您的 Cassandra 节点工具状态输出和 Amazon Keyspaces 的预期无服务器配置中的指标，以比较两种解决方案之间的直接成本。请注意，此计算器仅关注与您的现有 Cassandra 部署相比 Amazon Keyspaces 的运营成本。它不包括总拥有成本 (TCO) 因素，例如基础架构维护、运营开销或Cassandra的支持成本。 + **用于亚马逊密钥空间迁移的 ZDM 双写代理** — Github [上](https://github.com/aws-samples/amazon-keyspaces-examples/blob/main/migration/online/zdm-proxy/README.md)提供的 ZDM 双写代理支持从 Apache Cassandra 到亚马逊密钥空间的零停机迁移。 + **CQLReplicator**— CQLReplicator 是 [Github](https://github.com/aws-samples/cql-replicator) 上提供的开源实用程序，可帮助您近乎实时地将数据从 Apache Cassandra 迁移到 Amazon Keyspaces。 有关更多信息，请参阅 [使用迁移数据 CQLReplicator](migration-hybrid-cql-rep.md)。 + 要详细了解如何使用 Amazon Managed Streaming for Apache Kafka 实现[在线迁移](migrating-online.md)过程及双重写入，请参阅 [Guidance for continuous data migration from Apache Cassandra to Amazon Keyspaces](https://aws.amazon.com/solutions/guidance/continuous-data-migration-from-apache-cassandra-to-amazon-keyspaces/)。 + 对于大型迁移，请考虑使用提取、转换、加载（ETL）工具。您可以使用 AWS Glue 来快速有效地执行数据转换迁移。有关更多信息，请参阅 [离线迁移过程：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。 + 要了解如何使用 Apache Cassandra Spark 连接器向 Amazon Keyspaces 写入数据，请参阅 [教程：与 Apache Spark 集成以导入或导出数据](spark-integrating.md)。 + 使用 cqlsh `COPY FROM` 命令快速开始将数据加载到 Amazon Keyspaces。cqlsh 包含在 Apache Cassandra 中，最适用于加载小型数据集或测试数据。有关 step-by-step说明，请参阅[教程：使用 cqlsh 将数据加载到 Amazon Keyspaces](bulk-upload.md)。 + 您也可以使用适用于 Apache Cassandra 的 DataStax 批量加载器使用命令将数据加载到 Amazon Keyspaces 中。`dsbulk` DSBulk[提供了比 cqlsh 更强大的导入功能，并且可从存储库中获取。GitHub ](https://github.com/datastax/dsbulk)有关 step-by-step说明，请参阅[教程：使用将数据加载到 Amazon Keyspaces DSBulk](dsbulk-upload.md)。 将数据上传到 Amazon Keyspaces 的一般注意事项 + **将数据上传分解为较小的组成部分。** 考虑以下迁移单位及其在原始数据大小方面的潜在占用空间。在一个或多个阶段上传少量数据可能有助于简化迁移。 + **按集群**：一次性迁移所有 Cassandra 数据。这种方法可能适用于较小的集群。 + **按键空间或表**：将迁移分解为键空间或表组。此方法可以帮助您根据每个工作负载的要求分阶段迁移数据。 + **按数据**：考虑迁移特定用户组或产品的数据，进一步减少数据大小。 + **根据简便性，首选确定要上传的数据的优先顺序。** 考虑一下您是否有可以首先且更轻松地迁移的数据，例如，在特定时间段内不会更改的数据、来自夜间批处理作业的数据、离线期间未使用的数据或来自内部应用程序的数据。 **Topics** + [教程：使用 cqlsh 将数据加载到 Amazon Keyspaces](bulk-upload.md) + [教程：使用将数据加载到 Amazon Keyspaces DSBulk](dsbulk-upload.md) # 教程：使用 cqlsh 将数据加载到 Amazon Keyspaces 本教程将指导您完成使用 `cqlsh COPY FROM` 命令将数据从 Apache Cassandra 迁移到 Amazon Keyspaces 的过程。`cqlsh COPY FROM` 命令对于出于学术或测试目的快速轻松地将小型数据集上传到 Amazon Keyspaces 而言非常有用。有关如何迁移生产工作负载的更多信息，请参阅[离线迁移过程：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。在本教程中，您将完成以下步骤： 先决条件-使用证书设置 AWS 账户，为证书创建 JKS 信任存储文件，然后配置为连接`cqlsh`到 Amazon Keyspaces。 1. **创建源 CSV 和目标表** - 准备一个 CSV 文件作为源数据，然后在 Amazon Keyspaces 中创建目标键空间和表。 1. **准备数据** - 随机采样 CSV 文件中的数据，并对其进行分析，以确定平均行大小和最大行大小。 1. **设置吞吐容量**-根据数据大小和所需的加载时间计算所需的写入容量单位 (WCUs)，并配置表的预配置容量。 1. **配置 cqlsh 参数** - 确定诸如 `INGESTRATE`、`NUMPROCESSES`、`MAXBATCHSIZE` 和 `CHUNKSIZE` 之类的 `cqlsh COPY FROM` 参数的最佳值，以均匀分配工作负载。 1. **运行 `cqlsh COPY FROM` 命令** - 运行 `cqlsh COPY FROM` 命令，将 CSV 文件中的数据上传到 Amazon Keyspaces 表，并监控进度。 疑难解答 - 解决数据上传过程中出现的常见问题，例如无效请求、解析器错误、容量错误和 cqlsh 错误。 **Topics** + [先决条件：在使用 `cqlsh COPY FROM` 上传数据之前需要完成的步骤](bulk-upload-prequs.md) + [第 1 步：为数据上传创建源 CSV 文件和目标表](bulk-upload-source.md) + [第 2 步：为成功上传数据做好源数据准备](bulk-upload-prepare-data.md) + [步骤 3：为表设置吞吐容量](bulk-upload-capacity.md) + [步骤 4：配置 `cqlsh COPY FROM` 设置](bulk-upload-config.md) + [第 5 步：运行 `cqlsh COPY FROM` 命令将 CSV 文件中的数据上传到目标表](bulk-upload-run.md) + [问题排查](bulk-upload-troubleshooting.md) # 先决条件：在使用 `cqlsh COPY FROM` 上传数据之前需要完成的步骤 在开始本教程之前，您必须完成以下任务： 1. 如果您还没有这样做，请 AWS 账户 按照中的步骤进行注册[设置 AWS Identity and Access Management](accessing.md#SettingUp.IAM)。 1. 按照[创建用于通过编程方式访问 Amazon Keyspaces 的服务特定凭证。](programmatic.credentials.ssc.md)中的步骤创建特定于服务的凭证。 1. 设置 Cassandra 查询语言 Shell (cqlsh) 连接，并按照[使用 `cqlsh` 连接 Amazon Keyspaces](programmatic.cqlsh.md) 中的步骤确认您可以连接到 Amazon Keyspaces。 # 第 1 步：为数据上传创建源 CSV 文件和目标表 在本教程中，我们使用名为 `keyspaces_sample_table.csv` 的逗号分隔值 (CSV) 文件作为用于数据迁移的源文件。提供的示例文件包含名为 `book_awards` 的表中的几行数据。 1. 创建源文件。您可以选择以下选项之一： + 下载以下存档文件 [samplemigration.zip](samples/samplemigration.zip) 中包含的示例 CSV 文件 (`keyspaces_sample_table.csv`)。解压缩存档文件并记下指向 `keyspaces_sample_table.csv` 的路径。 + 要使用您自己存储在 Apache Cassandra 数据库中的数据来填充 CSV 文件，您可以使用 `cqlsh` `COPY TO` 语句来填充源 CSV 文件，如以下示例所示。 ``` cqlsh localhost 9042 -u "username" -p "password" --execute "COPY mykeyspace.mytable TO 'keyspaces_sample_table.csv' WITH HEADER=true"; ``` 确保您创建的 CSV 文件符合以下要求： + 第一行包含列名称。 + 源 CSV 文件中的列名称与目标表中的列名称相匹配。 + 数据用逗号分隔。 + 所有数据值均为有效的 Amazon Keyspaces 数据类型。请参阅[数据类型](cql.elements.md#cql.data-types)。 1. 在 Amazon Keyspaces 中创建目标键空间和表。 1. 使用 `cqlsh` 连接到 Amazon Keyspaces，将以下示例中的服务端点、用户名和密码替换为您自己的值。 ``` cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl ``` 1. 使用名称 `catalog` 创建新的键空间，如以下示例所示。 ``` CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'}; ``` 1. 当新的键空间可用后，使用以下代码创建目标表 `book_awards`。 ``` CREATE TABLE "catalog.book_awards" ( year int, award text, rank int, category text, book_title text, author text, publisher text, PRIMARY KEY ((year, award), category, rank) ); ``` 如果 Apache Cassandra 是您的原始数据来源，那么创建带有匹配标题的 Amazon Keyspaces 目标表的一种简单方法是从源表生成 `CREATE TABLE` 语句，如以下语句所示。 ``` cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;" ``` 然后，在 Amazon Keyspaces 中创建目标表，其列名称和数据类型与 Cassandra 源表中的描述相匹配。 # 第 2 步：为成功上传数据做好源数据准备 为高效传输准备源数据的过程包含两个步骤。第一步，随机化数据。第二步，分析数据以确定相应的 `cqlsh` 参数值和所需的表设置，确保数据上传成功。 **随机化数据** `cqlsh COPY FROM` 命令按数据在 CSV 文件中显示的顺序读取和写入数据。如果使用 `cqlsh COPY TO` 命令创建源文件，将在 CSV 中按键排序顺序写入数据。Amazon Keyspaces 在内部使用分区键对数据进行分区。尽管 Amazon Keyspaces 具有内置逻辑来帮助对针对同一分区键的请求进行负载均衡，但如果您随机排列顺序，则可以更快、更高效地加载数据。这是因为您可以利用 Amazon Keyspaces 在写入不同分区时会出现的内置负载均衡功能。 要将写入操作均匀地分布在分区中，您必须随机化源文件中的数据。您可以编写一个应用程序来执行此操作，也可以使用开源工具来执行此操作，比如 [Shuf](https://en.wikipedia.org/wiki/Shuf)。Shuf 在 Linux 发行版、macOS（通过在 [Homebrew](https://brew.sh) 中安装 coreutils）和 Windows [通过使用 Windows Subsystem for Linux (WSL)] 上免费提供。您还需要执行一个额外步骤来防止包含列名称的标题行在此步骤中被随机排序。 要在保留标题的同时随机化源文件，请输入以下代码。 ``` tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv ``` Shuf 将数据重写到名为 `keyspace.table.csv` 的新 CSV 文件中。现在，您可以删除 `keyspaces_sample_table.csv` 文件，您不再需要此文件了。 **分析数据** 通过分析数据来确定平均行大小和最大行大小。 执行此操作出于以下原因： + 平均行大小有助于估算要传输的数据总量。 + 您需要平均行大小来预置上传数据所需的写入容量。 + 您可以确保每行的大小小于 1MB，这是 Amazon Keyspaces 中的最大行大小。 **注意** 此限额指的是行大小，而不是分区大小。与 Apache Cassandra 分区不同，Amazon Keyspaces 分区实际上可以不受大小限制。分区键和聚类列需要额外的元数据存储空间，您必须将其加到行的原始大小中。有关更多信息，请参阅 [估算 Amazon Keyspaces 中的行大小](calculating-row-size.md)。 以下代码使用 [AWK](https://en.wikipedia.org/wiki/AWK) 分析 CSV 文件并打印平均行大小和最大行大小。 ``` awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv ``` 运行此代码将生成以下输出。 ``` using 10,000 samples: {lines: 10000, avg: 123 bytes, max: 225 bytes} ``` 在本教程的下一步中，您将使用平均行大小来预置表的写入容量。 # 步骤 3：为表设置吞吐容量 本教程向您展示了如何调整 cqlsh 以在设定的时间范围内加载数据。由于您提前知道自己要执行多少读取和写入操作，因此可以使用预置容量模式。完成数据传输后，应该将表的容量模式设置为与应用程序的流量模式相匹配。要了解有关容量管理的更多信息，请参阅 [在 Amazon Keyspaces（Apache Cassandra 兼容）中管理无服务器资源](serverless_resource_management.md)。 使用预置容量模式，您可以提前指定要为表预置多少读取和写入容量。写入容量按小时计费，并以写入容量单位 () WCUs 计量。每个 WCU 的写入容量足以支持每秒写入 1KB 数据。加载数据时，写入速率必须低于目标表上设置的最大值 WCUs（参数:`write_capacity_units`）。 默认情况下，您最多可以为一个表预配置 40,000， WCUs 为账户中的 WCUs 所有表配置最多 80,000。如果您需要更多容量，可以在[服务限额](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas)控制台中请求提高限额。有关限额的更多信息，请参阅[Amazon Keyspaces（Apache Cassandra 兼容）限额](quotas.md)。 **计算刀片 WCUs 所需的平均数量** 每秒插入 1KB 数据需要 1 个 WCU。如果您的 CSV 文件有 360000 行，并且您想在 1 小时内加载所有数据，则必须每秒写入 100 行（360000 行/60 分/60 秒 = 每秒 100 行）。如果每行包含最多 1 KB 的数据，则要每秒插入 100 行，则必须为表预配置 100 WCUs 行。如果每行有 1.5 KB 的数据，则需要两行 WCUs 才能每秒插入一行。因此，要每秒插入 100 行，必须预置 200 行 WCUs。 要确定每秒需要插入多少 WCUs 行，请将平均行大小（以字节为单位）除以 1024，然后向上舍入到最接近的整数。 例如，如果平均行大小为 3000 字节，则需要三个字节 WCUs 才能每秒插入一行。 ``` ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs ``` **计算数据加载时间和容量** 既然您已经知道了 CSV 文件中的平均大小和行数，就可以计算出在给定时间内需要加载多少 WCUs 数据，以及使用不同的 WCU 设置在 CSV 文件中加载所有数据所花费的大致时间。 例如，如果文件中的每行为 1 KB，而 CSV 文件中有 1,000,000 行，则要在 1 小时内加载数据，则需要在该小时内为表预置至少 278 WCUs 行。 ``` 1,000,000 rows * 1 KBs = 1,000,000 KBs 1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs ``` **配置预置容量设置** 您可以在创建表时或使用 `ALTER TABLE` CQL 命令来设置表的写入容量设置。以下是使用 `ALTER TABLE` CQL 语句来更改表的预置容量设置的语法。 ``` ALTER TABLE mykeyspace.mytable WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ; ``` 有关完整的语言参考，请参阅 [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)。 # 步骤 4：配置 `cqlsh COPY FROM` 设置 本部分概述如何确定 `cqlsh COPY FROM` 的参数值。`cqlsh COPY FROM` 命令读取您之前准备的 CSV 文件，并使用 CQL 将数据插入到 Amazon Keyspaces 中。该命令将行分开，并将 `INSERT` 操作分配给一组 Worker。每个 Worker 与 Amazon Keyspaces 建立连接并通过该通道发送 `INSERT` 请求。 `cqlsh COPY` 命令没有在 Worker 之间均匀分配工作的内部逻辑。但是，您可以手动对其进行配置，以确保均匀分配工作。首先查看以下关键的 cqlsh 参数： + **DELIMITER**：如果您使用逗号以外的分隔符，则可以设置此参数，此参数默认为逗号。 + **INGESTRATE**：`cqlsh COPY FROM` 每秒尝试处理的目标行数。如果未设置，则默认为 100000。 + **NUMPROCESSES**：cqlsh 为 `COPY FROM` 任务创建的子 Worker 进程的数量。此设置的最大值为 16，默认值为 `num_cores - 1`，其中 `num_cores` 是运行 cqlsh 的主机上的处理内核数。 + **MAXBATCHSIZE**：批次大小决定了在单个批次中插入到目标表中的最大行数。如果未设置，cqlsh 将使用插入 20 行的批次。 + **CHUNKSIZE**：传递给子 Worker 的工作单元的大小。默认情况下，它设置为 5000。 + **MAXATTEMPTS**：重试失败 Worker 块的最大次数。达到最大尝试次数后，失败记录将写入一个新的 CSV 文件中，您可以在调查失败后再次运行该文件。 `INGESTRATE`根据您配置到目标目标表 WCUs 的数量进行设置。`cqlsh COPY FROM` 命令的 `INGESTRATE` 不是限制，而是目标平均值。这意味着它可以（并且经常）突破您设定的数字。要允许暴增并确保有足够的容量来处理数据加载请求，请将 `INGESTRATE` 设置为表写入容量的 90%。 ``` INGESTRATE = WCUs * .90 ``` 接下来，将 `NUMPROCESSES` 参数设置为比系统上的内核数少一个。要弄清楚系统的内核数，您可以运行以下代码。 ``` python -c "import multiprocessing; print(multiprocessing.cpu_count())" ``` 在本教程中，我们使用以下值。 ``` NUMPROCESSES = 4 ``` 每个进程都会创建一个 Worker，并且每个 Worker 都会与 Amazon Keyspaces 建立连接。Amazon Keyspaces 在每个连接上每秒可支持最多 3000 个 CQL 请求。这意味着您必须确保每个 Worker 每秒处理的请求少于 3000 个。 与 `INGESTRATE` 一样，Worker 经常会突破您设置的数字，并且不受时钟秒数的限制。因此，考虑到暴增，请将 cqlsh 参数设置为每个 Worker 每秒处理 2500 个请求。要计算分配给 Worker 的工作量，请使用以下准则。 + `INGESTRATE` 除以 `NUMPROCESSES`。 + 如果 `INGESTRATE`/`NUMPROCESSES` > 2500，请降低 `INGESTRATE` 以使此公式成立。 ``` INGESTRATE / NUMPROCESSES <= 2,500 ``` 在配置设置以优化示例数据的上传之前，让我们回顾一下 `cqlsh` 默认设置，看看使用它们会如何影响数据上传过程。由于 `cqlsh COPY FROM` 使用 `CHUNKSIZE` 创建工作块（`INSERT` 语句）以分配给 Worker，因此工作不会自动均匀分配。根据 `INGESTRATE` 设置，有些 Worker 可能会处于闲置状态。 要在 Worker 之间均匀分配工作并使每个 Worker 保持每秒 2500 个请求的最佳速率，必须通过更改输入参数来设置 `CHUNKSIZE`、`MAXBATCHSIZE`、和 `INGESTRATE`。要优化数据加载期间的网络流量利用率，请为 `MAXBATCHSIZE` 选择一个接近最大值 30 的值。通过将 `CHUNKSIZE` 更改为 100，将 `MAXBATCHSIZE` 更改为 25，10000 行将均匀分配给四个 Worker（10000/2500 = 4）。 以下代码示例说明了如何执行此操作。 ``` INGESTRATE = 10,000 NUMPROCESSES = 4 CHUNKSIZE = 100 MAXBATCHSIZE. = 25 Work Distribution: Connection 1 / Worker 1 : 2,500 Requests per second Connection 2 / Worker 2 : 2,500 Requests per second Connection 3 / Worker 3 : 2,500 Requests per second Connection 4 / Worker 4 : 2,500 Requests per second ``` 总而言之，在设置 `cqlsh COPY FROM` 参数时使用以下公式： + **INGESTRATE** = 写入容量单位 \$1 0.90 + **NUMPROCESSES** = 内核数 - 1（默认设置） + **INGESTRATE/NUMPROCESSES** = 2500（这必须是一个真语句。） + **MAXBATCHSIZE** = 30（默认为 20。Amazon Keyspaces 最多可接受 30 个批次。） + **CHUNKSIZE** = (INGESTRATE/NUMPROCESSES)/MAXBATCHSIZE 现在您已经计算了 `NUMPROCESSES`、`INGESTRATE` 和 `CHUNKSIZE`，接下来可以加载数据。 # 第 5 步：运行 `cqlsh COPY FROM` 命令将 CSV 文件中的数据上传到目标表 要运行 `cqlsh COPY FROM` 命令，请完成以下步骤。 1. 使用 cqlsh 连接到 Amazon Keyspaces。 1. 使用以下代码选择键空间。 ``` USE catalog; ``` 1. 将写入一致性设置为 `LOCAL_QUORUM`。为了确保数据的持久性，Amazon Keyspaces 不允许使用其他写入一致性设置。查看以下代码。 ``` CONSISTENCY LOCAL_QUORUM; ``` 1. 使用以下代码示例准备 `cqlsh COPY FROM` 语法。 ``` COPY book_awards FROM './keyspace.table.csv' WITH HEADER=true AND INGESTRATE=calculated ingestrate AND NUMPROCESSES=calculated numprocess AND MAXBATCHSIZE=20 AND CHUNKSIZE=calculated chunksize; ``` 1. 运行上一步中准备的语句。cqlsh 会回显您配置的所有设置。 1. 确保设置与您的输入相匹配。请参阅以下示例。 ``` Reading options from the command line: {'chunksize': '120', 'header': 'true', 'ingestrate': '36000', 'numprocesses': '15', 'maxbatchsize': '20'} Using 15 child processes ``` 1. 查看传输的行数和当前的平均速率，如以下示例所示。 ``` Processed: 57834 rows; Rate: 6561 rows/s; Avg. rate: 31751 rows/s ``` 1. 当 cqlsh 完成数据上传后，查看数据加载统计信息（读取的文件数、运行时和跳过的行数）的摘要，如以下示例所示。 ``` 15556824 rows imported from 1 files in 8 minutes and 8.321 seconds (0 skipped). ``` 在本教程的最后一步中，您已将数据上传到 Amazon Keyspaces。 **重要** 现在您已经传输了数据，接下来调整目标表的容量模式设置，使其与应用程序的常规流量模式相匹配。在更改之前，您的预置容量按小时费率收费。 # 问题排查 数据上传完成后，检查是否跳过了行。为此，请导航到源 CSV 文件的源目录并搜索具有以下名称的文件。 ``` import_yourcsvfilename.err.timestamp.csv ``` cqlsh 将所有跳过的数据行写入具有该名称的文件中。如果文件存在于源目录中且其中包含数据，则说明这些行未上传到 Amazon Keyspaces。要重试这些行，请先检查上传过程中是否遇到任何错误，然后相应地调整数据。要重试这些行，您可以重新运行进程。 **常见错误** 行未加载的最常见原因是容量错误和解析错误。 **将数据上传到 Amazon Keyspaces 时出现无效请求错误** 在以下示例中，源表包含一个计数器列，该列会生成来自 cqlsh `COPY` 命令的记录的批处理调用。Amazon Keyspaces 不支持记录的批处理调用。 ``` Failed to import 10 rows: InvalidRequest - Error from server: code=2200 [Invalid query] message=“Only UNLOGGED Batches are supported at this time.“, will retry later, attempt 22 of 25 ``` 要解决此错误， DSBulk 请使用迁移数据。有关更多信息，请参阅 [教程：使用将数据加载到 Amazon Keyspaces DSBulk](dsbulk-upload.md)。 **将数据上传到 Amazon Keyspaces 时出现解析器错误** 以下示例显示了由于 `ParseError` 而跳过的行。 ``` Failed to import 1 rows: ParseError - Invalid ... – ``` 要解决此错误，您需要确保要导入的数据与 Amazon Keyspaces 中的表模式相匹配。查看导入文件中是否存在解析错误。您可以尝试通过 `INSERT` 语句来使用单行数据，从而隔离错误。 **将数据上传到 Amazon Keyspaces 时出现容量错误** ``` Failed to import 1 rows: WriteTimeout - Error from server: code=1100 [Coordinator node timed out waiting for replica nodes' responses] message="Operation timed out - received only 0 responses." info={'received_responses': 0, 'required_responses': 2, 'write_type': 'SIMPLE', 'consistency': 'LOCAL_QUORUM'}, will retry later, attempt 1 of 100 ``` Amazon Keyspaces 使用 `ReadTimeout` 和 `WriteTimeout` 异常指示写入请求何时因吞吐容量不足而失败。为了帮助诊断容量不足的异常，Amazon Keyspaces 在亚马逊上发布了`WriteThrottleEvents``ReadThrottledEvents`指标。 CloudWatch有关更多信息，请参阅 [使用亚马逊监控亚马逊密钥空间 CloudWatch](monitoring-cloudwatch.md)。 **将数据上传到 Amazon Keyspaces 时出现 cqlsh 错误** 要帮助对 cqlsh 错误进行问题排查，请重新运行带有 `--debug` 标志的失败命令。 使用不兼容的 cqlsh 版本时，您会看到以下错误。 ``` AttributeError: 'NoneType' object has no attribute 'is_up' Failed to import 3 rows: AttributeError - 'NoneType' object has no attribute 'is_up', given up after 1 attempts ``` 通过运行以下命令确认已安装正确版本的 cqlsh。 ``` cqlsh --version ``` 输出应该类似于以下内容。 ``` cqlsh 5.0.1 ``` 如果您使用的是 Windows，请将 `cqlsh` 的所有实例替换为 `cqlsh.bat`。例如，要检查 Windows 中的 cqlsh 版本，请运行以下命令。 ``` cqlsh.bat --version ``` cqlsh 客户端从服务器连续收到三个任意类型的错误后，与 Amazon Keyspaces 的连接失败。cqlsh 客户端失败时显示以下消息。 ``` Failed to import 1 rows: NoHostAvailable - , will retry later, attempt 3 of 100 ``` 要解决此错误，您需要确保要导入的数据与 Amazon Keyspaces 中的表模式相匹配。查看导入文件中是否存在解析错误。您可以尝试通过 INSERT 语句来使用单行数据，从而隔离错误。 客户端会自动尝试重新建立连接。 # 教程：使用将数据加载到 Amazon Keyspaces DSBulk 本 step-by-step教程将指导您使用上提供的 DataStax 批量加载器 () DSBulk 将数据从 Apache Cassandra 迁移到 Amazon Keyspaces。[GitHub](https://github.com/datastax/dsbulk.git)用于 DSBulk 将数据集上传到 Amazon Keyspaces 用于学术或考试目的非常有用。有关如何迁移生产工作负载的更多信息，请参阅[离线迁移过程：Apache Cassandra 到 Amazon Keyspaces](migrating-offline.md)。在本教程中，您将完成以下步骤。 先决条件-使用凭据设置 AWS 帐户，为证书创建 JKS 信任存储文件，配置`cqlsh`、下载和安装 DSBulk以及配置`application.conf`文件。 1. **创建源 CSV 和目标表** - 准备一个 CSV 文件作为源数据，然后在 Amazon Keyspaces 中创建目标键空间和表。 1. **准备数据** - 随机采样 CSV 文件中的数据，并对其进行分析，以确定平均行大小和最大行大小。 1. **设置吞吐容量**-根据数据大小和所需的加载时间计算所需的写入容量单位 (WCUs)，并配置表的预配置容量。 1. **配置 DSBulk 设置**-使用身份验证、SSL/TLS、一致性级别和连接池大小等设置创建 DSBulk 配置文件。 1. **运行 DSBulk 加载命令 — 运行加载命令**将数据从 CSV 文件上传到 Amazon Keyspaces 表，并监控进度。 DSBulk **Topics** + [先决条件：在上传数据之前必须完成的步骤 DSBulk](dsbulk-upload-prequs.md) + [步骤 1：使用创建源 CSV 文件和用于上传数据的目标表 DSBulk](dsbulk-upload-source.md) + [第 2 步：使用准备要上传的数据 DSBulk](dsbulk-upload-prepare-data.md) + [第 3 步：为目标表设置吞吐能力](dsbulk-upload-capacity.md) + [第 4 步：配置 `DSBulk` 设置，以将 CSV 文件中的数据上传到目标表](dsbulk-upload-config.md) + [第 5 步：运行 DSBulk `load` 命令将 CSV 文件中的数据上传到目标表](dsbulk-upload-run.md) # 先决条件：在上传数据之前必须完成的步骤 DSBulk 在开始本教程之前，您必须完成以下任务： 1. 如果您还没有这样做，请按照中的步骤注册一个 AWS 帐户[设置 AWS Identity and Access Management](accessing.md#SettingUp.IAM)。 1. 按照[为 Amazon Keyspaces 创建和配置 AWS 证书](access.credentials.md)中的步骤创建凭证。 1. 创建 JKS 信任存储文件。 1. 下载以下数字证书并将文件保存在本地或您的主目录中。 1. AmazonRootCA1 1. AmazonRootCA2 1. AmazonRootCA3 1. AmazonRootCA4 1. Starfield Class 2 Root（可选 — 为了向后兼容） 要下载证书，您可以使用以下命令。 ``` curl -O https://www.amazontrust.com/repository/AmazonRootCA1.pem curl -O https://www.amazontrust.com/repository/AmazonRootCA2.pem curl -O https://www.amazontrust.com/repository/AmazonRootCA3.pem curl -O https://www.amazontrust.com/repository/AmazonRootCA4.pem curl -O https://certs.secureserver.net/repository/sf-class2-root.crt ``` **注意** Amazon Keyspaces 之前使用锚定在 Starfield Class 2 CA 上的 TLS 证书。 AWS 正在将所有证书全部迁移 AWS 区域 到根据亚马逊信任服务（Amazon Root CAs 1—4）颁发的证书。在此过渡期间，将客户端配置为同时信任 Amazon Root CAs 1—4 和 Starfield 根，以确保所有区域之间的兼容性。 1. 将数字证书转换为 TrustStore 文件并将其添加到密钥库中。 ``` openssl x509 -outform der -in AmazonRootCA1.pem -out temp_file.der keytool -import -alias amazon-root-ca-1 -keystore cassandra_truststore.jks -file temp_file.der openssl x509 -outform der -in AmazonRootCA2.pem -out temp_file.der keytool -import -alias amazon-root-ca-2 -keystore cassandra_truststore.jks -file temp_file.der openssl x509 -outform der -in AmazonRootCA3.pem -out temp_file.der keytool -import -alias amazon-root-ca-3 -keystore cassandra_truststore.jks -file temp_file.der openssl x509 -outform der -in AmazonRootCA4.pem -out temp_file.der keytool -import -alias amazon-root-ca-4 -keystore cassandra_truststore.jks -file temp_file.der openssl x509 -outform der -in sf-class2-root.crt -out temp_file.der keytool -import -alias cassandra -keystore cassandra_truststore.jks -file temp_file.der ``` 在最后一步中，您需要为密钥库创建密码并信任每个证书。交互式命令如下所示。 ``` Enter keystore password: Re-enter new password: Owner: CN=Amazon Root CA 1, O=Amazon, C=US Issuer: CN=Amazon Root CA 1, O=Amazon, C=US Serial number: 66c9fcf99bf8c0a39e2f0788a43e696365bca Valid from: Tue May 26 00:00:00 UTC 2015 until: Sun Jan 17 00:00:00 UTC 2038 Certificate fingerprints: SHA1: 8D:A7:F9:65:EC:5E:FC:37:91:0F:1C:6E:59:FD:C1:CC:6A:6E:DE:16 SHA256: 8E:CD:E6:88:4F:3D:87:B1:12:5B:A3:1A:C3:FC:B1:3D:70:16:DE:7F:57:CC:90:4F:E1:CB:97:C6:AE:98:19:6E Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 84 18 CC 85 34 EC BC 0C 94 94 2E 08 59 9C C7 B2 ....4.......Y... 0010: 10 4E 0A 08 .N.. ] ] Trust this certificate? [no]: yes Certificate was added to keystore Enter keystore password: Owner: CN=Amazon Root CA 2, O=Amazon, C=US Issuer: CN=Amazon Root CA 2, O=Amazon, C=US Serial number: 66c9fd29635869f0a0fe58678f85b26bb8a37 Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040 Certificate fingerprints: SHA1: 5A:8C:EF:45:D7:A6:98:59:76:7A:8C:8B:44:96:B5:78:CF:47:4B:1A SHA256: 1B:A5:B2:AA:8C:65:40:1A:82:96:01:18:F8:0B:EC:4F:62:30:4D:83:CE:C4:71:3A:19:C3:9C:01:1E:A4:6D:B4 Signature algorithm name: SHA384withRSA Subject Public Key Algorithm: 4096-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: B0 0C F0 4C 30 F4 05 58 02 48 FD 33 E5 52 AF 4B ...L0..X.H.3.R.K 0010: 84 E3 66 52 ..fR ] ] Trust this certificate? [no]: yes Certificate was added to keystore Enter keystore password: Owner: CN=Amazon Root CA 3, O=Amazon, C=US Issuer: CN=Amazon Root CA 3, O=Amazon, C=US Serial number: 66c9fd5749736663f3b0b9ad9e89e7603f24a Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040 Certificate fingerprints: SHA1: 0D:44:DD:8C:3C:8C:1A:1A:58:75:64:81:E9:0F:2E:2A:FF:B3:D2:6E SHA256: 18:CE:6C:FE:7B:F1:4E:60:B2:E3:47:B8:DF:E8:68:CB:31:D0:2E:BB:3A:DA:27:15:69:F5:03:43:B4:6D:B3:A4 Signature algorithm name: SHA256withECDSA Subject Public Key Algorithm: 256-bit EC (secp256r1) key Version: 3 Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: AB B6 DB D7 06 9E 37 AC 30 86 07 91 70 C7 9C C4 ......7.0...p... 0010: 19 B1 78 C0 ..x. ] ] Trust this certificate? [no]: yes Certificate was added to keystore Enter keystore password: Owner: CN=Amazon Root CA 4, O=Amazon, C=US Issuer: CN=Amazon Root CA 4, O=Amazon, C=US Serial number: 66c9fd7c1bb104c2943e5717b7b2cc81ac10e Valid from: Tue May 26 00:00:00 UTC 2015 until: Sat May 26 00:00:00 UTC 2040 Certificate fingerprints: SHA1: F6:10:84:07:D6:F8:BB:67:98:0C:C2:E2:44:C2:EB:AE:1C:EF:63:BE SHA256: E3:5D:28:41:9E:D0:20:25:CF:A6:90:38:CD:62:39:62:45:8D:A5:C6:95:FB:DE:A3:C2:2B:0B:FB:25:89:70:92 Signature algorithm name: SHA384withECDSA Subject Public Key Algorithm: 384-bit EC (secp384r1) key Version: 3 Extensions: #1: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:2147483647 ] #2: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: D3 EC C7 3A 65 6E CC E1 DA 76 9A 56 FB 9C F3 86 ...:en...v.V.... 0010: 6D 57 E5 81 mW.. ] ] Trust this certificate? [no]: yes Certificate was added to keystore Enter keystore password: Owner: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US Issuer: OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US Serial number: 0 Valid from: Tue Jun 29 17:39:16 UTC 2004 until: Thu Jun 29 17:39:16 UTC 2034 Certificate fingerprints: SHA1: AD:7E:1C:28:B0:64:EF:8F:60:03:40:20:14:C3:D0:E3:37:0E:B5:8A SHA256: 14:65:FA:20:53:97:B8:76:FA:A6:F0:A9:95:8E:55:90:E4:0F:CC:7F:AA:4F:B7:C2:C8:67:75:21:FB:5F:B6:58 Signature algorithm name: SHA1withRSA (weak) Subject Public Key Algorithm: 2048-bit RSA key Version: 3 Extensions: #1: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U..... 0010: 0E A9 88 E7 .... ] [OU=Starfield Class 2 Certification Authority, O="Starfield Technologies, Inc.", C=US] SerialNumber: [ 00] ] #2: ObjectId: 2.5.29.19 Criticality=false BasicConstraints:[ CA:true PathLen:2147483647 ] #3: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: BF 5F B7 D1 CE DD 1F 86 F4 5B 55 AC DC D7 10 C2 ._.......[U..... 0010: 0E A9 88 E7 .... ] ] Warning: The input uses the SHA1withRSA signature algorithm which is considered a security risk. This algorithm will be disabled in a future update. Trust this certificate? [no]: yes Certificate was added to keystore ``` 1. 设置 Cassandra 查询语言 Shell (cqlsh) 连接，并按照[使用 `cqlsh` 连接 Amazon Keyspaces](programmatic.cqlsh.md) 中的步骤确认您可以连接到 Amazon Keyspaces。 1. 下载并安装 DSBulk。 **注意** 本教程中显示的版本可能不是可用的最新版本。下载之前 DSBulk，请查看 B [DataStax ulk Loader 下载页面](https://downloads.datastax.com/#bulk-loader)以获取最新版本，并相应地更新以下命令中的版本号。 1. 要下载 DSBulk，您可以使用以下代码。 ``` curl -OL https://downloads.datastax.com/dsbulk/dsbulk-1.8.0.tar.gz ``` 1. 然后解压 tar 文件并将其 DSBulk 添加到您的文件中`PATH`，如以下示例所示。 ``` tar -zxvf dsbulk-1.8.0.tar.gz # add the DSBulk directory to the path export PATH=$PATH:./dsbulk-1.8.0/bin ``` 1. 创建一个`application.conf`文件来存储要使用的设置 DSBulk。您可以将以下示例保存为 `./dsbulk_keyspaces.conf`。如果您不在本地节点上，请将 `localhost` 替换为本地 Cassandra 集群的联系点，例如 DNS 名称或 IP 地址。记下文件名和路径，因为稍后您需要在 `dsbulk load` 命令中指定这些内容。 ``` datastax-java-driver { basic.contact-points = [ "localhost"] advanced.auth-provider { class = software.aws.mcs.auth.SigV4AuthProvider aws-region = us-east-1 } } ``` 1. 要启用 SigV4 支持，请从下载阴影`jar`文件[GitHub](https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/)并将其放在 DSBulk `lib`文件夹中，如以下示例所示。 ``` curl -O -L https://github.com/aws/aws-sigv4-auth-cassandra-java-driver-plugin/releases/download/4.0.6-shaded-v2/aws-sigv4-auth-cassandra-java-driver-plugin-4.0.6-shaded.jar ``` # 步骤 1：使用创建源 CSV 文件和用于上传数据的目标表 DSBulk 在本教程中，我们使用名为 `keyspaces_sample_table.csv` 的逗号分隔值 (CSV) 文件作为用于数据迁移的源文件。提供的示例文件包含名为 `book_awards` 的表中的几行数据。 1. 创建源文件。您可以选择以下选项之一： + 下载以下存档文件 [samplemigration.zip](samples/samplemigration.zip) 中包含的示例 CSV 文件 (`keyspaces_sample_table.csv`)。解压缩存档文件并记下指向 `keyspaces_sample_table.csv` 的路径。 + 要使用您自己存储在 Apache Cassandra 数据库中的数据来填充 CSV 文件，您可以使用 `dsbulk unload` 来填充源 CSV 文件，如下例所示。 ``` dsbulk unload -k mykeyspace -t mytable -f ./my_application.conf > keyspaces_sample_table.csv ``` 确保您创建的 CSV 文件符合以下要求： + 第一行包含列名称。 + 源 CSV 文件中的列名称与目标表中的列名称相匹配。 + 数据用逗号分隔。 + 所有数据值均为有效的 Amazon Keyspaces 数据类型。请参阅[数据类型](cql.elements.md#cql.data-types)。 1. 在 Amazon Keyspaces 中创建目标键空间和表。 1. 使用 `cqlsh` 连接到 Amazon Keyspaces，将以下示例中的服务端点、用户名和密码替换为您自己的值。 ``` cqlsh cassandra.us-east-1.amazonaws.com 9142 -u "111122223333" -p "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY" --ssl ``` 1. 使用以下示例中所示的名称 `catalog` 创建新的键空间。 ``` CREATE KEYSPACE catalog WITH REPLICATION = {'class': 'SingleRegionStrategy'}; ``` 1. 在新键空间变为可用状态后，使用以下代码创建目标表 `book_awards`。要了解有关异步资源创建以及如何检查资源是否可用的更多信息，请参阅[在 Amazon Keyspaces 中查看键空间的创建状态](keyspaces-create.md)。 ``` CREATE TABLE catalog.book_awards ( year int, award text, rank int, category text, book_title text, author text, publisher text, PRIMARY KEY ((year, award), category, rank) ); ``` 如果 Apache Cassandra 是您的原始数据来源，那么创建带有匹配标题的 Amazon Keyspaces 目标表的一种简单方法是从源表生成 `CREATE TABLE` 语句，如以下语句所示。 ``` cqlsh localhost 9042 -u "username" -p "password" --execute "DESCRIBE TABLE mykeyspace.mytable;" ``` 然后，在 Amazon Keyspaces 中创建目标表，其列名称和数据类型与 Cassandra 源表中的描述相匹配。 # 第 2 步：使用准备要上传的数据 DSBulk 为高效传输准备源数据的过程包含两个步骤。第一步，随机化数据。第二步，分析数据以确定相应的 `dsbulk` 参数值和所需的表设置。 **随机化数据** `dsbulk` 命令按数据在 CSV 文件中显示的顺序读取和写入数据。如果使用 `dsbulk` 命令创建源文件，将在 CSV 中按键排序顺序写入数据。Amazon Keyspaces 在内部使用分区键对数据进行分区。尽管 Amazon Keyspaces 具有内置逻辑来帮助对针对同一分区键的请求进行负载均衡，但如果您随机排列顺序，则可以更快、更高效地加载数据。这是因为您可以利用 Amazon Keyspaces 在写入不同分区时会出现的内置负载均衡功能。 要将写入操作均匀地分布在分区中，您必须随机化源文件中的数据。您可以编写一个应用程序来执行此操作，也可以使用开源工具来执行此操作，比如 [Shuf](https://en.wikipedia.org/wiki/Shuf)。Shuf 在 Linux 发行版、macOS（通过在 [Homebrew](https://brew.sh) 中安装 coreutils）和 Windows [通过使用 Windows Subsystem for Linux (WSL)] 上免费提供。您还需要执行一个额外步骤来防止包含列名称的标题行在此步骤中被随机排序。 要在保留标题的同时随机化源文件，请输入以下代码。 ``` tail -n +2 keyspaces_sample_table.csv | shuf -o keyspace.table.csv && (head -1 keyspaces_sample_table.csv && cat keyspace.table.csv ) > keyspace.table.csv1 && mv keyspace.table.csv1 keyspace.table.csv ``` Shuf 将数据重写到名为 `keyspace.table.csv` 的新 CSV 文件中。现在，您可以删除 `keyspaces_sample_table.csv` 文件，您不再需要此文件了。 **分析数据** 通过分析数据来确定平均行大小和最大行大小。 执行此操作出于以下原因： + 平均行大小有助于估算要传输的数据总量。 + 您需要平均行大小来预置上传数据所需的写入容量。 + 您可以确保每行的大小小于 1MB，这是 Amazon Keyspaces 中的最大行大小。 **注意** 此限额指的是行大小，而不是分区大小。与 Apache Cassandra 分区不同，Amazon Keyspaces 分区实际上可以不受大小限制。分区键和聚类列需要额外的元数据存储空间，您必须将其加到行的原始大小中。有关更多信息，请参阅 [估算 Amazon Keyspaces 中的行大小](calculating-row-size.md)。 以下代码使用 [AWK](https://en.wikipedia.org/wiki/AWK) 分析 CSV 文件并打印平均行大小和最大行大小。 ``` awk -F, 'BEGIN {samp=10000;max=-1;}{if(NR>1){len=length($0);t+=len;avg=t/NR;max=(len>max ? len : max)}}NR==samp{exit}END{printf("{lines: %d, average: %d bytes, max: %d bytes}\n",NR,avg,max);}' keyspace.table.csv ``` 运行此代码将生成以下输出。 ``` using 10,000 samples: {lines: 10000, avg: 123 bytes, max: 225 bytes} ``` 确保最大行大小不超过 1MB。否则，必须拆分行或压缩数据，使行大小小于 1MB。在本教程的下一步中，您将使用平均行大小来预置表的写入容量。 # 第 3 步：为目标表设置吞吐能力 本教程向您展示如何调整 DSBulk 以在设定的时间范围内加载数据。由于您提前知道自己要执行多少读取和写入操作，因此可以使用预置容量模式。完成数据传输后，应该将表的容量模式设置为与应用程序的流量模式相匹配。要了解有关容量管理的更多信息，请参阅 [在 Amazon Keyspaces（Apache Cassandra 兼容）中管理无服务器资源](serverless_resource_management.md)。 使用预置容量模式，您可以提前指定要为表预置多少读取和写入容量。写入容量按小时计费，并以写入容量单位 () WCUs 计量。每个 WCU 的写入容量足以支持每秒写入 1KB 数据。加载数据时，写入速率必须低于目标表上设置的最大值 WCUs（参数:`write_capacity_units`）。 默认情况下，您最多可以为一个表预配置 40,000， WCUs 为账户中的 WCUs 所有表配置最多 80,000。如果您需要更多容量，可以在[服务限额](https://console.aws.amazon.com/servicequotas/home#!/services/cassandra/quotas)控制台中请求提高限额。有关限额的更多信息，请参阅[Amazon Keyspaces（Apache Cassandra 兼容）限额](quotas.md)。 **计算刀片 WCUs 所需的平均数量** 每秒插入 1KB 数据需要 1 个 WCU。如果您的 CSV 文件有 360000 行，并且您想在 1 小时内加载所有数据，则必须每秒写入 100 行（360000 行/60 分/60 秒 = 每秒 100 行）。如果每行包含最多 1 KB 的数据，则要每秒插入 100 行，则必须为表预配置 100 WCUs 行。如果每行有 1.5 KB 的数据，则需要两行 WCUs 才能每秒插入一行。因此，要每秒插入 100 行，必须预置 200 行 WCUs。 要确定每秒需要插入多少 WCUs 行，请将平均行大小（以字节为单位）除以 1024，然后向上舍入到最接近的整数。 例如，如果平均行大小为 3000 字节，则需要三个字节 WCUs 才能每秒插入一行。 ``` ROUNDUP(3000 / 1024) = ROUNDUP(2.93) = 3 WCUs ``` **计算数据加载时间和容量** 既然您已经知道了 CSV 文件中的平均大小和行数，就可以计算出在给定时间内需要加载多少 WCUs 数据，以及使用不同的 WCU 设置在 CSV 文件中加载所有数据所花费的大致时间。 例如，如果文件中的每行为 1 KB，而 CSV 文件中有 1,000,000 行，则要在 1 小时内加载数据，则需要在该小时内为表预置至少 278 WCUs 行。 ``` 1,000,000 rows * 1 KBs = 1,000,000 KBs 1,000,000 KBs / 3600 seconds =277.8 KBs / second = 278 WCUs ``` **配置预置容量设置** 您可以在创建表时或使用 `ALTER TABLE` 命令来设置表的写入容量设置。以下是使用 `ALTER TABLE` 命令来更改表的预置容量设置的语法。 ``` ALTER TABLE catalog.book_awards WITH custom_properties={'capacity_mode':{'throughput_mode': 'PROVISIONED', 'read_capacity_units': 100, 'write_capacity_units': 278}} ; ``` 有关完整的语言参考，请参阅 [CREATE TABLE](cql.ddl.table.md#cql.ddl.table.create) 和 [ALTER TABLE](cql.ddl.table.md#cql.ddl.table.alter)。 # 第 4 步：配置 `DSBulk` 设置，以将 CSV 文件中的数据上传到目标表 本节概述了配置 DSBulk 将数据上传到 Amazon Keyspaces 所需的步骤。您可以使用配置文件 DSBulk 进行配置。您可以直接从命令行指定配置文件。 1. 创建用于迁移到 Amazon Keyspaces 的 DSBulk 配置文件，在本示例中，我们使用文件名。`dsbulk_keyspaces.conf`在 DSBulk 配置文件中指定以下设置。 1. *`PlainTextAuthProvider`*：使用 `PlainTextAuthProvider` 类创建身份验证提供者。`ServiceUserName` 和 `ServicePassword` 应该与您按照[创建用于通过编程方式访问 Amazon Keyspaces 的凭证。](programmatic.credentials.md)中的步骤生成特定于服务的凭证时获得的用户名和密码相匹配。 1. *`local-datacenter`*— 将的值设置 AWS 区域 为`local-datacenter`要连接的。例如，如果应用程序要连接到 `cassandra.us-east-1.amazonaws.com`，则将本地数据中心设置为 `us-east-1`。有关所有可用信息 AWS 区域，请参阅[Amazon Keyspaces 的服务端点](programmatic.endpoints.md)。为了避免复制，请将 `slow-replica-avoidance` 设置为 `false`。 1. *`SSLEngineFactory`*：要配置 SSL/TLS，初始化 `SSLEngineFactory`，方法是在配置文件中添加一个部分，其中只有一行，用于指定类 `class = DefaultSslEngineFactory`。提供指向 `cassandra_truststore.jks` 的路径和您之前创建的密码。 1. *`consistency`*：将一致性级别设置为 `LOCAL QUORUM`。不支持其他写入一致性级别，有关更多信息，请参阅 [支持的 Apache Cassandra 读写一致性级别和相关成本](consistency.md)。 1. 可以在 Java 驱动程序中配置每个池的连接数。在此示例中，将 `advanced.connection.pool.local.size` 设置为 3。 以下是完整的示例配置文件。 ``` datastax-java-driver { basic.contact-points = [ "cassandra.us-east-1.amazonaws.com:9142"] advanced.auth-provider { class = PlainTextAuthProvider username = "ServiceUserName" password = "ServicePassword" } basic.load-balancing-policy { local-datacenter = "us-east-1" slow-replica-avoidance = false } basic.request { consistency = LOCAL_QUORUM default-idempotence = true } advanced.ssl-engine-factory { class = DefaultSslEngineFactory truststore-path = "./cassandra_truststore.jks" truststore-password = "my_password" hostname-validation = false } advanced.connection.pool.local.size = 3 } ``` 1. 查看 DSBulk `load`命令的参数。 1. *`executor.maxPerSecond`*：load 命令尝试每秒同时处理的最大行数。如果未设置，则使用 -1 禁用此设置。 `executor.maxPerSecond`根据您配置到目标目标表 WCUs 的数量进行设置。`load` 命令的 `executor.maxPerSecond` 不是限制，而是目标平均值。这意味着它可以（并且经常）突破您设定的数字。要允许暴增并确保有足够的容量来处理数据加载请求，请将 `executor.maxPerSecond` 设置为表写入容量的 90%。 ``` executor.maxPerSecond = WCUs * .90 ``` 在本教程中，我们将 `executor.maxPerSecond` 设置为 5。 **注意** 如果您使用的是 DSBulk 1.6.0 或更高版本，则可以改用`dsbulk.engine.maxConcurrentQueries`。 1. 为 DSBulk `load`命令配置这些其他参数。 + *`batch-mode`*：此参数告诉系统按分区键对操作进行分组。我们建议禁用批处理模式，因为它可能会导致热键情况并导致 `WriteThrottleEvents`。 + *`driver.advanced.retry-policy-max-retries`*：这决定了重试失败查询的次数。如果未设置，则默认值为 10。您可以根据需要调整此值。 + *`driver.basic.request.timeout`*：系统等待查询返回的时间（以分钟为单位）。如果未设置，则默认值为“5 分钟”。您可以根据需要调整此值。 # 第 5 步：运行 DSBulk `load` 命令将 CSV 文件中的数据上传到目标表 在本教程的最后一步中，您要将数据上传到 Amazon Keyspaces。 要运行 DSBulk `load` 命令，请完成以下步骤。 1. 运行以下代码，将您的 csv 文件中的数据上传到 Amazon Keyspaces 表中。请确保更新指向您之前创建的应用程序配置文件的路径。 ``` dsbulk load -f ./dsbulk_keyspaces.conf --connector.csv.url keyspace.table.csv -header true --batch.mode DISABLED --executor.maxPerSecond 5 --driver.basic.request.timeout "5 minutes" --driver.advanced.retry-policy.max-retries 10 -k catalog -t book_awards ``` 1. 输出包括详细说明成功和不成功操作的日志文件的位置。该文件存储在以下目录中。 ``` Operation directory: /home/user_name/logs/UNLOAD_20210308-202317-801911 ``` 1. 日志文件条目将包括指标，如以下示例所示。检查以确保行数与 csv 文件中的行数一致。 ``` total | failed | rows/s | p50ms | p99ms | p999ms 200 | 0 | 200 | 21.63 | 21.89 | 21.89 ``` **重要** 现在您已经传输了数据，接下来调整目标表的容量模式设置，使其与应用程序的常规流量模式相匹配。在更改之前，您的预置容量按小时费率收费。有关更多信息，请参阅 [在 Amazon Keyspaces 中配置 read/write 容量模式](ReadWriteCapacityMode.md)。