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

標籤：

孔淼：大資料分析處理與使用者畫像實踐

直播內容如下：

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

第三方資料分析

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

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

微博剛剛火起來的時候，大家發現開複曾經一段時間內都是微博的 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的調度，通過非同步解析的方式來最大程度的利用好網路資源。

爬蟲這塊想瞭解更多的話，可以看看我之前寫的兩篇爬蟲入門文章。
《爬蟲入門上篇》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 的相關推薦，這個是我比較推崇的：不只計算結果，而是運用資料最佳化業務。

個人化推薦現在常用的就是協同過濾。基本也是分為兩種，一個是基於熱度，一個是基於興趣。前者是 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劫持都被某些資料商販賣，黑色產業鏈
   另外未來的資料分析和交換更多可能會基於企業自由交易，以及使用者的身份加密

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