大家好，我是諸葛io的CEO孔淼，今天很高興能和各位前輩一起交流，我是晚輩，如果我分享的一些內(nèi)容如果以偏概全，也希望大家能夠指正。

諸葛io是一款精細化的數(shù)據(jù)分析產(chǎn)品，以覆蓋Android、iOS、JS/H5、服務端API等多種數(shù)據(jù)采集方式，幫助企業(yè)整合分析用戶行為，并且提供強大的后臺驅動產(chǎn)品、運營、業(yè)務等方面的決策，具體可以登錄zhugeio.com或者關注諸葛io公眾號進行了解。

言歸正傳，今天咱們就來閑聊下我過去接觸過的數(shù)據(jù)分析領域，因為我是連續(xù)創(chuàng)業(yè)者，所以我更多的還是聚焦在解決問題和業(yè)務場景上。如果把我在數(shù)據(jù)分析的經(jīng)驗劃分的話，剛好也就是我所經(jīng)歷的兩次創(chuàng)業(yè)階段，第一階段是“第三方數(shù)據(jù)分析”，第二階段是“第一方數(shù)據(jù)分析”。所以今天咱們就來漫談下第三方到第一方數(shù)據(jù)分析。

先聊聊“第三方數(shù)據(jù)分析”，這個主要結緣于我給開復做微博數(shù)據(jù)挖掘開始。

物起因：給開復做“微博推薦”

我之前有段時間給開復做實習生，也是微博剛剛火起來的時候，大家發(fā)現(xiàn)開復曾經(jīng)一段時間內(nèi)都是微博top1，很多人會在想，開復每天沒事兒做都在刷微博嗎?或者開復的微博是不是有個龐大的運營團隊?

我可以給你答案，其實基本上都是開復自己處理的，但是有一點的確是痛點，開復每天都很忙，沒有時間看那么多微博，所以我們玩了個“trick”，目的就是通過程序自動化微博推薦，“揪出”可能會成為爆點或者有意義的微博。開復提了個算法，就是抓取了開復關注的人，和關注人的關注作為種子，然后首先將這些人的微博轉發(fā)歷史建立一個“歷史檔案”，每個人理論上都會計算出一個時間與轉發(fā)量的相關曲線，然后我們會監(jiān)控這些人發(fā)布微博，如果微博在某個時刻超出歷史檔案一定倍數(shù)，我們就會認為這是可被推薦的微博，所以開復每天都是看經(jīng)過篩選后的微博，在這個過程中，其實趕上微博增長爆發(fā)的時候，所以在計算歷史檔案的效率上，我們用了連續(xù)信號的時序抽樣相關算法，減少計算復雜度，并且也會去調整倍數(shù)的參數(shù)，同時我們也每天會手動添加一些新的有價值的種子用戶。

轉承：微博數(shù)據(jù)挖掘到第三方數(shù)據(jù)挖掘

剛剛講了一些故事哈，其實跟開復還做了很多關于微博數(shù)據(jù)的挖掘，后來其實演變成了一款產(chǎn)品叫“脈搏網(wǎng)”，包括微博轉發(fā)的可視化監(jiān)控，找出KOL(意見領袖)分析爆點原因等等。

“脈搏網(wǎng)”雖然表面是微博工具，但是其實我們是一群爬蟲精英。提到第三方數(shù)據(jù)就不得不說到爬蟲了，其實我在做第三方數(shù)據(jù)分析的時候，所有的用戶數(shù)據(jù)都來自于網(wǎng)絡公開數(shù)據(jù)抓取，比如微博、豆瓣、人人、知乎等等，所有的標簽數(shù)據(jù)來自于垂直網(wǎng)站的抓取，例如汽車品類就是汽車之家，旅游就是旅游網(wǎng)站等等。

所謂第三方數(shù)據(jù)分析，其實相對于數(shù)據(jù)使用方而言的，所以對于數(shù)據(jù)提供方的數(shù)據(jù)來源也大概分為幾種：

1. 類似“脈搏網(wǎng)”這種的爬蟲專業(yè)戶

2. 類似Admaster這樣的廣告監(jiān)控，cookie跟蹤用戶頁面訪問記錄等等

3. talkingdata這種數(shù)據(jù)分析平臺，用戶的應用列表數(shù)據(jù)等等

