但是怎么办?采用 Cloud Bigtable 意味着迁移 Box 最关键的服务之一，其安全文件上传和下载功能是其内容云的核心。它还意味着在零停机的情况下迁移超过 600 TB 的数据。继续阅读以了解我们是如何做到的，以及我们最终享受到的好处。 

背景

历史上，Box 使用 HBase 来存储客户文件元数据，其架构如下表所示。这为我们提供了从文件到文件物理存储位置的映射。此元数据由运行在 Kubernetes 上的名为 Storage Service 的服务管理;此元数据用于 Box 的每次上传和下载。对于我们规模的某些上下文:在迁移开始时，我们有多个 HBase 集群，每个集群存储超过 6000 亿行和 200 TB 的数据。此外，这些集群每秒接收大约 15,000 次写入和每秒 20,000 次读取，但可以扩展以服务数百万个分析作业或更高负载的请求。

准备迁移

为了为我们的用例选择最佳的 Bigtable 集群配置，我们在迁移之前运行了性能测试和异步读写。您可以在此处的Box 博客上了解更多相关信息。 

由于 Bigtable 不需要维护停机时间，我们决定将我们的三个 HBase 集群合并为两个位于不同区域的 Bigtable 集群以进行灾难恢复。这是一个很大的好处，但现在我们需要找出将三个副本合并为两个副本的最佳方法!

理论上，由于分区写入和保证复制，我们所有三个 HBase 集群中的元数据应该是相同的。然而，在实践中，所有集群的元数据都发生了变化，Box 的存储服务在读取时处理了这些不一致。因此，在迁移的回填阶段，我们决定拍摄每个 HBase 集群的快照并将它们导入 Bigtable。但是我们不确定是将快照叠加还是将快照导入到单独的集群中。

为了决定如何将三个集群合并为两个，我们运行了 Google 提供的 Multiverse Scan Job，这是一个定制的 MapReduce 作业，可以并行顺序扫描 HBase 表快照。这使我们能够有效地执行三个表的排序-合并-连接，并比较行和单元格以了解三个 HBase 集群之间的差异。当作业扫描整个表时，会随机比较 10% 的关键行。该作业使用了 160 个Dataproc工作器节点并运行了四天。然后，我们将差异导入 BigQuery 进行分析。

我们发现不一致分为三类:

HBase 集群中缺少行

一行存在，但在 HBase 集群中缺少列

一行存在，但在 HBase 集群中有不同的非关键列

这个练习帮助我们决定将所有三个快照合并为一个将为我们提供最一致的副本，并让 Bigtable 复制处理将数据导入辅助 Bigtable 集群。这将解决丢失列或行的任何问题。

迁移计划

那么，如何将数万亿行迁移到实时数据库中?根据我们之前将较小的数据库迁移到 Bigtable 的经验，我们决定实施同步修改。换句话说，每次成功的 HBase 修改都会导致相同的 Bigtable 修改。如果任一步骤失败，则整个请求将被视为失败，从而保证原子性。例如，当写入 HBase 成功时，我们将向 Bigtable 发出写入，序列化操作。这将写入的总延迟增加到写入 HBase 和 Bigtable 的总和。然而，我们认为这是一个可以接受的权衡，因为对这两个数据库进行并行写入会在 Box 的存储服务中引入复杂的逻辑。

一种复杂性是 Box 的存储服务执行了许多检查和修改操作。在没有回填 Bigtable 的迁移期间，这些无法在 Bigtable 中进行镜像，因此检查和修改操作将不同于 HBase 检查和修改。为此，我们决定依赖HBase查改的结果，只有HBase查改成功才进行修改。

推出计划

为了安全地推出同步修改，我们需要通过百分比和区域来控制它。例如，我们针对某个区域的推出计划如下所示:

1% 区域 1

5% 区域 1

25% 区域 1

50% 区域 1

100% 区域 1

同步修改确保 Bigtable 将所有新数据写入其中。但是，我们仍然需要回填旧数据。在运行了一周的同步修改并没有观察到任何不稳定情况后，我们准备拍摄三个 HBase 快照并进入导入阶段。

Bigtable导入:回填数据

我们有 3 个 HBase 快照，每个 200TB。我们需要使用 Google 提供的Dataproc Import Job将它们导入 Bigtable 。由于我们完全依赖 Bigtable 集群的性能，因此必须小心运行此作业。如果我们的 Bigtable 集群过载，我们会立即看到不利的客户影响——用户流量延迟增加。事实上，我们的快照非常大，以至于我们将 Bigtable 集群扩展到 500 个节点以避免任何性能问题。然后我们开始按顺序导入每个快照。我们完全不知道这种大小的导入，因此我们通过缓慢增加 Dataproc 集群的大小和监控 Bigtable 用户流量延迟来控制导入速率。

