随着社区的不断发展，apachespark已经发布了它的1.1版本。MLlib已经有了相当大的贡献，现在支持许多新特性。我们很高兴与大家分享MLlib自1.0发布以来的一些性能改进，并讨论两个关键因素：torrent广播和树聚合。Torrent广播Spark作为一个统一框架的好处在于，对核心引擎所做的任何改进都是免费的，包括MLlib、sparksql、流和GraphX等标准组件。在ApacheSpark1.1中，我们将Spark的默认广播实现从传统的HttpBroadcast更改为TorrentBroadcast，这是一种类似BitTorrent的协议，可以在驱动程序和执行器之间平均分配负载。当一个对象被广播时，驱动程序将序列化对象分成多个块，并将这些块广播给不同的执行器。随后，执行器可以从先前获取块的其他执行器单独获取块。Spark-Core中的这种变化如何影响MLlib的性能？在机器学习算法中，一种常见的通信模式是在每次训练迭代开始时对中间模型进行一对所有的广播。在大规模机器学习中，模型通常是巨大的，通过http进行广播会使驱动程序成为一个严重的瓶颈，因为所有的执行器（工作者）都从驱动程序中获取模型。通过新的torrent广播，这个负载也在执行器之间共享。它导致了显著的加速，MLlib免费使用它。树聚合与每次迭代开始时的广播模型类似，驱动程序在每次迭代结束时通过聚合从执行器收集的部分更新来构建新模型。这是MapReduce范例的基础。Spark（和原始MapReduce）中reduce或aggregate函数的一个性能问题是，聚合时间与数据分区的数量成线性关系（由于合并部分结果时的CPU成本和网络带宽限制）。在mllib1.1中，我们引入了一种新的基于多级聚合树的聚合通信模式。在这种设置中，模型更新在发送到驱动程序之前在一小组执行器上进行部分组合，这大大减少了驱动程序必须处理的负载。测试表明，这些函数可以将聚合时间减少一个数量级，特别是在具有大量分区的数据集上。性能改进改变模型的广播和聚合方式对性能有着巨大的影响。下面，我们给出了比较MLlib中一些常用机器学习算法性能的实证结果。x轴可以被认为是1.1版本相对于1.0版本的加速。在所有算法中，可以观察到1.5-5倍的加速。这些测试是在一个有16个从机的EC2集群上使用m3.2x大型实例执行的。运行测试的脚本是"spark perf"测试套件的一部分，可以在上找到https://github.com/databricks/spark-perf。对于岭回归和logistic回归，高标识符对应于高瘦矩阵（1000000 x 10000），而脂肪对应于短脂肪矩阵（10000 x 1000000）。分布式机器学习的性能改进通常来自通信模式改进和算法改进的结合。在这篇文章中，我们关注前者，算法的改进将在后面讨论。所以现在就下载spark1.1，享受性能改进，并继续关注未来的文章。免费试用Databricks。今天就开始吧