使用ElasticSearch賦能HBase二級索引 | 實踐一年後總結

前言：還記得那是2018年的一個夏天，天氣特別熱，我一邊擦汗一邊聽領導大刀闊斧的講述本身將來的改革藍圖。會議開完了，核心思想就是：咱們要搞一個數據大池子，要把公司能灌的數據都灌入這個大池子，而後讓別人用 各類姿式 來撈這些數據。系統從開始打造到上線差很少花了半年多不到一年的時間，線上穩定運行也有一年多的時間。今天想簡單作個總結。

一。背景介紹

公司成立差很少十五六年了，老公司了。也正是由於資格老，業務迭代太多了，各個業務線錯綜複雜，接口調用也密密麻麻。有時候A向B要數據，有時候B向C要接口，有時候C向A要服務；各個業務線各有各的財產，各自爲營，像一個個小諸侯擁兵自重，跑腿費會議費都貴的很。面對這個現狀，咱們急需進行一波大改造了。

而這個系統（咱們暫且叫它天池吧），正是爲了整合公司各個業務線的資源，改造這個錯綜複雜的蜘蛛網爲簡單的直線班車。省去沒必要要的接口調用、業務穿插、會議溝通以及不知去哪裏拿數據、拿不到數據、拿數據慢的困擾。固然，更節省了產品、開發人員的時間，提高了各業務線總體工做效率。

幾個詞形容一下天池：穩、快、大、省、清晰。

二。業務梳理

通過對公司各線業務進行梳理，總結出如下幾大常見的數據輸出模型：

• Key-Value快速輸出型，最簡單的kv查詢，併發量可能很高，速度要求快。好比風控。

• Key-Map快速輸出型，定向輸出，好比常見的經過文章id獲取文章詳情數據，kv查詢升級版。

• MultiKey-Map批量輸出型，好比常見的推薦Feed流展現，Key-Map查詢升級版。

• C-List多維查詢輸出型，指定多個條件進行數據過濾，條件可能很靈活，分頁輸出知足條件的數據。這應該是很是常見的，好比篩選指定標籤或打分的商品進行推薦、獲取指定用戶過去某段時間買過的商品等等。

• G-Top統計排行輸出型，根據某些維度分組，展現排行。如獲取某論壇熱度最高Top10帖子。

• G-Count統計分析輸出型，數倉統計分析型需求。

• Multi-Table混合輸出型，且不一樣表查詢條件不一樣，如列表頁混排輸出內容。

• Term分詞輸出型

或許還有更多數據模型，這裏就再也不列舉了。從前端到後臺，不管再多數據模型，其實均可以轉化爲索引+KV的形式進行輸出，甚至有時候，我以爲索引+KV>SQL。

基於此業務數據模型分析及公司對ElasticSearch的長期使用，咱們最終選擇了HBase + ElasticSearch這樣的技術方案來實現。

三。架構設計與模塊介紹

先看一下總體架構圖，以下圖：

整個天池系統核心主要分爲數據接入層、策略輸出層、元數據管理、索引創建、平臺監控以及離線數據分析六大子模塊，下面將分別對其進行介紹。

1. 數據接入模塊介紹

數據接入模塊咱們主要對HBase-Client API進行了二次輕封裝，支持在線RESTFUL服務接口和離線SDK包兩種主要方式對外提供服務，同時兼容HBase原生API和HBase BulkLoad大批量數據寫入。

其中，在線RESTFUL服務以HBase Connection長鏈接的方式對外提供服務，好處是：在性能影響不大的狀況下方便跨語言操做，更主要的一點是便於管理。在這一層，能夠作不少工做，好比權限管理、負載均衡、失敗恢復、動態擴縮容、數據接口監控等等，固然這一切都要感謝K8S的強大能力。

2. 策略輸出模塊介紹

該模塊主要就是對接咱們上文業務梳理模塊概括的各類業務需求，都由此模塊提供服務。顧名思義，策略模塊主要用於爲用戶配置策略，或用戶本身配置策略，最終基於策略生成策略ID。

這一層咱們主要是對ElasticSearch和HBase的一些封裝，經過動態模板將用戶請求轉化爲ElasticSearch DSL語句，然後對ES進行查詢，直接返回數據或是獲取到rowkey進而查詢HBase進行結果返回。

經過元數據管理中心，咱們能夠判斷出用戶所需字段是否被索引字段覆蓋，是否有必要二次查詢HBase返回結果。而這整個查詢過程，用戶並不會感知，他們只須要一個PolicyID便可。

固然，咱們也在不斷普及用戶如何經過後臺本身配置生成策略。合做較多的業務方，甚至能夠本身在測試環境配置好一切，完成數據的自助獲取工做。而咱們須要作的，只是一鍵同步測試環境的策略到線上環境，並通知他們線上已可用。整個過程5~10分鐘，一個新的接口就誕生了。

