[[150060]]

身為一名七年的數(shù)據(jù)從業(yè)者，對一些專業(yè)概念尚不能準確的描述。比如什么是大數(shù)據(jù)？我雖然從2008年開始做這塊的東西，但國內(nèi)到了2011年的時候才興起了這一概念。我花了三四年的時間，也不能對其有一個準確的把握。就在前天，我把我對大數(shù)據(jù)的認識拿出來和團隊交流時，也產(chǎn)生了多處分歧，甚至有成員提議不要提“大數(shù)據(jù)”這一名詞?？捎锌蛻艟褪潜?ldquo;大數(shù)據(jù)”這一概念吸引過來的，你繞開這塊不講可不行。同樣，對于什么是數(shù)據(jù)驅(qū)動（Data-driven）？我依舊不能給一個準確的描述，這也許是一個新事物在發(fā)展過程中必須經(jīng)歷的階段，等到塵埃落定，沒有分歧的時候，也是它壽終正寢的時候。雖然無法準確定義數(shù)據(jù)驅(qū)動，但我卻能通過一些對數(shù)據(jù)驅(qū)動的似是而非的認識（迷思，Myth）做一個剖析，然后再做一個總結，我們對它的認識就會更進一步了。

迷思一、KPI就是數(shù)據(jù)驅(qū)動

KPI是Key Performance Indicator的縮寫，指關鍵績效指標。我們在衡量目標是否達到時，***能夠有一個能夠衡量總體效果的標準，這就是KPI。KPI通常是一個數(shù)字，比如今年某一企業(yè)的銷售目標是5000萬元，國家的GDP增長要不低于7.5%，小米手機的出貨量要突破1億。這些KPI可能是基于以往的表現(xiàn)評估得出的，也可能是拍腦袋的。有了KPI，組織就有了明確的目標，組織內(nèi)部就按照這一目標，層層向下分解，只要每個基層完成了任務，那么組織整體的KPI就可以達到了。這種方式的好處有一堆，壞處也有一堆，咱們在這里就不論證了。咱們只討論KPI是否是數(shù)據(jù)驅(qū)動？

KPI有一個典型特點是自上而下的，先有了一個數(shù)據(jù)，然后上下齊心協(xié)力把這個數(shù)據(jù)給坐實了。這種方式有可能是不切實際的，比如中國歷史上的大躍進運動。這種方式不是先有了數(shù)據(jù)，從數(shù)據(jù)出發(fā)，再做新的決策。KPI的達成過程，是組織通過努力驅(qū)動數(shù)據(jù)的過程。正好是我們說的數(shù)據(jù)驅(qū)動相反的模式。

迷思二、有了儀表盤就是數(shù)據(jù)驅(qū)動

不管是稍大規(guī)模的傳統(tǒng)企業(yè)，還是任何規(guī)模的互聯(lián)網(wǎng)企業(yè)，儀表盤已經(jīng)是標配了。通過儀表盤，我們可以監(jiān)測到公司的總體運作情況。對于公司的創(chuàng)始人來說，有了儀表盤，就可以對公司總體做決策了。但對于產(chǎn)品、運營等具體干活的人員，這可就傻了眼了。明明昨天一個機房掛了，但流量還在漲。只看到總用戶量下跌了，但儀表盤上根本看不出來原因。如果想要進一步研究問題，必須對數(shù)據(jù)進行進一步的下鉆，這又超出了儀表盤的承載能力。難免對有些成員來說，這些泛泛的指標很難指導決策，不看也罷。

迷思三、有專職數(shù)據(jù)工程師跑數(shù)據(jù)就是數(shù)據(jù)驅(qū)動

