LiveRamp是一家大数据公司。
很多公司拥有大数据。每天早餐之前,健壮的日志框架就已经生成了PB级别的日志,并以防万一将这些数据长期保存在了亚马逊的S3上。
还有一些公司会使用他们自己的大数据。他们拥有自己的产品,他们会通过Hadoop和Spark来做一些机器学习,从而生成针对客户的产品推荐。
但是像LiveRamp这样的大数据公司就很少了。我们从客户那里赚取的每一分钱都来自于我们的Hadoop处理流水线。LiveRamp的产品线很广,但这些产品都经由了相同的生产流程,即提取、转换、加载、加入Hadoop处理管道。如果说今天我们关闭了Hadoop基础设施,那公司也就可以直接关门停业了。
到去年为止,LiveRamp所有的大数据计算都是在本地数据中心完成的。我们的数据中心部署了一个超过2500节点的Cloudera Hadoop集群。而从今年开始,我们逐步把它们迁移到了GCP(谷歌云计算平台)。
Sasha Kipervarg,Patrick Raymond和我在Google Next大会上展示了这次迁移之旅,包括我们从中学到的经验教训,以及接下来的计划等。在本系列博客文章中,我将从技术角度更深入地探讨这次迁移,重点有:
尽管这是一项巨大的工程,但我们仍然对其感到兴奋,因为它将改变LiveRamp的开发体验,让我们可以用前所未有的速度将可扩展的、可靠的产品推向市场。
LiveRamp有很多产品,但它们都是本着匹配客户CRM(客户关系管理)以及匹配数据集的原则在不同生态系统之间转移数据。我们通过批文件传输管道和实时的像素服务器这两种方式将这些转换后的数据传输到数字广告生态系统中去。
Hadoop生态系统尤其适合执行大规模数据连接,这也是我们所使用的。我们的绝大多数硬件都用在了Cloudera Hadoop集群。本地集群的最大规模可达到为:
我们的基础设施非常繁忙,每天有超过10万个YARN应用在运行,读写量超过13个PB/天,以及超过80%的系统利用率:
任何拥有150名工程师并且在不断增长的公司都会面对大量的服务以及与之对应的支持基础设施。截至2018年,我们使用了500多个由Chef统一配置管理的VMWare虚拟机(一个相对小一些的基于CoreOS Tectonic版本的Kubernetes集群。我们的实时键值服务平台则由内部的一个开源项目实现。
我们需要每天从合作伙伴处获取文件和日志,然后将处理后的文件送还,平均数据量约为8TB每天,像素服务器的平均访问量也达到了20万QPS。
尽管我们在AWS运行了一些与国际团队和像素服务器相关的服务,但如此大的工作任务仍然用尽了本地数据中心的硬件资源。
虽然我们对自己的基础设施有诸多不满,但是本着“正常工作”优先的原则,我们一直没有对它进行改变。但到了2017年中旬,我们开始意识到本地数据中心的规模已经无法满足我们的国际化需求。于是我们具备了所有迁移到云的一般动机:
因此,到2017年底,我们开始认真地评估云服务供应商,并开始把LiveRamp想象成一家云原生技术公司。
我们喜欢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/
领取专属 10元无门槛券
私享最新 技术干货