写点什么

大数据公司 LiveRamp 上云记(二):哪些功能可以直接迁移,哪些需要重新设计?

  • 2020-02-20
  • 本文字数:1993 字

    阅读完需:约 7 分钟

大数据公司 LiveRamp 上云记(二):哪些功能可以直接迁移,哪些需要重新设计?

踏上征途

在上一篇文章中我们讨论了迁移到云也就是 GCP(谷歌云计算平台)的原因。一旦确定了迁移,我们就开始问自己三个问题:


  1. 我们的云架构在第一天会是什么样子?云平台的确可以让我们做很多令人兴奋的事情,但我们究竟希望自己的 MVP 看起来如何呢?

  2. 我们该如何实现?构建一个全新的云环境很容易,但是要把一个现有的基础设施平稳迁移到云上就没有那么容易了。

  3. 我们的环境在一年后又会是什么样子?我们知道自己的基础设施不会在第一天就很完美,这没关系,但我们希望会在接下来成功。


我会在这里详细讨论第一个问题。

MVP 架构

单单要求开发团队迁移到云上已经很困难了,而在迁移过程中又不断要求他们重新设计原有的应用程序,这就给整个过程带来了很大的不确定性。所以当我们不能在 GCP 中找到适合我们基础设施的替代品时,我们会尽量避免重新设计原有架构。


即便这样,GCP 上的很多功能已经很棒了,也为我们的基础设施提供了一些足够直接的转换方式,我们也觉得在迁移时进行这些切换是非常适合的。


首先,我们保留的部分:


  • 我们的本地环境有一个单逻辑内部网络。内部服务通过私有 IP 进行通信,大部分通过 Hashicorp Consul 进行协调。我们认为保留这一点对应用程序团队至关重要,至少在迁移期间是这样的。通过使用专用互连共享VPC网络,我们为开发人员提供了一个就像本地数据中心扩展一样的云。

  • Liveramp 的大数据处理核心 ETL 和连接管道都运行在 Cloudera Hapdoop 平台上。这一点不会改变,至少目前不会。

  • 尽管本文的重点不是我们的安全和数据隐私决策,但它们与我们做的每一件事都息息相关。我们的运营团队保留了对数据权限和网络规则的控制权。云平台让开发人员更加强大,但也使他们更容易做出非常愚蠢的决定。只有当你知道你不能意外泄露客户数据时,你才能更容易进行安全快速的开发。


那我们又需要改变那些部分呢?有很多,但这里将重点关注下面的三种技术:



在本地数据中心,我们很自然地选择 Hadoop HDFS 来保存持久数据。虽然我们的 HDFS 集群在迁移时仍然运行良好,但无停机或无中断的维护和升级要求让我们倍感压力。随着公司的发展,我们能够跟产品团队协调的停机时间也越来越短,直到再也无法在规定停机时间内完成升级。我们知道我们想使用 GCS(谷歌云存储),只有这样才可以保持作为开发团队的灵活性。


在本地数据中心,我们使用 Chef 管理所有的虚拟机。我们在 Chef 中嵌入了很多逻辑,也尝试在云平台中使用 Chef 管理虚拟机,但是效果不佳。再加上 Docker 和 Kubernetes 为我们提供了非常好的使用体验,我们最终在新环境里完全放弃了 Chef。


最后一点,我们认为 Google 的 BigTable 可以很好地替代我们自主研发的键值数据存储。放弃一个已经使用了这么久的工具的确令人难过,但只有这样才能让我们专注于那些新的令人兴奋的挑战。

云上 Hadoop

接下来,我将着重介绍一下我们的 Hadoop 基础设施,包括过去和现在。我会简要介绍一下我们的基础设施,以及我们在 GCP 上的构建。


下面是我们本地 Hadoop 集群的一个高度简化视图:



为保持简洁,该图省略了 Journal Nodes、ZooKeeper 和 Cloudera 管理角色。值得一提的是,该生产环境集群能够:


  • 在不同开发团队之间共享;

  • 在不随负载扩展的物理节点上运行;

  • 从网关虚拟机启动作业;

  • 将所有数据存储在一个 HDFS 联邦中(4 个 HA NameNode 对);

  • 自 2009 年以来持续运行(除了某些系统升级的时段)。


毫无疑问,HDFS 是最具可伸缩性的本地文件系统,但与云原生的对象存储(S3,GCS)相比仍有一些缺点。例如,数据会随着实例的销毁而丢失(除非你还保留了持久磁盘记录)。在设计云集群时,我们知道有以下需求:


  • 能够长期运行的临时集群(有问题?结束当前集群重启一个开始就好);

  • GCS 中所有重要的数据;

  • 按应用程序团队隔离集群;

  • 快速自动伸缩;

  • 从 GKE(谷歌 Kubernetes 引擎)发起工作任务。


