案例主要關注三個問題：數據從哪里來?數據如何存儲?數據如何計算?
1. Last.fm
1.1 背景
創建于2002年，提供網絡電臺和網絡音樂服務的社交網絡。每個月有2500萬人使用Last.fm，產生大量數據。現在有了中文版http://cn.last.fm/，界面很不錯!
2006年初，Last.fm開始使用Hadoop，幾個月后投入實際應用。Hadoop是Last.fm基礎平臺的關鍵組件，有2個Hadoop集群，50臺計算機，300個內核，100TB的硬盤空間。在集群上，運行數百種各種日常作業，包括日志文件分析，A/B測試評測，即時處理和圖表生成。
1.2 圖表生成
圖表生成是Hadoop在Last.fm的第一個應用。
1.3 數據從哪里來
Last.fm有兩種收聽信息：用戶播放自己的音樂，如pc或者其他設備mp3，這種信息通過Last.fm的客戶端或者第三方應用發送到Last.fm，這一類叫scrobble收藏數據;用戶收聽Last.fm網絡電臺的節目，以及聽節目時候的喜愛，跳過，禁止等操作信息，這一類叫radio listen電臺收聽數據。
1.4 數據存儲
收聽數據被發送到Last.fm，經歷驗證和轉換，形成一系列有空格分隔的文本文件，包含用戶id-userid，音樂id-trackid，這首音樂被收藏的次數scrobble，這首音樂在電臺中收聽的次數radio，被跳過的次數skip。真實數據達到GB級別，有更多屬性字段。
1.5 數據處理
1.5.1 Unique Listeners作業：統計收聽某一首歌的不同用戶數，也就說說，有多少個用戶聽過某個歌，如果用戶重復收聽，只算一次。
1.5.2 Sum作業：每首歌的收聽總數，收藏總數，電臺收聽總數，被跳過的總數。
1.5.3 合作作業：每首歌的被多少不同用戶收聽總數，收聽總數，收藏總數，電臺收聽總數，被跳過的總數。
1.5.4 這些數據會被作為周排行榜等在Last.fm主站上顯示出來。
2. Facebook
2.1 背景
Facebook社交網絡。
開始時，試用一個小Hadoop集群，很成功。同時開始開發Hive，Hive讓工程師能用SQL語言處理Hadoop集群的數據，畢竟很多人更熟悉SQL。后來，Facbook運行了世界第二大Hadoop集群，數據超多2PB，每天加入10TB數據，2400個內核，9TB內存，大部分時間硬件滿負荷運行。
2.2 使用情況
2.2.1 在大規模數據是以天和小時為單位產生概要信息。如用戶數，網頁瀏覽次數，網站訪問時間增常情況，廣告活動效果數據，計算用戶喜歡人和應用程序。
2.2.2 分析歷史數據，以設計和改進產品，以及管理。
2.2.3 文件存檔和日志查詢。
2.3 廣告分析
2.3.1 cpc-cost perclick點擊數計費，cpm-cost per mille每千人成本。
2.3.2 個性化廣告定制：根據個體用戶進行不同的內容剪輯。Yahoo!的SmartAds，Facebook的Social Ads，Engagement Ad廣告意見/嵌入視頻交互。Facebook每天處理1TB數量級廣告數據。
2.3.3 用Hive分析A/B測試的結果。
2.3.4 Hadoop和Hive分析人氣網站，生物信息公司，原油勘探公司，在線廣告。
3.Nutch搜索引擎
3.1 Nutch框架用戶建立可擴展的crawler網絡爬蟲和搜索引擎。
3.2 架構
3.2.1 crawlDb網頁數據庫：跟蹤網絡crawler抓取的網頁和它們的狀態。
3.2.2 fetchlist爬取網頁清單：crawler定期刷新web視圖信息，下載新的網頁。
3.2.3 page content原始網頁數據：從遠程網站下載，以原始的未世界的格式在本地存儲成字節數組。
3.2.4 解析的網頁數據：Nutch為html, pdf, open office, ms office, rss提供了解析器。
3.2.5 linkdb鏈接圖數據庫：page rank來的。
3.2.6 lucene全文檢索索引：倒排索引，基于搜集到的所有網頁元數據和抽取到的純文本內容建立。
3.3 使用情況
Nutch使用Hadoop作業處理數據。
4 Rackspace
4.1 背景
Rackspace hosting為企業提供管理系統。在數百臺服務器上為100萬用戶和幾千家公司提供郵件服務。
4.2 使用情況
日志分析。發送郵件需要使用多個postfix郵件代理服務器，大部分消息穿越多個Postfix服務器，但每個服務器只知道郵件的目的地，為了給消息建立完整的歷史信息，需要用Hadoop處理日志記錄。
4.3 使用方式
在數據中心, syslog-ng從source機器傳統日志數據到一組負載均衡的collector收集器機器。在收集器上，日志數據被匯集成一個單獨的數據流，用gzip格式進行輕量級壓縮。
當壓縮的日志流到達本地收集器，數據會被寫入Hadoop，這一步用簡單的python腳本寫入即可。
Hadoop集群有15個數據節點，每個節點使用普通cpu和3個500G硬盤。
4.4 計算
每個電子郵件有一個唯一標示符號queue-id。每個電子郵件有一個唯一的message-id，但惡意客戶端會重復發送消息，所以message-id會被偽造。
在Postfix日志，需要用queue-id查找message-id。
第一步，以queue-id為健，進行map，把日志log的每個分配給對應的queue-id，然后，執行reduce過程，根據日志消息數值判斷queue-id的發送過程是否完整。
第二步，根據message-id對第一步的結果進行分組，以queue-di和message-id同時為鍵，以它們對應的日志行作為值，在reuce階段，判斷針對某個message-id的所有queue-id是否合理，驗證消息是否離開系統。
5. Cascading
5.1 背景
Cascading是一個開源的Java庫，為MapReduce提供抽象層。用Java寫Hadoop的MapReduce是有難度的：cascading用簡單字段名和數據元組模型代替MapReduce的key-value;cascading引入了比Map和Reduce更抽象的層次，如Function, Fileter, Aggregator和Buffer。
5.2 使用情況
Cascading以字段名和元組的方式，把多個MapReduce的處理簡化成一個管道鏈接起來的形式處理數據。從例子來看非常簡潔，需要的代碼很少。
6. 用Pig和Wukong探索十億數據級別的網絡圖
6.1 圖=節點+連接節點的邊。
6.2 Infochimps項目，一個發現，共享，出售數據集的全球性網站。用簡單的腳本語言-不超過一頁，就可以處理TB級別的圖數據。
6.3 在Infochimps，有twitter，faceboobk的數據集;有wiki百科數據集;線蟲項目神經愿和突觸的聯系;高速公路地圖等等。
6.4 在網絡圖分析上可以做出很多很好玩的有趣東東。
京公網安備 11010502049343號