HBase在阿里搜索中的應用實踐

李鈺，花名絕頂，WOTA全球架構與運維技術峯會分享嘉賓，現任阿里巴巴搜索事業部高級技術專家，HBase開源社區PMC &   committer。開源技術愛好者，主要關注分佈式系統設計、大數據基礎平臺建設等領域。連續3年基於HBase/HDFS設計和開發存儲系統應對雙十一訪問壓力，具有豐富的大規模集羣生產實戰經驗。

HBase做爲淘寶全網索引構建以及在線機器學習平臺的核心存儲系統，是阿里搜索基礎架構的重要組成部分。本文咱們將介紹HBase在阿里搜索的歷史、規模，應用的場景以及在實際應用當中遇到的問題和優化。

HBase在阿里搜索的歷史、規模和服務能力

歷史：阿里搜索於2010年開始使用HBase，從最先到目前已經有十餘個版本。目前使用的版本是在社區版本的基礎上通過大量優化而成。社區版本建議不要使用1.1.2版本，有較嚴重的性能問題， 1.1.3之後的版本體驗會好不少。

集羣規模：目前，僅在阿里搜索節點數就超過3000個，最大集羣超過1500個。阿里集團節點數遠遠超過這個數量。

服務能力：去年雙十一，阿里搜索離線集羣的吞吐峯值一秒鐘訪問超過4000萬次，單機一秒鐘吞吐峯值達到10萬次。還有在CPU使用量超過70%的狀況下，單cpu core還可支撐 8000+ QPS。

HBase在阿里搜索的角色和主要應用場景

角色：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來替代，達到更高的性能。

以上內容根據絕頂老師在WOTA2017 「大數據系統架構」專場的演講內容整理。