要深入了解这些基准，请观看Reynold Xin的网络研讨会。性能往往是选择大数据平台的关键因素。鉴于SQL是大数据分析的通用语言，我们希望确保我们提供的是统一分析平台中性能最好的SQL平台之一。在这篇博文中，我们将Databricks Runtime 3.0（包括Apache Spark和DBIO加速器模块）与使用行业标准TPC-dsv2.4基准测试的vanilla开源Apache Spark和Presto on进行了比较。除了云设置之外，Databricks运行时还以10TB的规模与apacheimpala上最近使用本地硬件的Cloudera基准进行了比较。在本例中，在Cloudera发布的Impala结果中，104个TPC-DS查询中只有77个被报告。结果汇总显示：在相同的硬件规格下，Databricks Runtime 3.0比AWS上的vanilla Spark高出5倍。Databricks的性能比Presto高出8倍，虽然Presto在104个查询中只能运行62个，Databricks却可以运行所有查询。Databricks不仅在Cloudera报告中选择的查询上比本地Impala高出3倍，而且与内部固定物理磁盘相比，它还得益于S3的存储弹性。为了重现这个基准测试，你可以从这里得到所有的脚本。TPC-DS公司TPC-DS由第三方委员会创建，是衡量决策支持解决方案性能的事实上的行业标准基准。根据它自己的主页，它将决策支持系统定义为那些能够检查大量数据、给出真实业务问题答案、执行各种操作需求和复杂性的SQL查询（例如，即席、报告、迭代OLAP、数据挖掘）并具有高CPU和IO负载的特点的决策支持系统。该基准测试包括104个查询，这些查询执行SQL 2003标准的大部分内容—TPC-DS基准测试的99个查询，其中4个查询具有两个变体（14、23、24、39）和"s_max"查询，它们执行最大表store峎sales的完整扫描和聚合。正如在前面的一篇博客文章中所讨论的，Spark SQL是为数不多的能够运行所有TPC-DS查询而无需修改的开源SQL引擎之一。Databricks运行时vs Vanilla Apache Spark我们使用最新的Databricks Runtime 3.0版本进行了这个实验，并将其与另一个流行的AWS云数据平台上的Spark集群设置进行了比较。Databricks运行时通过IO层（DBIO）增强Spark，该层支持对云存储的优化访问（在本例中为S3）。优化Spark性能的云存储不同于Spark on prem HDFS，因为云存储IO语义可能会引入网络延迟或文件不一致-在某些情况下，不适合大数据软件。但是使用Spark on Databricks，我们可以同时消除两者。如上所示，Spark-on-Databricks在整个运行时的性能大约提高了5倍，在几何平均数方面则提高了4倍。接下来，我们将解释基准设置的更多细节。硬件配置：我们在Amazon EC2上使用了以下设置：机器类型：11个r3.xle节点（10个工人和1个驱动程序）CPU核数：44个虚拟核（22个物理核）系统内存：335 GBshuffle的总本地磁盘空间：880gb（在S3上作为Parquet存储基准数据）亚马逊将网络性能描述为"中等"数据集：TPC-DS 1000比例因子，在S3上。我们选择这个，而不是比例因子10000，因为Presto在下一节中进行了比较，存在严重的扩展问题。查询重写：没有执行查询重写。两种sparksql风格都能够运行所有104个查询。配置调优：我们在Databricks上使用开箱即用配置运行基准测试，并在AWS集群上进行额外的手动调优。我们最初使用默认配置在竞争平台上运行此基准测试，但发现性能低于我们的预期。然后我们进行了一些手动调优，以匹配Databricks上的配置，这样AWS上的Spark性能会更好。非Databricks平台上的附加配置可以在这里和这里找到。为了进一步分析查询结果，我们还将查询分为三类：交互式查询：此类查询在1分钟内完成。在这个类别中，Databricks Runtime 3.0快了3倍。报告查询：此类查询在3分钟内完成。在这一类中，Databricks Runtime 3.0快了4倍。深度分析查询：长时间运行的查询，可能需要一个小时或更长时间。在这一类中，Databricks Runtime 3.0快了5倍。由于交互查询受到元数据发现延迟的限制，我们观察到只有3倍的加速，而报告和深度分析查询则从优化的DBIO中受益匪浅。DBIO的未来版本还将大大提高元数据发现的延迟，从而进一步改进交互式查询。Databricks运行时与Presto使用相同的硬件配置，我们还比较了Databricks运行时与AWS上的Presto，使用相同的供应商来设置Presto集群。硬件配置：同上（11个r3.xle节点）数据集：TPC-DS 1000比例因子，S3查询重写：由于缺少对汇总的分组函数的支持，我们不得不为Presto重写一些查询。即使有一些小的重写，在Presto上也只能完成62个查询。其余的不是使系统崩溃就是没有返回结果。这解释了为什么Presto上的总运行时小于上一节中vanilla Spark的总运行时，因为Presto的总运行时没有考虑失败的查询。如上所示，Spark SQL on Databricks完成了所有104个查询，而Presto完成了62个查询。只比较Presto能够运行的62个查询，Databricks运行时在几何平均数方面比Presto好8倍。Databricks运行时比Presto快8倍，并具有更丰富的ANSI-SQL支持。云中的数据块与prem上的Apache Impalaapacheimpala是大数据领域另一个流行的查询引擎，主要由Cloudera客户使用。Cloudera发布了Impala引擎的基准数据。最新的基准测试是两个月前由Cloudera发布的，在104个查询中只运行了77个查询。在这个实验中，我们问自己：云环境中的Databricks运行时与物理硬件上的Impala结果相比如何？如果我们将使用现成的Databricks配置与由产品背后的工程团队调优的Impala以及cherry-picked查询集进行比较呢？此外，在S3上的Spark到Impala的物理磁盘性能如何？本节介绍了这个实验的结果。硬件配置：Databricks运行时黑斑羚CPU核心计数144（288 AWS vCPUs）280内存（GB）21961792本地磁盘（TB）68112数据存储S3（分离存储和计算）HDFS（本地磁盘）机器详细信息18云i3.4x大7个prem节点数据集：对于数据块，TPC-DS 10000比例因子，在S3上。对于黑斑羚，在HDFS上。查询重写：没有，但是Cloudera团队选择的77个查询排除了TPC-DS中一些最苛刻的查询。配置调优：在Databricks上没有；我们使用现成的配置运行。对于Cloudera基准测试中做了什么还不知道，因为它没有被报告（看看评论）。所有104个查询在19990秒内以10000比例因子完成。下表比较了Cloudera在其报告中选取的77个查询的运行时：在我们将CPU数量作为标准化因子的情况下，Databricks运行时使用云中的商品硬件，其效率是Impala的3倍：Databricks运行时在Impala上的Cloudera发布的数据上获得了更好的性能，在Impala的工程团队选择的查询上，使用的集群只有物理CPU的一半。这些数据本身并没有突出显示的一个重要因素是，Databricks实验是针对S3中的数据运行的，使用了分离的存储和计算，与本地磁盘相比，这增加了灵活性和易管理性，正如Impala基准测试中所做的那样。在之前的一篇比较S3和HDFS的博客文章中，我们得出的结论是S3的总体拥有成本要低得多，而HDFS在每个节点上的性能可能更好。这个基准测试结果表明，通过我们的优化，这两个方面都是可能的：灵活性和更低的云总体拥有成本、更好的性能以及更广泛的ANSI-SQL支持。结论这篇博客文章报道了我们将Databricks Runtime 3.0与其他大数据引擎（包括vanilla ApacheSpark和云中Presto）进行比较的基准测试。即使在改进了AWS上Spark的Spark配置之后，Databricks运行时在相同的硬件规格下也比vanilla Spark高出5倍。与Presto相比，Databricks运行时性能提高了8倍，同时能够运行所有查询。Presto只能运行104个查询中的62个，而Spark能够在普通的开源版本和Databricks中运行104个未经修改的查询。除了云计算结果，我们还将我们的平台与Cloudera最近发布的impala10tb规模的结果进行了比较。虽然结果来自一个on-prem集群，但是在报告中选择的对相同数量的CPU核心的查询上，Databricks运行时的性能比本地Impala高出3倍。Databricks运行时测试使用S3作为存储，并具有额外的云弹性，这导致TCO比on-prem更低。要深入了解这些基准，请观看Reynold Xin的网络研讨会。要利用Databricks Runtime 3.0中的最新性能优化，请注册Databricks帐户。免费试用Databricks。今天就开始吧