介绍：

SQL over Hadoop 领域的早期采用者现在正在创建大型数据库来存储他们更珍贵的商品和数据。 IBM在2014年10月发布了第一个（也是唯一一个）经过独立审计的Hadoop-DS基准测试时预测了这一趋势.Hadoop-DS是行业标准TPC-DS基准测试的衍生产品，经过定制，可以更好地匹配SQL over Hadoop空间的功能在Data Lake环境中。那时，IBM使用10TB的比例因子来比较Big SQL与其他领先的SQL Over Hadoop解决方案，即Hive 0.13和Impala 1.4.1。从那时起，所有产品都在性能和可扩展性方面取得了重大进步。 HortonWorks和Cloudera也投入了大量资金来丰富他们对SQL语言的支持（IBM已经在那里）。

Spark已成为开源社区中分析的最爱，Spark SQL允许用户使用熟悉的SQL语言向Spark提出问题。因此，有什么更好的方法来比较Spark的功能，而不是通过它的步伐，并使用Hadoop-DS基准来比较性能，吞吐量和SQL与Big SQL的兼容性。由于这是2017年，Data Lakes日渐变大，我们选择使用100TB的比例因子。

本研究将再次强调SQL over Hadoop引擎的需求，该引擎不仅快速高效，而且更重要的是可以成功地对大数据执行复杂查询。在选择SQL over Hadoop解决方案时，性能不是唯一的因素。该解决方案还需要由成熟且强大的运行时环境进行备份。成本仍然是采用SQL Over Hadoop解决方案的企业的主要吸引力之一（特别是与传统的RDBM相比），但无论出于何种原因，失败的查询将严重影响生产力并降低这些SQL相对于Hadoop解决方案的成本效益。没有交付。

摘要

在项目过程中，我们发现Big SQL是唯一能够在100 TB下执行所有未修改的99个查询的解决方案，可以比Spark SQL快3倍，同时使用更少的资源。 这些事实使我们得出结论，使用Big SQL的Data Professional比使用Spark SQL的数据提高了3倍。

测试环境：

Big SQL和Spark SQL测试都在同一个集群上执行。 该集群的构建基于Spark; 也就是说，它有大量的内存和SSD取代了传统的旋转磁盘。

使用了28节点集群，包括：

• 2 management nodes (Lenovo x3650 M5), collocated with data nodes
• 28 data nodes (Lenovo x3650 M5)
• 2 racks, 20x 2U servers per rack (42U racks)
• 1 switch, 100GbE, 32 ports, 1U, (Mellanox SN2700)

每个数据节点包括：

• CPU: 2x E5-2697 v4 @ 2.3GHz (Broardwell) (18c) Passmark: 23,054 / 46,108
• Memory: 1.5TB per server, 24x 64GB DDR4 2400MHz
• Flash Storage: 8x 2TB SSD PCIe MVMe (Intel DC P3700), 16TB per server
• Network: 100GbE adapter (Mellanox ConnectX-5 EN)
• IO Bandwidth per server: 16GB/s, Network bandwidth 12.5GB/s
• IO Bandwidth per cluster: 480GB/s, Network bandwidth 375GB/s

配置和调整：

产品的配置和调整由两个不同的团队进行; IBM的Big SQL性能团队和Spark SQL性能团队。

Spark团队使用了最新发布的Spark SQL 2.1版。 Spark的调优符合Hadoop-DS规范中规定的规则，但有一个关键的例外。传递给Spark SQL shell的执行程序属性的数量针对单流和4流运行进行了不同的调整。 4流运行中的每个流都传递了执行器值，该值是用于单个流运行的值的四分之一。这阻止了4流中的任何一个流都抓住了集群上的所有执行槽，这实际上会导致每个查询串行执行。虽然这很简单，有些人可能会说逻辑调整，但实际上不可能在生产集群上有效地执行此操作，在生产集群中不会知道并发执行查询的数量。但是，该团队决定，如果没有这一调整，就无法与Big SQL进行公平的比较。

Big SQL Worker

 

Big SQL团队使用了Big SQL版本4.3的技术预览版。技术预览包含对新功能的支持，其中每个物理节点可以托管多个Big SQL工作进程（以前，每个物理节点上只允许一个Big SQL工作进程）。单个物理节点上的多个Big SQL工作程序在Big SQL环境中提供了更大的操作并行化，从而提高了性能。考虑到测试集群中计算机的大量内存和CPU资源，团队将每个物理节点配置为包含12个Big SQL worker - 如图1所示。

 

