摘要：孔淼大數據分析處理與用戶畫像實踐直播內容如下今天咱們就來閑聊下我過去接觸過的數據分析領域，因為我是連續創業者，所以我更多的注意力還是聚焦在解決問題和業務場景上。在對微博數據進行上面提到的計算分析之前，我們其實還做了很多數據處理的工作。

孔淼：大數據分析處理與用戶畫像實踐

今天咱們就來閑聊下我過去接觸過的數據分析領域，因為我是連續創業者，所以我更多的注意力還是聚焦在解決問題和業務場景上。如果把我在數據分析的經驗進行劃分的話，剛好就是我所經歷的兩次創業階段，第一階段是“第三方數據分析”，第二階段是“第一方數據分析”。所以今天咱們就從這兩點來談談數據分析。

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

微博剛剛火起來的時候，大家發現開復曾經一段時間內都是微博的 Top1，很多人會在想，開復每天都在刷微博嗎？或者開復的微博是不是有個龐大的運營團隊？

我可以給你答案，其實基本上都是開復自己處理的。但是開復每天都很忙，沒有時間看那么多微博，所以我們玩了個 “trick” ，通過程序自動化微博推薦，“揪出”可能會成為爆點或者有意義的微博。

開復提了個算法，就是抓取自己關注的人，以及關注人的關注作為種子，首先將這些人的微博轉發歷史建立一個“歷史檔案”，理論上每個人都可以計算出一個時間與轉發量的相關函數曲線，然后通過監控這些人的微博，如果在某個時刻，微博的發布超出歷史檔案一定倍數，我們就會認為這是可被推薦的微博，所以開復每天看的都是經過篩選后的微博。

在這個過程中，趕上了微博增長的爆發階段，所以在計算歷史檔案的效率上，我們用了連續信號的時序抽樣相關算法，減少計算復雜度，并且也會去調整倍數的參數，同時我們每天也會在數據庫里手動添加一些新的有價值的種子用戶。

剛剛講了一些故事，其實跟著開復還做了很多關于微博數據的挖掘，后來其演變成了一款產品叫“脈搏網”，包括微博轉發的可視化監控，找出 KOL （意見領袖）分析爆點原因等等?！懊}搏網”雖然表面是微博工具，但是其本質是一群精英爬蟲。談到今天的話題，第三方數據，就不得不說爬蟲。

其實我在做第三方數據分析的時候，所有的用戶數據都來自于網絡公開的數據抓取，比如微博、豆瓣、人人、知乎等等，所有的標簽數據來自于垂直網站的抓取，例如汽車品類就是汽車之家，旅游就是旅游網站等等。

所謂第三方數據分析，其實相對于數據使用方的自有數據（第一方數據）而言的。對于數據提供方的數據來源也大概分為幾種：

類似“脈搏網”這種的爬蟲專業戶

類似 Admaster 這樣的廣告監控， Cookie 跟蹤用戶頁面訪問記錄等等

Talkingdata 這種數據分析平臺，用戶的應用列表數據等等

所以包括我們上家創業公司（37degree）、 Admaster 和 Talkingdata 都做了DMP（Data management platform），雖然大家的數據源不一樣，但是都會基于各種數據進行清洗，然后計算標簽，比如網頁有不同類型的網站，應用也有不同的分類，當然實際的算法會比這個復雜多了。

來聊聊我做的第三方數據的一些經驗：

先說說數據抓取，也就是爬蟲。

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

找到合適的接口，包括移動端抓包、PC 網站、Wap 站、Ajax 異步請求

突破限制和驗證，包括模擬請求，繞過驗證碼，登錄驗證，網絡代理

效率問題

先說說第一個問題：

爬蟲的第一要點一定是巧取。
很多人盲目的去爬取所有能爬到的網頁接口，這樣做是不對的。找到合適的接口是做爬蟲的第一步，這樣節省的時間可能是指數級的。舉個例子，假如要抓取微博用戶的 profile ，有以下幾種辦法：

網頁

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

wap 網站

同樣的業務，各個終端都有。我們所要作的就是在其中找邏輯最簡單的，并且限制最少的接口去做爬取。

對于PC網站，很多人之前都會被一些 Javascript 異步加載，也就是需要點擊交互才能觸發的接口卡住，所以喜歡用模擬瀏覽器的庫去處理，這種做法小打小鬧還可以，大規模處理就會遇到性能等各方面的問題。一般來講，用 Chrome 的調試工具，看 Network ，必要時要點下 Preserve Log ，防止日志在重定向時清掉。

對于移動端，可以用 Charles 或者 Fiddler2 設置終端代理，然后抓包網絡請求，這樣就可以看到很多請求數據了，然后找到自己需要的。這種做法我一般用的最多，因為移動端的 API 幾乎都是結構化的數據，不像網頁還需要解析。

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

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

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

