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的獨到之處。