写点什么

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

评论

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

webRTC实现音视频通话与屏幕共享

侠客行

WebRTC 屏幕共享 iOS屏幕共享 web屏幕共享

Tapdata 实时数据融合平台解决方案(四):技术选型

tapdata

大数据

​探讨AI+新模式,百度大脑提供纺织企业数字化转型新路径

百度大脑

AI 纺织企业

渣本毕业两年经验,精心整理

欢喜学安卓

android 程序员 面试 移动开发

Tapdata 实时数据融合平台解决方案(二):理解数据中台

tapdata

oracle mongodb

从零开始学习3D可视化之控制对象(1)

ThingJS数字孪生引擎

物联网 可视化 3D 3D可视化 数字孪生

Tapdata 实时数据融合平台解决方案(三):数据中台的技术需求

tapdata

oracle mongodb

Tapdata 实时数据融合平台解决方案(五):落地

tapdata

大数据

写给想做程序员的半吊子应届毕业生们

北游学Java

Java Python 求职 秋招

智能炒币机器人系统开发案例解析,智能炒币机器人源码设计

系统开发咨询1357O98O718

Qcon大会百度智能云出招,AI-Native云计算架服务企业融合创新

百度大脑

人工智能 云计算 Qcon

OpenKruise v0.9.0 版本发布:新增 Pod 重启、删除防护等重磅功能

阿里巴巴云原生

容器 运维 云原生 k8s

基于 BDD 理论的 Nebula 集成测试框架重构(上篇)

NebulaGraph

持续测试 | 让测试更自由:在 CODING 中实践自动化执行用例

CODING DevOps

DevOps 自动化测试 持续测试

BZZ节点挖矿系统搭建,BZZ矿机分币系统

Tapdata 实时数据融合平台解决方案(一):现代企业数据架构及痛点

tapdata

mongodb

我对技术潮流的一点看法

Phoenix

架构实战营模块5作业

eoeoeo

架构实战营

【Apache BookKeeper】 概念与架构

awen

Apache 分布式存储 bookKeeper

你真的了解 “开源” 么?请查收【保姆级】开源百科

程序员鱼皮

Java c++ Python GitHub 开源

5分钟速读之Rust权威指南(十五)

wzx

rust

HarmonyOS 2正式发布 硬件生态品牌HarmonyOS Connect一同亮相

科技汇

架构实战营 - 模块 5- 作业

carl

我的树莓派居然偷偷的学会了日语

IT蜗壳-Tango

IT蜗壳教学 6月日更

6月2日,讲一个鸿蒙的故事

这不科技

华为 鸿蒙

🔎【Java 源码探索】深入浅出的分析HashMap(JDK7)

洛神灬殇

Java hashmap 6月日更 JDK7

《堂食点餐》APP前后端全部免费开源啦!

YonBuilder低代码开发平台

源码 大前端 APP开发 APICloud 外卖app

源码解读-别再说你不知道HashMap原理!面试真题解析

欢喜学安卓

android 程序员 面试 移动开发

🏆大势所趋,迈向认识WebRTC的第一步,加油!

洛神灬殇

WebRTC RTC RTC征文大赛 6月日更

AT智能量化炒币机器人系统开发详解案例

系统开发咨询1357O98O718

奇亚Chia挖矿系统开发方案丨奇亚Chia挖矿源码功能

系统开发咨询1357O98O718

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