与Spark SQL不同，Big SQL不需要基于并发查询流的数量进行微调，因此使用了单流和4流运行的相同配置。这是可能的，因为Big SQL具有成熟的自治，包括：

• 自调整内存管理器（STMM），它根据查询并发性动态管理消费者之间的内存分配
• 一个复杂的工作负载管理器（WLM），可以控制工作负载优先级，有助于维持一致的响应时间并实施SLA
• 在查询执行时自动调整并行度以考虑系统活动

这些都是关键功能，可以解决调整Big SQL的痛苦 - 无论是在基准测试环境还是现实环境中 - 多年来，组织一直认为这些功能在关系数据库中是必不可少的，以支持生产环境。那么为什么在Big SQL中找到这些功能而在Hadoop解决方案中找不到大多数其他SQL？简而言之，这是因为IBM围绕我们现有的关系数据库技术（已经在生产系统中运行了25年）构建了Big SQL的核心。因此，Big SQL具有强化，成熟且非常高效的SQL优化器和运行时，以及一组支持生产级部署的功能 - 这些是Big SQL世界级可伸缩性和性能的关键。

对于此基准测试，大多数Big SQL调优工作都集中在单个节点上共存的多个Big SQL工作者（这是此功能首次在此规模上进行了道路测试）。此功能在Big SQL v4.3 Technology Preview中可用，并且可以在安装后通过Ambari手动添加逻辑Big SQL worker。 Big SQL工程团队正在利用从本练习中获得的经验来改进自动化，并为Big SQL v4.3版本设置有意义的开箱即用默认值。因此，Big SQL客户不必自己进行任何调整。 Spark SQL团队的经验被用于创建一组最佳实践。在Spark SQL具有一组成熟的自我调整和工作负载管理功能之前，必须手动应用这些最佳实践。

查询执行：

使用100TB数据，使用Big SQL v4.3在4个并发查询流中成功执行了源自TPC-DS工作负载的所有99个查询（总共创建了396个查询）。在第一次运行三个Big SQL查询时，执行时间比预期的要长。使用统计视图和列组统计信息调整这些查询。这些独特的功能对Big SQL客户来说非常宝贵;允许他们收集有关复杂关系的详细信息，这些信息通常存在于现实数据中，从而提高性能。跨比例因子的Spark查询失败

图3：跨不同比例因子的Spark SQL查询

 

图4：Spark SQL查询失败的分类

 

虽然Spark SQL v2.1可以在1GB和1TB上成功执行所有99个查询（并且自v2.0以来已经能够执行），但是在10TB时两个查询失败，并且在100TB时失败的次数明显更多。在花费大量精力调整Spark（由Spark工程师，而不是Big SQL工程师）之后，总共可以在100TB的4个流中成功执行83个查询。为了确保苹果与苹果的比较，这组83个查询被用作比较Big SQL与Spark SQL性能的基础。图4：100TB的Big SQL vs Spark SQL查询细分

图5：100TB的Big SQL和Spark SQL查询细分

 

Spark故障可分为2大类; 1）查询未在合理的时间内完成（少于10小时），以及2）运行时故障。此外，几乎一半（7）的Spark SQL查询在100TB时失败，本质上是复杂的。事实的这种组合表明Spark SQL在更大规模的因素下与更复杂的查询斗争;因为Spark是一种缺乏现代RDBMS成熟度的相对较新的技术，所以这应该不会让人感到惊讶。这些发现也与2014年最初的Hadoop-DS工作一致; Hive和Impala都在使用复杂的查询（所有这些都是10TB），但Big SQL能够成功执行所有99个查询，在30TB的4个流中。

数据专业人员或任何用户的主要抑制因素是浪费宝贵的时间将有效查询重写为SQL解释器可以理解的表单，以及执行引擎可以成功完成的表单。重要信息本研究中的数据表明，使用Spark SQL的Data Professional将花费宝贵的时间重新编写或调整，每10个查询中有1个或2个（确切地说是16％）。不幸的是，对于不成熟的SQL引擎，尤其是SQL over Hadoop空间中的那些，通常就是这种情况。在10TB的原始Hadoop-DS评估中，Hive和Impala首先突出了这个问题，今天仍然适用于Spark SQL。值得注意的是，对于许多SQL over Hadoop引擎，以较低比例因子成功执行查询并不能保证真正的大数据成功。

构建一个100TB的数据库

