AWS 云 VS 阿里云 横向对比

文章背景

个人日常工作中，会涉及到多云的大数据环境使用及运维，主要涉及到 AWS 云 EMR、阿里云 EMR、还有华为云 MRS，所以一直考虑开一篇文章，来描述下个人在使用云上大数据集群服务（Elastic Map Reduce)的一些个人的感悟，希望也能帮助后续上云的朋友，能够提供一些不一样的视角来感受下云上大数据服务。

本文并没有包含一些实战内容，而是从个人最佳实践以及踩过的一些坑来进行总结，分享下个人的一些经验和方案，尝试在大方向上横向对比下两朵云（AWS 和 Aliyun）上 EMR 服务的体验。

当然如果大家想了解实战内容，可以留言反馈具体方面，我也尝试写一些实战内容。

功能架构篇

先上官方的两张的描述自己的 EMR 架构图片， 我个人直观感受还是比较喜欢 AWS 这种风格，描述的简单明了，同时实际上内部的功能并不别阿里云的少，只是并没有想通过一张图片就想全部展示出来。 阿里云的就是有点过于丰富了，想通过一张图片把所有的东西都展示出来，有点堆砌的感受。

产品形态对比

两个 EMR 的产品形态对比，我们一一对比：

AWS EMR on EC2 VS Aliyun EMR on ECS：

本质上都是基于各自云服务上的主机搭建的，也就是计算节点就是云主机，但是收费模式都有包年包月，按需付费，竞价节点模式 这块基本上没啥区别，主要是体现在费用的问题。

• 包年包月：就是提前约定好使用长周期，可以享一定折扣

• 按需付费：按实际使用时长付费，销毁之后就不再收费，更为灵活，但是每小时单价更高一些

• 竞价节点：按竞价高低付费，可以设置竞价上限，日常平均会比按需便宜 50%以上，要看具体可用区的资源紧张程度，但是会存在资源被其他方抢占，或者可用区无竞价资源导致申请不下来计算节点

AWS EMR on EKS VS Aliyun EMR on ACK：

EKS ACK 分别是各自云服务的托管的 Kubernetes 服务，EKS 背后可以是 EC2 或者 Fargate，Fargate 可以理解更细粒度的使用计算资源，AWS EMR on EKS 和 AWS EMR on EC2 之间的区别，可以看下图。

Aliyun on ACK 集群同样底层有 ECS 和 ECI， 同时我看官网主要描述的优势为：同其他应用共享一个集群，实现计算资源跨可用区共享。

AWS EMR on Serverless VS Aliyun EMR on Serverless：

Serverless 服务即为无服务器服务，让使用者不需要考虑服务器等资源，专注于即时使用，用后销毁。

• AWS EMR on Serverless：结合 aws emr studio 开发 spark 或 hive 任务，然后通过 emr on serverless 执行，方便数据科学家用来使用，同时不需要考虑 aws emr 背后的架构以及配置。

• Aliyun EMR on Serverless：目前来说 阿里云的是单指 Starrocks 的 serverless，也就是阿里云基于开源版 starrocks 适配，构建在阿里云上，同时 starrocks 本身是 MPP 架构，也适合横向扩展，从我个人理解上来说，其实这块是属于 OLAP 的，但是阿里云把它归集到 EMR 内，估计也是考虑到一般用 EMR 的场景也是会需要 OLAP 解决方案，但是这里并不是真正的 Serverless，只是提供了一个快速伸缩的功能，使用时快速扩展计算节点。

AWS EMR on Outposts

这种解决方案目前阿里云还没有跟进，Outposts 可以理解为，一些大一点的厂商，希望用 AWS 云的服务同时又很看重数据安全性，AWS 可以支持在厂商的数据中心部署一整天 AWS 服务，但是网络是和外部隔离的，安全性更有保障，EMR on Outposts 也就是可以在自己的数据中心中，使用 AWS EMR 服务。

方案选择

如果是初次使用 EMR 服务的话，无论 AWS 还是 Aliyun 都推荐直接使用 EMR on 云主机（EC2 or ECS)，相对基于 EMR on Kubernetes(EKS or ACK) 来说，上手更容易，以及初期人工维护成本低，当任务上了一定规模，需要进行资源优化，可以再考虑逐步切换到 容器编排上，降本增效，做精细化管理。

架构设计篇

节点类型

