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

阅读数:2 2020 年 2 月 21 日 10:15

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

我们如何实现?

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

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

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

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

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

数据传输

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

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

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

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

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

  • 优先化数据传输;
  • 避免复制重复文件到 GCS(谷歌云存储);
  • 可视化带宽利用率。

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

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

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

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

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

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

服务迁移

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

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

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

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

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

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

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

  • 服务端点在 Hashicorp Consul 注册为可用,等待响应服务请求;
  • 当服务客户端希望提交一个工作单元时(例如,一个客户新导入的文件),它会在 Consul 中找到一个实时服务器;
  • 客户端提交工作单元。服务器将其转换为一个请求,并把该请求插入到一个队列中,每个应用程序的排队行为不同,但最简单的版本是优先级队列;
  • 驻留 worker 从队列中提取工作单元。在数据应用程序中,工作单元通常作为 Hadoop 任务处理。

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

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

因为驻留 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 上云记(二):哪些功能可以直接迁移,哪些需要重新设计?

评论

发布