【51CTO.com原創(chuàng)稿件】李鈺，花名絕頂，WOTA全球架構(gòu)與運(yùn)維技術(shù)峰會(huì)分享嘉賓，現(xiàn)任阿里巴巴搜索事業(yè)部高級(jí)技術(shù)專(zhuān)家，HBase開(kāi)源社區(qū)PMC & committer。開(kāi)源技術(shù)愛(ài)好者，主要關(guān)注分布式系統(tǒng)設(shè)計(jì)、大數(shù)據(jù)基礎(chǔ)平臺(tái)建設(shè)等領(lǐng)域。連續(xù)3年基于HBase/HDFS設(shè)計(jì)和開(kāi)發(fā)存儲(chǔ)系統(tǒng)應(yīng)對(duì)雙十一訪問(wèn)壓力，具備豐富的大規(guī)模集群生產(chǎn)實(shí)戰(zhàn)經(jīng)驗(yàn)。

HBase作為淘寶全網(wǎng)索引構(gòu)建以及在線機(jī)器學(xué)習(xí)平臺(tái)的核心存儲(chǔ)系統(tǒng)，是阿里搜索基礎(chǔ)架構(gòu)的重要組成部分。本文我們將介紹HBase在阿里搜索的歷史、規(guī)模，應(yīng)用的場(chǎng)景以及在實(shí)際應(yīng)用當(dāng)中遇到的問(wèn)題和優(yōu)化。

HBase在阿里搜索的歷史、規(guī)模和服務(wù)能力

歷史：阿里搜索于2010年開(kāi)始使用HBase，從最早到目前已經(jīng)有十余個(gè)版本。目前使用的版本是在社區(qū)版本的基礎(chǔ)上經(jīng)過(guò)大量?jī)?yōu)化而成。社區(qū)版本建議不要使用1.1.2版本，有較嚴(yán)重的性能問(wèn)題， 1.1.3以后的版本體驗(yàn)會(huì)好很多。

集群規(guī)模：目前，僅在阿里搜索節(jié)點(diǎn)數(shù)就超過(guò)3000個(gè)，***集群超過(guò)1500個(gè)。阿里集團(tuán)節(jié)點(diǎn)數(shù)遠(yuǎn)遠(yuǎn)超過(guò)這個(gè)數(shù)量。

服務(wù)能力：去年雙十一，阿里搜索離線集群的吞吐峰值一秒鐘訪問(wèn)超過(guò)4000萬(wàn)次，單機(jī)一秒鐘吞吐峰值達(dá)到10萬(wàn)次。還有在CPU使用量超過(guò)70%的情況下，單cpu core還可支撐 8000+ QPS。

HBase在阿里搜索的角色和主要應(yīng)用場(chǎng)景

角色：HBase是阿里搜索的核心存儲(chǔ)系統(tǒng)，它和計(jì)算引擎緊密結(jié)合，主要服務(wù)搜索和推薦的業(yè)務(wù)。

HBase在搜索和推薦的應(yīng)用流程

如上圖，是HBase在搜索和推薦的應(yīng)用流程。在索引構(gòu)建流程中會(huì)從線上MySQL等數(shù)據(jù)庫(kù)中存儲(chǔ)的商品和用戶(hù)產(chǎn)生的所有線上數(shù)據(jù)通過(guò)流式的方式導(dǎo)入到HBaes中，并提供給搜索引擎構(gòu)建索引。在推薦流程中，機(jī)器學(xué)習(xí)平臺(tái)Porshe會(huì)將模型和特征數(shù)據(jù)存儲(chǔ)在HBase里，并將用戶(hù)點(diǎn)擊數(shù)據(jù)實(shí)時(shí)的存入HBase，通過(guò)在線training更新模型，提高線上推薦的準(zhǔn)確度和效果。

應(yīng)用場(chǎng)景一：索引構(gòu)建。淘寶和天貓有各種各樣的的線上數(shù)據(jù)源，這取決于淘寶有非常多不同的線上店鋪和各種用戶(hù)訪問(wèn)。

索引構(gòu)建應(yīng)用場(chǎng)景

如上圖，在夜間我們會(huì)將數(shù)據(jù)從HBase批量導(dǎo)出，供給搜索引擎來(lái)構(gòu)建全量索引。而在白天，線上商品、用戶(hù)信息等都在不停的變化，這些動(dòng)態(tài)的變化數(shù)據(jù)也會(huì)從線上存儲(chǔ)實(shí)時(shí)的更新到HBase并觸發(fā)增量索引構(gòu)建，進(jìn)而保證搜索結(jié)果的實(shí)時(shí)性。

