写点什么

大数据公司 LiveRamp 上云记(一):为什么选择 GCP?

  • 2020-02-19
  • 本文字数:1987 字

    阅读完需:约 7 分钟

大数据公司LiveRamp上云记(一):为什么选择GCP?

LiveRamp 是一家大数据公司。


很多公司拥有大数据。每天早餐之前,健壮的日志框架就已经生成了 PB 级别的日志,并以防万一将这些数据长期保存在了亚马逊的 S3 上。


还有一些公司会使用他们自己的大数据。他们拥有自己的产品,他们会通过 Hadoop 和 Spark 来做一些机器学习,从而生成针对客户的产品推荐。


但是像 LiveRamp 这样的大数据公司就很少了。我们从客户那里赚取的每一分钱都来自于我们的 Hadoop 处理流水线。LiveRamp 的产品线很广,但这些产品都经由了相同的生产流程,即提取、转换、加载、加入 Hadoop 处理管道。如果说今天我们关闭了 Hadoop 基础设施,那公司也就可以直接关门停业了。


到去年为止,LiveRamp 所有的大数据计算都是在本地数据中心完成的。我们的数据中心部署了一个超过 2500 节点的 Cloudera Hadoop 集群。而从今年开始,我们逐步把它们迁移到了 GCP(谷歌云计算平台)。


Sasha Kipervarg,Patrick Raymond 和我在 Google Next 大会上展示了这次迁移之旅,包括我们从中学到的经验教训,以及接下来的计划等。在本系列博客文章中,我将从技术角度更深入地探讨这次迁移,重点有:


  • 在 2018 年及其以前,我们是如何在本地运营 LiveRamp 大数据基础设施的?

  • 我们为什么要决定迁移?

  • 我们希望 LiveRamp 基础设施在 GCP 上是什么样子?

  • 我们是如何实现的?

  • 我们下一步该如何发展?


尽管这是一项巨大的工程,但我们仍然对其感到兴奋,因为它将改变 LiveRamp 的开发体验,让我们可以用前所未有的速度将可扩展的、可靠的产品推向市场。

LiveRamp 一览


LiveRamp 有很多产品,但它们都是本着匹配客户 CRM(客户关系管理)以及匹配数据集的原则在不同生态系统之间转移数据。我们通过批文件传输管道和实时的像素服务器这两种方式将这些转换后的数据传输到数字广告生态系统中去。


Hadoop 生态系统尤其适合执行大规模数据连接,这也是我们所使用的。我们的绝大多数硬件都用在了 Cloudera Hadoop 集群。本地集群的最大规模可达到为:


  • 2500 个工作节点

  • 90000 个 CPU

  • 300TB 的内存

  • 100PB 的存储


我们的基础设施非常繁忙,每天有超过 10 万个 YARN 应用在运行,读写量超过 13 个 PB/天,以及超过 80%的系统利用率:



