摘要：孔淼大數(shù)據(jù)分析處理與用戶畫像實(shí)踐直播內(nèi)容如下今天咱們就來閑聊下我過去接觸過的數(shù)據(jù)分析領(lǐng)域，因?yàn)槲沂沁B續(xù)創(chuàng)業(yè)者，所以我更多的注意力還是聚焦在解決問題和業(yè)務(wù)場景上。在對微博數(shù)據(jù)進(jìn)行上面提到的計(jì)算分析之前，我們其實(shí)還做了很多數(shù)據(jù)處理的工作。

孔淼：大數(shù)據(jù)分析處理與用戶畫像實(shí)踐

今天咱們就來閑聊下我過去接觸過的數(shù)據(jù)分析領(lǐng)域，因?yàn)槲沂沁B續(xù)創(chuàng)業(yè)者，所以我更多的注意力還是聚焦在解決問題和業(yè)務(wù)場景上。如果把我在數(shù)據(jù)分析的經(jīng)驗(yàn)進(jìn)行劃分的話，剛好就是我所經(jīng)歷的兩次創(chuàng)業(yè)階段，第一階段是“第三方數(shù)據(jù)分析”，第二階段是“第一方數(shù)據(jù)分析”。所以今天咱們就從這兩點(diǎn)來談?wù)剶?shù)據(jù)分析。

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

微博剛剛火起來的時(shí)候，大家發(fā)現(xiàn)開復(fù)曾經(jīng)一段時(shí)間內(nèi)都是微博的 Top1，很多人會在想，開復(fù)每天都在刷微博嗎？或者開復(fù)的微博是不是有個(gè)龐大的運(yùn)營團(tuán)隊(duì)？

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

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

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

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

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

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

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

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

Talkingdata 這種數(shù)據(jù)分析平臺，用戶的應(yīng)用列表數(shù)據(jù)等等

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

來聊聊我做的第三方數(shù)據(jù)的一些經(jīng)驗(yàn)：

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

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

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

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

效率問題

先說說第一個(gè)問題：

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

網(wǎng)頁

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

wap 網(wǎng)站

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

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

對于移動端，可以用 Charles 或者 Fiddler2 設(shè)置終端代理，然后抓包網(wǎng)絡(luò)請求，這樣就可以看到很多請求數(shù)據(jù)了，然后找到自己需要的。這種做法我一般用的最多，因?yàn)橐苿佣说?API 幾乎都是結(jié)構(gòu)化的數(shù)據(jù)，不像網(wǎng)頁還需要解析。

然后說說第二個(gè)問題，突破限制：

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

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

登錄驗(yàn)證，一般來講其實(shí)最主要的有兩個(gè)問題：

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

網(wǎng)絡(luò)代理就得看實(shí)際情況了。有的請求是 HTTP ，有的請求是 HTTPS ，我們當(dāng)時(shí)是抓了大部分網(wǎng)絡(luò)公開的代理網(wǎng)站，然后結(jié)合不同的抓取域名，驗(yàn)證這些代理的有效性，保證隨時(shí)擁有大量可用的代理庫，包括 HTTP 和 HTTPS 的。

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

我們當(dāng)時(shí)的框架主要分為三種，都是自己寫的:

基于 Hadoop 的爬蟲

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

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

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

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

算法分析

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

影響力算法
我們對微博用戶影響力的計(jì)算用的就是 Pagerank 相關(guān)的算法，因?yàn)橛脩糁暗年P(guān)注關(guān)系很類似網(wǎng)頁之間的鏈接關(guān)系，所以我們當(dāng)時(shí)抓取了所有用戶的關(guān)注關(guān)系，用 Pagerank 的算法來計(jì)算這些人的影響力排名。

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

標(biāo)簽計(jì)算
預(yù)先標(biāo)注一些標(biāo)簽庫，然后將用戶的微博進(jìn)行分詞詞頻統(tǒng)計(jì)，然后找到對應(yīng)標(biāo)簽統(tǒng)計(jì)權(quán)重，標(biāo)簽庫主要來源于垂直網(wǎng)站的抓取訓(xùn)練。

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

在對微博數(shù)據(jù)進(jìn)行上面提到的計(jì)算分析之前，我們其實(shí)還做了很多數(shù)據(jù)處理的工作。大家都知道，數(shù)據(jù)大體可以分為兩種，一種是非結(jié)構(gòu)化數(shù)據(jù)，一種是結(jié)構(gòu)化的數(shù)據(jù)。

比方說：微博抓下來的大多都是人口屬性和 Json ，這些屬于結(jié)構(gòu)化數(shù)據(jù)；同時(shí)，大家發(fā)的140個(gè)字的微博內(nèi)容，這些就屬于非結(jié)構(gòu)化的數(shù)據(jù)。而在簡歷數(shù)據(jù)匹配的項(xiàng)目里，簡歷內(nèi)容和職位要求也大多是非結(jié)構(gòu)化的。

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