毫无疑问，100TB这是一个大数据工作负载 - 最终数据库包含超过五万亿行：

 

大事实表被分区以利用Big SQL v4.2以后的新“分区消除串联连接密钥”功能。所有销售表都在各自的'* _SOLD_DATE_SK'列上进行了分区，并在各自的'* _RETURN_DATE_SK'列中返回表。以这种方式进行分区符合原始TPC-DS规范，并允许在查询执行期间删除分区 - 这可以极大地提高查询的时间和效率。图7：100TB数据库构建

 

图7：100TB数据库构建时间（秒）

数据库构建包括两个不同的操作，即加载阶段和统计信息收集阶段。加载阶段从数据生成器生成的原始文本中获取数据，并将其转换为Parquet存储格式。 Parquet是Big SQL和Spark SQL中查询的最佳存储格式，是这些测试的理想选择。加载阶段对于Big SQL和Spark SQL都是通用的，只需要超过39个小时即可完成。

39小时中的大部分用于加载STORE_SALES表的NULL分区（SS_SOLD_DATE_SK = NULL）。事实证明，STORE_SALES表在空分区上严重偏斜（大小约为570GB，而其他分区大约为20GB）。由于查询是重复执行的，而数据库构建是一次性操作，因此两个团队都没有专门用于提高负载性能的资源。但实际数据集中的严重偏差很常见。此数据集中所选分区列的严重偏差给执行某些更复杂的查询带来了挑战。工程团队致力于改进Big SQL Scheduler以应对这些挑战，这些改进将在Big SQL v4.3中提供。

收集统计信息使Big SQL基于成本的优化器能够就最有效的访问策略做出明智的决策，并且是Big SQL可以执行具有领先性能的所有99个TPC-DS查询的关键原因。目前，Spark SQL不需要收集相同级别的统计信息，因为它的优化程序还不够成熟，无法使用这些详细的统计信息。但是，随着Spark优化器的成熟，它对详细统计数据的依赖性会增加，收集所述统计数据的时间也会增加，但查询过程时间也会随之改善。

比较Big SQL和Spark SQL性能：

在现实生活中，单个用户不能单独使用组织的Hadoop集群。因此，我们专注于比较4个并发查询流中Big SQL和Spark SQL的性能。为了进行苹果与苹果的比较，生成的工作负载仅包括在合理的时间内（少于10小时）在Spark SQL中成功完成的83个查询。删除Spark SQL无法在10小时内完成的查询会使结果偏向于Spark，因为保留四个超时的查询几乎会使Spark SQL执行时间翻倍。

 

图8比较了在Spark SQL和Big SQL中完成所有4个流（总共332个查询）的83个查询所用的时间，以及Big SQL在4个流中完成所有99个查询所用的时间（总计396个查询）。 Spark SQL花了超过43个小时来完成测试，而Big SQL在13.5个小时内完成了相同数量的查询 - 使Big SQL比Spark SQL快3.2倍。

图8：4个查询流的100TB工作负载经历时间

图8：100TB的工作负载经历时间

事实上，Big SQL能够完成一个4流工作负载，每个流执行99个查询的完整补充，几乎比Spark SQL每个流执行83个查询快2倍。当您考虑到Spark SQL无法执行的16个查询中的7个是工作负载中最复杂的查询时，这会更令人印象深刻。

虽然对于Big SQL来说令人印象深刻，但如果查询集包含来自99的原始集合中的那些查询，那么性能差异会大得多，这些查询在10小时后在Spark SQL中超时。

重要信息将这些结果输入到现实环境中意味着使用Big SQL的数据专业人员的效率比使用Spark SQL的数据专业人员高三倍。图9：平均CPU消耗的比较

图9：100TB的4流的平均CPU消耗

对整个群集的CPU消耗的分析表明，Big SQL在工作负载持续时间内平均为76.4％，Spark SQL为88.2％。虽然Big SQL和Spark SQL之间消耗的用户CPU百分比大致相同，但Spark SQL的系统CPU几乎是Big SQL的3倍。系统CPU周期是不合需要的CPU周期，它们没有代表您的应用程序执行有用的工作。注意：两种产品的IO等待CPU时间可以忽略不计。

当然，由于Spark SQL测试需要花费3倍的时间才能完成，因此在执行工作负载中的所有332个查询的过程中，Spark SQL实际上消耗的CPU周期比Big SQL多3倍，系统CPU周期比Big SQL多9倍 - 突出显示随着Big SQL优化器和运行时的成熟，效率更高。 Big SQL不仅比Spark SQL快3.2倍，而且使用更少的CPU资源也实现了这一点。