任何拥有 150 名工程师并且在不断增长的公司都会面对大量的服务以及与之对应的支持基础设施。截至 2018 年,我们使用了 500 多个由 Chef 统一配置管理的 VMWare 虚拟机(一个相对小一些的基于 CoreOS Tectonic 版本的 Kubernetes 集群。我们的实时键值服务平台则由内部的一个开源项目实现。


我们需要每天从合作伙伴处获取文件和日志,然后将处理后的文件送还,平均数据量约为 8TB 每天,像素服务器的平均访问量也达到了 20 万 QPS。


尽管我们在 AWS 运行了一些与国际团队和像素服务器相关的服务,但如此大的工作任务仍然用尽了本地数据中心的硬件资源。

上云

虽然我们对自己的基础设施有诸多不满,但是本着“正常工作”优先的原则,我们一直没有对它进行改变。但到了 2017 年中旬,我们开始意识到本地数据中心的规模已经无法满足我们的国际化需求。于是我们具备了所有迁移到云的一般动机:


  • 规模扩展:我们需要能够更快地扩展我们的基础设施,而不再受限于数据中心物理设备的搭建,例如 2 个月的硬件购买时间以及更多的空间放置需求等。

  • 灾难恢复:我们并不满意自己的灾难恢复系统。我们希望在数小时内就可以从灾难性的停机状态中恢复过来,而不是花费几个星期从冷备份开始恢复。

  • 招聘:工程师们希望能够接触到更重要和实用的技能,而在 2019 年,这就是着云计算。

  • 开发速度:假如我们有 30%的开发人员可以从基础设施维护中解放出来,这意味着他们可以重新转向产品开发,从而将产品推向市场的速度提高 30%。


因此,到 2017 年底,我们开始认真地评估云服务供应商,并开始把 LiveRamp 想象成一家云原生技术公司。

为什么选择 GCP?


我们喜欢 GCP,但我们知道它并不是默认选项。我们之所以选择 GCP 主要有两个驱动因素:


  • 技术


技术评估并不适合放在本篇文章中,但我要强调的一点是 GKE(谷歌Kubernetes引擎)是一个非常关键的因素。本次迁移有一个很明确的方向,那就是要把所有的应用程序和服务迁移到 Kubernetes 平台。可以粗略地讲,GKE 就是 Kubernetes 领域事实上的领头羊。


虽然我们可以选择任意一家云供应商并最终完成迁移,但一个很大的区别就是云供应商背后的技术支持人员。GCP 把我们同那些想回答我们问题并提供解决方案的工程师很好地联系了起来。


我们对 GCP 的技术支持合约也非常满意。我们总是能够与专业工程师及时取得联系并迅速得到解决措施。这也给了我们信心,通过与 GCP 合作,我们相信可以解决任何问题,这一点都现在也没有改变。


在下一篇文章中,我将讨论一些大数据基础设施迁移到 GCP 的细节,哪些方面可以直接转换到 GCP,而哪些方面又需要重新设计。敬请期待!


原文链接:


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


2020-02-19 09:523702

评论

发布
暂无评论
发现更多内容

芯片破壁者(二十四):1987战役启示录

脑极体

写在再次学习python之前-why篇

赵开忠

Python 28天写作

网络工程师职业指南

SpringBoot系列1——概述和快速入门

程序员的时光

springboot 七日更 28天写作

架构师训练营第 1 期 - 第 12 周 - 命题作业

wgl

架构师训练营第 1 期

记一次JVM OOM 实战优化

AI乔治

Java 架构 JVM OOM

技术人小故事-团队愿景篇-第1段

Ian哥

28天写作

架构师第 4 课作业及学习总结

小诗

「架构师训练营第 1 期」

架构师训练营 1 期 - 第 十四周总结(vaik)

行之

「架构师训练营第 1 期」

28天瞎写的第二百一二天:一次删库没跑路的故事

树上

28天写作 删库

牛啤了!阿里技术官整理的这份《Java面试手册5000题》已经成功让数百名社招生“圆梦BATJ”

Java 编程 面试

架构师第 3 课作业及学习总结

小诗

「架构师训练营第 1 期」

缓存穿透,缓存击穿,缓存雪崩

en

redis 缓存穿透 缓存击穿 缓存并发

意识会在哪个早晨降落——「幻想短篇1/28」

道伟

28天写作

【计算机内功修炼】三:一文彻底理解IO多路复用

码农的荒岛求生

epoll

极客大学架构师训练营大作业

Meow

腾讯T3面试官透露!360°深入了解Flutter,聪明人已经收藏了!

欢喜学安卓

android 程序员 面试 移动开发

职业成长就是一个逐渐“变帅”的过程

L3C老司机

区块链的前世今生(1)

抗哥

MySQL中的哥哥表、妹妹字段,是什么鬼?

Java MySQL 数据库

【薪火计划】08 - 非暴力沟通

码字与律动

管理 28天写作

LeetCode题解:17. 电话号码的字母组合,BFS,JavaScript,详细注释

Lee Chen

算法 大前端 LeetCode

架构师训练营第 1 期 - 第 12 周 - 学习总结

wgl

「架构师训练营第 1 期」

【Node.js】静态页面和简单的路由

德育处主任

大前端 Node 28天写作

CSS10 - 盒子模型&常用无序列表样式

Mr.Cactus

html/css

手把手教你如何巧用Github的Action功能

flutter android 持续集成

谬误词典:置信度

lidaobing

随机漫步的傻瓜 28天写作 谬误词典

资深大牛带你了解源码!阿里内部Android笔记火爆IT圈,醍醐灌顶!

欢喜学安卓

android 程序员 面试 移动开发

jstat使用实用教程

JavaPub

Java JVM

SafePoint 与 Stop The World 全解(基于OpenJDK 11版本)

AI乔治

Java 架构 jdk JVM

kill -9 导致 kafka 重启失败的惨痛经历!

AI乔治

Java kafka 架构

大数据公司LiveRamp上云记(一):为什么选择GCP?_服务革新_Benjamin Podgursky_InfoQ精选文章