目前，可以做到端到端的延時(shí)控制在秒級(jí)，即庫(kù)存變化，產(chǎn)品上架等信息在服務(wù)端更新后，迅速的可在用戶(hù)終端搜索到。

索引構(gòu)建應(yīng)用場(chǎng)景抽象圖

如上圖，整個(gè)索引構(gòu)建過(guò)程可以抽象成一個(gè)持續(xù)更新的流程。如把全量和增量看做是一個(gè)Join，線上有不同的數(shù)據(jù)源且實(shí)時(shí)處于更新?tīng)顟B(tài)，整個(gè)過(guò)程是長(zhǎng)期持續(xù)的過(guò)程。這里，就凸顯出HBase和流式計(jì)算引擎相結(jié)合的特點(diǎn)。

應(yīng)用場(chǎng)景二：機(jī)器學(xué)習(xí)。這里舉一個(gè)簡(jiǎn)單的機(jī)器學(xué)習(xí)示例：用戶(hù)想買(mǎi)一款三千元的手機(jī)，于是在淘寶按照三千元的條件篩選下來(lái)，但是沒(méi)有中意的。之后 ，用戶(hù)會(huì)從頭搜索，這時(shí)就會(huì)利用機(jī)器學(xué)習(xí)模型把三千塊錢(qián)左右的手機(jī)排在搜索結(jié)果的靠前位置，也就是用前一個(gè)搜索結(jié)果來(lái)影響后一個(gè)搜索結(jié)果的排序。

分析線上日志

如上圖，分析線上日志，歸結(jié)為商品和用戶(hù)兩個(gè)緯度，導(dǎo)入分布式、持久化消息隊(duì)列，存放到HBase上。隨線上用戶(hù)的點(diǎn)擊行為日志來(lái)產(chǎn)生數(shù)據(jù)更新，對(duì)應(yīng)模型隨之更新，進(jìn)行機(jī)器學(xué)習(xí)訓(xùn)練，這是一個(gè)反復(fù)迭代的過(guò)程。

HBase在阿里搜索應(yīng)用中遇到的問(wèn)題和優(yōu)化

HBase架構(gòu)分層。在說(shuō)問(wèn)題和優(yōu)化之前，先來(lái)看HBase的架構(gòu)圖，大致分為如下幾個(gè)部分：

HBase的架構(gòu)圖

首先是API，一些應(yīng)用程序編程接口。RPC，這里把遠(yuǎn)程過(guò)程調(diào)用協(xié)議分為客戶(hù)端會(huì)發(fā)起訪問(wèn)與服務(wù)端來(lái)處理訪問(wèn)兩部分。MTTR故障恢復(fù)、Replication數(shù)據(jù)復(fù)制、表處理等，這些都是分布式管理的范疇。中間Core是核心的數(shù)據(jù)處理流程部分，像寫(xiě)入、查詢(xún)等，***層是HDFS（分布式文件系統(tǒng)）。HBase在阿里搜索應(yīng)用中遇到的問(wèn)題和優(yōu)化有很多，下面挑選近期比較重點(diǎn)的RPC的瓶頸和優(yōu)化、異步與吞吐、GC與毛刺、IO隔離與優(yōu)化、IO利用這五方面進(jìn)行展開(kāi)。

問(wèn)題與優(yōu)化一：RPC的瓶頸和優(yōu)化

RPC Server線程模型

PPC服務(wù)端的實(shí)際問(wèn)題是原有RpcServer線程模型效率較低，如上圖，可以看到整個(gè)過(guò)程通常很快，但會(huì)由不同的線程來(lái)處理，效率非常低。基于Netty重寫(xiě)之后，可以更高效的復(fù)用線程，實(shí)現(xiàn)HBase RpcServer。使得RPC平均響應(yīng)時(shí)間從0.92ms下降到0.25ms，吞吐能力提高接近2倍。

問(wèn)題與優(yōu)化二：異步與吞吐

RPC的客戶(hù)端存在的實(shí)際問(wèn)題是流式計(jì)算對(duì)于實(shí)時(shí)性的要求很高、分布式系統(tǒng)無(wú)法避免秒級(jí)毛刺、同步模式對(duì)毛刺敏感，吞吐存在瓶頸。優(yōu)化手段就是基于netty實(shí)現(xiàn)non-blocking client，基于protobuf的non-blocking Stub/RpcCallback實(shí)現(xiàn)callback回調(diào)，當(dāng)和flink集成后實(shí)測(cè)吞吐較同步模式提高2倍。