所以包括我們上家創(chuàng)業(yè)公司(37degree)、Admaster和Talkingdata都做了DMP，數(shù)據(jù)源不一樣，但是都會基于各種數(shù)據(jù)進行清洗，然后計算標簽，比如網(wǎng)頁有不同類型的網(wǎng)站，應用也有不同的分類，當然實際的算法會比這個復雜多了。

我來聊聊我做的第三方數(shù)據(jù)的一些點：

先說說數(shù)據(jù)抓取，也就是爬蟲

這個爬蟲不是簡單的發(fā)個請求，解析一下DOM就可以了，實戰(zhàn)中主要從以下方面去解決：

1. 找到合適的接口，包括移動端抓包、PC網(wǎng)站、Wap站，Ajax異步請求

2. 突破限制和驗證，包括模擬請求，繞過驗證碼，登錄驗證，網(wǎng)絡代理

3. 效率問題

先說說第一個問題：

爬蟲的第一點一定是要巧，因為可能節(jié)省的就是指數(shù)級的時間，很多人希望盲目的就去爬取網(wǎng)頁，找到合適的接口是第一步，舉個例子，假如要抓取微博用戶的profile，其實有好幾種辦法：

1. 網(wǎng)頁

2. 客戶端，iOS、Android、平板等等

3. wap網(wǎng)站

同樣的業(yè)務，這些終端都有，所以我們要找的當然是邏輯最簡單的，并且限制最少的，然后就是找接口，對于PC網(wǎng)站，很多人之前都會被一些Javascript異步加載，也就是需要點擊交互才能觸發(fā)的接口卡住，所以喜歡用模擬瀏覽器的庫去處理，這種做法小打小鬧還可以，大規(guī)模處理就會遇到性能等各方面的問題，一般來講，其實用Chrome的調試工具，看network，必要時要點下preserve log，防止日志在重定向時清掉。對于移動端，可以用Charles或者Fiddler2設置終端代理，然后抓包網(wǎng)絡請求，你就可以看到很多請求數(shù)據(jù)了，然后找到自己需要的。這種做法是我一般用的最多的，因為移動端的API幾乎都是結構化的數(shù)據(jù)，不像網(wǎng)頁還需要解析。

然后說說第二個問題，突破限制：

模擬請求肯定是第一步，你要熟知Http協(xié)議，簡單的比如UA、Referer，又比如Cookie在請求頭哪兒設置的，還有的就是一些常用的協(xié)議，比如XAuth協(xié)議，OAuth2.0協(xié)議，我們當時對于爬蟲的同事都是在原理級需要貫通的。

繞過驗證碼，簡單的用一些OCR的庫，比如早期的12306很簡單，復雜的就只能找漏洞了。

登錄驗證，一般來講其實最主要的有兩個，一個是需要連續(xù)請求，中間涉及到添加了一些cookie或者參數(shù)傳遞都得完整跟蹤模擬，第二個就是弄清楚加密的機制，比如早期新浪微博是二次SHA1加密還加salt，后來是RSA加密。對于PC網(wǎng)頁弄清楚加密原理比較簡單，就是要學會閱讀Javascript的代碼。然后就是需要有足夠多的賬號，然后來偽造身份，有的時候也可以不用模擬登陸，用OAuth的一些授權來做，道理也類似，就是要模擬拿到access_token，中間也有一些很有意思的，就比如說我看了OAuth2.0的RFC協(xié)議，然后找到了授權一個隱藏的漏洞。

網(wǎng)絡代理就得看實際情況了。有的請求是http，有的請求是https的，我們當時是抓了大部分網(wǎng)絡公開的代理網(wǎng)站，然后結合不同的抓取域名，驗證這些代理的有效性，然后定時保證大量可用的代理庫，包括http和https的。

最后一個問題就是效率，爬蟲還是一個很大而工程，舉個簡單的例子，我要抓取微博用戶的個人資料、關注關系、微博內(nèi)容，微博內(nèi)容和關注關系還需要分頁，如果是3億的微博賬號，平均一個人5個請求，也就是需要15億請求，一天是86400秒，所以可想而知抓一遍壓力還是很大的。

我們當時的框架主要分為三種，都是自己寫的:

1. 基于Hadoop的爬蟲

2. 基于Celery的單網(wǎng)卡

