介绍

几年前，一些大公司开始运行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对象存储运行了以下操作: