1

HBase在Ad Tracking的應(yīng)用

1.1

Ad Tracking的業(yè)務(wù)場景

Ad Tracking是TalkingData的移動廣告監(jiān)測產(chǎn)品，其核心業(yè)務(wù)模型是歸因。App用戶點擊廣告之后，及隨后安裝廣告跳轉(zhuǎn)到的應(yīng)用或者游戲，Ad Tracking會對這些點擊事件(用戶點擊廣告的行為)和激活事件(用戶安裝應(yīng)用的行為)進(jìn)行監(jiān)測。

歸因需要做的是，接收到激活事件之后，通過激活事件匹配之前接收到的點擊事件，如果激活歸因到了點擊，那么這個激活事件就是點擊廣告帶來的，也就歸因到了該廣告對應(yīng)的推廣活動，而推廣活動對應(yīng)某個渠道，歸因到了推廣活動就歸因到了投放廣告的渠道等。后續(xù)的所有效果點事件(例如應(yīng)用內(nèi)的注冊、登錄等事件)也都將通過對應(yīng)的激活事件找到對應(yīng)的推廣活動信息。

激活和各種效果點事件的原始信息，包括對應(yīng)的設(shè)備、歸因到的推廣活動等，都可以提供給Ad Tracking用戶為參考——Ad Tracking的數(shù)據(jù)導(dǎo)出功能。

1.2

HBase與數(shù)據(jù)導(dǎo)出

HBase作為一個分布式的列式存儲，擁有強(qiáng)悍的數(shù)據(jù)寫入能力，由于是列式存儲，隨著后期需求的增加，可以動態(tài)的增加存儲的字段，非常契合Ad Tracking的數(shù)據(jù)導(dǎo)出的業(yè)務(wù)場景。

通過合理的設(shè)計rowkey，HBase又能保證很快的查詢速度，用戶在Ad Tracking后臺進(jìn)行數(shù)據(jù)導(dǎo)出之后，基本上秒級時間就能夠完成數(shù)據(jù)的下載，能夠保證很好的導(dǎo)出體驗。

下面將對HBase的架構(gòu)原理和在Ad Tracking數(shù)據(jù)導(dǎo)出功能中的應(yīng)用進(jìn)行介紹下。

2

HBase的架構(gòu)

圖：HBase的基本架構(gòu)

• master：

  ?表的操作，例如修改列族配置等

  ?region的分配，merge，分割

• zookeeper：

  ?維護(hù)服務(wù)器存活、是否可訪問的狀態(tài)

  ?master的HA

  ?記錄HBase的元數(shù)據(jù)信息的存儲位置

• region server：數(shù)據(jù)的寫入與查詢

• hdfs：數(shù)據(jù)的存儲，region不直接跟磁盤打交道，通過hdfs實現(xiàn)數(shù)據(jù)的落盤和讀取

3

數(shù)據(jù)的寫入

3.1

數(shù)據(jù)的寫入過程

圖：數(shù)據(jù)的寫入概覽

• WAL：write ahead log，數(shù)據(jù)首先寫入log，保證數(shù)據(jù)不丟失，該log也是保存在hdfs上

• MemStore：數(shù)據(jù)進(jìn)入內(nèi)存，按照rowkey進(jìn)行排序

• HFile：MemStore中的數(shù)據(jù)到達(dá)一定量或者一定時間，創(chuàng)建HFile落盤

3.2

數(shù)據(jù)格式

HBase存儲的所有內(nèi)容都是byte數(shù)組，所以只要能轉(zhuǎn)化成byte數(shù)組的數(shù)據(jù)都可以存儲在HBase中。

4

存儲模型

圖：HBase的存儲概念模型

• 表：一個表由一個或者多個列族構(gòu)成

• 行：一個行包含多個列，列通過列族進(jìn)行分類，每一行都有唯一主鍵rowkey

• 列族：列族包含若干列，這些列在物理上存儲在一起，所以列族內(nèi)的列一般是在查詢的時候需要一起讀取。數(shù)據(jù)的屬性，例如超時時間、壓縮算法等，都需要在列族上定義

• 列：一個行包含多個列，多個列維護(hù)在一個或者多個列族中

• 單元格：列的內(nèi)容保存在單元格中，如果有過更新操作，會有多個版本

5

存儲實現(xiàn)

圖：HBase的存儲結(jié)構(gòu)

5.1

region

Table的數(shù)據(jù)以region的形式分布在所有的服務(wù)器上。region的存在是為了解決橫向擴(kuò)展問題。

5.1.1

region的拆分

通過將數(shù)據(jù)均衡的分布到所有機(jī)器上，可以充分利用各個服務(wù)器的能力，提高查詢速度。隨著數(shù)據(jù)的不斷寫入，region會不斷增大，region太大會影響查詢性能，所以hbase會自動對region進(jìn)行拆分。

下面是兩種常見的region的拆分策略：

