數(shù)據(jù)科學(xué)難在實踐，有哪些彎路可以不走？
大數(shù)據(jù)文摘出品
編譯：李雷、欒紅葉
數(shù)據(jù)科學(xué)這一名詞流行了這么長時間，對于很多企業(yè)來說仍然是熟悉而又陌生的詞匯。
對于積極向布局數(shù)據(jù)科學(xué)應(yīng)用的企業(yè)來說，如何避免走彎路是始終追求的目標。
Blue Yonder，一個成立于2008年的大數(shù)據(jù)分析平臺，用他8年的數(shù)據(jù)科學(xué)經(jīng)驗告訴你，什么是真正的數(shù)據(jù)科學(xué)、有哪些彎路可以不走。
正如Blue Yonder創(chuàng)始人在采訪中說到：“在這八年里，我們經(jīng)歷了不少痛苦的教訓(xùn)，尤其是在數(shù)據(jù)科學(xué)應(yīng)用方面。”
以下是采訪原文，請欣賞!
數(shù)據(jù)科學(xué)
我相信許多人都知道什么是數(shù)據(jù)科學(xué)，但我想分享一下我個人對它的理解：數(shù)據(jù)科學(xué)的目的是構(gòu)建自動化的數(shù)據(jù)驅(qū)動運營決策支持系統(tǒng)。
根據(jù)這么嚴格的定義(你也許會有異議)，數(shù)據(jù)科學(xué)的唯一目便成了決策的支持和自動化。那么“運營決策”是什么?
它是指企業(yè)需要頻繁定期進行的大量決策，這些決策對業(yè)務(wù)KPI(關(guān)鍵績效指標)有直接影響，其結(jié)果也需要在短時間內(nèi)進行評估。
企業(yè)可能需要作出以下決策，例如：各種產(chǎn)品明天的***定價是多少或發(fā)送給供應(yīng)商X的下一個訂單中各產(chǎn)品的***定價是多少。
由于人們經(jīng)常在不經(jīng)意間受到影響，因此在大多數(shù)情況下，自動決策勝于人類的運營決策，并且自動決策可以顯著提高業(yè)務(wù)流程的效率。
人類決策偏見列表：
https://en.wikipedia.org/wiki/List_of_cognitive_biases#Decision-making.2C_belief.2C_and_behavioral_biases
所有這一切實際上意味著，數(shù)據(jù)科學(xué)對于運營決策的意義就像工業(yè)機器人對于制造業(yè)那樣。正如機器人可以自動執(zhí)行重復(fù)的生產(chǎn)任務(wù)一樣，數(shù)據(jù)科學(xué)也可以自動執(zhí)行重復(fù)的運營決策。
DevOps與數(shù)據(jù)科學(xué)
DevOps工作流程旨在克服傳統(tǒng)IT組織中由于開發(fā)團隊和運營團隊相互獨立而導(dǎo)致的普遍沖突問題。開發(fā)團隊希望開發(fā)新功能并希望新功能盡早上線，而運營團隊負責系統(tǒng)的穩(wěn)定性，因為所有變更都會帶來風險。他們需要盡可能地阻止新功能上線。
在這場沖突中，兩個團隊都忽略了以穩(wěn)定可靠的新功能為客戶創(chuàng)造價值這一共同目標。
開發(fā)人員和運營團隊之間的沖突只是組織結(jié)構(gòu)不合理導(dǎo)致的其中一種情形，對于按功能劃分的其他組織機構(gòu)也存在相同的問題。
在許多公司里，數(shù)據(jù)科學(xué)也被困在類似的“功能團隊孤島”中。更詳細的解釋，我建議閱讀這篇《什么是DevOps》
相關(guān)鏈接：https://theagileadmin.com/what-is-devops/
數(shù)據(jù)科學(xué)-麻煩制造者
有個虛構(gòu)的段子，但卻透著真實的無奈。兩位管理人員在一次會議上相遇，其中一位經(jīng)理問道，“你們公司是不是已經(jīng)開始使用數(shù)據(jù)科學(xué)決策分析了?”另一位回答說：“我們的數(shù)據(jù)科學(xué)家團隊已經(jīng)成立一年了，但什么時候可以開始分析還遙遙無期呢。”
為了更好地理解為什么許多數(shù)據(jù)科學(xué)工作的進展緩慢，我們需要看一下用數(shù)據(jù)科學(xué)進行自動化業(yè)務(wù)決策的典型工作流程。
下面的工作流程示例是以零售行業(yè)為例，同樣也適用于其他行業(yè)。
(1) 從各種來源提取各種必要的數(shù)據(jù)：
- 內(nèi)部數(shù)據(jù)源，如ERP，CRM和POS系統(tǒng)，或來自在線商店的數(shù)據(jù)。
- 外部數(shù)據(jù)，如天氣或公眾假期數(shù)據(jù)
(2) 提取，轉(zhuǎn)換和加載數(shù)據(jù)：
- 關(guān)聯(lián)數(shù)據(jù)源
- 聚合并轉(zhuǎn)換數(shù)據(jù)，
- 用“一張大表”關(guān)聯(lián)所有數(shù)據(jù)
(3) 機器學(xué)習(xí)和決策制定：
- 使用歷史數(shù)據(jù)來訓(xùn)練機器學(xué)習(xí)模型
(4) 對于決策，使用當前的***數(shù)據(jù)
- 由此產(chǎn)生的決策被送回ERP系統(tǒng)或其他數(shù)據(jù)倉庫
這些步驟基本上涉及業(yè)務(wù)的方方面面，并且需要深入集成到業(yè)務(wù)流程中，以創(chuàng)建有效的決策系統(tǒng)。
然而這也是迄今為止數(shù)據(jù)科學(xué)決策分析工作***的麻煩。為了整合數(shù)據(jù)科學(xué)，就需要改變核心業(yè)務(wù)流程，而改變核心業(yè)務(wù)流程卻是一項艱巨的任務(wù)。
數(shù)據(jù)科學(xué)本質(zhì)上是貪婪的
沒有數(shù)據(jù)科學(xué)家會說“目前的數(shù)據(jù)庫規(guī)模足夠明年用的了。”
人們通常覺得數(shù)據(jù)科學(xué)家都是貪婪的，因為他們似乎對可用資源有著不切實際的想法。但實際上，數(shù)據(jù)科學(xué)本身才是貪婪的。
總的來說，以下因素會使數(shù)據(jù)科學(xué)項目的結(jié)果更準確：
- 更多屬性(“列”)
- 更多歷史數(shù)據(jù)(“行”)
- 更獨立的數(shù)據(jù)源(例如，天氣，金融市場，社交媒體......)
- 更復(fù)雜的算法(例如，深度學(xué)習(xí))
綜上，這不是數(shù)據(jù)科學(xué)家的問題!原則上，他們有權(quán)提出這些要求。幸運的是，我們有方法來解決資源短缺問題，我將在稍后進行論證。
另一個問題是低估了決策的絕對數(shù)量。比如一家擁有100個店鋪和5,000種產(chǎn)品的小型超市連鎖店的每日補貨量預(yù)測，補貨算法需要14天的日預(yù)測數(shù)據(jù)才能進行分析。那實際意味著每天需要計算，處理和存儲7百萬個預(yù)測數(shù)據(jù)。
由于建立一個有效的機器學(xué)習(xí)模型需要許多不同的數(shù)據(jù)源，部門之間可能會引入新的共通性和糾結(jié)。整個公司必須在公共標識符(common identifiers)和數(shù)據(jù)類型(data types)上達成一致。
以前，斷開鏈接的子部分需要與它們的數(shù)據(jù)流保持同步。比如，一個自動的日常補貨系統(tǒng)可能要依賴營銷部門的促銷數(shù)據(jù)和商店的庫存數(shù)據(jù)。所有必要的數(shù)據(jù)需要在一天中的固定時間獲取，這樣才方便系統(tǒng)設(shè)計決策并及時發(fā)送給供應(yīng)商。
數(shù)據(jù)科學(xué)家 VS 公司的其他人
現(xiàn)在回到DevOps上來，這一運動旨在克服開發(fā)人員和運營團隊之間潛在的偏差。
如果你試圖在一個單獨的地方與數(shù)據(jù)科學(xué)家團隊一起構(gòu)建自動化決策系統(tǒng)，那么就會不可避免地出現(xiàn)以上這種問題。
由于數(shù)據(jù)科學(xué)與其他部分的不可分離和對數(shù)據(jù)的貪婪，其團隊很難成功地將一個系統(tǒng)與其他具有不同績效體制的團隊進行合作。
為了防止或解決這些問題，我們必須接受DevOps模式的基本原則：
- 調(diào)整所有團隊的目標，使他們在工作上不至于產(chǎn)生“沖突”，而是努力實現(xiàn)共同目標。
- 拆除部門之間的墻，建立跨職能團隊
- 根據(jù)用戶附加值的估量，改進決策方式并分配資源和功能
關(guān)于承諾
決策是任何公司成功的核心。因此，在引入數(shù)據(jù)科學(xué)時，整個公司，包括所有的領(lǐng)導(dǎo)層和部門，都需要接受并重視。
運用數(shù)據(jù)科學(xué)進行自動化決策是價值流的重要組成部分。這很可能意味著，你需要改變既定的流程，重組團隊，重新考慮公司的組織架構(gòu)。
此外，想要成功執(zhí)行這些措施，你需要獲得必要的認可。每個人都需要知道為什么會有這些改變，并且還要支持這些決策。如果沒有這種誠摯的諾言，自動化決策就不可能會成功執(zhí)行。
相關(guān)鏈接：
https://www.datascience.com/blog/stakeholder-buy-in-for-data-science-product
反過來，你的數(shù)據(jù)科學(xué)工作必須著重于真正的附加值：一個是需要評估執(zhí)行成本，包括技術(shù)債務(wù)成本、復(fù)雜性的累積、糾結(jié)的增加等;另一方面也要將其與改進后的預(yù)期收益進行比較。
數(shù)據(jù)科學(xué)從來不是一個以自我為目標的團隊。
相關(guān)鏈接：https://www.datascience.com/blog/agile-data-science)
拆除數(shù)據(jù)科學(xué)的自我壁壘
DevOps的一個關(guān)鍵目標就是使團隊團結(jié)以實現(xiàn)公司的共同目標，并且也要拆毀不同團隊之間的壁壘。因為，如果把數(shù)據(jù)科學(xué)家分到一個單獨的小組，安排在一個單獨的房間里，這將會是一條通往失敗的必經(jīng)之路。
相關(guān)鏈接：
https://www.datascience.com/blog/centralized-data-science
相反，如果我們將數(shù)據(jù)科學(xué)家安排到一個跨職能的團隊中，這將有助于構(gòu)建一個端到端的完整決策系統(tǒng)，并有助于使其工作與公司目標保持一致。一旦每個部門都連接起來，數(shù)據(jù)科學(xué)家的工作就不會與其他部門相矛盾。
相反，這種決策系統(tǒng)的成功將變成公司的共同利益。以共同努力為特點的整體優(yōu)化就能夠?qū)崿F(xiàn)一個共同目標，這將會取代以自我為中心和不一致的目標為特征的局部優(yōu)化。
這個跨職能團隊和其他的團隊一樣致力于相同的質(zhì)量標準，在質(zhì)量、彈性或穩(wěn)健性方面沒有任何妥協(xié)的余地。
相反，由于自動化決策具有較高的風險，我們需要采用更高的標準。同時，遵循“精益思想”的方法，創(chuàng)造一個既便宜又安全的實驗環(huán)境。
用奧卡姆剃刀與貪婪作斗爭
有一個解決問題的原則叫做奧卡姆剃刀(Occam’s razor)，也就是：“在相互競爭的假說中，應(yīng)該選擇假設(shè)最少的。”在數(shù)據(jù)科學(xué)領(lǐng)域，我們可以將這個原則重新表述為：
如果兩個數(shù)據(jù)科學(xué)模型的結(jié)果是兼容的，那么就采用資源覆蓋面較小的模型。
這條簡單的規(guī)則為我們提供了如何建立數(shù)據(jù)科學(xué)模型的明確指導(dǎo)，解決了數(shù)據(jù)科學(xué)固有的貪婪性問題。
如果不測量生成值并在整個實現(xiàn)周期中應(yīng)用此原則，您可能會面臨成本激增，回報有限的問題。
相關(guān)鏈接：
https://www.datascience.com/blog/lessons-from-a-canceled-data-science-project
所以，必須要確保數(shù)據(jù)科學(xué)家致力于這一重要原則，因為與數(shù)據(jù)科學(xué)家對抗是非常困難的。他們有數(shù)據(jù)和專業(yè)知識來提出難以提出異議的論點。
創(chuàng)造一種盡可能簡單的，但又失必要的復(fù)雜的效率文化。
這同樣適用于不同數(shù)據(jù)源的使用。在數(shù)據(jù)安全領(lǐng)域，有一個“需要知道”(need to know)的原則，即只有需要訪問的人才能訪問數(shù)據(jù)。
也就是在數(shù)據(jù)科學(xué)的應(yīng)用中，我們需要衡量所額外添加的數(shù)據(jù)源的價值，如果改進不夠顯著，無法證明額外數(shù)據(jù)的相關(guān)性，那么就要嚴格清除這些數(shù)據(jù)源。
結(jié)語
數(shù)據(jù)科學(xué)也就是用來支持和自動化決策的。對大多數(shù)公司來說，這變得比以往任何時候都重要。由于它是一個決策系統(tǒng)，所以必須成為業(yè)務(wù)流程的核心。這一事實帶來了一系列嚴重的問題，特別是文化性質(zhì)的問題，可能是災(zāi)難性的。
沒有誠意的嘗試往往會導(dǎo)致時間和金錢的浪費，同時還加重了數(shù)據(jù)科學(xué)作為麻煩制造者的聲譽。
將數(shù)據(jù)科學(xué)進行合理的整合是一個不可忽視的轉(zhuǎn)折點。用DevOps模式來接受數(shù)據(jù)科學(xué)，測量重要的KPIs，從實驗中學(xué)習(xí)，并不斷改進流程。這是一條真正成為數(shù)據(jù)驅(qū)動公司的道路。
作者Twitter： https://twitter.com/sebineubauer
相關(guān)報道：
https://www.datascience.com/blog/why-is-it-so-hard-to-put-data-science-in-production
【本文是51CTO專欄機構(gòu)大數(shù)據(jù)文摘的原創(chuàng)譯文，微信公眾號“大數(shù)據(jù)文摘（ id: BigDataDigest）”】
