寫給大資料從業者：資料科學的5個陷阱與缺陷

作者注：文中標注藍色字體表明該內容具有比較強烈的主觀判斷，并不是行業共識，

最近看新聞，發現資料科學專業已經是北京大學高考入學門檻最高的專業了，其實"Data Science" 這個詞性感了快十年了，對互聯網行業而言，相當于性感了一個世紀，

從“資料說話”，”DT 時代”，到 “資料中臺”，“資料驅動（Data Drive/Data Driven)”，資料體系的不斷演進正在持續的改變大家的作業與決策方式；正在不斷的革新大家的思維方式；同時也產生了新的商業邏輯，新的發展機會，

1976 年，Pascal 作者 Nikalus Wirth 曰：Algorithms + Data Structures = Programs.

就像之前的“SOA”，“云計算”等概念一樣，目前資料科學自身的概念還在不斷的變革，各家公司的實踐者們一邊摸索，一邊獲利；一邊總結，一邊布道；當然同時還參雜著很多湊熱鬧的同志把概念折騰的更加模糊，所以資料科學本身的能力邊界，方法論體系，最佳實踐等等還沒有完善的建立起來，有很多問題沒有辦法很好的回答，由此就會產生一些迷信和誤會，”強行資料“，”隨意資料“，”政治正確資料“等等情況比較常見, 無論是實際的操作層面，還是方法層面，都存在著一些不小的誤會，這也是我打算總結一下在資料科學實踐中存在的陷阱與缺陷的緣由，

這篇分享是根據我自己的作業經驗，和對相關資深同事的訪談總結而成，它的正確性受限于我個人的認知水平和目前行業的發展水平，它整理了一些目前可能存在的問題，但未必是長久的道理，希望大家讀的時候批判性的看待，拋磚引玉，如果有不同想法歡迎大家跟我隨時溝通與驗證，結論本身也可以隨時更新，

陷阱與缺陷 1：資料質量殺死自動 / 智能決策

網易嚴選的很多業務，比如風控業務，核心驅動力是資料及演算法，我們在風控業務起步的時候就建立了資料演算法驅動風控的方法體系，所以能保證很小的團隊（3 個人）來支撐嚴選幾十個內外部風險場景，每天執行百萬次風險決策，當然，這是資料驅動自動決策 / 智能決策帶來的力量，成功的美好，或許會讓你按耐不住的想把很多業務運轉方式轉型過來，但遺憾的是，資料質量保障的缺失會讓這一切變成隨時會倒塌的空中樓閣！事實上，絕大部分組織對資料質量的理解 支撐不了更加自動和智能的決策場景，強行轉型與減員增效會讓他們原本穩定的業務接近崩潰，

嚴選風控出現過幾次大的故障都跟資料質量緊密相關，今年 8 月份的時候，風控在執行每周誤判巡檢的時候發現整體疑似誤判率增加了 4 倍，最終定位原因是設備號相關的日志內容有些例外，從而導致了相當一部分用戶的行為（簽到操作）被錯誤的執行了攔截，

這是一個很有意思的案例，一些關鍵的決策：比如用戶是不是壞人？某個商品要采購多少量？可能會依賴于很不被重視的某個線上日志的一小部分內容，我們的整個質量保障體系很難把視角投入到某個具體應用的某個日志欄位在高壓力下會不會出錯？在傳統的應用服務質量保障理念里，日志欄位的某個偶爾的小錯誤，沒人會把它當作 Bug，開發人員更不會去關注，但如果你一旦把 資料當作了生產資料，如果我們不對應用質量保障的理念和工具進行革新，你的大量的資料分析報告，訓練好的演算法模型，做出的決策可能很不可靠，因為你的生產資料本身就是垃圾，而古語有言：Garbage in , garbage out，

還有一個驚人的現狀是，大量用于生產資料的復雜 SQL 并沒有進行真正的測驗，甚至，大量的資料系統并不存在一個所謂的測驗環境，我們很難像測驗線上服務（比如訂單系統）那樣去測驗資料生產程序的正確性，那么這樣通過幾萬行，甚至幾十萬行（嚴選）SQL 生產出來的資料到底能不能用？這個問題其實很難回答，

資料的可靠性是組織在轉型資料驅動程序中一個非常大的陷阱，

大家都在討論資料質量的重要性，但是內心又默默覺得這個事情比較低級，因此，我們很少見到有團隊會把大量聰明的大腦投入到資料質量的保障上，

除了資源投入的缺失，很多資料團隊對資料質量的認知也是各不相同，我曾經跟一位在資料行業從業 15 年，為某知名公司資料體系做出巨大貢獻的前輩做過一次深入的溝通，聊起資料質量，”你覺得資料質量是什么？“ 他的回答是：“資料質量，真正需要考慮的是指標一致性，”，瞧瞧，就算是非常資深的同行，他的認知還是不夠完整，按他對資料質量的理解，資料的支撐能做到報表給人看，這個層面就很完美了，要落地到戰術層，落地到線上自動決策基本不可行（因為資料質量的故障難以像線上程式故障一樣快速修復，它是一個持續污染的程序），

