大数据公司 LiveRamp 上云记（三）：如何在吞吐量有限的情况下处理数据复制

我们如何实现？

在系列二中，我们讨论了云 MVP 应该是什么样子的。下一个问题就是如何在一个月内不关闭公司的情况下实现它？

我们先从已知需求开始。应用程序团队至少需要几个月的时间来将 GCP（谷歌云计算平台）和本地数据中心的内部服务隔离。因此，我们需要一个单逻辑网络来连接两者。对此，我们快速建立了一个云互连来连接 us-central1 和本地数据中心之间的环境：

为了避免将公司所有的项目都堆积在一个 GCP 项目下，我们使用了一个共享的 VPC 网络，每个团队都有一个单独的子网络。这可以加速 GCP 中的服务以便与本地数据中心的服务进行实时通信。同时，我们也不需要那些让人抓狂的数据库复制设置，因为 GCP 中的服务能够与仍在本地的数据库通信。

这个共享的逻辑网络在迁移过程中变得非常重要。如果我们的服务网络不能连接本地网络，那迁移也根本不可能实现。

数据传输

数据传输给我们带来了一个核心挑战：如何处理从数据中心到 GCP 的有限出口（egress）。在本地数据中心内部，我们拥有难以置信的大带宽，但是我们从来不需要为大量的数据出口优化基础设施；相反，在 GCP 中我们被限制到了 50Gbps。我们本来可以升级这个带宽值，但我们不想花费数百万美元来升级一个正在积极退役的数据中心。

对我们数据交付的输入和输出端来说，50Gbps 是一个合理的数字。真正的挑战来自于数据管道的中间；管道中间的分布式连接产生的数据量远远大于发送或接收的数据量。如果不留意团队之间的迁移时间，我们的连接会很容易饱和。

关于传输设备的一点说明：传输设备不适合我们，因为我们处理的数据只有很少一部分是冷数据；如果我们需要逐步迁移基础设施，那我们最终要移动比任何快照的数据量都要大得多的数据。此外，云服务提供商就像毒贩，例如数据入口（ingress）是免费的，但是如果你想把数据移出云，大数据的数据出口（engress）是非常昂贵的。

为了让迁移顺利进行，我们需要这样一项服务，它可以：

• 优先化数据传输；

• 避免复制重复文件到 GCS（谷歌云存储）；

• 可视化带宽利用率。

我将在下一篇文章中详细介绍 Data Replicator（数据复制）服务。简而言之，我们构建了一个内部服务，它按照优先顺序复制数据。团队可以任意使用互连来进行服务和数据库调用，但是数据基础设施团队负责所有文件副本。

这样，我们就可以优先传输那些只有较短 SLA（服务级别协议）的产品数据，而降低冷数据复制的优先级。并且，它可以让我们了解了带宽的去向，我们不再需要为了弄清谁占用了互连而在 tcpdump 上焦头烂额，我们只需要打开一个 DataDog 控制面板，直接查看就好：

这些限制决定了数据迁移的总体结构。我们的数据管道末端的一个团队会把一个应用程序迁移到 GCP。该应用程序将要求把它的输入从 HDFS 映射到 GCS。数据复制服务处理这些文件副本。稍后，上游应用程序将迁移到 GCP，而数据已经在 GCS 上了，不再需要复制：

虽然我们很为这个数据复制服务骄傲，但我们希望不要再用另外 6 个月的时间。一旦所有的数据都在 GCS 上，我们就没有任何东西需要复制了。

服务迁移

LiveRamp 数据流管道对于我们的无（应用程序）中断迁移至关重要，因为我们绝大多数的应用程序都使用了基于请求的面向服务架构（SOA）。

理解基于请求的架构与传统的 Hadoop 架构之间的区别非常重要。传统的 Hadoop 数据管道是一系列（每天都要运行的）批处理任务，一次处理所有的数据集：

LiveRamp 并没有使用这种架构。相反，数据集作为独立的单元来处理：

运行 100 个任务的确比运行一个批处理任务需要更多的跟踪基础设施。我们使用开源框架daemon_lib来协调服务请求。请求流程如下：

• 服务端点在 Hashicorp Consul 注册为可用，等待响应服务请求；

• 当服务客户端希望提交一个工作单元时（例如，一个客户新导入的文件），它会在 Consul 中找到一个实时服务器；

• 客户端提交工作单元。服务器将其转换为一个请求，并把该请求插入到一个队列中，每个应用程序的排队行为不同，但最简单的版本是优先级队列；

• 驻留 worker 从队列中提取工作单元。在数据应用程序中，工作单元通常作为 Hadoop 任务处理。

当迁移到 GCP 时，应用程序团队可以提供 GKE（谷歌 Kubernetes 引擎）上的 worker，这些 worker 与内部 worker 服务于相同的工作队列（切记，我们在同一个逻辑网络中工作，所有的 worker 都访问同一个数据库！）：

因为驻留 worker 可以自行决定他们能够处理的工作单元，所以团队可以逐步将服务迁移到 GCP：

• 首先，引导 GKE 的 worker 只处理测试或临时数据；

• 其次，引导 GKE 的 worker 只处理一小部分产品工作；

• 最后，完全使用 GKE 的 worker 并退役所有的本地 worker。

通过使用临时数据测试应用程序，然后逐步增加负载，应用程序团队可以：

• 轻微触发 GCP 的扩展问题（例如，达到我们不知道的配额，或者超过了我们的互连带宽）；

• 如果问题无法在几个小时内解决，则迅速将工作转移回我们的本地环境。

这并不是要简化迁移给应用程序团队带来的工作量，即使使用了这些工具，这次迁移对于我们所有的应用程序团队来说仍然是一项艰巨的任务。但是由于我们的实时数据复制和服务体系架构，我们可以在一个非常小的应用程序停机时间内完成这项工作。

在下一篇文章中，我们将着重介绍本文简要提到的数据复制服务，并讨论我们如何构建了一个服务，它让我们在 6 个月的迁移期间同时处理了数百万的请求和 PB 字节的数据传输。

原文链接：

https://LiveRamp.com/engineering/migrating-a-big-data-environment-to-the-cloud-part-3/

相关阅读：

大数据公司 LiveRamp 上云记（一）：为什么选择 GCP？

大数据公司 LiveRamp 上云记（二）：哪些功能可以直接迁移，哪些需要重新设计？