工程師老王（本來寫的是小張，團隊的小張同學抗議，后來改成老王，團隊的王姓同學說他老婆總叫他老王。。）負責處理所有跑數(shù)據(jù)的需求。運營同學相對上個月的活動效果進行一個評估，提了一個統(tǒng)計數(shù)據(jù)的需求。產(chǎn)品同學拿到了新功能上線的用戶數(shù)據(jù)，發(fā)現(xiàn)比上線之前還降了？這一定是統(tǒng)計程序?qū)懙挠袉栴}。我們再來看看干活的老王，每天干著沒有盡頭的跑數(shù)據(jù)的工作，為了能夠讓自己不過早累死，就制定了一個復雜的數(shù)據(jù)需求規(guī)范，讓那些想要跑數(shù)據(jù)的同學費一般功夫才能提過來，拉長周期，要是寫的不合格，直接讓需求提出者回去重寫。老王已經(jīng)盡力了，可因為需求提出者太多（在一個產(chǎn)品發(fā)展超過一年，就會出現(xiàn)這種情況，除非產(chǎn)品快掛了），后提的需求需要經(jīng)過很長的周期才能滿足，有些同學可能覺得提數(shù)據(jù)需求太麻煩，干脆還是換做拍腦袋吧。

這種模式下看似也能運轉(zhuǎn)的通，但實際許多需求被壓抑了，被強制串行化。

迷思四、每個需求都是一個新的腳本

在創(chuàng)業(yè)公司，多面手居多，有的甚至是全棧（什么技術活都能干）。產(chǎn)品運營同學或老板有了數(shù)據(jù)需求，某位同學可能三下五除二就搞定了。寫了一個只有他一個人能看懂的腳本（腳本是一類開發(fā)效率很高但是運行效率可能較低的程序代碼，比如用perl、python等編寫。）。這久而久之，就出現(xiàn)了一堆不同的人寫的不同的腳本。如果來了新人，十有八九會交給新人去維護。因為這些腳本寫的時候圖快，并不會做code review，甚至連跑的數(shù)據(jù)是否正確都不能保證，那代碼質(zhì)量可想而知。特別是如果有人專門負責寫統(tǒng)計腳本，那干三個月還行，覺得能夠?qū)W到不少的知識。干六個月的時候，就有點膩了，發(fā)現(xiàn)都是重復的工作。干到一年的時候，十有八九會想走人。如果小李是接手者，發(fā)現(xiàn)上百個腳本，看不懂，看不完，就只能罵娘了。

工程師都是樂觀主義者，對于某個數(shù)據(jù)需求，總會說這很簡單，給我10分鐘就搞定了。而實際要把這個腳本變成可用的任務，可能要花費兩天時間。許多數(shù)據(jù)需求是例行的，那么就需要管理數(shù)據(jù)源、生成的中間數(shù)據(jù)、最終結果的發(fā)送，那么想要維護好，就不是那么容易了。更何況數(shù)據(jù)源頭的格式可能發(fā)生變化，那么所有的腳本可能都跑出了錯誤的數(shù)據(jù)。這讓我想到2008年，我剛加入百度新產(chǎn)品部統(tǒng)計團隊時。當時共有20臺統(tǒng)計機器，有500~600個統(tǒng)計腳本，共有兩個工程師負責開發(fā)維護，新需求處理不過來，已有任務總是出問題。于是經(jīng)理才痛下決心，安排我們?nèi)プ鲆粋€系統(tǒng)來解決這一問題。

回過頭來看數(shù)據(jù)驅(qū)動

前面我們看了幾個不那么數(shù)據(jù)驅(qū)動的例子，接下來我們看看數(shù)據(jù)驅(qū)動應該是什么樣子的。數(shù)據(jù)驅(qū)動的理想狀態(tài)應該是人人都是數(shù)據(jù)分析師，每個參與業(yè)務的人能夠直接和數(shù)據(jù)打交道，有了問題，可以直接從數(shù)據(jù)中要結論，并且數(shù)據(jù)的獲取，不依賴于第三者，不像前面提到的有那么一個中間人老王。為了達到這一點，有許多的工作要做，比如數(shù)據(jù)源要采集全，數(shù)據(jù)模型要化繁為簡，強大的分析工具等，這是一個系統(tǒng)工程。