整体架构，阿里云和 AWS 云是相近的，都是分 Master -> Core -> Task 三种类型节点，阿里云特殊的包含一种叫做 Gateway 的提交机，这个会单独讲下，然我们先看下各种类型节点的功能。

• Master 节点 : 也就是主节点，大数据集群的的一些服务的主节点都配置在这上边，Yarn，Hive，Hadoop 的 NameNode，所以这个 Master 节点至关重要，所以一般如果生产环境配置，可以配置多个 Master 节点，一个 Primary，其他的为 Slave 节点，日常 standby，主节点异常，进行主备切换。

• Core 节点：可以理解为 Hadoop DataNode ，HDFS 存储的位置，同时也提供计算资源，但是 EMR 集群的使用中，一般不会把重要数据存储在这里，云上都是计算存储分离，AWS 云提供 S3 对象存储，阿里云提供 OSS 对象存储，所以正确用法，只使用 EMR 的计算资源，HDFS 只存储临时日志或者提交任务的相关依赖文件。这样就只会挂少量的云盘存储，节省存储费用。Core 节点一般只需要少量固定数量就可以，同时需要注意 Core 节点不适合缩容，所以注意不要设置过大。

• Task 节点：纯计算节点，不需要挂存储空间，根据计算规模调节数量，EMR 一般提供系统自动扩缩容功能，但是实际生产中还是建议根据业务自主控制

• Gateway 节点：这个是阿里云特有的，个人认为比较有亮点的功能。gateway 可以理解为大数据程序提交机，可以通过 gateway 节点提交 flink 或者 spark 等任务，如果公司本身有自研系统，需要适配的话，只需要适配 gateway，然后通过 gateway 绑定到指定的 emr 集群，就可以了，实现解耦，后续销毁或者重新创建 emr，只需重新绑定即可。

实例类型选择

Master 节点必须是按需或者包年包月的 Core 节点也是要按需或者包年包月，目前来说尝试过在 AWS 上 core 节点选择过 spot 模式，但是出现过，资源紧张情况下，spot 都被回收，emr 集群整体不可用。Task 节点可以选择 Spot 模式，但是也要分情况，如果是跑 Flink 这种常驻应用，就不适合用 Spot 模式，如果跑离线任务，重试策略，监控策略配置好，可以选择 Spot 模式来搞，省钱很可观。还有一种叫做实例队列模式，就是节点的实例类型可以选多种，方便后续扩容，缩容的时候根据场景，配置不同类型的实例（比如 核内存比 1:2， 或者 1:8 都选一些，应付不同场景），但是实际使用下来，这种的属于进阶配置了。

个人体验

技术角度：

作为一个技术人员，我在整套使用下来更偏好于 AWS EMR 的使用，说下我个人喜欢的几点：

1. 文档全面： 无论是技术架构，基础使用教程，还是最佳实践以及常见问题 都有详细的文档供我们查阅，身为一名合格的技术人员，个人认为查阅技术文档是解决一般问题最快的途径，基本上 AWS 的技术文档可以解决我迄今为止遇到的 90%以上的问题。但就是需要转变思想，做之前要先详细读相关技术文档，摸清整体架构以及功能。反过来，阿里云这方面是反面了，很多文档过时，链接失效，甚至有的都是错误的，我有时是按照已知在 AWS 如何配置，然后按图求索在阿里云上去找相关解决方案的。基本上很多问题都是直接钉钉提工单，但是基本上对接的技术口，也不是很懂有很多初级问题，都拿不准解决方案，然后不得不扩大范围，拉更多人来回答，十分耗时间。

2. 版本的稳定，开源：基本上 EMR 上用到的都是主流的开源版本，所以各大厂商如果平时也使用的主流开源版本，那么上云迁移过程，很多都是平替兼容的，不需要有多少大的改动，同时这样也不用担心被厂商完全绑定，可以依旧延续开源框架。反观阿里云，大家应该知道 FLink 的母公司，阿里几年前已经收了过来，所以 EMR 上 flink 是对应的商业版本 vvr 同时内部有个加速层，jindo 也是要闭源的同样要进行适配，所以整体上阿里云 EMR 有很多自己自研的同时还对用户暴露的服务，使用过程中要不适配，要不迁移，如果能做到对用户使用透明，只体现在性能上就更好了。

