对数据科学家而言，如果所需的计算能力价格过高，那么纵使创建出一个完美的统计模型也是徒然。我们需要工具来评估模型替代方案对性能的影响。

大数据是一种极端规模下的先进分析方法。在许多情况下，数据科学家是这一新时代中关键应用开发团队的成员。他们创建的统计模型往往会成为生产性资产。这些资产必须具备性能扩展能力，以适应业务分析工作负载的容量、速度和种类。

尽管如此，大多数的数据科学家在本质上都是统计分析人员。在进行更深层次的数据探索中，他们可能不会将关注点放在由他们创建和改良的分析模型的下游生产性能。如果进行回归分析，那么由他们整合的神经网络或是自然语言处理算法将无法在大负载的情况下扩展，模型可能必须被废弃，或是在为生产做好准备之前进行大幅修改。

在这种情况下，DevOps软件持续交付能够提供帮助。DevOps是一种软件开发方法，强调开发人员和运营人员之间的协作与一体化。目前DevOps还不是商业数据科学家眼中的核心词汇，不过它应该会成为未来的核心。对先进分析方法性能要求的提高，将导致更多注意力被放在生产级环境中对分析模型快速、彻底地进行性能测试这一需求上。随着这些需求的增长，数据科学家（他们可能将性能看作是一种后来加入的东西）和IT管理者（他们时刻都在关注性能的影响）在看法和实践方面的分歧将变得越来越严重。

近期一份关于应用预测建模的文章引力了许多人的注意。该文的作者Steve Miller在文中给出了这样的观察结果：

我一直批评统计学习（SL）教育在评估不同建模技术方面缺乏对计算性能的考虑。由于重点是对调谐/测试模型进行自展和交互验证，因此SL完全属于计算密集型。再加之内嵌在如装袋（bagging）和提升（boosting）等技术中的重采样，对大数据集监督式学习的计算噩梦将一直萦绕在身边。实际上，R语言的内存限制对适用于随机森林（random forests）等高级方法的各种大小的模型都产生了严重制约。虽然统计学习能够很好地校准小数据集模型的性能，但是搞清楚性能与大数据计算成本之间的关系无疑将事半功倍。

我们赞同这种建议，并支持将其提升至一个新的水平。但在此之前，最好还是先判断是一下它是不是资源浪费型的算法。如果无意间将它内置在生产大数据分析应用中，那么最终将产生严重的不良后果。不仅企业要对昂贵的CPU、内存、存储以及应用连接所必须的互联能力进行投资，而且数据科学家也将不得不要使用资源效率型方法从头开始设计。

理想情况下，对计算费用指标的计算应该能够自动地在数据科学家的开发工作台内执行。换句话说，分析工具、库和沙箱平台应该将这些指标作为关键的决策支持功能呈现出来。这样一来，数据科学家就能够全面地衡量他们将要创建模型的下游性能特点。

站在开发与运营的立场上，理想的数据科学家工具箱应该对模型在下列延时中可能的下游性能影响进行评估：

数据延时：当用于数据采集、集成和清洗的模型被部署后，这一模型是否严重地影响了从源头至下游消费应用的数据传输速度？

执行延时：当模型在内置数据库分析平台被执行时，该模型提交结果是否需要过长的时间？如果部署在混合工作负载平台上，它们是否会严重影响到在同一平台上运行的其他工作负载的执行速度？

建模延时：在用现有统计分析法和数据准备工具建模时，模型的开发、填充、记录、迭代和部署是否需要过长的时间？

考虑到有许多可以用于处理相同建模域的替代性算法，理想的工具应该能够显示出各种算法的优势与不足，以便开发人员能够做出更明智的选择。总之，这些都是我们所期望的。我们相信它们一定能够引起许多数据科学家和大数据专业人员的共鸣。如果这些模型在大数据平台上的执行时间过长，那么世界上最复杂的分析法也没有什么用处。