其次，因爲ES抗壓能力畢竟不如HBase猛，咱們的策略接口也會根據業務需求決定是否開啓緩存。事實上，大部分接口是能夠接受短期內數據緩存的。固然像簡單KV、K-Map、Mk-Map這種是直接走HBase的，需求量也挺大。

到目前爲止，上述業務輸出模型基本都已支持動態策略配置。這真的要感謝ElasticSearch強大的語法和業務場景覆蓋能力，畢竟在我看來，ElasticSearch更像是一個爲業務而生的產品。深刻了解ES後，你會發如今有些方面它真的比SQL更強大；如今咱們的策略平臺甚至支持分詞查詢、分桶查詢、多表聯合查詢、TopN、聚合查詢等多種複合查詢，這都要感謝ElasticSearch強大的功能。

3. 元數據管理模塊介紹

你們都知道HBase是No-Schema模型，元數據管理層咱們也就是爲其和ES作一個虛擬的Schema管理，同時去動態控制哪些字段要建索引。在數據接入的時候，咱們會經過元數據中心判斷數據是否符合規則（咱們本身定的一些規則）；在數據輸出的時候，咱們控制哪些策略須要走緩存，哪些策略不須要走HBase等等。其次，維護一套元數據方便咱們作一些簡單的頁面指標監控，並對ES和HBase有一個總線控制（如建表刪表等），該模塊就很少說了。

4. 索引創建模塊介紹

這個模塊呢，其實算是相對比較複雜的一個模塊。咱們沒有采用HBase + WAL + ES的方式而是HBase + Kafka + ES 的方式去同步索引數據。一是由於WAL層不太好控制和監控，二是ES消費WAL的效率問題，三是WAL層數據一致性很差維護。

因此咱們把一部分的工做放到了數據接入層，在數據寫完HBase以後，即對外響應Success並異步將數據推至Kafak隊列中等待ES去二次消費；寫入失敗則對外拋出異常，咱們首先要保證的是，寫入HBase要麼成功，要麼失敗。

在ES消費層，咱們是能夠動態指定消費線程數量的。當Kafka Lag堆積超過必定閾值（閾值可進行Group級調節和監控），會進行警報，並動態調整消費線程數。

在數據一致性方面，咱們也作了大量工做，且咱們只保證數據最終一致性。當數據寫入HBase成功以後，咱們會對寫Kafka和寫ES進行鏈路追蹤，任何一個環節一旦寫入失敗，即將Failed Key寫入黑名單（Redis存儲）。

對於進入黑名單的數據，咱們會起定時調度線程去掃描這些Key並進行自動回補索引。回補方式是：到HBase中拿最新的數據再次寫入隊列中去。若是此時又失敗，咱們會把這些Key放入終極死亡名單（Redis存儲），並經過定時調度線程去掃描這個死亡名單，若是有屍體，則報警，此時人力介入。

這種分層處理方式，也是借鑑了些許HBase LSM的思想，勿噴勿噴~

我簡單畫了一下這個流程，方便你們理解，見下圖：

5. 平臺監控模塊介紹

該模塊再也不細說了，主要是Hadoop集羣、HBase集羣的監控，外加K8S平臺監控。K8S監控平臺主要基於Prometheus+Grafana+Fluent實現。

6. 離線數據分析模塊介紹

該模塊依賴於HBase Replication集羣間複製功能實現。數據在同步至離線HBase集羣以後，主要用於對接數據倉庫、Spark讀寫分析、大範圍掃描操做等等。主要是減少面向分析型做業對線上實時平臺的影響。

六大模塊就簡單介紹到這裏。

四。心得

總的感覺：使用ES賦能HBase感受很融洽，ES很棒，ES+HBase真的能夠媲美SQL了。

好像ES天生跟HBase是一家人，HBase支持動態列，ES也支持動態列，這使得二者結合在一塊兒很融洽。而ES強大的索引功能正好是HBase所不具有的，若是隻是將業務索引字段存入ES中，體量其實並不大；甚至不少狀況下，業務索引字段60%以上都是Term類型，根本不須要分詞。雖然咱們仍是支持了分詞，好比多標籤索引就會用到。

不少設計者可能會以爲HBase + Kafka + ES三者結合在一塊兒有點過重了，運維成本很高，有點望而卻步。但轉換角度想一下，咱們不就是搞技術的嘛，這下子能夠三個成熟產品一塊兒學了！如今看來，收穫仍是大於付出的。

至於ES和Solr選擇誰去作二級索引的問題，我以爲差異不大，根據自家公司的現狀作選擇就行了。

最後，仍是要爲ElasticSearch點個贊！不錯的產品！

五。將來要作的事

• 多租戶全鏈路打通
• 策略層SQL支持
• 系統不斷優化、產品化

轉載請註明出處！歡迎關注本人微信公衆號【HBase工做筆記】