對數據科學家而言，如果所需的計算能力價格過高，那么縱使創建出一個完美的統計模型也是徒然。我們需要工具來評估模型替代方案對性能的影響。

大數據是一種極端規模下的先進分析方法。在許多情況下，數據科學家是這一新時代中關鍵應用開發團隊的成員。他們創建的統計模型往往會成為生產性資產。這些資產必須具備性能擴展能力，以適應業務分析工作負載的容量、速度和種類。

盡管如此，大多數的數據科學家在本質上都是統計分析人員。在進行更深層次的數據探索中，他們可能不會將關注點放在由他們創建和改良的分析模型的下游生產性能。如果進行回歸分析，那么由他們整合的神經網絡或是自然語言處理算法將無法在大負載的情況下擴展，模型可能必須被廢棄，或是在為生產做好準備之前進行大幅修改。

在這種情況下，DevOps軟件持續交付能夠提供幫助。DevOps是一種軟件開發方法，強調開發人員和運營人員之間的協作與一體化。目前DevOps還不是商業數據科學家眼中的核心詞匯，不過它應該會成為未來的核心。對先進分析方法性能要求的提高，將導致更多注意力被放在生產級環境中對分析模型快速、徹底地進行性能測試這一需求上。隨著這些需求的增長，數據科學家（他們可能將性能看作是一種后來加入的東西）和IT管理者（他們時刻都在關注性能的影響）在看法和實踐方面的分歧將變得越來越嚴重。

近期一份關于應用預測建模的文章引力了許多人的注意。該文的作者Steve Miller在文中給出了這樣的觀察結果：

我一直批評統計學習（SL）教育在評估不同建模技術方面缺乏對計算性能的考慮。由于重點是對調諧/測試模型進行自展和交互驗證，因此SL完全屬于計算密集型。再加之內嵌在如裝袋（bagging）和提升（boosting）等技術中的重采樣，對大數據集監督式學習的計算噩夢將一直縈繞在身邊。實際上，R語言的內存限制對適用于隨機森林（random forests）等高級方法的各種大小的模型都產生了嚴重制約。雖然統計學習能夠很好地校準小數據集模型的性能，但是搞清楚性能與大數據計算成本之間的關系無疑將事半功倍。

我們贊同這種建議，并支持將其提升至一個新的水平。但在此之前，最好還是先判斷是一下它是不是資源浪費型的算法。如果無意間將它內置在生產大數據分析應用中，那么最終將產生嚴重的不良后果。不僅企業要對昂貴的CPU、內存、存儲以及應用連接所必須的互聯能力進行投資，而且數據科學家也將不得不要使用資源效率型方法從頭開始設計。

理想情況下，對計算費用指標的計算應該能夠自動地在數據科學家的開發工作臺內執行。換句話說，分析工具、庫和沙箱平臺應該將這些指標作為關鍵的決策支持功能呈現出來。這樣一來，數據科學家就能夠全面地衡量他們將要創建模型的下游性能特點。

站在開發與運營的立場上，理想的數據科學家工具箱應該對模型在下列延時中可能的下游性能影響進行評估：

數據延時：當用于數據采集、集成和清洗的模型被部署后，這一模型是否嚴重地影響了從源頭至下游消費應用的數據傳輸速度？

執行延時：當模型在內置數據庫分析平臺被執行時，該模型提交結果是否需要過長的時間？如果部署在混合工作負載平臺上，它們是否會嚴重影響到在同一平臺上運行的其他工作負載的執行速度？

建模延時：在用現有統計分析法和數據準備工具建模時，模型的開發、填充、記錄、迭代和部署是否需要過長的時間？

考慮到有許多可以用于處理相同建模域的替代性算法，理想的工具應該能夠顯示出各種算法的優勢與不足，以便開發人員能夠做出更明智的選擇。總之，這些都是我們所期望的。我們相信它們一定能夠引起許多數據科學家和大數據專業人員的共鳴。如果這些模型在大數據平臺上的執行時間過長，那么世界上最復雜的分析法也沒有什么用處。