我談談對大數據分析的理解，這要從什么是大數據講起。
因為從事這一方向，經常會有人問我什么是大數據?我一直都回答不好。在最近的幾個月，我對這一概念思考的更多一些，結合看過的一些書籍(如《大數據時代》、《數學之美》第二版等)和實際的經歷，算是有了一些認識，今天我就從大數據的概念開始講起，試圖給大家講清楚什么是大數據分析。
首先，我來談談我對大數據的理解，分為大數據概念和大數據思維。
我把大數據的概念總結為四個字：大、全、細、時。
我們先來看一組數據：
百度每天采集的用戶行為數據有1.5PB以上
全國各地級市今天的蘋果價格數據有2MB
1998年Google抓取的互聯網頁面共有47GB(壓縮后)
一臺風力發電機每天產生的振動數據有50GB
百度每天的行為數據1.5個PB夠大吧?我們毫無懷疑這是大數據。但全國各個地級市今天的蘋果價格只有2MB大小，是典型的小數據吧?但如果我們基于這個數據，做一個蘋果分銷的智能調度系統，這就是個牛逼的大數據應用了。Google在剛成立的時候，佩奇和布林下載了整個互聯網的頁面，在壓縮后也就47GB大小，現在一個U盤都能裝的下，但Google搜索顯然是個大數據的應用。如果再來看一臺風機每天的振動數據可能都有50GB，但這個數據只是針對這一臺風機的，并不能從覆蓋面上，起到多大的作用，這我認為不能叫大數據。
這里就是在強調大，是Big不是Large，我們強調的是抽象意義的大。
我們再來看關于美國大選的三次事件：
2012年Nate Silver通過互聯網采集社交、新聞數據，預測大選結果
《文學文摘》所收集的問卷有240萬，絕對是夠大的，但為什么預測錯誤了呢?當時《文學文摘》是通過電話調查的，能夠裝電話的就是一類富人，這類人本身就有不同的政治傾向，調查的結果本身就是偏的。而蓋洛普只收集了5萬人的意見，但是他采用按照社會人群按照比例抽樣，然后匯集總體結果，反而預測正確了。因為這次預測，蓋洛普一炮而紅，現在成了一個著名的調研公司。當然，后來蓋洛普也有預測失敗的時候。到了2012年，一個名不見經傳的人物Nate Silver通過采集網上的社交、新聞數據，這是他預測的情況和真實的情況：
兩者是驚人的接近的。
從這點我是想強調要全量而不是抽樣，大數據時代有了更好的數據采集手段，讓獲取全量數據成為可能。
在2013年9月，百度知道發布了一份《中國十大吃貨省市排行榜》，在關于“××能吃嗎?”的問題中，寧夏網友最關心“螃蟹能吃嗎?”內蒙古、新疆和西藏的人最關心“蘑菇能吃嗎?”浙江、廣東、福建、四川等地網友問得最多的是“××蟲能吃嗎?”而江蘇以及上海、北京等地則最愛問“××的皮能不能吃?”。下圖是全國各地關心的食物：
用戶在問什么能吃嗎的時候，并不會說“我來自寧夏，我想知道螃蟹能吃嗎”，而是會問“螃蟹能吃嗎”，但是服務器采集到了用戶的IP地址，而通過IP地址就能知道他所在的省份。這就是數據多維度的威力，如果沒有IP這個維度，這個分析就不好辦了。而現有的采集手段，能夠讓我們從多個維度獲取數據，再進行后續分析的時候，就能對這些維度加以利用，就是“細”。
我們現在對CPI已經不再陌生，是居民消費價格指數(consumer price index)的簡稱。我們努力工作，起碼要跑過CPI。
那你有了解過CPI是怎么統計的嗎?這里包括兩個階段，一個是收集商品價格數據，一個是分析并發布數據。我從百度百科上了解到，中國CPI采樣500多個市縣，采價調查點6.3萬個，近4000名采價員，次月中旬發布報告。我還曾找國家統計局的朋友確認了這個事情。
而在美國有一家創業公司叫Premise Data。它通過眾包方式，25000個采價員(學生、收銀員、司機等)，使用手機APP采集數據，每條6~40美分，比美國政府數據提前4~6周發布。
這就是“時”，強調實時收集數據和實時分析數據。當然，在CPI的例子中，我們可以讓價格上報更智能一些，不需要人工的方式。
從上面的大、全、細、時四個字，我們就可以對大數據的概念有個較為清晰的認識。這四點主要強調的數據的獲取和規模上，和以往傳統數據時代的差異。有了這個基礎，我們還要看怎么對大數據加以利用。這里就要看看大數據思維。我們也來看兩個例子。
85前應該都用過智能ABC，一種古老的輸入法，打起來特別慢。到了2002年左右，出了一個叫紫光的輸入法，當時我就震驚了。真的輸入很快，仿佛你的按鍵還沒按下去，字就已經跳出來了。但漸漸的發現紫光拼音有個問題是許多新的詞匯它沒有。后來有了搜狗輸入法，直接基于搜索的用戶搜索記錄，去抽取新的詞庫，準實時的更新用戶本地的詞庫數據，因為有了大量的輸入數據，就能直接識別出最可能的組合。
我們以前都用紙質的地圖，每年還要買新的，舊的地址可能會過時，看著地圖你絕對不知道哪里堵車。但有了百度地圖就不一樣了，我們上面搜索的地址都是及時更新的，雖然偶爾也會有被帶到溝里的情況，但畢竟是少數?？梢詫崟r的看到路面堵車情況，并且可以規劃防擁堵路線。
我們想想這種做事方式和以前有和不同?
我們發現不是在拍腦袋做決定了，不是通過因果關系或者規則來決定該怎么辦了，而是直接通過數據要答案。我們獲取的數據越全面，越能消除更多的不確定性。也就是用數據說話，數據驅動。
在百度文化的29條中，我第二認可的一條就是“用數據說話”，數據有時候也會欺騙人，但大部分時候它還是客觀冷靜的，不帶有感情色彩。據說在硅谷用數據說話都是一種很自然的工作習慣，但你放眼望去你周圍，你會發現許多沒有數據的例子，拍腦袋的，拼嗓門的，拼關系的，拼職位的，這一點都不科學。
那我們再來看看互聯網領域的數據驅動。許多公司的情況是這樣的：
不管是運營、產品、市場、老板，都通過數據工程師老王獲取數據，老王忙的痛不欲生。但數據需求方都對數據獲取的速度很不滿意，有的等不及，還是決定拍腦袋了。這樣極大的阻礙的迭代的速度。
還有的公司情況是這樣的：
對老板來說，有個儀表盤還不錯，終于知道公司的總體運營情況了，可以基于總體情況做決策了。但如果發現某天的銷售額下跌了20%，肯定是要安排下面的人追查的。對于實際干活的運營、產品同學來說，光看一個宏觀的指標是不夠的，解決不了問題，還要想辦法對數據進行多維度的分析，細粒度的下鉆，這是儀表盤解決不了的。
那么理想的數據驅動應該是什么樣子的?應該是人人都能夠自助式(Self-Service)的數據分析，每個業務人員和數據之間，有一個強大的工具，而不是苦逼的老王。或者只是能看到數據的冰山一角。在數據源頭上，又可以獲取到全面的數據。
我們接下來看看現有的解決方案上，離真正的數據驅動還有多遠的距離。
常見的方案有三種：
我們先來看看第三方統計服務，目前國內用的比較多的有三家，友盟、百度統計和TalkingData，他們都類似Google Analytics(簡稱GA，谷歌分析)。
這些工具的優勢是使用簡單，并且免費。
是有以下幾點：
數據源：只能覆蓋前端JS/APP SDK記錄的數據，無法覆蓋服務
端和業務數據庫的數據;
分析能力：只能覆蓋宏觀通用分析，使用后還需要數據團隊滿足
運營/產品的各類定制化的需求;
第二種是使用數據庫寫SQL，這種在創業公司用的比較多：
京公網安備 11010502049343號