介绍
几年前,一些大公司开始运行Spark和Hadoop分析集群,使用共享Ceph对象存储来扩充和/或取代HDFS。
我们开始调查他们为什么要这么做,以及它的表现如何。
具体来说,我们想知道以下三个问题的第一手答案:
- 公司为什么要这么做?(见“为什么Ceph上有Spark ?”(第三部分第一部分)”)
- 主流的分析作业会直接运行在Ceph对象存储上吗?(这篇文章)
- 它的运行速度会比在HDFS上的本机慢多少?(见“为什么Ceph上的Spark(第三部分)”)
对于那些想要更深入,我们将交联到一个单独的architect-level博客系列提供详细描述,测试数据,和配置场景,我们记录与英特尔这个播客,我们谈论我们的关注使火花,Hadoop, Ceph在英特尔工作更好的硬件和帮助企业有效地扩展。
使用Ceph对象存储的基本分析管道
我们的早期采用者客户正在直接摄取、查询和转换数据到共享的Ceph对象存储。换句话说,他们的分析工作的目标数据位置是Ceph中的“s3://bucket-name/path-to-file- In -bucket”,而不是“hdfs:///path-to-file”。通过Spark、Hive和Impala等分析工具直接访问s3兼容的对象存储,可以通过Hadoop S3A客户端实现。
我们与几个客户合作,使用以下分析工具,成功地直接针对Ceph对象存储运行了1000多个分析作业:
Figure 1: Analytics tools tested with shared Ceph object store
除了运行像TestDFSIO这样的简单测试外,我们还希望运行能够代表现实世界工作负载的分析作业。为此,我们基于摄取、转换和查询作业的TPC-DS基准测试进行测试。TPC-DS生成合成数据集,并提供一组示例查询,用于模拟大型零售公司的分析环境,该公司拥有来自商店、目录和web的销售操作。它的模式有10个表,有些表中有数十亿条记录。它定义了99个预先配置的查询,我们从中选择了54个io密集的输出测试。与业内合作伙伴一起,我们还用模拟的点击流日志补充了TPC-DS数据集,比TPC-DS数据集大10倍,并添加了SparkSQL作业,以将这些日志与TPC-DS web销售数据连接起来。
总之,我们直接对Ceph对象存储运行了以下操作:
- 批量摄取(批量负荷工作-模拟1PB+/天的大容量流摄取)
- 摄取(MapReduce工作)
- 转换(Hive或SparkSQL作业,将纯文本数据转换为Parquet或ORC柱状压缩格式)
- 查询(Hive或SparkSQL作业-经常以批处理/非交互模式运行,因为这些工具会自动重启失败的作业)
- 交互式查询(Impala或Presto作业)
- 合并/连接(Hive或SparkSQL作业将半结构化的点击流数据与结构化的web销售数据连接起来)
架构概述
在过去的一年中,我们与4个大客户运行了上述测试的变体。一般来说,我们的架构是这样的:
Figure 2: High-level lab architecture
它工作了吗?
是的,上面描述的1000个分析任务成功完成了。SparkSQL、Hive、MapReduce、Impala作业都使用S3A客户端直接读写数据到共享的Ceph对象存储中。相关的架构级博客系列将详细记录所获得的经验教训和配置技术。
在本博客系列的最后一集中,我们将会看到最重要的一点——与传统HDFS相比,性能如何?有关答案,请继续阅读本系列的第3部分....
原文:https://www.redhat.com/en/blog/why-spark-ceph-part-2-3
本文:http://jiagoushi.pro/node/1503
讨论:请加入知识星球【首席架构师圈】或者小号【cea_csa_cto】或者QQ【2808908662】
最新内容
- 34 minutes 20 seconds ago
- 41 minutes 29 seconds ago
- 56 minutes 19 seconds ago
- 1 hour ago
- 1 hour ago
- 5 hours ago
- 7 hours ago
- 7 hours ago
- 7 hours ago
- 1 week 1 day ago