登錄驗證，一般來講其實最主要的有兩個問題：

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

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

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

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

基于 Hadoop 的爬蟲

基于 Celery 的單網卡

基于 Celery 的多網卡分布式

分布式其實一個很重要的特性就是消息通信，爬蟲框架核心是頻繁的URL調度和解析的調度。如果是用分布式解析的方法來解析站點的話，那么爬下來的內容會占用非常多的帶寬。在多網卡環境下，一般內網千兆，外網百兆，通信走內網，抓取走外網，這樣對帶寬影響不大。但是如果是單網卡環境時就不一樣了，所以單網卡時，基本上就會相應減少解析調度，主要的信息通信依然是URL的調度，通過異步解析的方式來最大程度的利用好網絡資源。

爬蟲這塊想了解更多的話，可以看看我之前寫的兩篇爬蟲入門文章。
《爬蟲入門上篇》https://zhuanlan.zhihu.com/p/20334680?refer=zhugeio
《爬蟲入門下篇》https://zhuanlan.zhihu.com/p/20336750?refer=zhugeio

算法分析

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

影響力算法
我們對微博用戶影響力的計算用的就是 Pagerank 相關的算法，因為用戶之前的關注關系很類似網頁之間的鏈接關系，所以我們當時抓取了所有用戶的關注關系，用 Pagerank 的算法來計算這些人的影響力排名。

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

標簽計算
預先標注一些標簽庫，然后將用戶的微博進行分詞詞頻統計，然后找到對應標簽統計權重，標簽庫主要來源于垂直網站的抓取訓練。

其實計算影響力和消費能力是很大的挑戰，雖然這些事情都是通過算法去實現，但效率上還是有很大的挑戰，比如 1 秒計算 100 個人，一天也只能計算 800 多萬個用戶，算完所有用戶也要一個月，所以我們做了很多算法和性能的優化，甚至犧牲一定準確性換取效率。最開始我們用過 Pagerank ，后來嘗試了 Hadoop 也不是很理想，計算量太大。最后我們優化了算法，換了 Graphlab 的計算引擎。

在對微博數據進行上面提到的計算分析之前，我們其實還做了很多數據處理的工作。大家都知道，數據大體可以分為兩種，一種是非結構化數據，一種是結構化的數據。

比方說：微博抓下來的大多都是人口屬性和 Json ，這些屬于結構化數據；同時，大家發的140個字的微博內容，這些就屬于非結構化的數據。而在簡歷數據匹配的項目里，簡歷內容和職位要求也大多是非結構化的。

對于非結構話數據的匹配分析，就要用聚類分類的算法了。簡歷匹配的場景，主要適用于在茫茫簡歷中找到和企業自身職位相關性最高的簡歷，或者一個應聘者需要快速找到和自己相關度最高的職位，這個時候，為結構化數據準備的傳統的目錄索引的方式就很難滿足需求了。舉個例子，即便都是 Java 工程師，不同公司給這個崗位取的名稱可能不一樣（ Java 工程師、后端工程師等等），這個時候就要看詳細的職位要求，通過對非結構的“崗位描述”信息進行聚類分析來實現匹配。

機器學習主要分為兩種，無監督學習和有監督的學習。

我們做簡歷的項目運用的就是無監督的 LDA 算法，這個在廣告領域應用較多，核心原理你可以認為我們想要聚類分類的就是一些方向，每一個文本行可以是一堆向量，向量有長度和方向，最終我們通過比較找到這些向量的相似性。

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

用戶畫像其實就是像上述一樣，我們會設計好很多人口特征的維度，也會根據我們的數據源去找到可以潛在推測的維度，那么這些維度就可能構成人物的畫像，例如影響力，消費能力，興趣能力，品牌標簽等等，又結合應用領域的不一樣，標簽往往要從細分領域提取，所以就提到要去抓取垂直網站的語料，然后抽取訓練，最后給用戶打標簽，或者給用戶聚類分類。

我們建立了龐大的用戶數據庫，一直服務于廣告營銷等行業。但是在做這個過程中，我們深深感受到的是當今企業內分析能力的不足，以及過多的分析需求聚焦于“流量獲取”上，總想從外部拿到數據匹配用戶的標簽，但是自己的業務數據分析處理很薄弱，另外一方面也是不關心用戶的 engagement ，所以我才想到要做第一方數據分析工具，幫助更多企業從內容數據處理優化做起。

接下來來聊聊第一方數據分析。

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

對于大多數初期小公司而言，都沒有自己的數據分析平臺，所以多數時候的第一方數據分析是依賴于工程師寫腳本，根據需求去查數據庫。大量的時間都浪費在溝通、確認需求、寫腳本、等待結果運算這些流程中。