3. 基于Celery的多網(wǎng)卡分布式

分布式其實一個很重要的就是消息通信，爬蟲框架核心還是URL調度，解析的調度，所以本身如果是分布式解析的話，那么爬下來的內(nèi)容也會占用帶寬，所以多網(wǎng)卡的時候，一般內(nèi)網(wǎng)網(wǎng)卡是千兆，外網(wǎng)帶寬是百兆，通信走內(nèi)網(wǎng)ip，抓取走外網(wǎng)，影響不大，但是如果是單網(wǎng)卡就不一樣了，所以單網(wǎng)卡時，基本上就會減少解析調度，主要信息通信還是URL的調度，利用好網(wǎng)絡資源，解析是異步的。

爬蟲這塊兒詳細的可以看看我之前寫的兩篇爬蟲入門文章。

算法分析

接下來說說算法分析這塊。抓取數(shù)據(jù)只是一部分，其實更大的挑戰(zhàn)還是算法分析這塊，諸如用戶畫像、標簽計算，以及機器學習應用里面的聚類分類等等。

首先說說影響力算法。有個很有意思的就是之前我們對于微博用戶影響力的計算，我們用的就是pagerank相關的算法，因為用戶之前的關注關系很類似網(wǎng)頁之間的鏈接關系，所以我們當時抓去了所有用戶的關注關系，用pagerank的算法來計算了這些人的影響力排名。

消費能力計算。微博用戶有發(fā)布微博的設備列表，有加V認證的類型，并且還有關注關系，所以我們結合這些維度計算了消費能力。

標簽計算我們是預先標注了一些標簽庫，然后將用戶的微博進行分詞詞頻統(tǒng)計，然后找到對應標簽然后統(tǒng)計權重，標簽庫就是主要來源于垂直網(wǎng)站的抓取訓練。

其實計算影響力和消費能力也是很大的挑戰(zhàn)，就是這種都是算法應用，還是一樣效率有很大的挑戰(zhàn)，比如1秒計算100個人，一天也只能計算800多萬個用戶，算完所有用戶也要一個月，所以我們做了很多性能優(yōu)化，降維，犧牲一定準確性換取效率。另外比如pagerank這種算法還是迭代性的，用hadoop的話其實不是很適合，后來我們又嘗試了graphlab。

除了微博數(shù)據(jù)的分析，我們其實還有很多數(shù)據(jù)分析處理，大體其實主要是兩種，一種是非結構化數(shù)據(jù)，一種是結構化的數(shù)據(jù)。

微博抓下來的大多都是人口屬性和json，都屬于結構化數(shù)據(jù)，但是微博內(nèi)容又屬于非結構化的。

簡歷數(shù)據(jù)的匹配

簡歷和職位要求匹配就是非結構化數(shù)據(jù)處理，用的主要還是聚類分類的算法。

簡歷匹配的場景主要是，用于很多公司需要去在茫茫簡歷中找到和自己職位相關性最高的簡歷。或者一個應聘者需要快速找到和自己相關度最高的職位，因為即使是java工程師，其實也有很多類型，傳統(tǒng)通過目錄索引方式很難匹配，不同公司取的名稱也不一樣，也必須要看詳細的職位要求。

機器學習其實主要分為兩種，無監(jiān)督和有監(jiān)督的學習，我們當時運用的就是無監(jiān)督的LDA算法，這個在廣告領域應用較多，核心原理你可以認為我們想要聚類分類的就是一些方向，每一個文本行可以是一堆向量，向量有長度和方向，最終我們找到這些向量的相似性。

解釋下，比如一個簡歷認為是一個處理單元，我們預先準備好職位相關的詞庫，然后這些詞可以認為就是方向，我們將簡歷TF-IDF算法處理后，去除無關詞匯，其實就是一些詞和詞頻的組合，可以認為是向量和向量的長度，然后再進行聚類，因為是無監(jiān)督，所以我們需要去預估大概有多少個分類，然后不停去調配參數(shù)。

最終得到一些聚類。