機(jī)器學(xué)習(xí)主要分為兩種，無監(jiān)督學(xué)習(xí)和有監(jiān)督的學(xué)習(xí)。

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

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

用戶畫像其實(shí)就是像上述一樣，我們會設(shè)計(jì)好很多人口特征的維度，也會根據(jù)我們的數(shù)據(jù)源去找到可以潛在推測的維度，那么這些維度就可能構(gòu)成人物的畫像，例如影響力，消費(fèi)能力，興趣能力，品牌標(biāo)簽等等，又結(jié)合應(yīng)用領(lǐng)域的不一樣，標(biāo)簽往往要從細(xì)分領(lǐng)域提取，所以就提到要去抓取垂直網(wǎng)站的語料，然后抽取訓(xùn)練，最后給用戶打標(biāo)簽，或者給用戶聚類分類。

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

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

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

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

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

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

第二種做法就是利用行為數(shù)據(jù)進(jìn)行個(gè)性化的數(shù)據(jù)推薦。這個(gè)還是比較 Make Sense 的，從早期亞馬遜的推薦到 Facebook 的相關(guān)推薦，這個(gè)是我比較推崇的：不只計(jì)算結(jié)果，而是運(yùn)用數(shù)據(jù)優(yōu)化業(yè)務(wù)。

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

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

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

于是就想到了做諸葛 io，那諸葛 io 和過去的第一方數(shù)據(jù)運(yùn)用有什么區(qū)別呢？我們先從業(yè)務(wù)來看就是以用戶為中心，所以“流量時(shí)代”關(guān)注的是用戶數(shù)量結(jié)果，BI關(guān)注的是維度聚合結(jié)果，而我們關(guān)心的是用戶。

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

我們過去看到一些 Dashboard 的圖表，上升下降可能很難找到原因，因?yàn)橐婚_始分析的基礎(chǔ)就是維度匯總的數(shù)據(jù)。

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

可以說“行為即標(biāo)簽”。用戶的行為數(shù)據(jù)、之前每次的交互行為等，都可以構(gòu)成豐富的業(yè)務(wù)標(biāo)簽。舉“知乎”這個(gè)社區(qū)為例，“關(guān)注了XX話題”“關(guān)注了XX用戶”“點(diǎn)贊了XX內(nèi)容”“分享XX文章”，這些行為本身就是非常豐富且有用的標(biāo)簽，組合起來亦然。基于用戶在產(chǎn)品內(nèi)的行為所構(gòu)建的標(biāo)簽體系，比之前說的第三方數(shù)據(jù)計(jì)算出標(biāo)簽意義更大。因?yàn)榛谛袨樵O(shè)定的標(biāo)簽，后續(xù)是能反作用于用戶的，我們可以為不同行為標(biāo)簽下的用戶群設(shè)定更精準(zhǔn)的運(yùn)營策略，例如內(nèi)容推薦、活動促銷、精準(zhǔn)推送等等。

最后，再從技術(shù)上來講講，主要使用的其實(shí)還是 lambda 架構(gòu)。

我們以 Kafka 為消息中心，利用多層生產(chǎn)者與消費(fèi)者的概念，對數(shù)據(jù)進(jìn)行運(yùn)用，例如實(shí)時(shí)計(jì)算、打標(biāo)簽、導(dǎo)入數(shù)據(jù)倉庫、備份等等。

數(shù)據(jù)存儲，也用了 SQL 和 NoSQL，但 SQL 也是用的列式存儲數(shù)據(jù)庫，NoSQL 諸如對 Elastic search 進(jìn)行索引，承載一些快速查詢的場景，關(guān)系型主要用于復(fù)雜計(jì)算，因?yàn)槲覀儾恢故怯脩簟⑹录蓚€(gè)主題，還有會話，所以復(fù)雜度很高，中間我們也用了一些小 trick ，以后有機(jī)會和大家分享一下。

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

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

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

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

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

何種算法對于用戶肖像描繪比較適合
這個(gè)問題不好回答哈，分享中提及到了影響力、標(biāo)簽算法，其實(shí)還是要根據(jù)業(yè)務(wù)應(yīng)用場景以及數(shù)據(jù)源來的，很靈活

對于多項(xiàng)數(shù)據(jù)分析，比如天氣的陰晴雨雪如何設(shè)定權(quán)值更合理
權(quán)值需要設(shè)定結(jié)果目標(biāo)，然后多做測試，相關(guān)性分析，調(diào)配參數(shù)

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

customer acquisition時(shí)代我們依賴第三方數(shù)據(jù)進(jìn)行匹配和用戶獲取，但是customer engagement時(shí)代，我們要做的是理解user behavior，提高轉(zhuǎn)化率，和企業(yè)效率

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

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