• ConstantSizeRegionSplitPolicy：老版本的Hbase使用的拆分策略，按照固定的大小進(jìn)行拆分，默認(rèn)為10G。缺點：太死板、太簡單，無論是數(shù)據(jù)寫入量大還是小，都是通過這個固定的值來判斷

• IncreasingToUpperBoundRegionSplitPolicy：新版本的默認(rèn)策略，這個策略能夠隨著數(shù)據(jù)增長，動態(tài)改變拆分的閾值。

5.1.2

region的merge

場景：region中大量數(shù)據(jù)被刪除，不需要開始那么多region，可以手動進(jìn)行region的merge

5.2

store

一個region內(nèi)部有多個store，store是列族級別的概念，一個表有三個列族，那么在一臺服務(wù)器上的region中會有三個store。

5.2.1

MemStore

每個列族/store對應(yīng)一個獨(dú)立的MemStore，也就是一塊內(nèi)存空間，數(shù)據(jù)寫入之后，列族的內(nèi)容進(jìn)入對應(yīng)的MemStore，會按照rowkey進(jìn)行排序，并創(chuàng)建類似于Btree的索引——LMS-Tree。

LMS-Tree(Log-Structured Merge Tree)

LMS樹采用的索引結(jié)構(gòu)與B+Tree相同，而且通過批量存儲技術(shù)規(guī)避磁盤隨機(jī)寫入問題，因為數(shù)據(jù)過來之后，首先會在內(nèi)存中進(jìn)行排序，構(gòu)建索引，當(dāng)?shù)竭_(dá)一定的量的時候，flush到磁盤中，隨著磁盤中的小文件的增多，后臺進(jìn)行會自動進(jìn)行合并，過多的小文件合并為一個大文件，能夠有效加快查詢速度。

圖：LMS樹的合并

flush時機(jī)：

• 大小達(dá)到刷寫閥值

• 整個RegionServer的memstore總和達(dá)到閥值

• Memstore達(dá)到刷寫時間間隔

• WAL的數(shù)量大于maxLogs

• 手動觸發(fā)flush

5.2.2

HFile

HBase的數(shù)據(jù)文件，HBase的所有數(shù)據(jù)都保存在HFile中，查詢的時候也是從HFile中進(jìn)行查詢。

HFile包含多個數(shù)據(jù)塊，存儲了一個列族內(nèi)的數(shù)據(jù)，以及相關(guān)的索引：

• scan block：scan查詢的時候需要讀取的部分

  ?data block：數(shù)據(jù)KV存儲

  ?leaf index block：Btree的葉子節(jié)點

  ?bloom block：布隆過濾器

• none scan block

  ?meta block

  ?intermediate index block：Btree的中間節(jié)點

• load on open：HFile加載的時候，需要加載到內(nèi)存的部分

  ?root index block：Btree的根節(jié)點

  ?meta index

  ?file info

  ?bloom filter metadata：布隆過濾器的索引

• trailer：記錄上面各個部分的偏移量，HFile讀取的時候首先讀取該部分，然后獲取其他部分所在的位置

Hfile的compaction：

每次memstore的刷寫都會產(chǎn)生一個新的HFile，而HFile畢竟是存儲在硬盤上的東西，凡是讀取存儲在硬盤上的東西都涉及一個操作：尋址，如果是傳統(tǒng)硬盤那就是磁頭的移動尋址，這是一個很慢的動作。當(dāng)HFile一多，每次讀取數(shù)據(jù)的時候?qū)ぶ返膭幼髯兌?#xff0c;查詢速度也就變慢。所以為了防止尋址的動作過多，需要適當(dāng)?shù)販p少碎片文件，后臺需要持續(xù)進(jìn)行compaction操作。

compaction的分類：

• 小compaction：小的HFile的合并成大的

• 大compaction：大的最終合并成一個，注意：只有在大compaction之后，標(biāo)記刪除的文檔才會真正被刪除

compaction的過程：

• 讀取compaction列表中的hfile

• 創(chuàng)建數(shù)據(jù)讀取的scanner

• 讀取hfile中的內(nèi)容到一個臨時文件中

• 臨時文件替換compaction之前的多個hfile

6

數(shù)據(jù)查詢

6.1

查詢順序

1. 首先查找block cache：HFile的load on open部分是常駐內(nèi)存的，data block是在磁盤上的，查詢的時候，定位到某個data block之后，HBase會將整個data block加載到block cache中，后續(xù)查詢的時候，先檢查是否存在block cache中，如果是，優(yōu)先查詢block cache。之所以可以這么放心的使用block cache，是基于Hfile的不可變性，后續(xù)的修改和刪除操作不會直接修改HFile，而是追加新的文件，所以只要HFile還在，對應(yīng)的block cache就是不變的。

2. block cache查詢不到再去查找region(memstore + hfile)：通過hbase的元數(shù)據(jù)表，找到需要查詢的rowkey所在的region server，從而定位到memstore和hfile

6.2

region的查找過程

圖：region的查找過程

一個表有多個region，分布在不同機(jī)器上，需要一定的機(jī)制來確定需要查找的region

