HBaseCon Asia 2019 Track 3 概要回顧

                           Track 3：Application

Track3是關於HBase應用的分享，來自騰訊、快手、滴滴、Pinterest、中國移動、中國人壽等多家公司的工程師爲咱們分享了HBase在應用和實踐中遇到的問題和經驗。

Track3-1: HBase at Tencent

PPT下載連接： http://t.cn/AijgoTGY

來自騰訊的工程師程廣旭爲咱們帶來了 HBase 在騰訊的業務中的應用場景和經驗。

騰訊目前有90多個 HBase 集羣，最大的集羣有500多臺節點。騰訊內部多個業務包括騰訊視頻，微信支付和騰訊雲等都在使用HBase服務。其首先分享了使用 HBase 進行數據遷移的經驗：Replication 和 ExportSnapshot.在實際使用中，業務天天的數據量都很大，這些數據須要保存的週期要麼很大，要麼很小。所以採起了按天分表的方式，也就是天天會建立一個新的表，對於過時的數據，直接把當天的表刪掉便可。其次分享了對帶寬的優化。

寫入HBase的流量主要有五個部分:

1.寫入，2.WAL，3.Flush，4.Small Compaction，5.Major Compaction。優化的方法有：1.開啓CellBlock的壓縮。2.WAL的壓縮。3.增大memstore，減小Flush，減小Compaction。4.減小Compaction的線程數目。5.關閉Major Compaction。6.按天建表。最後介紹瞭如何共享RestServer。當每一個HBase集羣搭建一個RestServer時，若是讀取集羣的請求不多，那麼集羣的RestServer資源比較浪費。騰訊作了一個改進，配置一個RestServer能夠訪問多個HBase集羣，同時在MySQL裏記了哪些表能夠經過這種方式訪問。

Track3-2: HBase at Kuaishou

PPT下載連接：http://t.cn/AijgodXA

來自快手的工程師徐明爲咱們分享了HBase在快手的應用和實踐。

快手天天有大量的用戶上傳大量的視頻，這部分視頻大部分是幾MB的對象，其存儲方案是：數據直接存儲在HDFS上，數據的索引存儲在HBase上，而最新的數據則存儲在memcache中。

爲了提升HBase的可用性，加快故障恢復速度，快手自研了hawk系統，其包括master，agent，sniffer三個組件，由多個agent投票來確認一個節點是否掛了，而後由sniffer來處理掛的節點，並將有問題的節點迅速的從zk上刪掉。同時快手作了一些優化來加速split log和assign region的過程。在Client端，則主要是確保有問題節點的region location能被快速清理掉。

RSGroup功能也在快手被大量使用，並作了一些優化。一個是添加了FallBack RSGroup，若是某個RSGroup的所有節點都掛了，就從這個FallBack RSGroup中選擇機器；一個是添加了Global RSGroup，主要是知足監控需求，由於hbase的canary表須要分佈在各個機器上。

快手還分享了其如何使用HBase來存儲和分析海量數據的案例。好比要解決計算用戶留存的問題，若是使用SQL的話執行很慢，快手使用了Bitmap的解決方案。把須要提取的維度轉化成Bitmap，使用空間來減小消耗的時間。使用MR把選擇的維度轉成Bitmap，把Bitmap切成小塊，Bitmap的數據及meta都導入到HBase中。

Track3-3: HBase at DiDi

PPT下載連接：

http://t.cn/AijgK2qq

來自滴滴的工程師唐天航爲咱們帶來了HBase在滴滴的業務中的應用場景和經驗。

滴滴國內的HBase集羣有7個，海外國際化集羣有4個。覆蓋了滴滴所有的業務線，目前服務的項目大概有200多個，數據級是PB級。

滴滴使用HBase主要有兩個場景：1.離線數據查詢，包括Phoenix、Kylin、openTSDB的使用，2.GeoMesa系統構建的軌跡數據系統，可用於實時查詢、監控和特徵工程的數據挖掘。GeoMesa系統提供導入和導出接口，導入接口支持Native API、MR/BulkLoad、StreamingSQL，導出接口支持SparkCore、SparkSQL、CQL、GeoServer。這樣使用GeoMesa能夠有如下好處：一、開箱即用，二、類SQL文本語言支持，三、橫向可擴張、4基於Hadoop生態。

滴滴在實踐中對zookeeper的改進爲：分離server和client所依賴ZK，當client端的突發大量訪問形成zk不可用時，不會影響到服務端。(HBASE-20159，ZOOKEEPER-832)。滴滴在HBase/Phoenix上的改進，主要是Quota設置、replication以及查詢優化（HBASE-21964，HBASE-22620，PHOENIX-5242）

最後， 滴滴創建了從Client端到HAProxy，而後到Thriftserver和QueryServer上，以後再到Hbase的多元用戶全鏈路追蹤，可以更加有效提高運維效率。

Track3-4: Phoenix Best Practice In China Life Insurance Company

PPT下載連接：http://t.cn/AijgKfM4

來自中國人壽的工程師袁利鷗爲咱們分享了Phoenix在中國人壽的最佳實踐

中國人壽目前總的節點數有200多個，Phoenix集羣的節點是30多個。集羣總體的數據量是1300T，HBase單表最大30T，天天大概會有上百個腳本運行。

