從Hadoop 說起 六個真實的大數據應用案例_數據分析師

案例主要關注三個問題：數據從哪里來？數據如何存儲？數據如何計算？

1. Last.fm

1.1 背景
創建于2002年，提供網絡電臺和網絡音樂服務的社交網絡。每個月有2500萬人使用Last.fm，產生大量數據?，F在有了中文版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作業處理數據。

36大數據知識圖譜：

關于Nutch：Nutch 是一個開源Java 實現的搜索引擎。它提供了我們運行自己的搜索引擎所需的全部工具。包括全文搜索和Web爬蟲。

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是否合理，驗證消息是否離開系統。

36大數據知識圖譜：

關于Rackspace：

Rackspace （NYSE：RAX）全球三大云計算中心之一，1998年成立，是一家全球領先的托管服務器及云計算提供商，公司總部位于美國，在英國，澳大利亞，瑞士，荷蘭及香港設有分部。在全球擁有10個以上數據中心，管理超過10萬臺服務器。Rackspace的托管服務產品包括專用服務器，電子郵件，SharePoint，云服務器，云存儲，云網站等。在服務架構上提供專用托管，公有云，私有云及混合云。

2010年，Rackspace與美國航空航天局（NASA）合作創始了開源云平臺OpenStack。2012年Rackspace宣布在自己的云平臺使用建立于OpenStack的技術，并開源自己的云平臺軟件Rackspace Cloud。

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 在網絡圖分析上可以做出很多很好玩的有趣東東。