問(wèn)題與優(yōu)化三： GC與毛刺

如上圖，這部分的實(shí)際問(wèn)題是PCIe-SSD的高IO吞吐能力下，讀cache的換入換出速率大幅提高、堆上的cache內(nèi)存回收不及時(shí)，導(dǎo)致頻繁的CMS gc甚至fullGC。優(yōu)化手段是實(shí)現(xiàn)讀路徑E2E的offheap，使得Full和CMS gc頻率降低200%以上、讀吞吐提高20%以上。

如上圖，是線上的一個(gè)結(jié)果，QPS之前是17.86M，優(yōu)化之后是25.31M。

問(wèn)題與優(yōu)化四： IO隔離與優(yōu)化

HBase本身對(duì)IO非常敏感，磁盤(pán)打滿會(huì)造成大量毛刺。在計(jì)算存儲(chǔ)混合部署環(huán)境下，MapReduce作業(yè)產(chǎn)生的shuffle數(shù)據(jù)和HBase自身Flush/Compaction這兩方面都是大IO來(lái)源。

如何規(guī)避這些影響呢？利用HDFS的Heterogeneous Storage功能，對(duì)WAL(write-ahead-log)和重要業(yè)務(wù)表的HFile使用ALL_SSD策略、普通業(yè)務(wù)表的HFile使用ONE_SSD策略，保證Bulkload支持指定storage policy。同時(shí)，確保MR臨時(shí)數(shù)據(jù)目錄(mapreduce.cluster.local.dir)只使用SATA盤(pán)。

HBase集群IO隔離后的毛刺優(yōu)化效果

對(duì)于HBase自身的IO帶來(lái)的影響，采用Compaction限流、Flush限流和Per-CF flush三大手段。上圖為線上效果，綠線從左到右分別是響應(yīng)時(shí)間、處理時(shí)間和等待時(shí)間的p999數(shù)據(jù)，以響應(yīng)時(shí)間為例，99.9%的請(qǐng)求不會(huì)超過(guò)250ms。

問(wèn)題與優(yōu)化五： IO利用

HDFS寫(xiě)3份副本、通用機(jī)型有12塊HDD盤(pán)、SSD的IO能力遠(yuǎn)超HDD。如上圖，實(shí)際問(wèn)題是單WAL無(wú)法充分使用磁盤(pán)IO。

如上圖，為了充分利用IO，我們可以通過(guò)合理映射對(duì)region進(jìn)行分組，來(lái)實(shí)現(xiàn)多WAL。基于Namespace的WAL分組，支持App間IO隔離。從上線效果來(lái)看，全HDD盤(pán)下寫(xiě)吞吐提高20%，全SSD盤(pán)下寫(xiě)吞吐提高40%。線上寫(xiě)入平均響應(yīng)延時(shí)從0.5ms下降到0.3ms。

開(kāi)源&未來(lái)

為什么要擁抱開(kāi)源？其一，試想如果大家做了優(yōu)化都不拿出來(lái)，認(rèn)為這是自己強(qiáng)于別人的優(yōu)勢(shì)，結(jié)果會(huì)怎樣？如果大家把自己的優(yōu)勢(shì)都拿出來(lái)分享，得到的會(huì)是正向的反饋。其二， HBase的團(tuán)隊(duì)一般都比較小，人員流失會(huì)產(chǎn)生很大的損失。如把內(nèi)容貢獻(xiàn)給社區(qū)，代碼的維護(hù)成本可以大大降低。開(kāi)源一起做，比一個(gè)公司一個(gè)人做要好很多，所以我們要有貢獻(xiàn)精神。

未來(lái)，一方面，阿里搜索會(huì)進(jìn)一步把PPC服務(wù)端也做異步，把HBase內(nèi)核用在流式計(jì)算、為HBase提供嵌入式的模式。另一方面，嘗試更換HBase內(nèi)核，用新的DB來(lái)替代，達(dá)到更高的性能。

讓我們共同期待， 2017年8月4號(hào)于深圳舉行的HBaseCon Asia，現(xiàn)場(chǎng)見(jiàn)！！！

以上內(nèi)容根據(jù)絕頂老師在WOTA2017 “大數(shù)據(jù)系統(tǒng)架構(gòu)”專(zhuān)場(chǎng)的演講內(nèi)容整理。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文作者和出處為51CTO.com】