技術培訓 | 大資料分析處理與使用者畫像實踐

孔淼：大資料分析處理與使用者畫像實踐
直播內容如下：

---

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

第三方資料分析

先聊聊“第三方資料分析”，這個主要結緣於我給開復做微博資料探勘。

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

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

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

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

在這個過程中，趕上了微博增長的爆發階段，所以在計算歷史檔案的效率上，我們用了連續訊號的時序抽樣相關演算法，減少計算複雜度，並且也會去調整倍數的引數，同時我們每天也會在資料庫裡手動新增一些新的有價值的種子使用者。

轉承：微博資料探勘到第三方資料探勘

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

其實我在做第三方資料分析的時候，所有的使用者資料都來自於網路公開的資料抓取，比如微博、豆瓣、人人、知乎等等，所有的標籤資料來自於垂直網站的抓取，例如汽車品類就是汽車之家，旅遊就是旅遊網站等等。

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

1. 類似“脈搏網”這種的爬蟲專業戶
2. 類似 Admaster 這樣的廣告監控， Cookie 跟蹤使用者頁面訪問記錄等等
3. 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的排程，透過非同步解析的方式來最大程度的利用好網路資源。

爬蟲這塊想了解更多的話，可以看看我之前寫的兩篇爬蟲入門文章。
《爬蟲入門上篇》
《爬蟲入門下篇》

演算法分析

接下來說說演算法分析這塊。抓取資料只是一部分，其實更大的挑戰還是演算法分析，諸如使用者畫像、標籤計算，以及機器學習應用裡面的聚類分類等等。

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

消費能力計算
微博使用者有釋出微博的裝置列表，有加 V 認證的型別，並且還有關注關係，所以我們結合這些維度計算了消費能力。

標籤計算
預先標註一些標籤庫，然後將使用者的微博進行分詞詞頻統計，然後找到對應標籤統計權重，標籤庫主要來源於垂直網站的抓取訓練。

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

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

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

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

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

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

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

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

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

第一方資料分析

接下來來聊聊第一方資料分析。

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

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

對於很多有一定能力的網際網路公司，公司內部也開始構建自己的資料分析平臺，並且已經開始收集使用者的行為資料進行分析，但是大多數對於行為的資料利用還是限制於兩種：

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

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

個性化推薦現在常用的就是協同過濾。基本也是分為兩種，一個是基於熱度，一個是基於興趣。前者是 user-based，後者是 item-based，如果你想打造一個興趣社群，那麼一定要避免根據統計結果，進行熱門推薦，而興趣推薦的一個重點就是要預設一些標籤。

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

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

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

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

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

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

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

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

我們以 Kafka 為訊息中心，利用多層生產者與消費者的概念，對資料進行運用，例如實時計算、打標籤、匯入資料倉儲、備份等等。

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

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

---

Q&A

1. 如何高效的剔除無用的資料，減少大量批次註冊的使用者的資料，讓資料探勘更加有價值。
   第一層就是透過簡單的ip或者其他反spam規則過濾，第二層就是基於使用者行為分層可以做一些過濾，比如滿足完成過某些行為或者訪問次數大於多少天的等等，第三層就是使用者聚類可以找到這些差異使用者
2. 如何提高爬蟲的效率，剔除無價值的資訊
   這個問題和資料分析很類似，就是先明確目的，然後過濾無關資料來源，比如說如果是計算標籤，那麼確定需要的垂直網站，語料範圍等等，再開始定向抓取，有些人會直接用廣度優先的開源爬蟲框架根據URL抓取，多設定些相關性規則
3. 如何繞開被爬取對方的對於防爬蟲的機制
   剛剛已經講了一些，一定要思路靈活，潛在的漏洞，可觸及的訪問方式，幾近的模擬，肯定有辦法的
4. 請問如何有效防止爬蟲爬取網站資料，防止盜取盜鏈
   反爬的策略也是一層層的，最簡單的就是UA或者Referer或者cookie的http協議設定，會攔住一大批初級爬蟲，然後就是高階一點的請求次數許可權控制，最後可能就是要損失一些使用者體驗了，驗證碼等等，另外HTTPS很重要，防止閘道器大規模使用者token洩露
5. 何種演算法對於使用者肖像描繪比較適合
   這個問題不好回答哈，分享中提及到了影響力、標籤演算法，其實還是要根據業務應用場景以及資料來源來的，很靈活
6. 對於多項資料分析，比如天氣的陰晴雨雪如何設定權值更合理
   權值需要設定結果目標，然後多做測試，相關性分析，調配引數
7. 怎樣建立一種評估體系，讓真正有價值的大資料凸顯出來，同時可以節省成本呢？
   這其實就是諸葛io在做的，現在的大資料大多都是aggregation，真正的大資料要懂user behavior，然後個性化服務，以及產品市場策略，提高ROI，也降低使用者發現價值的成本，那麼企業就更有可能提升效益，以及降低成本了
   customer acquisition時代我們依賴第三方資料進行匹配和使用者獲取，但是customer engagement時代，我們要做的是理解user behavior，提高轉化率，和企業效率
8. 企業線上蒐集使用者資料，在做大資料分析時如何平衡企業效用與網路使用者個人隱私之間的關係，尊重和保證網路使用者的個人隱私？
   歐盟有很多規範，至少比國內現在很多企業透過植入SDK到開發者程式，透過覆蓋抓取客戶資料，然後來支撐自己的商業利益有很多，比如你們用google和apple的服務經常會彈出是否允許收集資料要好很多
   現在資料隱私洩露很普遍，比如大家的簡訊，網路的DNS劫持都被某些資料商販賣，黑色產業鏈
   另外未來的資料分析和交換更多可能會基於企業自由交易，以及使用者的身份加密