HBase使用場景和成功案例 (轉)

HBase 使用場景和成功案例

有時候瞭解軟件產品的最好方法是看看它是怎麼用的。它能夠解決什麼問題和這些解決方案如何適用於大型應用架構，可以告訴你不少。由於HBase有許多公開的產品部署，咱們正好能夠這麼作。本章節將詳細介紹一些人們成功使用HBase的使用場景。

注意：不要自我限制，認爲HBase只能解決這些使用場景。它是一個初生的技術，根據使用場景進行創新正驅動着系統的發展。若是你有新想法，認爲能夠受益於HBase提供的功能，試試吧。社區很樂於幫助你，也會從你的經驗中學習。這正是開源軟件精神。

HBase仿效了Google的BigTable，讓咱們開始探索典型的BigTable問題：存儲互聯網。

 

典型互聯網搜索問題：BigTable發明的緣由

搜索是一個定位你所關心的信息的行爲：例如，搜索一本書的頁碼，其中含有你想讀的主題，或者網頁，其中含有你想找的信息。搜索含有特定詞語的文檔，須要查找索引，該索引提供了特定詞語和包含該詞語的全部文檔的映射。爲了可以搜索，首先必須創建索引。Google和其餘搜索引擎正是這麼作的。他們的文檔庫是整個互聯網；搜索的特定詞語就是你在搜索框裏敲入的任何東西。

BigTable，和模仿出來的HBase，爲這種文檔庫提供存儲，BigTable提供行級訪問，因此爬蟲能夠插入和更新單個文檔。搜索索引能夠基於BigTable 經過MapReduce計算高效生成。若是結果是單個文檔，能夠直接從BigTable取出。支持各類訪問模式是影響 BigTable設計的關鍵因素。

 

創建互聯網索引

1 爬蟲持續不斷地抓取新頁面，這些頁面每頁一行地存儲到BigTable裏。

2 MapReduce計算做業運行在整張表上，生成索引，爲網絡搜索應用作準備。

搜索互聯網

3 用戶發起網絡搜索請求。

4 網絡搜索應用查詢創建好的索引，或者直接從BigTable直接獲得單個文檔。

5 搜索結果提交給用戶。

 

講完典型HBase使用場景之後，咱們來看看其餘使用HBase的地方。願意使用HBase的用戶數量在過去幾年裏迅猛增加。部分緣由在於HBase產品變得更加可靠和性能更好，更多緣由在於愈來愈多的公司開始投入大量資源來支持和使用它。隨着愈來愈多的商業服務供應商提供支持，用戶愈加自信地把HBase應用於關鍵應用系統。一個設計初衷是用來存儲互聯網持續更新網頁副本的技術，用在互聯網相關的其餘方面也非常合適的。例如，HBase在社交網絡公司內部和周圍各類各樣的需求中找到了用武之地。從存儲我的之間的通訊信息，到通訊信息分析，HBase成爲Facebook，Twitter，和StumbleUpon等公司裏的關鍵基礎架構。

在這個領域，HBase有三種主要使用場景，但不限於這些。爲了保持本節簡單明瞭，咱們這裏介紹主要的使用場景。

捕獲增量數據

數據一般是細水長流，累加到已有數據庫以備未來使用，例如分析，處理和服務。許多HBase使用場景屬於這個類別——使用HBase做爲數據存儲，捕獲來自於各類數據源的增量數據。例如，這種數據源多是網頁爬蟲（咱們討論過的BigTable典型問題），多是記錄用戶看了什麼廣告和多長時間的廣告效果數據，也多是記錄各類參數的時間序列數據。咱們討論幾個成功的使用場景和公司。

 

捕獲監控參數：OPENTSDB

服務於數百萬用戶的WEB產品的後臺基礎架構通常都有數百或數千臺服務器。這些服務器承擔了各類功能——服務流量，捕獲日誌，存儲數據，處理數據等等。爲了保持產品正常運行，監控服務器和上面運行軟件的健康狀態是相當重要的（從OS到用戶交互應用）。大規模監控整個環境須要可以採集和存儲來自於不一樣數據源的各類參數的監控系統。每一個公司有本身的辦法。一些公司使用商業工具來收集和展現參數；而其餘一些公司採用開源框架。

StumbleUpon 建立了一個開源框架，用來收集服務器的各類監控參數。按照時間收集參數通常稱之爲時間序列數據：也就是說，按照時間順序收集和記錄數據。StumbleUpon 的開源框架叫作OpenTSDB，其含義是開放時間序列數據庫 Open Time Series Database 。這個框架使用HBase做爲核心平臺來存儲和檢索所收集的參數。建立這個框架的目的是爲了擁有一個可擴展的監控數據收集系統，一方面可以存儲和檢索參數數據並保存很長時間，另外一方面若是須要增長功能也能夠添加各類新參數。StumbleUpon 使用OpenTSDB監控全部基礎架構和軟件，包括HBase機羣自身。咱們將在第7章做爲建構在HBase之上的示例應用來詳細介紹OpenTSDB。

 

捕獲用戶交互數據：Facebook和StumbleUpon