資料做為智能決策的輸入，是動態變化的，它沒法像代碼的依賴那樣做靜態分析，它的依賴層次動態而不穩定，

資料科學是我們常常說起的一個詞，也是形容我們日常作業的一個詞，但當我們說起的時候，內心就會有些心虛，就光看到資料了，“科學”在哪里？如果沒有”科學“的部分，我們的產出的結論會不會有問題？

這是一個最常見的問題，資料科學的從業者們，不知道什么是”科學“，所以江湖上才會有 SQL Boy, SQL Girl 的稱呼，

一個常見的問題是資料指標之間的相關性到底是不是真的相關？我們做資料分析往往能看到很多有趣的相關性，比如最近幾個月買了拖鞋的用戶，看起來有更大的可能性在最近一個月復購另外一個商品，但是，這個相關性到底是不是真的存在，還是只是偶然的巧合（False Postive）？我們的分析報告很容易對這個問題視而不見，但如果這個相關性本身經不起推敲，它又如何來指導我們的作業呢？資料分析報告難道要靠運氣來驅動業務發展么？

就算我們有不錯的統計基礎，給每個假設都加上了 P Value, 我們往往還很容易把相關性與因果性給搞混，兩個事情相關，并不能得出結論說他們之間互為因果，我們需要通過因果分析的方法，為資料之間的相關性提出符合業務邏輯和商業邏輯的解釋，

如果資料分析遺漏了因果分析這個程序，就會得出一些奇怪的結論，比如，我們發現較大的用戶，買的鞋子一般也是大號，如果缺乏基于業務邏輯的因果分析我們可能會這樣指導運營作業：為了讓用戶的腳變大，我們應該多賣大號的鞋子給他們，

但有的時候，我們很難直接的分析出資料之間的因果關系，很難直觀的得出結論，這個時候，我們需要借助科學實驗，幫我們更深入的理解我們的業務，

如何去做科學實驗，我結合滴滴謝梁大神的觀點（謝梁，資料科學中的“科學”），總結如下：

• 通過對資料的敏銳度和業務的熟悉程度，發現和定義問題；
• 提出結構化，可量化的假設；
• 設計驗證實驗，科學與實驗是緊密關聯的，在嚴選和很多公司，我們往往利用實驗來判斷方案的好壞，但是，其實實驗更多的是用于幫助我們驗證假設，幫我們更加深入的理解我們的用戶（著名實驗公司今天頭條 CEO 說： 更多的時候，AB 測驗幫助我們理解用戶，而不是幫助我們決策），設計一個好的實驗，并不容易，需要根據假設梳理出要驗證的指標，樣本集，可控制的因子（往往是流量），設計實驗，需要極強的專業性，
• 收集與分析資料，分析資料并不僅僅是直觀的去看趨勢的高低，分析資料首先需要對業務的主要指標及其相關性有清晰的概念，需要把指標之間的相關因子量化，甚至可計算， 我認為是先有結構化、系統化、量化的體系，再有資料分析，所幸的是，結構化的體系我們可以用系統和服務來支撐， 我們團隊今年主要在設計與研發的 DIS 系統（ 嚴選資料智能平臺），一個主要目標就是解決這個問題，
• 分析人員需要專業的量化分析能力、統計學能力，

資料民主化在國外的資料社區討論的很多，國內聊的比較少，資料科學家們通過黑魔法制造出一些模型來，然后告訴業務同學該怎么決策，告訴高層業務指標完成的好不好，資料的能力被限制在某一個專業團隊，但它的產出卻又跟業務緊密相關，這些未知會給業務人員和管理層帶來恐懼與不安，資料團隊給的結論會不會有可能是被操縱的？會不會有意無意的誤導？這些問題會很容易讓團隊之間滋生不信任，

所以資料民主化不足帶來的一個重要問題就是信任問題，那該怎么解決？

嚴選在一次產技共創會中，有同事提出，要跟業務“談戀愛”，對于眼下的現實，這確實是解決信任問題的一個好辦法，阿里的曾經的資料一把手車品覺老師也說過類似的話：資料同學要會"混，通，曬"，跟業務同吃同行，建立信任，才能互相成功，

但這終究不是一個可規模化和標準化的解決方案 ，去年，我們在考慮 2019-2020 年嚴選資料平臺發展的時候，想了很久這個問題，如何去降低資料使用的門檻，讓一切更直觀和更容易解釋？我們開展的一些專案，SQL on AI, Data Intelligence System(DIS)，演算法平臺等，一個共同的目標是 降低資料使用門檻，并通過產品的方式固化甚至可視化資料分析程序，

