假如L 是一家大数据公司。下面我们的文章将围绕L展开分析。
很多公司拥有大数据。每天早餐之前,健壮的日志框架就已经生成了 PB 级别的日志,并以防万一将这些数据长期保存在了亚马逊的 S3 上。
还有一些公司会使用他们自己的大数据。他们拥有自己的产品,他们会通过 Hadoop 和 Spark 来做一些机器学习,从而生成针对客户的产品推荐。
但是像 L 这样的大数据公司就很少了。我们从客户那里赚取的每一分钱都来自于我们的 Hadoop 处理流水线。L 的产品线很广,但这些产品都经由了相同的生产流程,即提取、转换、加载、加入 Hadoop 处理管道。如果说今天我们关闭了 Hadoop 基础设施,那公司也就可以直接关门停业了。
到去年为止,L 所有的大数据计算都是在本地数据中心完成的。我们的数据中心部署了一个超过 2500 节点的 Cloudera Hadoop 集群。而从今年开始,我们逐步把它们迁移到了 GCP(谷歌云计算平台)。
Sasha Kipervarg,Patrick Raymond 和我在 Google Next 大会上展示了这次迁移之旅,包括我们从中学到的经验教训,以及接下来的计划等。在本系列博客文章中,我将从技术角度更深入地探讨这次迁移,重点有:
- 在 2018 年及其以前,我们是如何在本地运营 L 大数据基础设施的?
- 我们为什么要决定迁移?
- 我们希望 L 基础设施在 GCP 上是什么样子?
- 我们是如何实现的?
- 我们下一步该如何发展?
尽管这是一项巨大的工程,但我们仍然对其感到兴奋,因为它将改变 L 的开发体验,让我们可以用前所未有的速度将可扩展的、可靠的产品推向市场。
L 一览
![bc4bb68440b66567c559691dd1606afa.png](https://i-blog.csdnimg.cn/blog_migrate/56e6bf7e572a1e29faf4716f33922e19.jpeg)
L 有很多产品,但它们都是本着匹配客户 CRM(客户关系管理)以及匹配数据集的原则在不同生态系统之间转移数据。我们通过批文件传输管道和实时的像素服务器这两种方式将这些转换后的数据传输到数字广告生态系统中去。
Hadoop 生态系统尤其适合执行大规模数据连接,这也是我们所使用的。我们的绝大多数硬件都用在了 Cloudera Hadoop 集群。本地集群的最大规模可达到为:
- 2500 个工作节点
- 90000 个 CPU
- 300TB 的内存
- 100PB 的存储
我们的基础设施非常繁忙,每天有超过 10 万个 YARN 应用在运行,读写量超过 13 个 PB/ 天,以及超过 80% 的系统利用率:
![9e37b9dbaa11a4d8e58bdce8b7035c7e.png](https://i-blog.csdnimg.cn/blog_migrate/0362dffce9355e4eacf27fab1174bce2.jpeg)
任何拥有 150 名工程师并且在不断增长的公司都会面对大量的服务以及与之对应的支持基础设施。截至 2018 年,我们使用了 500 多个由 Chef 统一配置管理的 VMWare 虚拟机(一个相对小一些的基于 CoreOS Tectonic 版本的 Kubernetes 集群。我们的实时键值服务平台则由内部的一个开源项目实现。
我们需要每天从合作伙伴处获取文件和日志,然后将处理后的文件送还,平均数据量约为 8TB 每天,像素服务器的平均访问量也达到了 20 万 QPS。
尽管我们在 AWS 运行了一些与国际团队和像素服务器相关的服务,但如此大的工作任务仍然用尽了本地数据中心的硬件资源。
上云
虽然我们对自己的基础设施有诸多不满,但是本着“正常工作”优先的原则,我们一直没有对它进行改变。但到了 2017 年中旬,我们开始意识到本地数据中心的规模已经无法满足我们的国际化需求。于是我们具备了所有迁移到云的一般动机:
- 规模扩展:我们需要能够更快地扩展我们的基础设施,而不再受限于数据中心物理设备的搭建,例如 2 个月的硬件购买时间以及更多的空间放置需求等。
- 灾难恢复:我们并不满意自己的灾难恢复系统。我们希望在数小时内就可以从灾难性的停机状态中恢复过来,而不是花费几个星期从冷备份开始恢复。
- 招聘:工程师们希望能够接触到更重要和实用的技能,而在 2019 年,这就是着云计算。
- 开发速度:假如我们有 30% 的开发人员可以从基础设施维护中解放出来,这意味着他们可以重新转向产品开发,从而将产品推向市场的速度提高 30%。
因此,到 2017 年底,我们开始认真地评估云服务供应商,并开始把 L 想象成一家云原生技术公司。
为什么选择 GCP?
![3a98cfac7f4c47f73455bdcfdd317dd7.png](https://i-blog.csdnimg.cn/blog_migrate/2420d3b1248d86b4692ce4240afbaf07.jpeg)
我们喜欢 GCP,但我们知道它并不是默认选项。我们之所以选择 GCP 主要有两个驱动因素:
- 技术
- 人
技术评估并不适合放在本篇文章中,但我要强调的一点是 GKE(谷歌 Kubernetes 引擎)是一个非常关键的因素。本次迁移有一个很明确的方向,那就是要把所有的应用程序和服务迁移到 Kubernetes 平台。可以粗略地讲,GKE 就是 Kubernetes 领域事实上的领头羊。
虽然我们可以选择任意一家云供应商并最终完成迁移,但一个很大的区别就是云供应商背后的技术支持人员。GCP 把我们同那些想回答我们问题并提供解决方案的工程师很好地联系了起来。
我们对 GCP 的技术支持合约也非常满意。我们总是能够与专业工程师及时取得联系并迅速得到解决措施。这也给了我们信心,通过与 GCP 合作,我们相信可以解决任何问题,这一点都现在也没有改变。
在下一篇文章中,我将讨论一些大数据基础设施迁移到 GCP 的细节,哪些方面可以直接转换到 GCP,而哪些方面又需要重新设计。敬请期待!