捕獲監控數據是一種使用方式。還有一種是捕獲用戶交互數據。如何跟蹤數百萬用戶在網站上的活動？怎麼知道哪個網站功能是最受歡迎的？怎樣使得這一次的網頁瀏覽直接影響到下一次？例如，誰看了什麼？某個按鈕被點擊了多少次？還記得Facebook和Stumble 裏的Like按鈕和StumbleUpon 裏的+1 按鈕嗎？是否是聽起來像是一個計數問題？每次用戶Like一個特定主題計數器增長一次。

StumbleUpon 在開始階段採用MySQL，可是隨着網站服務愈來愈流行，這個技術選擇遇到問題了。急劇增加的用戶在線負載需求遠遠超過了MySQL機羣的能力，最終StumbleUpon 選擇HBase來替換這些機羣。當時，HBase產品不能直接提供必須的功能。StumbleUpon 在HBase上作了一些小的開發改動，後來這些開發工做貢獻回了項目社區。

FaceBook使用HBase的計數器來計量人們Like特定網頁的次數。內容原創人和網頁主人能夠獲得近乎實時的、多少用戶Like他們網頁的數據信息。他們能夠所以更敏捷地判斷應該提供什麼內容。Facebook 爲此建立了一個叫Facebook Insight的系統，該系統須要一個可擴展的存儲系統。公司考慮了不少種可能，包括關係型數據庫、內存數據庫、和Cassandra數據庫，最後決定使用HBase。基於HBase，Facebook 能夠很方便地橫向擴展服務規模，提供給數百萬用戶，也能夠繼續使用他們已有的運行大規模HBase機羣的經驗。該系統天天處理數百億條事件，記錄數百個參數。

 

TELEMETRY：MOZILLA 和 TREND MICRO

軟件運行數據和軟件質量數據，不像監控參數數據那麼簡單。例如，軟件崩潰報告是有用的軟件運行數據，常常用來探究軟件質量和規劃軟件開發路線圖。HBase能夠成功地用來捕獲和存儲用戶計算機上生成的軟件崩潰報告。這種使用場景不像前兩種使用場景，和網絡服務應用不必定有關係。

 

Mozilla基金會負責FireFox網絡瀏覽器和Thunderbird電郵客戶端兩個產品。這些工具安裝在全世界數百萬臺計算機上，支持各類操做系統。當這些工具崩潰時，會以Bug報告的形式返回一個軟件崩潰報告給Mozilla。Mozilla如何收集這些數據？收集後又是怎麼使用呢？實際狀況是這樣的，一個叫作Socorro的系統收集了這些報告，用來指導研發部門研製更穩定的產品。Socorrade系統的數據存儲和分析建構在HBase上。 [1]

採用HBase使得基本分析能夠用到比之前多得多的數據。這種分析用來指導Mozilla的開發人員，使其更爲專一，研製出Bug最少的版本。

Trend Micro爲企業客戶提供互聯網安全和入侵管理服務。安全的重要環節是感知，日誌收集和分析對於提供這種感知能力是相當重要的。Trend Micro使用HBase來管理網絡信譽數據庫，該數據庫須要行級更新和支持MapReduce批處理。有點像Mozilla的Socorro系統，HBase也用來收集和分析日誌活動，天天收集數十億條記錄。HBase中靈活的模式支持數據結構出現變化，當分析流程從新調整時Trend Micro能夠增長新屬性。

 

廣告效果和點擊流

過去的十年，在線廣告成爲互聯網產品的一個主要收入來源。提供免費服務給用戶，在用戶使用服務的時侯投放廣告給目標用戶。這種精準投放須要針對用戶交互數據作詳細的捕獲和分析，以便於理解用戶的特徵。基於這種特徵，選擇並投放廣告。精細的用戶交互數據帶來更好的模型，進而致使更好的廣告投放效果和更多的收入。但這類數據有兩個特色：它以連續流的形式出現，它很容易按用戶劃分。理想狀況下，這種數據一旦產生就可以立刻使用，用戶特徵模型能夠沒有延遲地持續優化——也就是說，以在線方式使用。

 

在線 VS 離線系統

在線和離線的術語屢次出現。對於初學者來講，這些術語描述了軟件系統執行的條件。在線系統須要低延遲。某些狀況下，系統哪怕給出沒有答案的響應，也要比花了很長時間給出正確答案的響應好。你能夠把在線系統想象爲一個跳着腳的沒有耐心的用戶。離線系統不須要低延遲，用戶能夠等待答案，不期待立刻給出響應。當實現應用系統時在線或者離線的目標影響着許多技術決策。HBase是一個在線系統。和Hadoop MapReduce的緊密結合又賦予它離線訪問的能力。

 

HBase很是適合收集這種用戶交互數據，HBase已經成功地應用在這種場合，它能夠增量捕獲第一手點擊流和用戶交互數據，而後用不一樣處理方式（MapReduce是其中一種）來處理數據（清理、裝飾、使用數據）。在這種公司，你會發現不少HBase案例。

 

內容服務

