HBase 使用場景和成功案例
有時候瞭解軟體產品的最好方法是看看它是怎麼用的。它可以解決什麼問題和這些解決方案如何適用於大型應用架構，能夠告訴你很多。因為HBase有許多公開的產品部署，我們正好可以這麼做。本章節將詳細介紹一些人們成功使用HBase的使用場景。
注意：不要自我限制，認為HBase只能解決這些使用場景。它是一個初生的技術，根據使用場景進行創新正驅動著系統的發展。如果你有新想法，認為可以受益於HBase提供的功能，試試吧。社群很樂於幫助你，也會從你的經驗中學習。這正是開源軟體精神。
HBase仿效了Google的BigTable，讓我們開始探索典型的BigTable問題：儲存網際網路。
典型網際網路搜尋問題：
搜尋是一個定位你所關心的資訊的行為：例如，搜尋一本書的頁碼，其中含有你想讀的主題，或者網頁，其中含有你想找的資訊。搜尋含有特定詞語的文件，需要查詢索引，該索引提供了特定詞語和包含該詞語的所有文件的對映。為了能夠搜尋，首先必須建立索引。Google和其他搜尋引擎正是這麼做的。他們的文件庫是整個網際網路；搜尋的特定詞語就是你在搜尋框裡敲入的任何東西。
BigTable，和模仿出來的HBase，為這種文件庫提供儲存，BigTable提供行級訪問，所以爬蟲可以插入和更新單個文件。搜尋索引可以基於BigTable 通過MapReduce計算高效生成。如果結果是單個文件，可以直接從
建立網際網路索引
1 爬蟲持續不斷地抓取新頁面，這些頁面每頁一行地儲存到BigTable裡。
2 MapReduce計算作業執行在整張表上，生成索引，為網路搜尋應用做準備。
搜尋網際網路
3 使用者發起網路搜尋請求。
4 網路搜尋應用查詢建立好的索引，或者直接從BigTable直接得到單個文件。
5 搜尋結果提交給使用者。
講完典型HBase使用場景以後，我們來看看其他使用HBase的地方。願意使用HBase的使用者數量在過去幾年裡迅猛增長。部分原因在於HBase產品變得更加可靠和效能更好，更多原因在於越來越多的公司開始投入大量資源來支援和使用它。隨著越來越多的商業服務供應商提供支援，使用者越發自信地把
在這個領域，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的獨到之處。