【大数据】为什么适用Ceph上运行Spark ?(三部分第一部分)
几年前,一些大公司开始运行Spark和Hadoop分析集群,使用共享Ceph对象存储来扩充和/或取代HDFS。
我们开始调查他们为什么要这么做,以及它的表现如何。
具体来说,我们想知道以下三个问题的第一手答案:
- 公司为什么要这么做?(这篇文章)
- 主流的分析作业会直接运行在Ceph对象存储上吗?(见“为什么Ceph上有Spark ?”(第三部分第二部分)”)
- 它的运行速度会比在HDFS上的本机慢多少?(见“为什么Ceph上有Spark ?”(第三部分)")
我们将在一个由三部分组成的博客系列中对这些问题提供摘要级别的答案。此外,对于那些想要更深入的人,我们将交叉链接到一个独立的参考体系结构博客系列,提供详细的描述、测试数据和配置场景。和Ceph在英特尔硬件上工作得更好,并帮助企业有效地扩大规模。
第1部分:公司为什么要这么做?
众人的敏捷,一人的力量。
许多分析集群的敏捷性,以及一个共享数据存储的能力。
(好吧…简单的对联已经够多了。)
以下是我在与30多家公司交谈后发现的一些常见问题:
- 共享相同分析集群的团队经常会感到沮丧,因为其他人的工作经常妨碍他们按时完成工作。
- 另外,一些团队希望在他们的集群中保持旧的分析工具版本的稳定性,而他们的同行团队需要加载最新和最好的工具版本。
- 因此,许多团队需要自己独立的分析集群,这样他们的工作就不会与其他团队争夺资源,因此他们可以根据自己的需求调整集群。
- 但是,每个单独的分析集群通常都有自己的非共享HDFS数据存储——创建数据竖井。
- 为了跨竖井提供对相同数据集的访问,数据平台团队经常在HDFS竖井之间复制数据集,试图保持它们的一致和最新。
- 结果,公司最终维护了许多独立的、固定的分析集群(一种情况下超过50个),每个集群都有自己的HDFS数据竖井,其中包含数据PBs的冗余副本,同时维护一个容易出错的脚本迷宫,以保持竖井之间的数据集更新。
- 但是,在不同的HDFS筒仓上维护5、10或20个多pb数据集副本的成本对许多公司来说都是高昂的(包括CapEx和OpEx)。
在图片中,他们的核心问题和最终选择如下所示:
Figure 1. Core problems
Figure 2. Resulting Options
事实证明,AWS生态系统多年前就通过Hadoop S3A文件系统客户端为选择#3(见上面的图2)构建了一个解决方案。在AWS中,您可以在EC2实例上启动许多分析集群,并在它们之间在Amazon S3上共享数据集(例如,请参阅Cloudera CDH对Amazon S3的支持)。在启动新的集群后,不再有冗长的延迟混合HDFS存储,或者在集群终止时去staging HDFS数据。使用Hadoop S3A文件系统客户端,Spark/Hadoop作业和查询可以直接针对共享S3数据存储中的数据运行。
底线……越来越多的数据科学家和分析师习惯于在AWS上快速创建分析集群,访问共享数据集,而不需要耗时的HDFS数据混合和分离循环,并期望在本地拥有相同的功能。
Ceph是排名第一的开源私有云对象存储平台,提供与s3兼容的对象存储。对于那些希望为其本地分析师提供兼容s3的共享数据湖体验的公司来说,这是(现在也是)自然的选择。
要了解更多信息,请继续本系列的下一篇文章,“为什么在Ceph上使用Spark ?(第三部分):主流的分析作业会直接运行在Ceph对象存储上吗?
原文:https://www.redhat.com/en/blog/why-spark-ceph-part-1-3
本文:http://jiagoushi.pro/node/1502
讨论:请加入知识星球【首席架构师圈】或者小号【cea_csa_cto】或者QQ【2808908662】
- 76 次浏览