3. 技术支持：这一点上，还是阿里云做的比较适合国人的使用习惯，日常钉钉整个工单体系，只要有问题，直接钉钉群里艾特机器人，就可以里面创建私聊群，相关产品服务的技术支持人员就里面跟你沟通，虽然技术专业性有待商榷，但是这样的服务水准和 AWS 比，简直是全方面吊打。平时可能没有感觉，如果遇到线上紧急生产事件，能够第一时间联系到云厂商，对一些初创小公司来说，会增加不少信心。反观 AWS，玩法不太相同，日常问题是需要提工单的，同时工单是分等级的，你需要购买相关支持力度的费用（比如聊天回复响应时长一天，电话立即沟通 响应时间 分钟级，价格是不同的），但是整体服务水平比阿里云高很多，背后都是很专业的技术人员，同时具体问题，也会出具相关排查问题报告，告诉你具体什么原因以及相关最佳实践的解决方案。

4. 日常沟通：阿里云是大群模式，只要你在云上用了哪些服务，都会拉一些相关技术专家进来，日常帮你答疑解问，相当于一个群里各种问题交织在一起，AWS 不同的是主要有一名 SA(解决方案架构师)，是一名资历，技术能力全方位很厉害的，帮你答疑，如果遇到具体服务细节，才会拉专门同事沟通，但是日常问题都会经过这名 SA，先过滤一下。 这两种方式，只能说思路是完全不一样的，体验上也分公司而已吧。

公司角度：

如果从公司发展和数据敏感性上来说，估计基本上国内很多厂商还是会偏重阿里云，说下个人的理解：

1. 如果海外业务大多数还会用 AWS 云，因为国外的安全合规这块，还是 AWS 耕耘的历史长，标杆在那里呢。同样国内来说，尤其目前中美关系上来说，核心数据放在阿里云上更保险些。

2. 阿里云及时目前使用体验上略逊 AWS，但是不得不承认，整体功能上和 AWS 不分上下，甚至有些情况下，阿里云更符合国人的习惯，换个思路，上云是为了服务业务发展而不是为了技术人员体验，AWS 虽然有些方面做的深受技术人员喜欢，但是目前国内整体云计算的普及还处在快速发展阶段，国内很多传统企业上云，但是企业内部技术人员对云计算知识水平有限，上云的辅导和人力的投入也是必要的，这点上阿里云是符合国情的。 但是还是希望后续技术专业度以及技术文档的准确性还是有待提高的。

3. 最后就是价格战了，基本上 AWS 上有的服务，阿里云上有同样对标的，虽然有些可能属于后面发展的，服务与服务之间协同能力弱些，但是能力差距没有明显到会影响到公司发展，同时不得不说，阿里云上也有很多有服务是 AWS 不具有的，这个细节就是见仁见智了。但是整体上阿里云产品是比 AWS 的产品便宜不少，以及商务洽谈，可竞价的尺度也不一样，这个就不展开说了。

总结：

个人第一次使用云上产品就是阿里云 OSS，那时候还是 14 年，但是对于当年刚入行的我来说只是用了表面功夫，随着工作深入也用过一些小众的云，比如当年的乐视云，如今的青云，腾讯云也用上了一点。 19 年随着公司大数据整体上云（AWS 云），我作为公司技术预研的角色以及实施小组核心成员，全面了解以及学习了 AWS 云，并亲手参与实施了大数据整体上云工作，第一次了解并使用了诸如：VPC、EMR、IAM、Kinesis、Athena、RedShift、CloudWatch、Lambda、Organization 等服务，并深刻学习了云上的实施构建一整套流程。深受影响，并被吸引，后续为了加深理解云计算概念，我又在 22 年利用业余时间学习，并最近考取了 AWS 的 SAA 和 SAP(solution architect professional)认证，这个过程中相当于对云环境有了更深刻的理解，之后过程中我接触的阿里云和华为云上相关产品，我都可以很容易的理解以及对各种服务的结合使用也得心应手。

云计算已经是当下技术人员的必学的一门课程，如果有时间也鼓励大家可以多了解学习，提升自己的专业能力，阿里云也有相关认证 ACP 和 ACE，感兴趣的朋友也可以了解一下。如果有任何问题，需要沟通交流也可以添加我的个人微信 coder_wukong，备注：云计算，或者关注我的公众号 WuKongCoder 日常也会不定期写一些文章和思考。

如果觉得文章不错，欢迎大家点赞，留言，转发，收藏 谢谢大家，我们下篇文章再会~~~