傳統數據庫的一個最大使用場合是爲用戶提供內容服務。各類各樣的數據庫支撐着提供各類內容服務的應用系統。多年來這些應用在發展，所以他們所依賴的數據庫也在發展。用戶但願使用和交互的內容種類愈來愈多。此外，因爲互聯網迅猛的增加以及終端設備更加迅猛的增加，對這些應用的鏈接方式提出了更高的要求。各類各樣的終端設備帶來了一個挑戰：不一樣種類設備須要以不一樣格式使用一樣的內容。

一方面是用戶使用內容 User Consuming Content，對應另外一面是用戶生成內容 User GenerateContent。Tweete、Facebook帖子、Instagram 圖片和微博等都是這樣的例子。

他們相同的地方是使用和生成了許多內容。大量用戶經過應用系統來使用和生成內容，而這些應用系統須要Hbase做爲基礎。

集中的內容系統系統 CMS能夠存儲內容和提供服務。可是當用戶愈來愈多，生成內容愈來愈多的時候，就須要一個更具擴展性的CMS解決方案。

這種可擴展的CMS每每使用Hbase做爲基礎，再加上其餘的開源框架，例如Solr，構成一個完整的功能組合。

Salesforce提供託管CRM產品，這個產品經過網絡瀏覽器界面提交給用戶使用，顯示出了豐富的關係型數據庫功能。在Google發表NoSQL原型概念論文以前很長一段時間，生產環境中使用的大型關鍵數據庫最合理的選擇就是商用關係型數據庫。多年來，Salesforce經過數據庫分庫和尖端性能優化這些手段擴展系統，達到天天處理數億事務的能力。

當Salesforce看到分佈式數據庫這樣的選擇後，他們評測了全部NoSQL技術的產品，最後決定部署HBase。這個選擇的主要緣由是有來由的。BigTable類型的系統是惟一的能夠無縫融合水平擴展能力和行級強一致性的結構方式。此外，Salesforce已經把Hadoop用於大型離線批處理任務，他們能夠繼續利用Hadoop上面積累的寶貴經驗。

URL短鏈

最近一段時間URL短鏈很是流行，許多相似產品破土而出。StumbleUpon使用名字爲su.pr.的短鏈產品，這個產品以HBase爲基礎。這個產品用來縮短URL，存儲大量的短鏈以及和原始長連接的映射關係，HBase幫助產品實現擴展能力。

用戶模型服務

通過HBase處理過的內容每每並不直接提交給用戶使用，而是用來決定應該提交給用戶什麼內容。這種中間處理數據用來豐富用戶的交互。還記得前面提到的廣告服務場景裏的用戶模式嗎？用戶模式（或者說模型）就是來自於HBase。這種模型多種多樣，能夠用於多種不一樣場景，例如，針對特定用戶投放什麼廣告的決定，用戶在電商門戶購物時實時報價的決定，用戶在搜索引擎檢索時增長背景信息和關聯內容，等等。不少這種使用案例可能不便於公開討論，說多了咱們就麻煩了。

當用戶在電商網站上發生交易時，用戶模型服務能夠用來實時報價。這種模型須要基於不斷產生的新用戶數據持續優化。

信息交換

各類社交網絡破土而出，世界變得愈來愈小。社叫網站的一個重要做用就是幫助人們進行交互。有時交互在羣組內發生（小規模和大規模）；有時交互在兩個我的之見發生。想一想看，數億人經過社交網絡進行對話的場面。只是和遠處的人通話是不夠的，人們還想看看和其餘人通話的歷史記錄。社交網絡公司感到幸運的是，存儲很廉價，大數據領域的創新能夠幫助他們充分利用廉價的存儲。

Facebook短信系統常常被公開討論，他也可能極大地驅動了HBase的發展。當你使用Facebook時，某個時候你可能會收到或者發送短信給你的朋友。Facebook的這個特性徹底依賴於HBase。用戶讀寫的全部短信都存儲在HBase裏。支持Facebook短信的系統須要具有：高的寫吞吐量，極大的表，數據中心內的強一致性。除了短信系統以外，使用HBase的其餘應用系統另外要求：高的讀吞吐量，計數器吞吐量，自動分庫。工程師們發現HBase是個理想的解決方案，由於他支持全部這些要求，他擁有一個活躍的用戶社區，Facebook運營團隊在Hadoop部署上有豐富經驗，等等。在「Hadoop goes realtime at Facebook」這篇文章裏，Facebook工程師解釋了這個決定背後的邏輯和顯示了他們使用Hadoop和HBase建設在線系統的經驗。

Facebook工程師在HbaseCon 2012會議上分享了一些有趣的數據。在這個平臺上天天交換數十億條短信，天天帶來大約750億次操做。尖峯時刻，Facebook的HBase集羣每秒發生150萬次操做。從數據規模角度看，Facebook的集羣每個月增長250TB的新數據，這多是已知的最大的HBase部署，不管是服務器的數量仍是服務器所承載的用戶量。

上述一些示例，解釋了HBase如何解決一些有趣的老問題和新問題。你可能注意到一個相同點：HBase能夠用來對相同數據進行在線服務和離線處理。這正是HBase的獨到之處。

轉自 http://blog.sina.com.cn/s/blog_ae33b83901016azb.html