棒球比赛中的统计分析美国职业棒球大联盟（MLB）中的一个投球产生了数十兆字节的数据，从投球运动到球的旋转，再到击球者的行为，再到每个棒球运动员对击球的反应。你如何从一场比赛和一个赛季的所有这些数据中得出可操作的见解？了解2019年美联中央赛区冠军明尼苏达双城队的棒球运营小组如何使用数据块获取大量传感器数据，在每个球场上运行数千或数万个模拟，然后快速生成可操作的见解，以分析和提高球员表现，侦察比赛，更好地评估人才。另外，在分析这些战术战术战术的基础上，还要进一步缩短教练员在比赛中的时间。在第1部分中，我们将介绍这对双胞胎的前台在对他们的球场数据进行数千次模拟以改进他们的球员评价模型时所面临的挑战。我们评估了在R中建模和推断音高结果的不同方法之间的权衡，以及为什么我们选择使用Spark中的R继续使用用户定义函数。在第2部分中，我们将深入研究在Spark中使用R的用户定义函数。我们将学习如何通过管理UDF中R的行为以及Spark在协调执行时的行为来优化性能以实现规模。背景有几个离散的棒球统计数据可以用来评估棒球运动员的表现，例如击球平均数或击球命中率，但sabermetric棒球社区开发了高于替补（WAR）的胜场，以评估球员对球队成功的总贡献，从而更容易比较球员。从方舟子网:在评估玩家时，你应该一次使用多个指标，但是战争是包罗万象的，它为比较玩家提供了一个有用的参考点。WAR提供了一个估计来回答这个问题："如果这个球员受伤了，他们的球队不得不用一个可以自由使用的小联盟球员或者一个AAAA球员从他们的板凳上替换他们，那么这个球队会失去多少价值？"这个值是用wins格式表示的，所以我们可以说，玩家X对他们的团队价值是+6.3胜，而玩家Y只值+3.5胜，这意味着玩家X很可能比玩家Y更有价值。从历史上看，比较球员在数百或数千次投球过程中的战争是衡量相对价值的最好方法。明尼苏达双城队有超过1500万次投球的数据，这些数据不仅包括最终结果（球、击球、垒打等），还包括更深层次的数据，如球的速度和旋转、出球速度、球员位置、外场独立投球（FIP）等等。然而，任何一个投球都可能有几个变量，比如击球手配对或天气，这些变量会影响比赛的预期跑动值（例如，微风吹起，原本可以是本垒打的球反而变成了一个犯规球）。但是，如何修正这些变量，以便得出更准确的未来业绩预测呢？基于大数定律，金融服务业等行业对历史数据进行蒙特卡罗模拟，以提高概率模型的准确性。类似地，场景增加100倍（把每个场景都看作一个场景）可以使战争估计更精确10倍。为了提高预期运行值的准确性，Twins公司寻找一种解决方案，该方案可以在数据库中的每个音高上生成20000个模拟，或者总共生成3000亿个场景（1500万个音高x 20000个模拟最大场景=3000亿个场景）。在一个节点上使用baser在prem上运行这个分析，他们意识到计算历史数据需要将近4年的时间（大约8秒来运行20k个模拟/1500万个音高/3.15×107秒/年）。如果他们最终要使用run value/WAR估计来优化游戏内的决策，在游戏中，每一场游戏可以产生超过40000个场景来得分，那么他们需要：一种在短时间内快速启动大量计算能力的方法一个活生生的模型，他们可以不断地添加新的棒球数据来提高预测的准确性，并在近乎实时的情况下产生可操作的见解。考虑到我们在海量数据集（包括结构化和非结构化数据）方面的经验，这对双胞胎转向了Databricks和microsoftazure。有了云端近乎无限的随需应变计算，这对孪生兄弟不再需要担心在分析历史数据时为一次性使用高峰配置硬件。以前每天运行40000次模拟需要44分钟，而在Azure上使用Databricks，则可以在数据生成时解锁实时评分功能。将音高模拟结果放大100倍在R为了对给定的投球结果进行建模，数据科学团队建立了一个由1500万行组成的训练数据集，该数据集包含球场位置坐标以及赛季和比赛特征，如投手击球手的惯用手、局等。为了在模型中捕捉到球场结果的非线性特性，该团队转向了R生态系统中可用的大量开源软件包库。最终选择了一个R包，它在建模非线性分布时具有灵活性和可解释性，数据科学家可以根据历史数据拟合复杂的模型，并且仍然能够理解每个预测因子对音高结果的精确影响。由于模型将用于帮助评估球员的表现和团队组成，因此模型的可解释性是教练和企业的重要考虑因素。模拟了各种不同的球场结果，然后，研究小组使用R来模拟数据集中每个球场的x-y坐标的联合概率分布。这有效地生成了可以用他们训练过的模型评分的额外记录。推断每个模拟球场的预期投球结果，勾勒出一幅球员预期表现的图像。模拟次数越多，图像越清晰。计划对历史数据集中的1500万行中的每一行生成20000个模拟，这将产生一个最终的3000亿个模拟投球的数据集，以便用它们的非线性模型进行推断，并为组织提供更准确地评估选手的数据。这种方法的问题在于，R在单线程、单节点的执行环境中运行，即使利用开源中提供的多线程包和云中CPU密集的VM，该团队估计，如果代码完全完成的话，它需要几个月的时间才能完成。问题就成了一个问题规模：如何将模拟和推理逻辑扩展到3000亿行，并在合理的时间范围内完成任务？答案在于由apachespark提供支持的Databricks统一分析平台。用火花缩放R扩展这个模拟管道的第一步是重构特性工程代码，使之与R中Spark-SparkR或sparklyr的两个包中的一个一起工作。幸运的是，他们使用流行的数据操作包dplyr编写了自己的逻辑，dplyr与sparklyr紧密集成。通过这种集成，可以在使用SparkyR读取数据时创建的tbl泳spark对象上使用dplyr函数。在本例中，我们只需将几个ifelse（）语句转换为dplyr:：mutate（case_when（…）），然后它们的功能工程代码将从单节点进程扩展到具有spark的大规模并行工作负载！事实上，只有10%的现有dplyr代码需要重构才能使用Spark，我们现在能够在几分钟内生成数十亿行用于推理。这个dplyr魔法是如何工作的？要了解这一点，我们首先需要了解R-To-Spark接口的结构：Spark+R包中的大多数函数都是本机Spark类的包装器——你的R代码被翻译成Scala，然后这些命令被发送到驱动程序上的JVM，然后任务被分配给每个工人，dplyr动词被转换成SQL表达式，然后由Spark通过SparkSQL进行计算，因此，Spark+R包的性能通常与Scala中的性能相同。基于R包的分布式推理随着特征工程流水线在Spark中运行，我们的注意力转向了缩放模型推理。我们考虑了三种不同的方法：Spark中非线性模型的再训练在Spark中从R和score中提取模型系数将R模型嵌入到用户定义函数中，并使用Spark并行执行让我们简单地检查一下这些方法的可行性和折衷。Spark中非线性模型的再训练第一种方法是查看Spark的机器学习库（SparkML）中是否存在R建模技术的实现。一般来说，如果您的模型类型在SparkML中可用，则最好选择性能、稳定性、，如果你来自R或Python，这可能需要对代码进行重构，但可伸缩性的提高很容易让你觉得值得。不幸的是，团队选择的建模方法在SparkML中不可用。学术界已经做了一些工作，但是由于它涉及到在Spark中引入对代码库的修改，所以我们决定将这种方法的优先级降低为替代方法，重构和维护这段代码所需的工作量使得它不能作为第一种方法使用。提取模型系数如果我们不能重新训练Spark，也许我们可以使用从R模型中学习到的系数并将它们应用到Spark数据帧中？这里的想法是推理