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

HBase 機器學習 HDFS 固態硬盤 51CTO傳媒 2017-06-03

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

作者介紹

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

注:本篇內容根據絕頂老師在 WOTA2017 “大數據系統架構”專場的演講內容整理。

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

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

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

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

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

角色:HBase 是阿里搜索的核心存儲系統,它和計算引擎緊密結合,主要服務搜索和推薦的業務。

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

上圖是 HBase 在搜索和推薦的應用流程。在索引構建流程中,會從線上 MySQL 等數據庫中存儲的商品和用戶產生的所有線上數據,通過流式的方式導入到 HBase 中,並提供給搜索引擎構建索引。

在推薦流程中,機器學習平臺 Porshe 會將模型和特徵數據存儲在 HBase 裡,並將用戶點擊數據實時的存入 HBase,通過在線 training 更新模型,提高線上推薦的準確度和效果。

應用場景一:索引構建

淘寶和天貓有各種各樣的的線上數據源,這取決於淘寶有非常多不同的線上店鋪和各種用戶訪問。

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

如圖所示。在夜間,我們會將數據從 HBase 批量導出,供給搜索引擎來構建全量索引。而在白天,線上商品、用戶信息等都在不停的變化,這些動態的變化數據也會從線上存儲實時的更新到HBase並觸發增量索引構建,進而保證搜索結果的實時性。

目前,可以做到端到端的延時控制在秒級,即庫存變化,產品上架等信息在服務端更新後,迅速的可在用戶終端搜索到。

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

索引構建應用場景抽象圖

整個索引構建過程可以抽象成一個持續更新的流程。如把全量和增量看做是一個 Join,線上有不同的數據源且實時處於更新狀態,整個過程是長期持續的過程。這裡,就凸顯出 HBase 和流式計算引擎相結合的特點。

應用場景二:機器學習

這裡舉一個簡單的機器學習示例:用戶想買一款三千元的手機,於是在淘寶按照三千元的條件篩選下來,但是沒有中意的。之後 ,用戶會從頭搜索,這時就會利用機器學習模型把三千塊錢左右的手機排在搜索結果的靠前位置,也就是用前一個搜索結果來影響後一個搜索結果的排序。

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

分析線上日誌

如上圖,分析線上日誌。歸結為商品和用戶兩個緯度,導入分佈式、持久化消息隊列,存放到 HBase 上。隨線上用戶的點擊行為日誌來產生數據更新,對應模型隨之更新,進行機器學習訓練,這是一個反覆迭代的過程。

HBase 在阿里搜索應用中遇到的問題和優化

HBase 架構分層

在說問題和優化之前,先來看 HBase 的架構圖,大致分為如下幾個部分:

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

HBase 的架構圖

首先是 API,一些應用程序編程接口。RPC,這裡把遠程過程調用協議分為客戶端會發起訪問與服務端來處理訪問兩部分。MTTR 故障恢復、Replication 數據複製、表處理等,這些都是分佈式管理的範疇。中間 Core 是核心的數據處理流程部分,像寫入、查詢等,最底層是 HDFS(分佈式文件系統)。

HBase 在阿里搜索應用中遇到的問題和優化有很多,下面挑選近期比較重點的五方面進行展開。

  • RPC 的瓶頸和優化

  • 異步與吞吐

  • GC 與毛刺

  • IO 隔離與優化

  • IO 利用

問題與優化一:RPC 的瓶頸和優化

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

實際問題:

  • 原有 RpcServer 的線程模型效率較低

優化手段:

  • Netty 可以更高效的複用線程

  • 基於 Netty 實現 HBase RpcServer

線上效果:

  • Rpc 平均響應時間從 0.92ms 下降到 0.25ms

  • Rpc 吞吐能力提高接近 2 倍

問題與優化二:異步與吞吐

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

實際問題:

  • 流式計算對於實時性的要求很高

  • 分佈式系統無法避免秒級毛刺

  • 同步模式對毛刺敏感,吞吐存在瓶頸

優化手段:

  • 基於 ne_y 實現 non-blocking client

  • 基於 protobuf 的 non-blockingStub/RpcCallback 實現 callback 回調

線上效果:

  • 和 flink 集成後實測吞吐較同步模式提高 2 倍

問題與優化三:GC與毛刺

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

實際問題:

PCIe-SSD 的高 IO 吞吐能力下,讀 cache 的換入換出速率大幅提高

堆上的 cache 內存回收不及時,導致頻繁的 CMS gc 甚至 fullGC

優化手段:

實現讀路徑 E2E 的 odeap

線上效果:

Full 和 CMS gc 頻率降低 200% 以上

讀吞吐提高 20% 以上

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

如上圖,是線上的一個結果,QPS 之前是 17.86 M,優化之後是 25.31 M。

問題與優化四: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 在阿里搜索中的應用實踐

HBase 集群 IO 隔離後的毛刺優化效果

對於 HBase 自身的 IO 帶來的影響,採用 Compaction 限流、Flush 限流和 Per-CF flush 三大手段。上圖為線上效果,綠線從左到右分別是響應時間、處理時間和等待時間的 p999 數據,以響應時間為例,99.9% 的請求不會超過 250ms。

問題與優化五:IO 利用

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

單 WAL 無法充分使用磁盤 IO

HDFS 寫 3 份副本、通用機型有 12 塊 HDD 盤、SSD 的 IO 能力遠超 HDD。如上圖,實際問題是單 WAL 無法充分使用磁盤 IO。

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

合理映射對 region 進行分組

如上圖,為了充分利用 IO,我們可以通過合理映射對 region 進行分組,來實現多 WAL。基於 Namespace的WAL 分組,支持 App 間 IO 隔離。從上線效果來看,全 HDD 盤下寫吞吐提高 20%,全 SSD 盤下寫吞吐提高 40%。線上寫入平均響應延時從 0.5ms 下降到 0.3ms。

開源&未來

為什麼要擁抱開源?其一,試想如果大家做了優化都不拿出來,認為這是自己強於別人的優勢,結果會怎樣?如果大家把自己的優勢都拿出來分享,得到的會是正向的反饋。其二, HBase 的團隊一般都比較小,人員流失會產生很大的損失。如把內容貢獻給社區,代碼的維護成本可以大大降低。開源一起做,比一個公司一個人做要好很多,所以我們要有貢獻精神。

未來,一方面,阿里搜索會進一步把 PPC 服務端也做異步,把 HBase 內核用在流式計算、為 HBase 提供嵌入式的模式。另一方面,嘗試更換 HBase 內核,用新的 DB 來替代,達到更高的性能。

相關推薦

推薦中...