用戶畫像其實就是像上述一樣，我們會設計好很多人口特征的維度，也會根據(jù)我們的數(shù)據(jù)源去找到可以潛在推測的維度，那么這些維度就可能構成人物的畫像，例如影響力，消費能力，興趣能力，品牌標簽等等，又結合應用領域的不一樣，標簽往往要從細分領域提取，所以就提到要去抓取垂直網(wǎng)站的語料，然后抽取訓練，最后給用戶打標簽，或者給用戶聚類分類。我們建立了龐大的用戶數(shù)據(jù)庫，一直服務于廣告營銷等行業(yè)。

但是在做這個過程中，我們深深感受到的是當今企業(yè)內(nèi)分析能力的不足，以及過多的分析需求聚焦于“流量獲取”上，總想從外部拿到數(shù)據(jù)匹配用戶的標簽，但是自己的業(yè)務數(shù)據(jù)分析處理很薄弱，另外一方面也是不關心用戶的engagement，所以才想到要做第一方數(shù)據(jù)分析工具，幫助更多企業(yè)從內(nèi)容數(shù)據(jù)處理優(yōu)化做起。

接下來來聊聊第一方數(shù)據(jù)分析。

第一方數(shù)據(jù)分析

第一方數(shù)據(jù)簡單來理解就是自有數(shù)據(jù)，大多數(shù)公司的自有數(shù)據(jù)就是數(shù)據(jù)庫里面的用戶產(chǎn)生的業(yè)務數(shù)據(jù)，數(shù)據(jù)分析意識高一點的公司在此之外，可能會嘗試通過日志收集一些用戶的行為數(shù)據(jù)。所謂行為數(shù)據(jù)就是包括進入產(chǎn)品，瀏覽等一系列的使用行為，或者收藏，關注，購買搜索等一系列的業(yè)務行為。

對于大多數(shù)初期小公司而言，都沒有自己的數(shù)據(jù)分析平臺，所以大多數(shù)時候的第一方數(shù)據(jù)分析，是依賴于工程寫腳本，根據(jù)需求查數(shù)據(jù)庫去計算。

很多時候時間都浪費在了溝通，確認需求，寫腳本，等待結果運算上，我相信很多公司一定有共鳴。

對于很多有一定能力的互聯(lián)網(wǎng)公司，公司內(nèi)部也開始構建自己的數(shù)據(jù)分析平臺，并且已經(jīng)開始收集用戶的行為數(shù)據(jù)進行分析，但是大多數(shù)對于行為的數(shù)據(jù)利用還是限制于兩種：

第一種做法還是傳統(tǒng)BI，基于Oracle等關系型數(shù)據(jù)庫或者基于Hadoop的統(tǒng)計分析，一般來講就是設計好數(shù)據(jù)倉庫的模型，包括待分析的一些維度，然后基于維度進行匯總統(tǒng)計，比如在產(chǎn)品領域，就是去統(tǒng)計一些關鍵行為的發(fā)生次數(shù)，常見的就是計算頁面訪問量，獨立用戶數(shù)，留存率等指標，簡而言之也就是用于統(tǒng)計結果了。

第二種做法就是利用行為數(shù)據(jù)進行個性化的數(shù)據(jù)推薦。這個還是比較make sense的，從早期的亞馬遜的推薦到Facebook的相關推薦，這個是我比較推崇的不做結果，而是優(yōu)化過程的數(shù)據(jù)運用。

個性化推薦現(xiàn)在常用的就是協(xié)同過濾了，基本也是分為兩種，一個是基于熱度，一個是基于興趣的，前者是user-based，后者是item-based，如果你想打造一個興趣社區(qū)，那么一定要避免根據(jù)統(tǒng)計結果，進行熱門推薦，而興趣推薦的一個重點就是要預設一些標簽。

綜合兩類公司的做法來看，其實用戶的產(chǎn)品互動行為數(shù)據(jù)基本上始終被當做一個黑盒子來看，推薦算法雖然對這些數(shù)據(jù)利用的比較好但是只是一個對單用戶縱深的分析做法，而橫向的用戶分析最終止于高度匯總的報表，并不能探索和驗證用戶在產(chǎn)品上的行為如何影響了公司的業(yè)務指標。一個典型的現(xiàn)象就是很多產(chǎn)品的迭代決策靠的是猜測或者直覺。

所以基于這些考慮，我們就想怎么才能打造一個更加有意義的第一方數(shù)據(jù)分析平臺，而不只是多維交叉匯總結果。

于是就想到了做諸葛io，那諸葛io和過去的第一方數(shù)據(jù)運用有什么區(qū)別呢?我們先從業(yè)務來看。