• 通過zk找到meta所在的sever：meta表的位置保存在zk中，meta中保存了每個region的rowkey范圍，以及region所在的位置

• 通過meta查詢出需要查詢的region所在的服務(wù)器

• 到服務(wù)器上進(jìn)行查詢

客戶端會對meta信息進(jìn)行緩存，加快查詢速度。

6.3

查詢API

• get：查詢某個rowkey對應(yīng)的列

• scan：指定rowkey范圍的掃描(setStartRow, setStopRow)

• filter：scan過程中，對內(nèi)容進(jìn)行過濾

其中指定rowkey范圍是最有效的加快查詢速度的方式，不限定rowkey的范圍則需要全表掃

7

?Ad Tracking的HBase設(shè)計

rowkey結(jié)構(gòu)：分區(qū)key-pid-eventTime-spreadid-序列

• 分區(qū)key：應(yīng)用的唯一key(隨機(jī)字符串)的hashcode / hbase的region個數(shù)

• pid：應(yīng)用的自增唯一主鍵

• eventTime：事件的時間

• spreadid：推廣活動的自增唯一主鍵

• 序列：隨機(jī)序列，保證上述字段相同的事件不會覆蓋寫入

Ad Tracking的hbase的rowkey是按照業(yè)務(wù)字段來設(shè)計的，相同應(yīng)用的數(shù)據(jù)保存在同一個region中，查詢快，但是由于用戶的數(shù)據(jù)量不同，查詢量也不同，可能導(dǎo)致熱點數(shù)據(jù)，造成某臺機(jī)器負(fù)載過高，影響機(jī)群正常工作。目前Ad Tracking的HBase的各個region空間占用尚存在一定程度的不均衡，但是還能接受。

一般HBase的rowkey中或多或少的會包含業(yè)務(wù)相關(guān)的信息，完全采用隨機(jī)的rowkey，跟業(yè)務(wù)不相關(guān)，查詢的時候只能全表掃，查詢效率低。rowkey設(shè)計的關(guān)鍵就在于權(quán)衡查詢速度和數(shù)據(jù)均衡之間的關(guān)系，下面介紹幾方面rowkey的設(shè)計建議。

7.1

rowkey長度設(shè)計建議

• 數(shù)據(jù)的持久化文件 HFile 中是按照 KeyValue 存儲的，如果 rowkey 過長，比如超過 100 字節(jié)，1000w 行數(shù)據(jù)，光 rowkey 就要占用 100*1000w=10 億個字節(jié)，將近 1G 數(shù)據(jù)，這樣會極大影響 HFile 的存儲效率；

• MemStore 將緩存部分?jǐn)?shù)據(jù)到內(nèi)存，如果 rowkey 字段過長，內(nèi)存的有效利用率就會降低，系統(tǒng)不能緩存更多的數(shù)據(jù)，這樣會降低檢索效率；

• 目前操作系統(tǒng)大都是 64 位系統(tǒng)，內(nèi)存 8 字節(jié)對齊，rowkey長度建議控制在 16 個字節(jié)(8 字節(jié)的整數(shù)倍)，充分利用操作系統(tǒng)的最佳特性。

7.2

rowkey設(shè)計方式-加鹽

圖：rowkey設(shè)計方式-加鹽

使用固定的隨機(jī)前綴：

• 優(yōu)點：數(shù)據(jù)均衡

• 缺點：因為前綴是隨機(jī)的，所以無法快速get；而scan的速度還可以

7.3

rowkey設(shè)計方式-hash

圖：rowkey設(shè)計方式-哈希

rowkey hash之后取md5的前五位：

• 優(yōu)點：打散數(shù)據(jù)，前綴在查詢的時候能通過rowkey得到，可以很快get

• 缺點：相同前綴的rowkey被打散，scan變慢

7.4

rowkey設(shè)計方式-反轉(zhuǎn)

圖：rowkey設(shè)計方式-反轉(zhuǎn)

反轉(zhuǎn)一段固定長度的rowkey，或者整個反轉(zhuǎn)。上圖中三個網(wǎng)址屬于相同域名下的，但是如果不反轉(zhuǎn)，會完全分散到不同的region中，不利于查詢。

end

參考資料

• [hbase-io-hfile-input-output](http://blog.cloudera.com/blog/2012/06/hbase-io-hfile-input-output/)

• [深入理解HBase的系統(tǒng)架構(gòu)]
  (https://blog.csdn.net/Yaokai_AssultMaster/article/details/72877127)

• [HBase底層存儲原理]
  (https://www.cnblogs.com/panpanwelcome/p/8716652.html)

• [HBase – 探索HFile索引機(jī)制]
  (http://hbasefly.com/2016/04/03/hbase_hfile_index/)

• [HBase – 存儲文件HFile結(jié)構(gòu)解析]
  (http://hbasefly.com/2016/03/25/hbase-hfile/)

作者：TalkingData 戰(zhàn)鵬弘

總結(jié)

以上是生活随笔為你收集整理的hbase filter原理_HBase应用|HBase在移动广告监测产品中的应用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。