大数据公司LiveRamp上云记（五）：如何使用云原生技术重构本地系统

接下来呢？

在之前的迁移文章中，我们问过自己：

• 为什么要迁移到云平台？
• 我们希望第一天的架构看起来像什么？
• 我们该如何实现？
• 我们该如何解决带宽限制问题？

最后也最令人兴奋的问题是，“接下来会发生什么？”，“我们该如何重新设计从而充分利用GCP平台的优势？”。

技术

虽然我们没有将现有的基础设施直接迁移到GCP上，最终做了不少改动，但我们在第一天还是使用了很多GCP的工具：

扩展：这很显然，但是能够在需要实例的时候添加它们而在不需要的时候关闭它们，这是一个能改变游戏规则的能力。我们最大的批处理图形构建程序在运行时需要大量资源，但其只占一半的运行时间。在本地环境下，这意味着我们必须为峰值容量提供物理机器，而在GCP中，我们可以在不需要机器的时候自动关闭它们：

Google Kubernetes Engine（GKE）+Google Container Registry（GCR）：到目前为止，我们做的最大的重构就是消除了的本地Chef环境，转而支持Kubernetes（通过GKE），并在GCR中存储镜像。虽然这是一项庞大的工程，但花费的时间却是100%物有所值。

云存储（GCS）：我们正在用GCS完全取代HDFS环境。采用对象存储可以使我们更灵活地迭代计算基础设施，而且不会有数据丢失的风险。

BigTable：我们已经用BigTable替换了内部的键值数据存储。

CloudSQL：Liveramp非常依赖MySQL。除了使用数据库的常规原因（数据规范、状态协调）之外，我们内部还将数据库用于队列、统计仓库等等。这项工作分成了几十个数据库，其中许多数据库由应用程序团队拥有。通过将轻量级数据库转移到CloudSQL中，应用程序团队可以完全拥有MySQL实例，而不必成为数据库管理员；团队可以考虑数据库的模式，而不必担心数据的备份或复制。

BigQuery：尽管分析性查询不是LiveRamp所做计算的主体，但这些查询有一个重要的用途，即不需要通过工程师就可以将我们的日志数据暴露给商业智能分析师。

FileStore：在本地，NFS是我们用来在虚拟机之间实现配置共享的粘合剂，也可以让支持工程师在将数据保存到HDFS之前进行阶段处理。FileStore完全可以作为一个高性能NFS的替代品，并且不必由我们自己管理。

下一步如何？

短回答是：我们不知道，找到答案的时候我们会在这里更新， : )

稍微长一点的回答是：我们不知道，但是我们非常肯定它会涉及到更多令人兴奋的技术：

BigTable（第2次）：我们使用BigTable来强化我们的像素服务器，但我们只是对可伸缩的实时查询存储做了一些浅尝辄止的工作。还有一种可能是用一个真正的实时管道来补充（甚至替换）我们的批处理管道。

DataFlow：LiveRamp非常倚重Hadoop。我们构建了很多复杂的工具来帮助处理每天数百万兆字节的数据，Hadoop支持所有这些工具。但是，我们不想用同一把锤子来处理所有问题；如果能不费力地用DataFlow来替换我们自己的ETL工作流，我们会这样做的。

Cloud函数，CloudRun：LiveRamp运行了很多服务；其中大多数服务主要用来封装不同团队的数据库，提供配置逻辑或封装请求等。这些服务通常导致非常不稳定的负载，有时可能会处理数百个请求，有时一个也没有：

虽然Kubernetes自伸缩功能可以起到缓解作用，但云函数随负载伸缩的原生能力将完全消除这个问题。

人

云计算迁移通常是在技术权衡的背景下讨论的。云计算提供原生服务、更容易的区域复制、灾难复制等（当然是有代价的）。

但人们往往忽略的是，云迁移其实还是一个重新思考自己工程实践的机会。虽然我相信LiveRamp在这次迁移中已经完成了一项令人惊讶的技术成就，但更让我自豪的是，随着对内部环境限制的摆脱，团队也开始利用这个机会重新思考自己的责任。我们的工程团队已经做了三个重要的改变，我将在下面提到。

不要在共享的基础设施上进行构建

因为提供新的硬件需要几个月的时间，在本地为新的应用程序团队创建新的基础设施是不切实际的；因此，我们在应用程序团队之间共享基础设施。我们最敏感的共享服务有：

• Hadoop环境：YARN和HDFS被所有应用程序团队共享。
• 数据库：一些团队运行独立的数据库，但所有数据库都由基础设施团队管理。
• Kubernetes：跨团队的应用程序将被部署到一个中央Kubernetes集群。
• 虚拟机：虚拟机从中央资源池统一分配。

不幸的是，中央服务的便利性是以敏捷性为代价的。如果十几个应用程序团队使用相同的Hadoop环境，那么最终就演变成无法升级基础设施；每次更改都会破坏一些关键的东西。当不同的团队以不同的方式使用相同的基础设施时，即使简单的性能调整也很难实现。

同样，共享的基础设施也非常容易受到单个应用程序或团队的（通常是偶然的）滥用行为的影响。Kubernetes可能会耗尽资源；NameNodes可能会被RPC调用压垮。如果团队的变更会影响不相关团队编写的应用程序，那么团队的变更迭代就会变得很不情愿。

而在GCP上，我们只需要几分钟就可以为基础设施提供一个新的轻量级副本，团队不再需要自举一个公共服务池。这在很大程度上提高了信心和迭代速度。

团队负责自己的资源开支

当很多应用程序使用共享的服务是，这会很难准确地将成本划分到单个团队或应用程序。优化项目通常是由基础设施驱动的；只有当基础设施耗尽一组共享资源时，我们才会去主动回收这些资源。团队通常不知道他们的应用程序耗费了太多的资源，直到基础设施告诉他们这一点。

在GCP中，团队在自己的项目中运行资源，所以划分成本变得非常容易。应用程序团队离客户最近，他们现在也被授权去做成本权衡的选择，如果花费2倍的资金但可以按2倍的速度交付数据，这就算物有所值，他们就可以去做。

基础设施引导，团队最终决定

资源和成本的共享把基础设施团队推到了技术仲裁者的尴尬位置上，因为基础设施团队最终将拥有所提供的任何基础设施，我们不得不更频繁地对实验性技术说不。

在云迁移的世界里，我们重新定义了基础设施团队在工程团队中的位置：

• 基础设施仍然处理安全和数据权限。
• 核心基础设施（例如，共享VPC网络）仍然由基础设施管理。
• 在其他任何地方，基础设施都可以通过构建工具和建议最佳实践的方式来提供帮助；团队可以自由使用他们认为最适合自己的工具，不论这些工具是内部的还是外部的。

没有人（至少我们团队中没有人）喜欢成为一个中央计划者；通过分解我们共享的基础设施，我们可以回归到基础架构团队的本质：构建工具和帮助其他工程师。

展望

这些都是很大的改变。写一篇关于未来的文章是很容易的，但我们完全明白要达到这个目标需要很多年。但是，无论一年后最终使用哪种技术，我们相信我们仍在朝着正确的方向前进。

原文链接：

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