介绍
几年前，一些大公司开始运行Spark和Hadoop分析集群，使用共享Ceph对象存储来扩充和/或取代HDFS。
我们开始调查他们为什么要这么做，以及它的表现如何。
具体来说，我们Red Hat Storage解决方案架构团队想要知道以下三个问题的第一手答案:
- 公司为什么要这么做?(见“为什么Ceph上有Spark ?”(第三部分第一部分)”)
- 主流的分析作业会直接运行在Ceph对象存储上吗?(见“为什么Ceph上有Spark ?”(第三部分第二部分)”)
- 它的运行速度会比在HDFS上的本机慢多少?(这篇文章)
对于那些想要更深入,我们将交联到一个单独的architect-level博客系列,提供详细的描述,测试数据,和配置场景,我们记录与英特尔这个播客,我们谈论我们的关注使火花,Hadoop, Ceph在英特尔工作更好的硬件和帮助企业有效地扩展。
研究结果总结
我们用不同的工作负载做了Ceph和HDFS的测试(关于一般工作负载的描述，请参阅博客第2部分和第3部分)。正如预期的那样，价格/性能比较基于以下几个因素而有所不同。
显然，许多因素影响着整体解决方案的价格。由于存储容量通常是大数据解决方案价格的主要组成部分，我们在价格/性能比较中选择了它作为价格的简单代理。
在我们的比较中，影响存储容量价格的主要因素是使用的数据持久性方案。由于复制数据持久性为3倍，客户需要购买3PB的原始存储容量来获得1PB的可用容量。在erasure code 4:2的数据持久性下，客户只需要购买1.5PB的原始存储容量就可以得到1PB的可用容量。HDFS使用的主要数据持久性方案是3倍复制(对HDFS擦除编码的支持正在出现，但在一些发行版中仍处于试验阶段)。Ceph多年来一直支持擦除编码或3倍复制数据持久性方案。所有与我们合作的Spark-on-Ceph早期采用者都出于成本效率的原因使用擦除编码。因此，我们的大多数测试都是使用Ceph擦除编码的集群(我们选择EC 4:2)。我们还用Ceph的3倍复制集群进行了一些测试，为这些测试提供了苹果对苹果的比较。
使用上面提到的相对价格的代理，图1提供了一个HDFS v. Ceph价格/性能的总结:
Figure 1: Relative price/performance comparison, based on results from eight different workloads
图1描述了基于八种不同工作负载的价格/性能比较。这8个工作负载中的每一个都使用HDFS和Ceph存储后端运行。Ceph解决方案相对于HDFS解决方案的存储容量价格要么相同，要么少50%。当使用复制了3倍的Ceph集群运行工作负载时，存储容量的价格显示为与HDFS相同。当使用Ceph erasure编码的4:2集群运行工作负载时，Ceph存储容量的价格显示为比HDFS低50%。(参见前面关于数据持久性方案如何影响解决方案价格的讨论。)
例如，工作负载8对于Ceph或HDFS存储具有类似的性能，但是Ceph存储容量的价格是HDFS存储容量价格的50%，因为Ceph运行的是一个擦除编码的4:2集群。在其他示例中，工作负载1和2使用Ceph或HDFS存储具有类似的性能，并且具有相同的存储容量价格(工作负载1和2使用复制了3倍的Ceph集群运行)。
发现细节
这里提供了一些使用Ceph和HDFS存储测试的工作负载的细节，如图1所示。
细节1
这个工作负载是一个通过TestDFSIO比较聚合读吞吐量的简单测试。如图2所示，当Ceph也使用3x复制时，HDFS和Ceph之间进行了比较。当Ceph使用擦除编码4:2时，对于更少的并发客户端(<300)，工作负载比HDFS或Ceph的3倍表现得更好。然而，在更多的客户机并发性下，Ceph 4:2上的工作负载性能由于主轴争用而下降(一个带有擦除编码的4:2存储的读取需要4次磁盘访问，而一个带有3倍复制存储的磁盘访问需要4次磁盘访问)。
Figure 2: TestDFSIO read results
细节2
这个工作负载比较了一个单用户执行一系列查询(54个TPC-DS查询，如博客2或3所述)的SparkSQL查询性能。如图3所示，当在HDFS或Ceph的3倍复制存储上运行时，总的查询时间是相当的。在运行Ceph EC4:2时，聚合查询时间翻了一番。
Figure 3: Single-user Spark query set results
细节3
该工作负载比较了10个用户每个并发执行一系列查询的Impala查询性能(54个TPC-DS查询由每个用户以随机顺序执行)。如图1所示，Ceph EC4:2上这个工作负载的总执行时间比HDFS慢了57%。但是，价格/性能几乎可以比较，因为HDFS的存储容量成本是Ceph EC4:2的2倍。
细节4
这种混合工作负载的特点是并发执行一个单用户运行SparkSQL查询(54个)，每个10个用户运行Impala查询(每个54个)，以及一个数据集合并/连接作业，用合成的点击流日志丰富TPC-DS web销售数据。如图1所示，Ceph EC4:2上这种混合工作负载的总执行时间比HDFS慢48%。但是，价格/性能几乎可以比较，因为HDFS的存储容量成本是Ceph EC4:2的2倍。
细节5
这个工作负载是通过TestDFSIO比较聚合写吞吐量的一个简单测试。如图1所示，这个工作负载在Ceph EC4:2上执行的平均速度比HDFS慢50%，跨一系列并发客户机/写入器。但是，价格/性能几乎可以比较，因为HDFS的存储容量成本是Ceph EC4:2的2倍。
细节6
这个工作负载比较了单用户执行一系列查询(54个TPC-DS查询，如博客2或3所述)的SparkSQL查询性能。如图3所示，当运行在HDFS或Ceph 3倍复制存储时，总的查询时间是相当的。在运行Ceph EC4:2时，聚合查询时间翻了一番。然而，在Ceph EC4:2上运行时，价格/性能几乎可以比较，因为HDFS的存储容量成本是Ceph EC4:2的2倍。
细节7
这个工作负载的特点是用合成的点击流日志丰富(合并/连接)TPC-DS网络销售数据，然后写入更新的网络销售数据。如图4所示，Ceph EC4:2上的工作负载比HDFS慢37%。但是，价格/性能对Ceph是有利的，因为HDFS的存储容量成本是Ceph EC4:2的2倍。
Figure 4: Data set enrichment (merge/join/update) job results
细节8
这个工作负载比较了10个用户每个并发执行一系列查询的SparkSQL查询性能(54个TPC-DS查询由每个用户以随机顺序执行)。如图1所示，尽管只需要50%的存储容量成本，但Ceph EC4:2上这个工作负载的总执行时间与HDFS的大致相当。这个工作负载的价格/性能因此有利于Ceph的2倍。要更深入地了解这种工作负载性能，请参见图5。在这个盒须图中，每个点反映了单个SparkSQL查询执行时间。因为这10个用户中的每个都同时执行54个查询，所以每个系列有540个点。显示的三个系列是Ceph EC4:2(绿色)、Ceph 3x(红色)和HDFS 3x(蓝色)。Ceph EC4:2框显示了相当于HDFS 3倍的中间执行时间，并在中间2个四分位数显示了更一致的查询时间。
Figure 5: Multi-user Spark query set results
奖励结果部分:24小时摄入
我们的一个潜在Spark-on-Ceph客户最近要求我们说明Ceph集群在24小时内的持续摄取率。对于这些测试，我们使用了博客2 / 3中描述的实验室变体。如图6所示，我们在配置了700个HDD数据驱动器(Ceph OSDs)的Ceph EC4:2集群中测量了每天大约1.3 PiB的原始摄取速率。
Figure 6: Daily data ingest rate into Ceph clusters of various sizes
结论观察
总之，下面是我们对上述结果的成本/收益分析，总结了本系列博客。
Spark-on- ceph vs. Spark在传统HDFS上的好处:
- 通过减少重复减少资本支出:当多个分析集群需要访问相同的数据集时，减少购买在HDFS筒仓中存储重复数据集的冗余存储容量的PBs。
- 降低OpEx/risk:当多个分析集群需要访问相同的数据集时，消除HDFS竖井之间的脚本/调度数据集副本的成本，并降低在HDFS竖井上试图维护这些重复数据集之间的一致性时的人为错误风险。
- 从新的数据科学集群加速洞察:通过在共享数据存储库中原位分析数据，而不是在开始分析之前将数据复制到一个新集群，从而在创建新的数据科学集群时减少洞察时间。
- 满足不同数据团队的不同工具/版本需求:在团队之间共享数据集的同时，允许每个集群内的用户选择适合其工作的Spark/Hadoop工具集和版本，而不会干扰其他需要不同工具/版本的团队的用户。
- 适当大小的CapEx基础设施成本:通过适当大小的计算需求(vCPU/RAM)，独立于存储容量需求(吞吐量/TB)，减少传统HDFS集群中常见的计算或存储过度供应，通过增加通用节点(无论是否只需要更多的CPU核或存储容量)。
- 通过提高数据持久性效率来降低资本支出:Ceph erasure编码效率比HDFS默认的3倍复制降低了高达50%的存储容量购买的资本支出。
Spark-on- ceph vs. Spark在传统HDFS上:
- 查询性能:Spark/Impala查询任务执行时间延长0% ~ 131%(单用户和多用户并发测试)。
- 写作业性能:面向写作业(加载、转换、充实)的性能范围为37%-200%+更长的执行时间。[注意:当下游发行版对Hadoop S3A客户端采用以下上游增强Hadoop -13600、Hadoop -13786、Hadoop -12891]时，写作业性能有望显著改善。
- 混合工作负载性能:并发执行多个查询和充实作业的性能导致执行时间延长90%。
要了解更多细节(以及亲身体验此解决方案的机会)，请继续关注这个Red Hat Storage博客位置的架构级博客系列。感谢你的阅读。
原文：https://www.redhat.com/en/blog/why-spark-ceph-part-3-3
本文：http://jiagoushi.pro/node/1504
讨论：请加入知识星球【首席架构师圈】或者小号【cea_csa_cto】或者QQ【2808908662】