兩張圖，一個核心，就是以用戶為中心，所以“流量時代”關注的是用戶數(shù)量結果，BI關注的是維度聚合結果，而我們關心的是用戶。

我們過去看到一些dashboard的圖表，上升下降可能很難找到原因，因為一開始分析的基礎就是維度匯總的數(shù)據(jù)。

但是如果所有的數(shù)據(jù)以獨立的用戶跟蹤為基礎就不一樣了，假若我們看到新增的這些數(shù)字，或者匯總分布的結果，我們可以找到每個delta數(shù)字背后的人，能還原這些用戶的豐富業(yè)務標簽和維度，亦然可以做更多的比較和深入分析了。

所以用戶的行為數(shù)據(jù)在個性化推薦之外，之前每次業(yè)務的交互，也都是這些用戶豐富的標簽，比如知乎“關注了XX話題”、“關注了XX用戶”、“點贊了XX內(nèi)容”、“分享XX文章”，這些行為是非常豐富的標簽，組合起來亦然，比之前說的第三方數(shù)據(jù)計算出標簽意義更大，因為后續(xù)還以為著你分析的結果是能反饋到這些用戶的，例如換回流失，精準推送等等。

再從技術上來講講，主要其實還是lambda架構。我們以Kafka為消息中心，利用多層生產(chǎn)者與消費者的概念，對數(shù)據(jù)進行多種運用，例如實時計算、打標簽、導入數(shù)據(jù)倉庫、備份等等。

數(shù)據(jù)存儲，也用了SQL和NoSQL，但即使是SQL也是用的列式存儲數(shù)據(jù)庫，NoSQL諸如Elasticsearch進行索引，承載一些快速查詢的場景，關系型主要用于復雜計算，因為我們不止是用戶、事件兩個主題，我們還有會話，所以復雜度很高，中間我們也用了一些小trick，以后有機會和大家分享一下：

Q&A

問題1：大數(shù)據(jù)開發(fā)和數(shù)據(jù)分析師的具體職能和區(qū)別

大數(shù)據(jù)開發(fā)和數(shù)據(jù)分析師還是很大不一樣的，數(shù)據(jù)分析其實是一個鏈條，從數(shù)據(jù)采集，到數(shù)據(jù)收集，到數(shù)據(jù)清洗，到數(shù)據(jù)建模，到數(shù)據(jù)分析，大數(shù)據(jù)開發(fā)一般來講主要是前面四環(huán)，負責為數(shù)據(jù)分析師做好基礎，大數(shù)據(jù)開發(fā)一般來講也有基礎數(shù)據(jù)ETL，和數(shù)據(jù)倉庫區(qū)別，整體而言還是偏技術，而數(shù)據(jù)分析師還是偏如何利用數(shù)據(jù)分析出價值來，數(shù)據(jù)分析師本身也是結合不同行業(yè)角色或者場景，洞察數(shù)據(jù)價值

問題2：大數(shù)據(jù)數(shù)據(jù)質量有哪些保障措施?

大數(shù)據(jù)最重要的是要保證原始數(shù)據(jù)的全和安全，后面的加工處理出問題，都能夠再恢復，質量分為兩方面，一個是數(shù)據(jù)準確性，一個是數(shù)據(jù)安全。數(shù)據(jù)準確性一般而言還是要進行測試校驗和核對，涉及一些SQL或者視圖的邏輯等等，數(shù)據(jù)安全性則要通過可信任的第三方，或者自有托管安全保障，防火墻，傳輸加密都是必要的

問題3：基于hadoop的爬蟲思路是什么?是屬于分布式爬蟲?

對，hadoop其實核心是mapreduce和HDFS，一套計算，一套存儲，本身也是能通過mapper和reducer進行調度，所以是利用這樣的一個特性，另外一方面HDFS的存儲，也能對接我們后面一些算法分析的job，也是通過hadoop編寫的

問題4：請問，諸葛IO分析細化到單用戶粒度，最主要的3個實際應用場景是什么?

1. 運營或者廣告領域的渠道評估

2. 產(chǎn)品下的功能模塊衡量，或者產(chǎn)品體驗優(yōu)化

3. 對業(yè)務的多維分析

來源：大數(shù)據(jù)雜談