一個大數據應用是如何煉成的

經歷了多年的BI專題應用建設，有幸能在一個傳統企業里探索大數據應用的建設過程，發現了很多不一樣的地方，獲得了不同的感受，在此以一個真實的案例的建設過程來品味其中的不同，也許能獲得一些啟示。

課題是怎么來的？

大數據應用最大的挑戰，就是未來的不確定性，因此，傳統公司動輒提前半年進行投資預算規劃的方式是不太適合大數據的。

做大數據幾年，雖然說現在靠譜的大數據的商業模式也就在廣告、金融、公益等方面，但真要下決心干某個大數據應用項目，其突發性、偶然性也非常強，因為對于大數據這個不成熟事物，無論是哪類公司，觀望占了很大部分，對大數據的質疑有之，對于大數據安全的惶恐有之，對于合作模式的疑惑有之，更多的是不停的提出想法，不停的被否定。

企業順應大勢成立了大數據團隊，最痛苦的是不知道干什么，什么能干，什么不能干，也沒啥可借鑒的經驗，這跟當前創業公司也類似吧，不知道哪種模式是靠譜的。

大數據幾乎無所不能，但真要做起來，其實當前是能者寥寥，雖然趨勢不可擋，但這一波搞大數據應用的，似乎大多要死在黎明前，一個概念從提出到最終普世大眾，的確路慢慢兒修遠兮。

今天要聊的，是個公益課題，電話反欺詐，課題有一定的偶然性，安全部門提到了，問我們能不能做做看，感覺社會意義很大，比如騰訊有反欺詐盒子，360有攔截系統，本來某公司希望來做這個課題，但綜合各方面因素，還是決定自己做。

作出這個決策的實際一天不到，所以決定自己做，基于以下幾個因素：

一是這個大數據應用是有顯著效益的。

二是很好評估，不像很多BI應用產出無法評估，備受質疑 。

三是公司大數據平臺建立了，提供了基礎條件。

四是自主建模團隊建立了一年多了，不需要太依賴合作伙伴，因此也無需走那套冗長的招標流程，失敗的代價也會小。團隊如何組建？

跟傳統的安排不同，拋出這個課題后，主動接受這個挑戰的，卻是一名從一線剛過來的同事，面對不確定性，想來大多數有資歷的員工也會猶豫老半天吧，這個也有一定偶然性。

谷歌講到了招聘人才，提到了無論多大代價也要找到創意精英，而做大數據，更加需要，需要主動型的創意精英，如果傳統企業每個人仍然像傳統那樣局限在自己一畝三分地，很難有創新突破。

很幸運，我們有一只黑天鵝。

這種自愿組隊模式的確有很大的好處，不按計劃分配，尊重個人的意愿，更能激發人的主動性，團隊組建也非?？?，當天組隊，第二天就開干，不存在類似項目的繁瑣流程。

雖然團隊成立有一定的偶然性，但的確與與企業近年來在大數據組織創新、人才引進和人員流動上的努力分不開。

假如沒有大數據組織的成立，誰牽頭都是個問題；假如不扔掉傳統的包袱，很難有人專心做這個；假如沒有企業內的人才流動和外部人才的引入，我們也干不了這個事。

平臺資源如何解決？

在那個傳統BI小型機時代，要做一個項目，拋開硬件資源環境的投資立項過程不說，光是一個新項目的集成估計也不止一個月。

而這個項目不同之處是：

一是基于大數據平臺的租戶能力，資源申請所見即所得，加上流程，一周內全部搞定。

二是提供的組件較為豐富，特別是流處理資源的快速提供，為反欺詐的實時性提供了堅實的基礎，換在幾年前基本不可能 。

三是公司技術團隊的保障，使得大多技術問題得以盡快解決，這也有賴于公司在大數據平臺上的末雨綢繆。

某人說過，凡是能用錢解決的問題都不是問題，但技術這個東西，雖然用錢的確可能解決，但對于大多數公司，錢都是個大問題，因此技術問題的解決又是何其艱難。

比如我們碰到Kafka的一些問題，長期難解決，大多企業的機制流程恐怕也不允許隨便開價100萬招個技術專家來解決吧，傳統企業的自我技術進步是部血淚史，外面的專家開價開不起，自己的專家起來了，又怕被人家挖。

