一,。背景介紹公司成立差不多十五六年了，老公司了,。也正是因為資格老,，業(yè)務迭代太多了，各個業(yè)務線錯綜復雜,，接口調用也密密麻麻,。有時候A向B要數(shù)據(jù)，有時候B向C要接口,，有時候C向A要服務,；各個業(yè)務線各有各的財產(chǎn)，各自為營,，像一個個小諸侯擁兵自重,，跑腿費會議費都貴的很。面對這個現(xiàn)狀,，我們急需進行一波大改造了,。 而這個系統(tǒng)（我們暫且叫它天池吧），正是為了整合公司各個業(yè)務線的資源,，改造這個錯綜復雜的蜘蛛網(wǎng)為簡單的直線班車,。省去不必要的接口調用、業(yè)務穿插,、會議溝通以及不知去哪里拿數(shù)據(jù),、拿不到數(shù)據(jù)、拿數(shù)據(jù)慢的困擾,。當然,，更節(jié)省了產(chǎn)品、開發(fā)人員的時間,，提升了各業(yè)務線整體工作效率,。 幾個詞形容一下天池：穩(wěn)、快,、大,、省、清晰,。 二,。業(yè)務梳理經(jīng)過對公司各線業(yè)務進行梳理，總結出以下幾大常見的數(shù)據(jù)輸出模型：
或許還有更多數(shù)據(jù)模型,，這里就不再列舉了。從前端到后臺,，無論再多數(shù)據(jù)模型,，其實都可以轉化為索引+KV的形式進行輸出，甚至有時候,，我覺得索引+KV>SQL,。 基于此業(yè)務數(shù)據(jù)模型分析及公司對ElasticSearch的長期使用，我們最終選擇了HBase + ElasticSearch這樣的技術方案來實現(xiàn),。 三,。架構設計與模塊介紹先看一下整體架構圖，如下圖： 整個天池系統(tǒng)核心主要分為數(shù)據(jù)接入層、策略輸出層,、元數(shù)據(jù)管理,、索引建立、平臺監(jiān)控以及離線數(shù)據(jù)分析六大子模塊,，下面將分別對其進行介紹,。 1. 數(shù)據(jù)接入模塊介紹數(shù)據(jù)接入模塊我們主要對HBase-Client API進行了二次輕封裝，支持在線RESTFUL服務接口和離線SDK包兩種主要方式對外提供服務,，同時兼容HBase原生API和HBase BulkLoad大批量數(shù)據(jù)寫入,。 其中，在線RESTFUL服務以HBase Connection長連接的方式對外提供服務,，好處是：在性能影響不大的情況下方便跨語言操作,，更主要的一點是便于管理。在這一層,，可以做很多工作,，比如權限管理、負載均衡,、失敗恢復,、動態(tài)擴縮容、數(shù)據(jù)接口監(jiān)控等等,，當然這一切都要感謝K8S的強大能力,。 2. 策略輸出模塊介紹該模塊主要就是對接我們上文業(yè)務梳理模塊歸納的各種業(yè)務需求，都由此模塊提供服務,。顧名思義,，策略模塊主要用于為用戶配置策略，或用戶自己配置策略,，最終基于策略生成策略ID,。 這一層我們主要是對ElasticSearch和HBase的一些封裝，通過動態(tài)模板將用戶請求轉化為ElasticSearch DSL語句,，而后對ES進行查詢,，直接返回數(shù)據(jù)或是獲取到rowkey進而查詢HBase進行結果返回。 通過元數(shù)據(jù)管理中心,，我們可以判斷出用戶所需字段是否被索引字段覆蓋,，是否有必要二次查詢HBase返回結果。而這整個查詢過程,，用戶并不會感知,，他們只需要一個PolicyID即可。 當然,，我們也在不斷普及用戶如何通過后臺自己配置生成策略,。合作較多的業(yè)務方,，甚至可以自己在測試環(huán)境配置好一切，完成數(shù)據(jù)的自助獲取工作,。而我們需要做的,，只是一鍵同步測試環(huán)境的策略到線上環(huán)境，并通知他們線上已可用,。整個過程5~10分鐘,，一個新的接口就誕生了。 其次,，由于ES抗壓能力畢竟不如HBase猛,，我們的策略接口也會根據(jù)業(yè)務需求決定是否開啟緩存。事實上,，大部分接口是可以接受短時間內數(shù)據(jù)緩存的,。當然像簡單KV、K-Map,、Mk-Map這種是直接走HBase的,，需求量也挺大。 到目前為止,，上述業(yè)務輸出模型基本都已支持動態(tài)策略配置。這真的要感謝ElasticSearch強大的語法和業(yè)務場景覆蓋能力,，畢竟在我看來,，ElasticSearch更像是一個為業(yè)務而生的產(chǎn)品。深入了解ES后,，你會發(fā)現(xiàn)在有些方面它真的比SQL更強大,；現(xiàn)在我們的策略平臺甚至支持分詞查詢、分桶查詢,、多表聯(lián)合查詢,、TopN、聚合查詢等多種復合查詢,，這都要感謝ElasticSearch強大的功能,。 3. 元數(shù)據(jù)管理模塊介紹大家都知道HBase是No-Schema模型，元數(shù)據(jù)管理層我們也就是為其和ES做一個虛擬的Schema管理,，同時去動態(tài)控制哪些字段要建索引,。在數(shù)據(jù)接入的時候，我們會通過元數(shù)據(jù)中心判斷數(shù)據(jù)是否符合規(guī)則（我們自己定的一些規(guī)則）,；在數(shù)據(jù)輸出的時候,，我們控制哪些策略需要走緩存，哪些策略不需要走HBase等等,。其次,，維護一套元數(shù)據(jù)方便我們做一些簡單的頁面指標監(jiān)控,，并對ES和HBase有一個總線控制（如建表刪表等），該模塊就不多說了,。 4. 索引建立模塊介紹這個模塊呢,，其實算是相對比較復雜的一個模塊。我們沒有采用HBase + WAL + ES的方式而是HBase + Kafka + ES 的方式去同步索引數(shù)據(jù),。一是因為WAL層不太好控制和監(jiān)控,，二是ES消費WAL的效率問題，三是WAL層數(shù)據(jù)一致性不好維護,。 所以我們把一部分的工作放到了數(shù)據(jù)接入層,，在數(shù)據(jù)寫完HBase之后，即對外響應Success并異步將數(shù)據(jù)推至Kafak隊列中等待ES去二次消費,；寫入失敗則對外拋出異常,，我們首先要保證的是，寫入HBase要么成功,，要么失敗,。 在ES消費層，我們是可以動態(tài)指定消費線程數(shù)量的,。當Kafka Lag堆積超過一定閾值（閾值可進行Group級調節(jié)和監(jiān)控）,，會進行警報，并動態(tài)調整消費線程數(shù),。 在數(shù)據(jù)一致性方面,，我們也做了大量工作，且我們只保證數(shù)據(jù)最終一致性,。當數(shù)據(jù)寫入HBase成功之后,，我們會對寫Kafka和寫ES進行鏈路追蹤，任何一個環(huán)節(jié)一旦寫入失敗,，即將Failed Key寫入黑名單（Redis存儲）,。 對于進入黑名單的數(shù)據(jù)，我們會起定時調度線程去掃描這些Key并進行自動回補索引,?；匮a方式是：到HBase中拿最新的數(shù)據(jù)再次寫入隊列中去。如果此時又失敗,，我們會把這些Key放入終極死亡名單（Redis存儲）,，并通過定時調度線程去掃描這個死亡名單，如果有尸體,，則報警,，此時人力介入。 這種分層處理方式,，也是借鑒了些許HBase LSM的思想,，勿噴勿噴~ 我簡單畫了一下這個流程,，方便大家理解，見下圖：
5. 平臺監(jiān)控模塊介紹該模塊不再細說了,，主要是Hadoop集群,、HBase集群的監(jiān)控，外加K8S平臺監(jiān)控,。K8S監(jiān)控平臺主要基于Prometheus+Grafana+Fluent實現(xiàn),。 6. 離線數(shù)據(jù)分析模塊介紹該模塊依賴于HBase Replication集群間復制功能實現(xiàn)。數(shù)據(jù)在同步至離線HBase集群之后,，主要用于對接數(shù)據(jù)倉庫,、Spark讀寫分析、大范圍掃描操作等等,。主要是減小面向分析型作業(yè)對線上實時平臺的影響,。 六大模塊就簡單介紹到這里。 四,。心得總的感受：使用ES賦能HBase感覺很融洽,，ES很棒，ES+HBase真的可以媲美SQL了,。 好像ES天生跟HBase是一家人,，HBase支持動態(tài)列，ES也支持動態(tài)列,，這使得兩者結合在一起很融洽,。而ES強大的索引功能正好是HBase所不具備的，如果只是將業(yè)務索引字段存入ES中,，體量其實并不大；甚至很多情況下,，業(yè)務索引字段60%以上都是Term類型,，根本不需要分詞。雖然我們還是支持了分詞,，比如多標簽索引就會用到,。 很多設計者可能會覺得HBase + Kafka + ES三者結合在一起有點太重了，運維成本很高,，有點望而卻步,。但轉換角度想一下，我們不就是搞技術的嘛,，這下子可以三個成熟產(chǎn)品一起學了,！現(xiàn)在看來，收獲還是大于付出的,。 至于ES和Solr選擇誰去做二級索引的問題,，我覺得差別不大,，根據(jù)自家公司的現(xiàn)狀做選擇就好了。 最后,，還是要為ElasticSearch點個贊,！不錯的產(chǎn)品！ 五,。未來要做的事
|
|
|