图10：100TB（每个节点）的4个流的平均I / O速率

在检查测试期间进行的I / O量时，Big SQL的效率也会突出显示。 Spark SQL的平均读取速率平均比Big SQL大3.6倍，而其写入速率平均高出9.4倍。在测试期间推断平均I / O速率（Big SQL比Spark SQL快3.2倍），然后Spark SQL实际读取的数据几乎是Big SQL的12倍，并且写入数据增加了30倍。

图11：100TB（每个节点）的4个流的最大I / O速率

有趣的是，Big SQL具有更高的最大I / O吞吐量，表明在需要时，Big SQL可以通过I / O子系统提高吞吐量，而不是Spark SQL。

读取/写入的数据量的巨大差异，以及Big SQL可以更加强大地驱动I / O子系统的事实，是Big SQL中更高效率的简单但有效的指标。

重要信息将这一点重新回到现实生活中，我们的Data Professional不仅使用Big SQL提高了三倍的效率，而且使用更少的资源来完成工作，这反过来又允许其他数据专业人员在集群上运行更多分析同时.

是什么让这份报告有所不同？

已经有越来越多的基于Hadoop解决方案的SQL基准测试报告;一些显示解决方案x比y快许多倍，而其他人表明y比x快 - 但两者都是如此？我是许多竞争基准的老手，我可以诚实地说，通过定义测试的范围来赢得和失去基准。每个供应商都会最大限度地影响基准规范，以突出其自身产品的优势以及竞争对手的弱点。这正是今天SQL over Hadoop空间正在发生的事情，也是组织面对这些解决方案时过多的冲突性能信息的原因。那么，是什么让这份报告与众不同：

比例因子 - 毕竟，我们正在谈论大数据！这是唯一一份以100TB发布的报告。以较小比例因子发布的许多其他报告甚至不使用整个数据集。

它很全面。它不会挑选查询来强调一种解决方案相对于另一种解决方案的好处。根据最初的Hadoop-DS基准测试，IBM将苹果与苹果进行了比较，比较了适用于这两种产品的所有查询。

这些产品由两个竞争（但友好）的IBM团队调整，两者都在努力突出其产品的优势。最后，两个团队的经验将使他们各自的产品受益。

它遵循Hadoop-DS规范的规则（基于行业标准TPC-DS基准）

摘要：

毫无疑问，Spark SQL在很短的时间内已经走过了漫长的道路。 Spark SQL可以在100TB完成99个查询中的83个，这是开源社区推动这个项目的证明。但是，仍然没有替代产品的成熟度，而Big SQL的优势在于它建立在IBM的数据库技术之上。正是这种谱系在SQL over Hadoop空间中将Big SQL提升到了其他供应商之上。

图12：作者在Hadoop Marketplace上的SQL视图

图12：作者在Hadoop Marketplace上的SQL视图

作者对此空间的看法虽然相当不科学，如图12所示.Big SQL优于Hadoop解决方案的开源SQL包，主要是因为Big SQL继承了IBM数据库的大量丰富功能（和性能）。遗产。假设Spark SQL保持其当前的势头，它可能最终超过Big SQL的速度，可扩展性和功能。然而，随着技术的成熟，它们的改进速度会慢下来 - 毕竟，对于一年前的产品而言，仅仅因为在产品生命的早期阶段，将十年的产品改进10倍就更容易了 - 酒吧的周期要低得多。

总而言之，这份报告显示了Big SQL：

可以在100TB，4个并发流中执行所有99个TPC-DS查询，以及

可以这样做至少比Spark SQL快3倍，而且

使用较少的群集资源来实现此类领先的性能。

但对于考虑购买SQL over Hadoop解决方案的组织来说，这意味着什么呢？重要的是，简单来说，这意味着Big SQL使他们的数据专业人员和业务分析师的工作效率（至少）提高了3倍。使用Big SQL可能需要3个小时才能完成深度分析，使用Spark SQL需要9个小时（或一个工作日）。在一天内，Big SQL用户可以使用不同的输入组合运行3次分析，以模拟不同的场景。使用Spark SQL完成相同的分析至少需要3个工作日;可能更长，因为查询无法完成的可能性更高，调整Spark SQL查询所需的持续时间通常更长。

我们还提供YouTube视频(https://www.youtube.com/watch?v=M5zqykmEu9U)，详细介绍了我们的体验。