HBaseCon 沒來參加怎麼辦？
三個Track沒法同時聽，分身乏術怎麼辦？
沒關係！“小米雲技術”將用三期時間帶你回顧
全部精華！
往期回顧：Track1乾貨回顧 / Track 2 乾貨回顧
Track 3：Application
Track3是關於HBase應用的分享，來自騰訊、快手、滴滴、Pinterest、中國移動、中國人壽等多家公司的工程師爲我們分享了HBase在應用和實踐中遇到的問題和經驗。
1、HBase at Tencent
PPT下載鏈接：http://t.cn/AijgoTGY
來自騰訊的工程師程廣旭爲我們帶來了 HBase 在騰訊的業務中的應用場景和經驗。
騰訊目前有90多個 HBase 集羣，最大的集羣有500多臺節點。騰訊內部多個業務包括騰訊視頻，微信支付和騰訊雲等都在使用 HBase 服務。其首先分享了使用 HBase 進行數據遷移的經驗：Replication 和 ExportSnapshot.在實際使用中，業務每天的數據量都很大，這些數據需要保存的週期要麼很大，要麼很小。因此採取了按天分表的方式，也就是每天會創建一個新的表，對於過期的數據，直接把當天的表刪掉即可。其次分享了對帶寬的優化。
寫入 HBase 的流量主要有五個部分:
-
寫入
-
WAL
-
Flush
-
Small Compaction
-
Major Compaction
優化的方法有：
-
開啓 CellBlock 的壓縮。
-
WAL 的壓縮。
-
增大 memstore,減少 Flush,減少 Compaction.
-
減少 Compaction 的線程數目。
-
關閉 Major Compaction.
-
按天建表。
最後介紹瞭如何共享 RestServer.當每個 HBase 集羣搭建一個 RestServer 時，如果讀取集羣的請求很少，那麼集羣的 RestServer 資源比較浪費。騰訊做了一個改進，配置一個 RestServer 可以訪問多個 HBase 集羣，同時在 MySQL 裏記了哪些表可以通過這種方式訪問。
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 中。
3、HBase at DiDi
PPT下載鏈接：http://t.cn/AijgK2qq
來自滴滴的工程師唐天航爲我們帶來了 HBase 在滴滴的業務中的應用場景和經驗。
滴滴國內的 HBase 集羣有7個，海外國際化集羣有4個。覆蓋了滴滴全部的業務線，目前服務的項目大概有200多個，數據級是 PB 級。
滴滴使用 HBase 主要有兩個場景：
-
離線數據查詢，包括 Phoenix,Kylin,openTSDB 的使用；
-
GeoMesa 系統構建的軌跡數據系統，可用於實時查詢、監控和特徵工程的數據挖掘。
GeoMesa 系統提供導入和導出接口，導入接口支持 Native API,MR/BulkLoad,StreamingSQL,導出接口支持 SparkCore,SparkSQL,CQL,GeoServer.這樣使用 GeoMesa 可以有以下好處：
-
開箱即用;
-
類 SQL 文本語言支持;
-
橫向可擴張;
-
基於 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 的多元用戶全鏈路追蹤，能夠更加有效提升運維效率。
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 的設計：
（1）對於整合後的表，會加入一些控制字段，記錄更新時間、刪除還是插入操作等。
（2）實時同步程序，按照表名或者統計字段做區分。
袁利鷗接着介紹了關於 Phoenix 的優化，把 Phoenix 的系統表做爲一個分組，數據表放在另一個分組中。客戶端訪問時，每天會拉去一次元數據，隨後就不用去訪問 Phoenix 系統表，可以降低負載。基於 HBase 的一些優化包括：
-
Region Balance By Table。
-
G1GC
-
Manual MajorCompaction
5、HBase Practice in China Mobile
PPT下載鏈接：http://t.cn/AijgOxGa
來自中國移動蘇州研發中心 HBase 負責人陳葉超介紹了 HBase 在中國移動的實踐
中國移動目前大概有6000個物理節點，100多個集羣，幾十PB數據，單集羣最大600多個節點，單表最大1.6PB，最大3000萬併發訪問，存儲的數據採用較高壓縮比進行壓縮，減少存儲空間。
HBase 在中國移動的幾個應用場景：
（1）北京移動的流量清單，比如手機使用流量，這個在掌上營業廳是可以查到的。
（2）DPI數據，主要是信令相關的，有一些網絡優化的設計。
（3）監控和日誌，包括小圖片、用戶標籤、爬蟲和市場營銷等。
中國移動在實踐中通過數據抽樣解決 BulkLoad 中數據傾斜問題。數據壓縮在Flush 和 BulkLoad 階段都不開啓，只在 compaction 階段使用，提高讀寫性能。混合使用 SSD/HDD 磁盤，compaction 後數據存儲在 HDD 磁盤。對於更好的使用 SSD,中國移動做了如下工作：
-
backport HSM To HBase 1.2.6版本。
-
所有用戶過來的寫入路徑都是SSD的，寫性能提高50%。
此外，中國移動還開發了 HBase 集羣智能運維工具：Slider 和RegionServerGroup,可以控制資源的分配，並基於 Region 做了一套權限認證體系。
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 系統，主要改進有：
-
將 commit 操作移到客戶端，解決 Transaction Manager 單點問題。
-
將 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 系統獨立，分開運行，可以很快的進行數據處理。
7、HBase at Tencent Cloud
PPT下載鏈接：http://t.cn/AijgOeGJ
來自騰訊的工程師陳龍爲我們分享了 HBase 在騰訊雲上的經驗。
雲上服務會遇到很多管理和用戶相關的問題。陳龍說明了雲服務的3個挑戰：
-
大量的技術諮詢工作。
-
緊急情況的處理。
-
故障定位分析。
並結合兩個案例分析雲服務的挑戰。
騰訊雲在監控方面，通過 OpenTSDB 收集 table 和 region 的 metirc, 用戶可以登錄雲監控，設置 Qps 到某一閾值後，做反向通知。
陳龍分析了雲上的故障有4類原因：
-
外部因素：例如資源泄露，大量請求，coprocessor 問題
-
硬件因素：磁盤、網絡、CVM、資源
-
存儲因素：塊丟失、讀寫超時
-
配置因素：jvm、memstore、blockcache、flushsize
騰訊雲通過提供文檔，工具和監控等三個方式，解決在雲上遇到的多種問題。陳龍最後分享了監控系統的架構。分享了雲上管理服務的架構，比如需要快速的擴容或者縮容集羣等。
完
通過三期的更新
小編已經把本次HBaseCon的全部精華呈現給你啦
什麼？還沒過癮？想看現場視頻？想要完整版的PPT？
點擊“閱讀原文”到官網獲取吧！