所以,我们得到了如下所示的设计:



上图包含了很多内容,让我们逐个分析:


  • 不同的集群按应用程序团队运行在不同的子网中;

  • 工作任务从 GKE 发起而不是从虚拟机发起。每个 pod 中只包含一个应用程序,不再需要手动将应用程序打包到虚拟机上;

  • HDFS 仍然存在,但只有很少的一部分:YARN 使用 HDFS 保存 JobConf、分布式 Cache 和应用程序日志。但所有的应用程序数据都存储在 GCS 上;

  • 因为几乎不怎么使用 HDFS,所以我们只需要几个数据节点。大多数 worker 节点只是节点管理器。它们可以根据应用程序负载快速伸缩。


我会在另一篇文章中更详细地讨论这个问题,但重点是,临时的去数据化基础设施让我们在配置和机器类型上迭代的速度比在物理机器上快了 1000 倍。


这些决定为我们的迁移提供了一个起点。在下一篇文章中,我将讨论迁移的实现细节问题,重点讨论如何在吞吐量有限的情况下处理数据复制。


原文链接:


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


相关阅读:


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


2020-02-20 10:061335

评论

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

HMS Core Discovery第17期回顾|音随我动,秒变音色造型师

HarmonyOS SDK

音频技术

最长字符串链,什么是“词链”?

掘金安东尼

算法 前端 8月月更

转转客户端持续交付—鲁班的构建管理

转转技术团队

CI/CD

视频结构化——原子能力解析

夏夜许游

物体检测 车牌识别 视频结构化 人体检测

再深一点:如何给女朋友解释什么是微服务?

浅羽技术

微服务 微服务架构 单体架构 微服务框架 8月月更

微服务面试必问的Dubbo,这么详细还怕自己找不到工作?

浅羽技术

微服务 dubbo 微服务框架 Dubbo服务 8月月更

了解“预训练-微调”,看这一篇就够了

博文视点Broadview

SpringBoot 打包发布

jar Linux SpringBoot 2 8月月更

超简单!Redis中的持久化策略汇总

知识浅谈

8月月更

软件,英特尔人工智能的未来重点布局

科技之家

详解GaussDB(DWS) 资源监控

华为云开发者联盟

数据库 后端

Bytebase 部署体验总结 & 评选结果

Bytebase

数据库 体验官

iofod - 新拟物设计的跨平台实践

iofod jude

FFmpeg打开输入文件

mei2022

8月月更

设备健康管理“悬丝诊脉”之能源行业浆液循环泵

PreMaint

设备健康管理 设备预测性维护 设备状态监测

活动报名:Tapdata 开源教程之异构数据库模型推演

tapdata

Tapdata 开源社区

项目经理的职能在Scrum框架下没有完全消失

ShineScrum

Scrum 敏捷 项目经理

🔛报名启动!「数智创新行」系列城市站沙龙首站开启

云桌派

流程挖掘的价值:头部制造业千万级增长的底牌

望繁信科技

阿里云视觉智能开放平台产品上新——能力前瞻

夏夜许游

人工智能 阿里云 元宇宙 图像分割 阿里云视觉智能开放平台

HarmonyOS开发者创新大赛总决赛结果公布

HarmonyOS开发者

HarmonyOS

[极致用户体验] 如何实现响应式canvas?保持canvas比例?教你让canvas自适应屏幕宽度!

HullQin

CSS JavaScript html 前端 8月月更

阿里云计算巢软件免费试用中心正式上线,企业用户可免费试用1个月

阿里云弹性计算

计算巢

深势科技创始人&首席科学家张林峰:AI+分子模拟,赋能药物发现新源头

阿里云弹性计算

AI gpu 药物研究 分子模拟

优秀的程序员不能只懂技术

LigaAI

程序人生 敏捷开发 自我提升 职场发展 企业号九月金秋榜

Spring Data 测试时的 Repository 提示为空对象

HoneyMoose

nft交易平台开发流程

开源直播系统源码

NFT 数字藏品 数字藏品系统

渗透攻防Web篇-深入浅出SQL注入

京东科技开发者

sql 安全 mybatis Web H5

企业数据现状分析:为什么需要实时数据?如何高效挖掘实时数据价值?

tapdata

Tapdata

@DataJpaTest 进行测试的坑

HoneyMoose

云原生(二十六) | Kubernetes篇之Kubernetes(k8s)持久化

Lansonli

云原生 k8s 8月月更

大数据公司 LiveRamp 上云记(二):哪些功能可以直接迁移,哪些需要重新设计?_大数据_Benjamin Podgursky_InfoQ精选文章