開發歷程

敏捷開發現在提得很多了， 但感覺以前BI的建設就是最大的敏捷，最極致的情況，一個人搞定需求、開發、上線和維護，當然，現在軟件工程的確還是要靠分工協作，需要一套方法論來解決顯性迭代和維護配合的問題。

大數據創新太特殊了，沒必要循規蹈矩，拋開全部的束縛，一切要為速度讓步。原因是失敗可能性很大，速度越快成本越低，同時既然對于公司原有業務沒有影響，因此可以放手去干，什么文檔都可以不要，什么既定流程都可以不遵守，反正光腳不怕穿鞋的。

因此，這個課題做的非?？?。

第10天，做出一個反欺詐簡單模型，包括了案例分析、數據準備、數據建模及驗證等，我們的觀點是第一個版本可以粗糙一點，希望盡快驗證這個事情的可行性，否則一切都是徒勞，因此就是討論和驗證數據。

當時規定兩個禮拜如果出不了結果，就會放棄，這類應用失敗可能性很高， 但船小好調頭，以后做一些創新，都建議給創新做個時間止損點。

第25天，生產完成部署，也就是具備系統支撐能力， 除了系統部署方案需要專業部門把關，其他基本是能省就省，當時的想法是，這類創新項目最好一個月就能搞上線，起碼能測試吧，相對以前BI應用項目動輒半年甚至1年的節奏，的確大不同。

創新，速度始終是王道，因此日報變成剛需，也回憶起了某位離職運營商去創業的一個領導，他說每天凌晨就要看昨天的日報，以便安排當天的工作，我們可能做不到這么瘋狂，但日報的節奏是對的。

第30天，一直在外呼現場進行驗證迭代，直到36天，獲得認可為止，以后就是持續調優，但這個數據已經可以投入生產了。一般電話詐騙很難在事中干預，但這個模型做到了，準確度達到90%以上，通過實時事中干預挽回收入損失超千萬。

這個應用就是中國移動的天盾大數據反欺詐系統，它就是這么誕生的，沒有什么大匯報，沒有什么流程，就是很輕很輕的來了。

現在算法還有很多問題，反欺詐矛與盾的爭奪是很艱辛的，面上的風光底下是每天建模師的艱苦卓絕的努力，上了很多新算法，很多很多失敗，拉低了成功率，對于這個大家是異常焦慮的，群里總是不停的討論，大家都知道這個是核心競爭力，路還很長，還需要堅持。

小結

這個應用還難言成功，只是傳統企業在大數據應用上的一次不同的嘗試，但不管怎樣，互聯網快速迭代的那套的確是給了很大的啟示，自己做了，才知道原來的差距是如此巨大，自己的能力是如此脆弱。

從課題的角度講，要認識到大數據這個事物的不確定性，選擇它具有偶然性，沒有規劃能預料到這個，當前大數據變現商業模式也并不成熟，不要奢望投資大數據馬上有產出，也許能力儲備是第一位的。

從組織的角度講，大數據人才屬于稀缺人才，要么打破原有框架，不拘一格外部找人才，要么充分企業內挖潛，讓人員能流動起來。流動的人才有一個特點，即至少有一顆騷動的心，主動性對于做成功一件事極為重要。

從能力的角度講，假如要向大數據轉型，則還是要對“沒有一個大數據公司，能依靠合作伙伴獲得成功”這句話有所敬畏，大數據的核心能力要掌握在自己手里。

從平臺的角度講，如果沒有大數據平臺的建立，這個項目能夠有效果也許是半年以后的事情，但機會稍縱即逝，沒人會等你這么久，因此此類基礎設施建設不能猶豫，“書到用時方恨少”。

從開發的角度講，先設定一個小目標，搞他個十萬八萬的，只要有點看得見的產出就行啊，快速迭代，始終是王道，失敗了也沒什么大不了，我們缺的就是經驗，多頭并行也不是不可以，只要有足夠的創意精英。

當然說易行難，以上幾點對于大多數公司來說是如此不易，也不能以一個應用的成功與否說明任何問題，大數據要成功，就像黑天鵝，有一定偶然性，但如果連準備的勇氣都沒有，沒有一點實質改革的動作，就沒有任何成功的可能了。