Phoenix在中國人壽的應用場景：數據源是從核心的交易系統上產生，而後經過SharePlex，打到Kafka上，數據從Kafka實時接入到Phoenix集羣上，經過查詢服務，爲APP提供權益信息訪問。從物理架構上看，最底層是Phoenix集羣，向上有兩條鏈路，一條是Phoenix Gateway，另外一條是實時查詢服務，經過負載平衡，承接到Weblogic集羣上。

袁利鷗介紹了Spark Streaming的設計：一、對於整合後的表，會加入一些控制字段，記錄更新時間、刪除仍是插入操做等。二、實時同步程序，按照表名或者統計字段作區分。

袁利鷗接着介紹了關於Phoenix的優化，把Phoenix的系統表作爲一個分組，數據表放在另外一個分組中。客戶端訪問時，天天會拉去一次元數據，隨後就不用去訪問Phoenix 系統表，能夠下降負載。基於HBase的一些優化包括：一、Region Balance By Table。 二、G1GC

三、Manual MajorCompaction

Track3-5: HBase Practice in China Mobile

PPT下載連接：http://t.cn/AijgOxGa

來自中國移動蘇州研發中心Hbase負責人陳葉超介紹了Hbase在中國移動的實踐

中國移動目前大概有6000個物理節點，100多個集羣，幾十PB數據，單集羣最大600多個節點，單表最大1.6PB，最大3000萬併發訪問，存儲的數據採用較高壓縮比進行壓縮，減小存儲空間。

HBase在中國移動的幾個應用場景：1.北京移動的流量清單，好比手機使用流量，這個在掌上營業廳是能夠查到的。二、DPI數據，主要是信令相關的，有一些網絡優化的設計。三、監控和日誌，包括小圖片、用戶標籤、爬蟲和市場營銷等。

中國移動在實踐中經過數據抽樣解決BulkLoad中數據傾斜問題。數據壓縮在Flush 和BulkLoad階段都不開啓，只在compaction階段使用，提升讀寫性能。混合使用SSD/HDD磁盤，compaction後數據存儲在HDD磁盤。對於更好的使用SSD，中國移動作了以下工做：1，backport HSM To HBase 1.2.6版本。2，全部用戶過來的寫入路徑都是SSD的，寫性能提升50%。此外，中國移動還開發了HBase集羣智能運維工具：Slider和RegionServerGroup，能夠控制資源的分配，並基於Region作了一套權限認證體系。

Track3-6: Recent work on HBase at Pinterest

PPT下載連接：http://t.cn/AijgO0KU

來自Pinterest 的技術lead徐良鴻分享了HBase在Pinterest的最新進展

Pinterest目前集羣規模50臺，都部署在AWS上，數據量大概在PB級。2013年開始使用HBase 0.94 ， 2016年升級爲1.2版本。

Pinterest經過Apache Omid實現HBase對事務的支持，使用中發現Omid存在性能瓶頸，隨後自研Sparrow系統，主要改進有：1，將commit操做移到客戶端，解決Transaction Manager 單點問題。2，將Transaction Manager 改成多線程實現，begin操做能夠不用等待commit完成。Sparrow與Omid相比，對於P99延時，Begin階段有100倍下降，commit階段也有3倍下降。

Pinterest自研了Argus系統，與Kafka結合使用，提供WAL通知機制。大概的實現爲：須要通知機制的數據會在client寫入時添加標記，這些標記會被傳到WAL層面，經過Kafka將WAL提供給 Argus Observer進行數據處理，處理方式是用戶自定義的。

Pinterest基於開源Lily實現Ixia，用於實時構建HBase二級索引，同時整合了Muse,實現類SQL查詢。大概的實現：寫入HBase的數據會傳到Replication Proxy，經過Kafka打到Indexer中，index manager會讀取HBase數據的列，若是須要建索引，會將數據寫入Muse中，Muse會根據數據的schema作檢索，query會在Muse中查詢，須要時會查詢HBase

徐良鴻介紹了Argus和Ixia設計的好處：一、基於異步的複製機制，對寫入的影響很小。二、與HBase系統獨立，分開運行，能夠很快的進行數據處理。

Track3-7 HBase at Tencent Cloud

PPT下載連接：http://t.cn/AijgOeGJ

來自騰訊的工程師陳龍爲咱們分享了HBase在騰訊雲上的經驗。

雲上服務會遇到不少管理和用戶相關的問題。陳龍說明了雲服務的3個挑戰：一、大量的技術諮詢工做。二、緊急狀況的處理。三、故障定位分析。並結合兩個案例分析雲服務的挑戰。

騰訊雲在監控方面，經過OpenTSDB收集table和region的metirc, 用戶能夠登陸雲監控，設置Qps到某一閾值後，作反向通知。

陳龍分析了雲上的故障有4類緣由：

一、外部因素，例如資源泄露，大量請求，coprocessor問題

二、硬件因素，磁盤、網絡、CVM，資源

三、存儲因素，塊丟失、讀寫超時

四、配置因素，jvm、memstore、blockcache、flushsize

騰訊雲經過提供文檔，工具和監控等三個方式，解決在雲上遇到的多種問題。陳龍最後分享了監控系統的架構。分享了雲上管理服務的架構，好比須要快速的擴容或者縮容集羣等。

轉載請註明出處「小米雲技術」