對于很多有一定能力的互聯網公司，公司內部也開始構建自己的數據分析平臺，并且已經開始收集用戶的行為數據進行分析，但是大多數對于行為的數據利用還是限制于兩種：

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

第二種做法就是利用行為數據進行個性化的數據推薦。這個還是比較 Make Sense 的，從早期亞馬遜的推薦到 Facebook 的相關推薦，這個是我比較推崇的：不只計算結果，而是運用數據優化業務。

個性化推薦現在常用的就是協同過濾?；疽彩欠譃閮煞N，一個是基于熱度，一個是基于興趣。前者是 user-based，后者是 item-based，如果你想打造一個興趣社區，那么一定要避免根據統計結果，進行熱門推薦，而興趣推薦的一個重點就是要預設一些標簽。

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

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

于是就想到了做諸葛 io，那諸葛 io 和過去的第一方數據運用有什么區別呢？我們先從業務來看就是以用戶為中心，所以“流量時代”關注的是用戶數量結果，BI關注的是維度聚合結果，而我們關心的是用戶。

諸葛 io 目前已經在青云 QingCloud 應用中心上線，歡迎各位青云的用戶前去使用。

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

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

可以說“行為即標簽”。用戶的行為數據、之前每次的交互行為等，都可以構成豐富的業務標簽。舉“知乎”這個社區為例，“關注了XX話題”“關注了XX用戶”“點贊了XX內容”“分享XX文章”，這些行為本身就是非常豐富且有用的標簽，組合起來亦然。基于用戶在產品內的行為所構建的標簽體系，比之前說的第三方數據計算出標簽意義更大。因為基于行為設定的標簽，后續是能反作用于用戶的，我們可以為不同行為標簽下的用戶群設定更精準的運營策略，例如內容推薦、活動促銷、精準推送等等。

最后，再從技術上來講講，主要使用的其實還是 lambda 架構。

我們以 Kafka 為消息中心，利用多層生產者與消費者的概念，對數據進行運用，例如實時計算、打標簽、導入數據倉庫、備份等等。

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

以上是我本次的分享，謝謝大家。

如何高效的剔除無用的數據，減少大量批量注冊的用戶的數據，讓數據挖掘更加有價值。
第一層就是通過簡單的ip或者其他反spam規則過濾，第二層就是基于用戶行為分層可以做一些過濾，比如滿足完成過某些行為或者訪問次數大于多少天的等等，第三層就是用戶聚類可以找到這些差異用戶

如何提高爬蟲的效率，剔除無價值的信息
這個問題和數據分析很類似，就是先明確目的，然后過濾無關數據源，比如說如果是計算標簽，那么確定需要的垂直網站，語料范圍等等，再開始定向抓取，有些人會直接用廣度優先的開源爬蟲框架根據URL抓取，多設置些相關性規則

如何繞開被爬取對方的對于防爬蟲的機制
剛剛已經講了一些，一定要思路靈活，潛在的漏洞，可觸及的訪問方式，幾近的模擬，肯定有辦法的

請問如何有效防止爬蟲爬取網站數據，防止盜取盜鏈
反爬的策略也是一層層的，最簡單的就是UA或者Referer或者cookie的http協議設定，會攔住一大批初級爬蟲，然后就是高級一點的請求次數權限控制，最后可能就是要損失一些用戶體驗了，驗證碼等等，另外HTTPS很重要，防止網關大規模用戶token泄露

何種算法對于用戶肖像描繪比較適合
這個問題不好回答哈，分享中提及到了影響力、標簽算法，其實還是要根據業務應用場景以及數據源來的，很靈活

對于多項數據分析，比如天氣的陰晴雨雪如何設定權值更合理
權值需要設定結果目標，然后多做測試，相關性分析，調配參數

怎樣建立一種評估體系，讓真正有價值的大數據凸顯出來，同時可以節省成本呢？
這其實就是諸葛io在做的，現在的大數據大多都是aggregation，真正的大數據要懂user behavior，然后個性化服務，以及產品市場策略，提高ROI，也降低用戶發現價值的成本，那么企業就更有可能提升效益，以及降低成本了

customer acquisition時代我們依賴第三方數據進行匹配和用戶獲取，但是customer engagement時代，我們要做的是理解user behavior，提高轉化率，和企業效率

企業在線搜集用戶數據，在做大數據分析時如何平衡企業效用與網絡用戶個人隱私之間的關系，尊重和保證網絡用戶的個人隱私？
歐盟有很多規范，至少比國內現在很多企業通過植入SDK到開發者程序，通過覆蓋抓取客戶數據，然后來支撐自己的商業利益有很多，比如你們用google和apple的服務經常會彈出是否允許收集資料要好很多

現在數據隱私泄露很普遍，比如大家的短信，網絡的DNS劫持都被某些數據商販賣，黑色產業鏈
另外未來的數據分析和交換更多可能會基于企業自由交易，以及用戶的身份加密