1. 程式人生 > >大數數應用:教你從立項到落地實施全過程!

大數數應用:教你從立項到落地實施全過程!

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

  課題是怎麼來的?

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

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

  企業順應大勢成立了大資料團隊,最痛苦的是不知道幹什麼,什麼能幹,什麼不能幹,也沒啥可借鑑的經驗,這跟當前創業公司也類似吧,不知道哪種模式是靠譜的。

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

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

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

  一是這個大資料應用是有顯著效益的。

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

  三是公司大資料平臺建立了,提供了基礎條件。

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

  團隊如何組建?

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

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

  很幸運,我們有一隻黑天鵝。

  這種自願組隊模式的確有很大的好處,不按計劃分配,尊重個人的意願,更能激發人的主動性,團隊組建也非常快,當天組隊,第二天就開幹,不存在類似專案的繁瑣流程。

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

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

  那麼平臺資源如何解決?

  在那個傳統BI小型機時代,要做一個專案,拋開硬體資源環境的投資立項過程不說,光是一個新專案的整合估計也不止一個月。

  而這個專案不同之處是:

  一是基於大資料平臺的租戶能力,資源申請所見即所得,加上流程,一週內全部搞定。

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

  三是公司技術團隊的保障,使得大多技術問題得以儘快解決,這也有賴於公司在大資料平臺上的末雨綢繆。

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

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

  接下來談談開發歷程

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

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

  因此,這個課題做的非常快。

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

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

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

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

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

  這個應用就是中國移動的天盾大資料反欺詐系統,它就是這麼誕生的,沒有什麼大彙報,沒有什麼流程,就是很輕很輕的來了。

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

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