大数据公司 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/

  • 发表于:
  • 本文为 InfoQ 中文站特供稿件
  • 首发地址https://www.infoq.cn/article/KEh5GaiIe0jiPSYiFTrf
  • 如有侵权,请联系 yunjia_community@tencent.com 删除。

扫码关注云+社区

领取腾讯云代金券