矽谷觀察之大資料篇【下】：矽谷巨頭們的大資料玩法

在矽谷觀察之大資料篇的【上】篇中(HTTP://www.china-cloud.com/yunjishu/shujuzhongxin/20141208_44107.html?1418016591)， 我把矽谷地區大資料生長狀況基本梳理了一個相對完整的形狀出來。 有朋友看了【下】的預告後在微博上給我留言說，聽說下篇要介紹一些公司的大資料部門情況，問能不能點名加個 Google 尤其是 Google Maps， 因為特別想知道這個世界上最大的搜尋引擎以及每天必不可少的出行神器是怎麼當一個挖掘機的。

於是，上周我又去了 Google 採訪。 本篇將一共呈現矽谷四大不同類型的公司如何玩轉大資料，其中包括了著名 FLAG 中的三家（Apple 在大資料這塊來說表現並不突出）。

本篇內容來自對 Evernote AI 負責人 Zeesha Currimbhoy、LinkedIn 大資料部門資深總監 Simon Zhang、前 Facebook 基礎架構工程師 Ashish Thusoo 和 Google 大資料部門一線 工程師及 Google Maps 相關負責人的專訪。 Enjoy~~

Evernote：今年新建AI部門劍指深度學習

Evernote 的全球大會上，CEO Phil Libin 提到，Evernote 的一個重要方向就是「讓 Evernote 變成一個強大的大腦」。 要實現這個目標，就不得不提他們剛剛整合改組的 Augmented Intelligence 團隊（以下簡稱 AI team）。 我在斯坦福約到 AI team 的 manager Zeesha Currimbhoy，在此分析一下從她那裡得到的一手資料。

是什麼

今年早些時候，這個 2 歲的資料處理團隊改組為由 Zeesha 帶領的 Augmented Intelligence team，總共十人不到，很低調，平日幾乎聽不到聲響。 他們究竟在做什麼？

與我們常說的 AI（artificial Intelligence）不同，Evernote 的團隊名叫做 Augmented Intelligence，通常情況下簡稱為 IA。

Zeesha 顯然是這個團隊裡元老級的人物：「我是在 2012 年加入 Evernote 的，直接加入到了當時剛剛建立的資料處理團隊，這也就是現在 AI team 的雛形。 我們最開始的專案都是簡單易行的小專案，比如按照你的個人打字方式來優化使用者的輸入體驗。 」

傳統意義上的 AI 指的是通過大量資料和演算法讓機器學會分析並作出決定。 而這裡講到 IA 則是讓電腦進行一定量的運算，而終極目的是以之武裝人腦，讓人來更好的做決定。 這兩個概念在具體實施中自然有不少相通之處，但是其出發點卻是完全不同的。

這個區別也是 Evernote AI team 的亮點所在。 作為一個筆記紀錄工具，Evernote 與 Google 之類的搜尋引擎相比，最大的區別就是它非常的個人化。 使用者所儲存的筆記、網站連結、照片、視頻等都是他思維方式和關注點的體現。

從哪來

Zeesha 小組的初衷便是，通過分析使用者儲存的筆記來學習其思維方式，然後以相同的模式從協力廠商資料庫（也就是互聯網上的各種開源資訊）抽取資訊推送給使用者，從而達到説明使用者思考的過程。 從這個意義上講，Zeesha 版的未來 Evernote 更像是一個大腦的超級外掛，為人腦提供各種強大的可理解的資料支援。

目前整個團隊的切入點是很小而專注的。

「我們不僅僅是説明使用者做搜索，更重要的是在正確的時間給使用者推送正確的資訊。 」

實現這個目標的第一步就是給使用者自己的筆記分類，找到關聯點。 今年早些時候，Evernote 已經在 Mac 的英文版上實行了一項叫做「Descriptive Search」的功能。 使用者可以直接描述想要搜索的條目，Evernote 就會自動返回所有相關資訊。

例如，使用者可以直接搜索「2012 後在布拉格的所有圖片」，或者「所有素食功能表」。 不管使用者的筆記是怎樣分類的，Decriptive Search 都可以搜索到相關的資訊並且避免返回過大範圍的資料。 而這還僅僅是 AI team 長期目標的開始，這個團隊將在此基礎上開發一系列智慧化的產品。

到哪去

不用說，這樣一個新創團隊自然也面臨這諸多方面的挑戰。 當下一個比較重要的技術難點就是 Evernote 使用者的資料量。 雖然 Evernote 的使用者量已經達到了一億，但是由於整個團隊的關注點在個人化分析，外加隱私保護等諸多原因，AI team 並沒有做跨使用者的資料分析。

這樣做的結果就是團隊需要分析一億組各不相同的小資料組。 比如，假設我只在 Evernote 上面存了 10 個筆記，那 Evernote 也應該能夠通過這些少量的資料來分析出有效結果。 當然，這些技術的直接結果是使用者用 Evernote 越多，得到的個人化使用者體驗就越好。 長期來講，也是一個可以增加使用者黏性的特點。

不過 Zeesha 也坦言：「的確，我們都知道沒有大資料就沒有所謂的智慧分析。 但是我們現在所做的正是在這樣的前提下來找到新的合適的演算法。 」她並沒有深入去講目前團隊所用的是什麼思路，但是考慮到這個領域一時還沒有很成功的先例，我們有理由期待在 Zeesha 帶領下的 Evernote AI team 在近期做出一些有意思的成果。

Facebook：大資料主要用於外部廣告精准投放和內部交流

Facebook 有一個超過 30 人的團隊花了近 4 年的時間才建立了 Facebook 的資料處理平臺。 如今，Facebook 仍需要超過 100 名工程師來支援這個平臺的日常運行。 可想而知，光是大資料分析的基礎設施就已經是一個耗時耗力的專案了。

Facebook 的一大價值就在於其超過 13.5 億活躍使用者每天發佈的資料。 而其大資料部門經過七八年的摸索，才在 2013 年把部門的 key foundation 定位成廣告的精准投放，開始建了一整套自己的資料處理系統和團隊。 並進行了一系列配套的收購活動，比如買下世界第二大廣告平臺 Atlas。

據前 Facebook Data Infrastructure Manager Ashish Thusoo 介紹，Facebook 的資料處理平臺是一個 self-service, self-managing 的平臺，管理著超過 1 Exaby te 的資料。 公司內部的各個部門可以直接看到處理過的即時資料，並根據需求進一步分析。

目前公司超過 30% 的團隊，包括工程師、Product Managers、Business Analysts 等多個職位人群每個月都一定會使用這項服務。 這個資料處理平臺的建立讓各個不同部門之間可以通過資料容易地交流，明顯改變了公司的運行方式。

追溯歷史，Facebook 最早有大資料的雛形是在 2005 年，當時是小紮克親自做的。 方法很簡單：用 Memcache 和 MySQL 進行資料存儲和管理。

很快 bug 就顯現了，使用者量帶來資料的急速增大，使用 Memcache 和 MySQL 對 Facebook 的快速開發生命週期（改變 - 修復 - 發佈）帶來了阻礙，系統同步不一致的情況經常發生。 基於這個問題的解決方案是每秒 100 萬讀操作和幾百萬寫操作的 TAO(「The Associations and Objects」) 分散式資料庫，主要解決特定資源過量訪問時伺服器掛掉的 bug。

小紮克在 2013 年第一季度戰略時提到的最重點就是公司的大資料方向，還特別提出不對盈利做過多需求，而是要求基於大資料來做好以下三個功能：

發佈新的廣告產品。 比如類似好友，管理特定好友和可以提升廣告商精確投放的功能。

除與Datalogix, Epsilon,Acxiom和BlueKai合作外，以加強廣告商定向投放廣告的能力。

通過收購Atlas Advertising Suite，加強廣告商判斷數位媒體廣告投資回報率（ROI）。

LinkedIn：大資料如何直接支援銷售和變現賺錢

LinkedIn 大資料部門的一個重要功用是分析挖掘網站上巨大的使用者和雇主資訊，並直接用來支援銷售並變現。 其最核心團隊商業分析團隊的總監 Simon Zhang 說，現在國內大家都在討論雲，討論雲計算，討論大資料，討論大資料平臺，但很少有人講：我如何用資料產生更多價值，通俗點講，直接賺到錢。

但這個問題很重要，因為關係到直接收入。 四年半前 LinkedIn 內所有使用者的簡歷裡抽取出來大概有 300 萬公司資訊，作為銷售人員不可能給每個公司都打電話，所以問題來了：哪家公司應該打？ 打了後會是個有用的 call？

銷售們去問 Simon，他說只有通過資料分析。 而這個問題的答案在沒有大資料部門之前這些決策都是拍腦袋想像的。

Simon 和當時部門僅有的另外三個同事寫出了一個模型後發現：真正買 LinkedIn 服務的人，在決定的那個環節上，其實是一線的產品經理，和用 LinkedIn 在上面獵聘的那些人。 但他們做決策後是上面的老闆簽字，這是一個迷惑項。 資料分析結果出來後，他們銷售人員改變投放策略，把目標群體放在這些中層的管理人身上，銷售轉化率瞬間增加了三倍。

那時 LinkedIn 才 500 個人，Simon 一個人支援 200 名銷售人員。 他當時預測谷歌要花 10 個 Million 美金在獵聘這一塊上，銷售人員說，Simon，這是不可能的事。

「但是資料就是這麼顯示的，只有可能多不會少。 我意識到，一定要流程化這個步驟。 」

今天 LinkedIn 的「獵頭」這塊業務佔據了總收入的 60%。 是怎麼在四年裡發展起來的，他透露當時建造這個模型有以下這麼幾個步驟：

分析每個公司它有多少員工。

分析這個公司它招了多少人。

分析人的位置功能職位級別一切參數，這些都是我們模型裡面的各種功能。 然後去分析，他們內部有多少HR 員工，有多少負責獵頭的人，他們獵頭的流失率，他們每天在Linkedin的啟用時間是多少。

這是 LinkedIn 大資料部門最早做的事情。

Simon 告訴36氪，公司內部從大資料分析這一個基本項上，可以不斷反覆運算出新產品線 LinkedIn 的三大商業模型是人才解決方案、市場行銷解決方案和付費訂閱，也是我們傳統的三大收入支柱。 事實上我們還有一個，也就是第四個商業模型，叫「銷售解決方案」，已經在今年 7 月底上線。

這是賣給企業級使用者的。 回到剛才銷售例子，LinkedIn 大資料系統是一個牛逼的模型，只需要改動裡面一下關鍵字，或者一個參數，就可以變成另一個產品。 「我們希望能幫到企業級使用者，讓他們在最快的速度裡知道誰會想買你的東西。 」

雖然這第四個商業模式目前看來對收入的貢獻還不多，只占 1%，但 anyway 有著無限的想像空間，公司內部對這個產品期待很高。 「我還不能告訴你它的增長率，但這方向代表的是趨勢，Linkedin 的 B2B 是一個不用懷疑的大的趨勢。 」Simon 說。

Google：一個閉環的大資料生態圈

作為世界上最大的搜尋引擎，Google 和大資料的關係又是怎樣的呢？ 感謝微博上留言的朋友，這可確實是一個很有意思的議題。

Google 在大資料方面的基礎產品最早是 2003 年發佈的第一個大規模商用分散式檔案系統 GFS（Google File System），主要由 MapReduce 和 Big Table 這兩部分組成。 前者是用於大資料平行計算的軟體架構，後者則被認為是現代 NOSQL 資料庫的鼻祖。

GFS 為大資料的計算實現提供了可能，現在湧現出的各種檔案系統和 NOSQL 資料庫不可否認的都受到 Google 這些早期專案的影響。

隨後 2004 和 2006 年分別發佈的 Map Reduce 和 BigTable，奠定了 Google 三大大資料產品基石。 這三個產品的發佈都是創始人謝爾蓋 - 布林和拉裡 - 佩奇主導的，這兩人都是斯坦福大學的博士，科研的力量滲透到工業界，總是一件很美妙的事。

2011 年，Google 推出了基於 Google 基礎架構為客戶提供大資料的查詢服務和存儲服務的 BigQuery，有點類似于 Amazon 的 AWS，雖然目前從市場佔有率上看與 AWS 還不在一個數量級，但價格體系更有優勢。 Google 通過這個迎上了互聯網公司拼服務的風潮，讓多家協力廠商服務中集成了 BigQuery 視覺化查詢工具。 搶佔了大資料存儲和分析的市場。

BigQuery 和 GAE（Google App Engine）等 Google 自有業務伺服器構建了一個大資料生態圈，程式創建，資料收集，資料處理和資料分析等形成了閉環。

再來看 Google 的產品線，搜索，廣告，地圖，圖像，音樂，視頻這些，都是要靠大資料來支撐，根據不同種類資料建立模型進行優化來提升使用者體驗提升市場佔有率的。

單獨說一下 Google maps，這個全球在移動地圖市場擁有超過 40% 的市場佔有率的產品，也是美國這邊的出行神器。 它幾乎標示了全球有互聯網覆蓋的每個角落，對建築物的 3D 視覺處理也早在去年就完成，這個資料處理的工作量可能是目前最大的了，但這也僅限於資料集中的層面。 真正的資料分析和挖掘體現在：輸入一個地點時，最近被最多使用者採用的路徑會被最先推薦給使用者。

Google 還把 Google+，Panoramio 和其他 Google 雲平臺的圖片進行了標記和處理，將圖片內容和地理位置資訊地結合在一起，圖像識別和社交系統評分處理後，Google 能夠把品質比較高的的圖片推送給使用者， 優化了使用者看地圖時的視覺感受。

大資料為 Google 帶來了豐厚的利潤，比如在美國你一旦上網就能感覺到時無處不在的 Google 廣告（AdSense）。 當然，它是一把雙刃劍，給站長們帶來收入的同時，但如何平衡使用者隱私的問題，是大資料處理需要克服的又一個技術難關，或許還需要互聯網秩序的進一步完善去支援。

像在【上】中所說，除 Facebook 等幾個很領先的公司外，大部分公司要麼還沒有能力自行處理資料的能力。 最後附上兩個例子，想說這邊的大公司沒有獨立大資料部門也是正常的，採取外包合作是普遍現象：

Pinterest：

Pinterest 曾嘗試自行通過 Amazon EMR 建立資料處理平臺，但是因為其穩定性無法控制和資料量增長過快的原因，最終決定改為使用 Qubole 提供的服務。 在 Qubole 這個協力廠商平臺上，Pinterest 有能力處理其 0.7 億使用者每天所產生的海量資料，並且能夠完成包括 ETL、搜索、ad

hoc query 等不同種類的資料處理方式。 儘管 Pinterest 也是一個技術性公司，也有足夠優秀的工程師來建立資料處理團隊，他們依然選擇了 Qubole 這樣的專業團隊來完成資料處理服務。

Nike:

不僅僅矽谷的互聯網公司，眾多傳統企業也逐漸開始使用大資料相關技術。 一個典型的例子就是 Nike。 Nike 從 2012 年起與 API 服務公司 Apigee 合作，一方面，他們通過 Apigee 的 API 完善公司內部的資料管理系統，讓各個部門的資料進行整合，使得公司內部運行更加順暢、有效率。 另一方面，他們也通過 API 開發 Nike Fuel Band 相關的移動產品。 更是在 2014 年開啟了 Nike+

FuelLab 專案，開放了相關 API，使得眾多的開放者可以利用 Nike 所收集的大量資料開發資料分析產品，成功地連接了 Nike 傳統的零售業務，新的科技開發，和大資料價值。

(責任編輯：mengyishan)