验证

在我们开始依赖 Bigtable 的读取之前，必须进行一系列验证。如果任何行不正确，这可能会对客户造成负面影响。我们集群的大小使得不可能对每一行进行验证。相反，我们采用了三种不同的验证方法来获得对迁移的信心:

1.异步读取验证:乐观的客户下载驱动验证

在每次读取时，我们从 Bigtable 异步读取并添加日志记录和指标以通知我们任何差异。这种方法的一个警告是我们有很多读取紧随其后的是更新。这种方法产生了很多噪音，因为我们发现的所有差异都来自 HBase 读取和 Bigtable 读取之间发生的修改。

在此读取验证期间，我们发现 Bigtable 正则表达式扫描与 HBase 正则表达式扫描不同。其一，Bigtable 仅支持“等于”正则表达式比较器。此外，Bigtable Regex 使用 RE2 来处理“.”。（任何字符，除非指定，否则不包括换行符）与 HBase 不同。因此，我们必须为 Bigtable 扫描推出一个特定的正则表达式，并验证它们是否返回了预期的结果。

2. 同步验证:运行一个 Dataproc 作业，在 Bigtable 和 HBase 之间进行哈希比较

此验证作业与此处的验证作业类似，对 Bigtable 和 HBase 行之间的哈希值进行了比较。我们在 3% 的行样本上运行它并发现了 0.1% 的不匹配。我们打印了这些不匹配项并对其进行了分析。这些不匹配中的大多数来自对某些列的乐观修改，发现不需要重新导入或更正。

3.客户视角验证 

我们希望执行应用程序级验证以了解客户会看到什么，而不是数据库级验证。

我们编写了一个扫描整个文件系统的作业，该文件系统将排队对象，我们将在其中调用存储服务中的端点，该端点将比较 Bigtable 和 HBase 中的条目。有关详细信息，请查看此 Box博客。

此验证支持同步验证作业的输出。我们没有发现上面没有解释的任何差异。

翻转到 Bigtable

所有这些验证让我们有信心从 Bigtable 而不是 HBase 返回读取。我们保留了对 HBase 的同步双重修改作为备份，以防我们需要回滚任何东西。仅返回 Bigtable 数据后，我们终于准备关闭对 HBase 的修改。在这一点上，Bigtable 成为我们的真相来源。

为 Bigtable 点赞

自从完成向 Bigtable 的迁移后，我们观察到了以下一些好处。 

发展速度

我们现在可以完全控制扩大和缩小 Bigtable 集群。我们打开了Bigtable autoscaling，它会根据 CPU 和存储利用率参数自动增加或减少我们的集群。我们以前无法使用物理硬件做到这一点。这使我们的团队能够在不影响客户的情况下快速发展。

我们的团队现在与管理数据库相关的开销要少得多。过去，我们不得不经常移动 HBase 流量来执行安全补丁。现在，我们根本不需要担心管理它。

最后，过去需要几天才能完成的 MapReduce 作业现在可以在 24 小时内完成。

节约成本

在 Bigtable 之前，我们运行三个完全复制的集群。使用 Bigtable，我们能够运行一个接收所有请求的主集群，以及一个复制的辅助集群，如果主集群出现任何问题，我们可以使用它。此外，对于灾难恢复，辅助集群对我们团队运行数据分析作业非常有用。

然后，通过自动缩放，我们可以更轻松地运行我们的辅助集群，直到我们需要运行一个作业，此时它会自我缩放。辅助集群运行的节点数比主集群少 25%。当我们使用 HBase 时，我们所有三个集群的大小都是均匀的。

新的分析工具

我们将所有 HBase MapReduce 作业移植到 Bigtable，发现 Bigtable 为我们提供了对等的功能，只需对现有作业进行微小的配置更改。

Bigtable 还使我们能够使用 Google Cloud 生态系统:

我们能够将 Bigtable 添加为外部 BigQuery 源。这允许我们实时查询我们的表，这在 HBase 中是不可能的。这个应用程序最适合我们的小桌子。由于对 CPU 利用率的影响，在生产 Bigtable 集群上运行查询时应小心。应用程序配置文件可用于将流量隔离到辅助集群。

对于较大的表，我们决定通过 Dataproc 作业将它们导入 BigQuery。这使我们能够在不运行任何额外作业的情况下提取临时分析数据。此外，查询 BigQuery 也比运行 MapReduce 作业快得多。

长话短说，迁移到 Bigtable 是一项艰巨的任务，但考虑到我们获得的所有好处，我们很高兴我们做到了!