大資料HBase在阿里搜尋中的應用實踐
HBase作為淘寶全網索引構建以及線上機器學習平臺的核心儲存系統，是阿里搜尋基礎架構的重要組成部分。本文我們將介紹HBase在阿里搜尋的 歷史、規模，應用的場景 以及在實際應用當中遇到的 問題和優化 。
HBase在阿里搜尋的歷史、規模和服務能力
歷史： 阿里搜尋於2010年開始使用HBase，從最早到目前已經有十餘個版本。目前使用的版本是在社群版本的基礎上經過大量優化而成。社群版本建議不要使用1.1.2版本，有較嚴重的效能問題， 1.1.3以後的版本體驗會好很多。
叢集規模： 目前，僅在阿里搜尋節點數就超過3000個，最大叢集超過1500個。阿里集團節點數遠遠超過這個數量。
服務能力 ：去年雙十一，阿里搜尋離線叢集的吞吐峰值一秒鐘訪問超過4000萬次，單機一秒鐘吞吐峰值達到10萬次。還有在CPU使用量超過70%的情況下，單cpu core還可支撐 8000+ QPS。
HBase在阿里搜尋的角色和主要應用場景
很多初學者，對大資料的概念都是模糊不清的，大資料是什麼，能做什麼，學的時候，該按照什麼線路去學習，學完往哪方面發展，想深入瞭解，想學習的同學歡迎加入大資料學習qq群：458345782，有大量乾貨（零基礎以及進階的經典實戰）分享給大家，並且有清華大學畢業的資深大資料講師給大家免費授課，給大家分享目前國內最完整的大資料高階實戰實用學習流程體系.
角色：HBase是阿里搜尋的核心儲存系統，它和計算引擎緊密結合，主要服務搜尋和推薦的業務。
HBase在搜尋和推薦的應用流程
如上圖，是HBase在搜尋和推薦的應用流程。在索引構建流程中會從線上MySQL等資料庫中儲存的商品和使用者產生的所有線上資料通過流式的方式匯入到HBaes中，並提供給搜尋引擎構建索引。在推薦流程中，機器學習平臺Porshe會將模型和特徵資料儲存在HBase裡，並將使用者點選資料實時的存入HBase，通過線上training更新模型，提高線上推薦的準確度和效果。
應用場景一：索引構建。淘寶和天貓有各種各樣的的線上資料來源，這取決於淘寶有非常多不同的線上店鋪和各種使用者訪問。
索引構建應用場景
如上圖，在夜間我們會將資料從HBase批量匯出，供給搜尋引擎來構建全量索引。而在白天，線上商品、使用者資訊等都在不停的變化，這些動態的變化資料也會從線上儲存實時的更新到HBase並觸發增量索引構建，進而保證搜尋結果的實時性。
目前，可以做到端到端的延時控制在秒級，即庫存變化，產品上架等資訊在服務端更新後，迅速的可在使用者終端搜尋到。
索引構建應用場景抽象圖
如上圖，整個索引構建過程可以抽象成一個持續更新的流程。如把全量和增量看做是一個Join，線上有不同的資料來源且實時處於更新狀態，整個過程是長期持續的過程。這裡，就凸顯出HBase和流式計算引擎相結合的特點。
應用場景二：機器學習。這裡舉一個簡單的機器學習示例：使用者想買一款三千元的手機，於是在淘寶按照三千元的條件篩選下來，但是沒有中意的。之後 ，使用者會從頭搜尋，這時就會利用機器學習模型把三千塊錢左右的手機排在搜尋結果的靠前位置，也就是用前一個搜尋結果來影響後一個搜尋結果的排序。
分析線上日誌
如上圖，分析線上日誌，歸結為商品和使用者兩個緯度，匯入分散式、持久化訊息佇列，存放到HBase上。隨線上使用者的點選行為日誌來產生資料更新，對應模型隨之更新，進行機器學習訓練，這是一個反覆迭代的過程。
HBase在阿里搜尋應用中遇到的問題和優化
HBase架構分層。在說問題和優化之前，先來看HBase的架構圖，大致分為如下幾個部分：
HBase的架構圖
首先是API，一些應用程式程式設計介面。RPC，這裡把遠端過程呼叫協議分為客戶端會發起訪問與服務端來處理訪問兩部分。MTTR故障恢復、Replication資料複製、表處理等，這些都是分散式管理的範疇。中間Core是核心的資料處理流程部分，像寫入、查詢等，最底層是HDFS（分散式檔案系統）。HBase在阿里搜尋應用中遇到的問題和優化有很多，下面挑選近期比較重點的RPC的瓶頸和優化、非同步與吞吐、GC與毛刺、IO隔離與優化、IO利用這五方面進行展開。
問題與優化一：RPC的瓶頸和優化
RPC Server執行緒模型
PPC服務端的實際問題是原有RpcServer執行緒模型效率較低，如上圖，可以看到整個過程通常很快，但會由不同的執行緒來處理，效率非常低。基於Netty重寫之後，可以更高效的複用執行緒，實現HBase RpcServer。使得RPC平均響應時間從0.92ms下降到0.25ms，吞吐能力提高接近2倍。
問題與優化二：非同步與吞吐
RPC的客戶端存在的實際問題是流式計算對於實時性的要求很高、分散式系統無法避免秒級毛刺、同步模式對毛刺敏感，吞吐存在瓶頸。優化手段就是基於netty實現non-blocking client，基於protobuf的non-blocking Stub/RpcCallback實現callback回撥，當和flink整合後實測吞吐較同步模式提高2倍。
問題與優化三： GC與毛刺
如上圖，這部分的實際問題是PCIe-SSD的高IO吞吐能力下，讀cache的換入換出速率大幅提高、堆上的cache記憶體回收不及時，導致頻繁的CMS gc甚至fullGC。優化手段是實現讀路徑E2E的offheap，使得Full和CMS gc頻率降低200%以上、讀吞吐提高20%以上。
如上圖，是線上的一個結果，QPS之前是17.86M，優化之後是25.31M。
問題與優化四： IO隔離與優化
HBase本身對IO非常敏感，磁碟打滿會造成大量毛刺。在計算儲存混合部署環境下，MapReduce作業產生的shuffle資料和HBase自身Flush/Compaction這兩方面都是大IO來源。
如何規避這些影響呢？利用HDFS的Heterogeneous Storage功能，對WAL(write-ahead-log)和重要業務表的HFile使用ALL_SSD策略、普通業務表的HFile使用ONE_SSD策略，保證Bulkload支援指定storage policy。同時，確保MR臨時資料目錄(mapreduce.cluster.local.dir)只使用SATA盤。
HBase叢集IO隔離後的毛刺優化效果
對於HBase自身的IO帶來的影響，採用Compaction限流、Flush限流和Per-CF flush三大手段。上圖為線上效果，綠線從左到右分別是響應時間、處理時間和等待時間的p999資料，以響應時間為例，99.9%的請求不會超過250ms。
問題與優化五： IO利用
HDFS寫3份副本、通用機型有12塊HDD盤、SSD的IO能力遠超HDD。如上圖，實際問題是單WAL無法充分使用磁碟IO。
如上圖，為了充分利用IO，我們可以通過合理對映對region進行分組，來實現多WAL。基於Namespace的WAL分組，支援App間IO隔離。從上線效果來看，全HDD盤下寫吞吐提高20%，全SSD盤下寫吞吐提高40%。線上寫入平均響應延時從0.5ms下降到0.3ms。
開源&未來
為什麼要擁抱開源？其一，試想如果大家做了優化都不拿出來，認為這是自己強於別人的優勢，結果會怎樣？如果大家把自己的優勢都拿出來分享，得到的會是正向的反饋。其二， HBase的團隊一般都比較小，人員流失會產生很大的損失。如把內容貢獻給社群，程式碼的維護成本可以大大降低。開源一起做，比一個公司一個人做要好很多，所以我們要有貢獻精神。
未來，一方面，阿里搜尋會進一步把PPC服務端也做非同步，把HBase核心用在流式計算、為HBase提供嵌入式的模式。另一方面，嘗試更換HBase核心，用新的DB來替代，達到更高的效能。很多初學者，對大資料的概念都是模糊不清的，大資料是什麼，能做什麼，學的時候，該按照什麼線路去學習，學完往哪方面發展，想深入瞭解，想學習的同學歡迎加入大資料學習qq群：458345782，有大量乾貨（零基礎以及進階的經典實戰）分享給大家，並且有清華大學畢業的資深大資料講師給大家免費授課，給大家分享目前國內最完整的大資料高階實戰實用學習流程體系