老板們經常會把演算法能力簡單化：預測的不準？找兩個 NB 的演算法專家做個模型就能搞定！遺憾的是，現實并不這么簡單，你可能找 100 個 NB 的演算法專家都沒用，

有人見過用演算法來預測下一輪雙色球中獎號碼的么？有人用演算法來預測接近混沌狀態的股市漲落么？作為一個旁觀者，你能利用演算法來預測意甲的每場比賽成績么？

有的業務問題本身是無法預測的，因為它跟過去沒有關系（比如雙色球）；有的業務問題預測成本很高，短時間內無法做出有價值的模型（比如預測股市，預測比賽等），需要考慮投入與回報，事實上，很多演算法的成功落地應用，不光是需要有合適的模型，還需要大量維度的資料作為生產資料，更關鍵的是要有一個完善，可靠的 演算法工程體系，而后者，往往會被決策者忽略，

決策者在考慮利用演算法模型去預測未來時，他需要想明白 投入與產出，組織需要投入的不止是 幾位演算法大神就行，還需要建設完善的資料基礎體系，還需要建設完善的演算法工程體系，決策者如果期望資料和演算法能發揮突破性的效應，需要有魄力把成本投入到自己目光不能及的地方，比如基礎資料體系，比如演算法工程，

這個問題比較抽象，對于 BI/ 演算法 / 資料產品的同學而言，可能不好理解，不過大家只需要記住：資料的最底層，搖搖欲墜，并不堅實，同樣需要一個團隊精心守護，

大家在興奮的玩耍資料，利用資料來驅動業務前進的時候，如果回頭望望做 Data Infra 的同學，如果他們告訴你其實你在用的資料能不能真的算出來、有沒有算對，他們也沒多少信心的時候，你會不會覺得心驚肉跳，會不會覺得人生其實有些虛無？如果大家有機會采訪下各個互聯網公司，可以問問他們被抱怨最多或者故障最多的技術團隊是哪個？相信答案都比較一致：“大資料基礎團隊”，包括嚴選的前面幾年，這個情況也非常嚴重（當然現在也沒好多少），資料故障頻出，資料產出排期長、節奏慢、不穩定等情況都很常見，很多時候我們是用睡覺時間在做人肉保障，每每回想起來，都會心驚，

這當然并不是因為大資料基礎行業的從業者敬業精神不足或者能力不足，而是因為大資料體系其實并沒有一個非常堅實的工程基礎，

資料的基礎設施可靠性不足：資料的采集系統，資料的存盤系統，資料的計算系統，資料的分析引擎，這些服務的可靠性相比其他的在線服務低一大截，資料平臺每天的定時資料計算服務，比如 Hive，或者 spark，成功率如果有 98%，已經算是很不錯了，而線上服務系統，如果可靠率長期在 98% 以下，相關團隊的同學很難堅持一年不被優化，就算資料成功的被計算出來了，我們的分析引擎，比如 impala，查詢成功率也長期低于 95% 以下，在嚴選這個資料還要更差一些，impala 的查詢失敗或者超時，幾乎每天都有不少，

計算模型不完備和廣泛的誤解：大資料的計算有兩個模型：Streaming，Batch，兩個模型對應的基礎設施各自獨立發展，誰也不理誰，同時，由于資訊流轉的速度問題，也有人把這兩個模型稱為實時計算和離線計算，雖然，Streaming & 實時計算；Batch & 離線計算，在很多現實場景中，存在著一致性，但本質上，它們是兩回事，甚至很多從業者也無法清晰的分清楚這些基本概念，把實時計算和流計算等同，這給資料作業帶來了巨大的困擾，

為了適配這兩個計算模型，很多組織的 Data Infrastructure 團隊會有獨立的流計算團隊和批處理團隊；會有實時數倉和離線數倉，會有實時指標和離線指標等等，這些數倉和指標的研發人員存在著割裂，數倉建設方法論、指標定義也不盡相同，維護成本和解釋成本都很高，出錯幾率也很大，很常見的情況是一個業務的資料需求，往往需要拆解成實時和離線兩個方案，共同去實作，這個糟糕的局面沒有變的更好，

LinkedIn、Uber、阿里等等公司都在嘗試做批流融合，嚴選也在嘗試，我們在做計算資源管理和調度層面的融合，但是，融合兩種完全不同的計算模型，是一件不美好的事情，直覺上也不大對，我覺得現實的業務問題可能并不是聚焦在批流兩種計算模型的不兼容上，而是聚焦在實時和離線兩個時間維度上的不兼容，由于歷史原因，實時的資料往往需要依賴流計算模式來產生，從而產生了實時計算 == 流計算的誤會，而融合實時資料與離線計算，解決起來就容易很多 ，而流處理也需要走向更適合它的場景，

其實能總結的問題遠不止這些，比如我們會擔心“演算法替代思考，會不會傷害組織的遠見？”、“大規模依賴 A/B 測驗做決策，可能會導致運營策略的短視” 等等，

內容來源：AI前線

作者：陳炬