作者：Pinterest Engineering 來源：InfoQ

PinalyticsDB 是 Pinterest 打造的一套專有時間序列數(shù)據(jù)庫。在 Pinterest，我們將 PinalyticsDB 作為后端以實現(xiàn)成千上萬份時間序列報表的存儲與可視化，例如下圖所示案例(按國家與地區(qū)劃分)。

 

 

我們在數(shù)年前以 HBase 為基礎(chǔ)開發(fā)出 PinalyticsDB，其利用實時 map-reduce 架構(gòu)通過 HBase 協(xié)處理器實現(xiàn)聚合。但隨著 Pinterest 業(yè)務(wù)的持續(xù)增長以及報表數(shù)量的不斷提升，PinalyticsDB 在處理龐大數(shù)據(jù)量及應(yīng)用負(fù)載中開始遭遇一系列可擴(kuò)展性挑戰(zhàn)。

過去幾個月以來，我們著手對 PinalyticsDB 進(jìn)行重構(gòu)，希望進(jìn)一步提高其性能與可靠性水平。在本文中，我們將共同了解 Pinterest 面臨的性能與可擴(kuò)展性挑戰(zhàn)，以及我們?nèi)绾瓮ㄟ^服務(wù)的重新設(shè)計構(gòu)建出更為強(qiáng)大的 PinalyticsDB 新形態(tài)。

Hbase 區(qū)域服務(wù)器熱點(diǎn)

隨著 Pinterest 內(nèi)平臺使用量的快速提升，熱點(diǎn)問題也開始成為 PinalyticsDB 區(qū)域服務(wù)器面臨的一大挑戰(zhàn)。在以往的設(shè)計中，PinalyticsDB 會為每份報表創(chuàng)建新的 HBase 表。

原有架構(gòu)設(shè)計

原本的行鍵設(shè)計方案為：

原行鍵 = 前綴|日期|后綴

前綴 = 指標(biāo)名稱(字符串)

日期 =YYYY-MM-DD 格式，同樣為字符串形式

后綴 = 由段號組成

行鍵由 ASCII 字符表示，其中“|”充當(dāng)分隔符。

這套方案存在以下幾個問題：

需要為每份報表創(chuàng)建一個新表，但由于某些報表的訪問頻率遠(yuǎn)超其他報表，因此承載這些報表的區(qū)域服務(wù)器將面對更多往來流量。

我們擁有成千上萬份報表，因此 HBase 管理員基本不可能以手動方式監(jiān)控報表并根據(jù)觀察到的熱點(diǎn)進(jìn)行表拆分。

在單一報表之內(nèi)，某些指標(biāo)的使用頻率可能較高。由于指標(biāo)名稱為行鍵的第一部分，因此導(dǎo)致熱點(diǎn)數(shù)量進(jìn)一步增加。

最近的數(shù)據(jù)使用趨勢傾向于更頻繁的訪問操作，而日期則為指標(biāo)后行鍵內(nèi)容的組成部分，同樣導(dǎo)致熱點(diǎn)數(shù)量進(jìn)一步增加。

以上提到的熱點(diǎn)主要針對讀取而言，但類似的熱點(diǎn)在寫入層面也同樣存在，主要表現(xiàn)為某些報表表具有相對更高的寫入次數(shù)，且指標(biāo)數(shù)據(jù)始終會寫入最新日期——這就導(dǎo)致各項指標(biāo)的最新日期部分成為區(qū)域內(nèi)的寫入熱點(diǎn)。

新的架構(gòu)設(shè)計

我們通過改進(jìn)行鍵架構(gòu)與 HBase 表設(shè)計的方式解決了這個問題。我們利用以下行鍵設(shè)計創(chuàng)建出一份面向所有報表的表。

新的行鍵 = SALT | < 報表 -id> | < 指標(biāo) -id> | < 日期 - 時間 > | < 段 >

該行鍵以字節(jié)數(shù)組(byte[])形式表示，而不再使用字符串形式。

 

 

鍵內(nèi)的各個部分都有固定的長度，作為定義行鍵的固定結(jié)構(gòu)，同時也支持模糊行過濾器。

由于采用固定結(jié)構(gòu)，因此我們不再需要“|”分隔符——這又進(jìn)一步節(jié)約了空間資源。

對讀取與寫入操作的影響

 

 

Pinalytics DB V2 讀取架構(gòu)

 

 

如大家所見，由于采用 salting 邏輯，讀取在整個集群當(dāng)中得到良好分發(fā)。更重要的是，寫入操作在這套架構(gòu)中的分發(fā)效果同樣令人滿意。

改進(jìn)協(xié)處理器性能

我們還計劃通過修改請求結(jié)構(gòu)與協(xié)處理器掃描行為的方式，進(jìn)一步優(yōu)化 PinalyticsDB 協(xié)處理器的性能。我們的優(yōu)化舉措使得區(qū)域服務(wù)器 CPU 利用率、RPC 延遲以及 JVM 線程阻塞情況都得到顯著改善。

我們的原始設(shè)計會針對發(fā)送至 PinalyticsDB 內(nèi)每一項指標(biāo)的對應(yīng)請求創(chuàng)建 Hbase 掃描。Pinalytics 會持續(xù)收到大量同類請求，從而引發(fā)大量掃描操作。通過將與同一報表及指標(biāo)相關(guān)的聚合請求合并起來，并對與所請求段相關(guān)的 FuzzyRowFilter 進(jìn)行單一掃描，我們顯著減少了實際產(chǎn)生的 Hbase 掃描次數(shù)。

在使用 Pinalytics 時，用戶通過會發(fā)出大批量請求，這些請求當(dāng)中包含的不同細(xì)份指標(biāo)往往數(shù)量有限。下圖所示為跨美國多個州段請求某一樣本指標(biāo)。

 

 

這是一類非常常見的用例。相當(dāng)一部分用戶使用的儀表板中都包含這類圖表。

在這個用例的啟發(fā)下，我們嘗試進(jìn)行“多細(xì)分優(yōu)化”，即利用協(xié)處理器對與同一指標(biāo)相關(guān)聯(lián)的 PinalyticsRequest 中的所有細(xì)分執(zhí)行一次掃描(每區(qū)域 salt)。

PinalyticsDB V2 韓國人協(xié)處理器設(shè)計

Pinalytics Thrift Server 將來自 Pinalytics 的全部請求按指標(biāo)進(jìn)行分組。接下來，協(xié)處理器會針對各個指標(biāo)接收一條請求，其中包含與該指標(biāo)相關(guān)的所有段 FuzzyRowFilters。

對于該協(xié)處理器區(qū)域內(nèi)的各 salt，協(xié)處理器會創(chuàng)建一條 MUST_PASS_ONE 掃描，并在單一 FilterList 的聚合請求中包含所有 FuzzyRowFilters。

該協(xié)處理器隨后按照日期與 FuzzyRowFilter 對所有掃描結(jié)合進(jìn)行聚合，并將響應(yīng)結(jié)果發(fā)送回 Thrift Server。

這意味著無論存在多少指向特定指標(biāo)的不同段組合請求，我們都只需要處理一條指向該指標(biāo)的聚合請求。

 

 

PinalyticsDB V2 協(xié)處理器設(shè)計：對于每種 salt，都只需要對指向同一指標(biāo)的所有段創(chuàng)建一次掃描。

這一全新協(xié)處理器設(shè)計顯著改善了區(qū)域服務(wù)器的 CPU 利用率、RPC 延遲以及 JVM 線程阻塞情況。

注意：下圖所示為部署多段優(yōu)化數(shù)小時后得到的捕捉結(jié)果，因此無法準(zhǔn)確反映系統(tǒng)的當(dāng)前性能。但總體來看，這些設(shè)計舉措仍然有助于提高協(xié)處理器的性能表現(xiàn)。

 

 

在部署新的協(xié)處理器后，區(qū)域服務(wù)器 CPU 利用率得到改善。

 

 

部署新的協(xié)處理器之后，區(qū)域服務(wù)器 JVM 線程阻塞情況得到改善。

 

 

部署新的協(xié)處理器之后，區(qū)域服務(wù)器 RPG 延遲得到改善。

大型報表元數(shù)據(jù)與 Thrift Server OOM

我們的 Thrift Server 還存在 OOM 頻繁崩潰的問題，如果這時用戶嘗試加載相關(guān)圖表，那么就會發(fā)生 Web 應(yīng)用程序超時的狀況。這是因為 Thrift Server 的 jvm 沒有設(shè)置 XX:+ExitOnOutOfMemoryError，因此 Thrift Server 無法退出 OOM，而繼續(xù)調(diào)用只能產(chǎn)生超時�？焖俚慕鉀Q辦法是添加 XX:+ExitOnOutOfMemoryError 標(biāo)記，以便在 OOM 生產(chǎn) Thrift Server 上自動進(jìn)行重啟。

為了調(diào)試這個問題，我們將 jconsole 指向其中一臺生產(chǎn) Thrift Server，使其夠捕捉到其他 Thrift Server 的崩潰情況。以下圖表所示為總 heap、上一代與新一代架構(gòu)的運(yùn)行情況。

 

 

Thrift Server 的總 heap 內(nèi)存為 8G。

請注意，內(nèi)存使用量從低于 4G 突然提升至 8G 以上，引發(fā)問題的根源正是 OOM。

 

 

用于 PinalyticsDB Thrift Server 的上一代 CMS。

同樣的，舊一代架構(gòu)的內(nèi)存使用量會突然猛增至 4G 以上，直接超出了系統(tǒng)極限。峰值出現(xiàn)得太快，CMS 收集器根本無暇介入，甚至連 full GC 都來不及出現(xiàn)。

 

 

用于 PinalyticsDB Thrift Server 的 Eden 空間。

我們通過負(fù)載測試在開發(fā)環(huán)境當(dāng)中重現(xiàn)這類問題，并最終確定問題根源與我們的報表元數(shù)據(jù)存儲與讀取機(jī)制有關(guān)。對于大部分報表而言，元數(shù)據(jù)一般僅為數(shù) KB。但對于某些大型報表，元數(shù)據(jù)可能超過 60 MB，甚至高達(dá) 120 MB。這是因為此類報表中可能包含大量指標(biāo)。

報表元數(shù)據(jù)結(jié)構(gòu)

以下為單一報表中的元數(shù)據(jù)。報表元數(shù)據(jù)存儲在一個專門的二級索引表當(dāng)中。

#!/usr/bin/python
# -*- coding: utf-8 -*-
ReportInfo(
tableName=u’growth_ResurrectionSegmentedReport’,
reportName=u’growth_ResurrectionSegmentedReport’,
segInfo={
u’segKey2': u’gender’,
u’segKey1': u’country’,
u’segKeyNum’: u’2',
},
metrics={u’resurrection’: MetricMetadata(name=u’resurrection’,
valueNames=None),
u’5min_resurrection’:MetricMetadata(name=u’5min_resurrection’
, valueNames=None)},
segKeys={
1: {
u’1': u’US’,
u’2': u’UK’,
u’3': u’CA’,
…
}
)

 

 

優(yōu)化表元數(shù)據(jù)的存儲與檢索使用

報表元數(shù)據(jù)以序列化 blob 的形式存儲在 HBase 的二次索引表中。因此，可以判斷問題的根源在于報表元數(shù)據(jù)的體量太大，而我們每次都在加載完整元數(shù)據(jù)——而非僅加載我們需要使用的部分。在高負(fù)載情況下，jvm leap 可能會很快被填滿，導(dǎo)致 jvm 無法處理洶涌而來的 full GC。

為了從根本上解決問題，我們決定將報表元數(shù)據(jù)內(nèi)容分發(fā)至報表行鍵下的多個列族與限定符當(dāng)中。

 

 

經(jīng)過增強(qiáng)的 PinalyticsDB V2 報表行鍵結(jié)構(gòu)，分布在多個列族與限定符之間。

行鍵采用原子更新，因此所有列族都將在單一 PUT 操作時以原子化方式更新。

我們還創(chuàng)建了一種新的 report-info 獲取方法。

getReportInfo(final String siTableName, final String reportName, List<String> metrics)

此方法會返回所有 seg-info 與 seg-keys 數(shù)據(jù)，且僅返回“metrics”列族中的相關(guān)指標(biāo)數(shù)據(jù)。由于報表的大部分內(nèi)容基于指標(biāo)數(shù)據(jù)，因此我們只需要返回幾 kb 數(shù)據(jù)，而非完整的 100 mb 以上數(shù)據(jù)。

Thrift Server 輪循池

我們還對 Thrift Server 做出另一項變更，旨在實現(xiàn)可擴(kuò)展性。每個 Thrift Server 都具有 hbase org.apache.hadoop.hbase.client.Connection 的單一實例。

hbase.client.ipc.pool.size=5
hbase.client.ipc.pool.type=RoundRobinPool

每個區(qū)域服務(wù)器默認(rèn)只擁有 1 個連接。這樣的設(shè)置增加了并發(fā)連接數(shù)，且有助于我們進(jìn)一步擴(kuò)展每個服務(wù)器的請求數(shù)量。

缺點(diǎn)與局限

通過以上設(shè)計，我們的業(yè)務(wù)體系運(yùn)行得更為順暢。但我們也意識到，其中仍存在一定局限性。

雖然橫向擴(kuò)展架構(gòu)帶來了均勻的讀取寫入分布，但卻會對可用性造成影響。例如：任何區(qū)域服務(wù)器或者 Zookeeper 問題，都會影響到全部讀取與寫入請求。我們正在設(shè)置一套具有雙向復(fù)制能力的備份集群，從而在主集群發(fā)生任何問題時實現(xiàn)讀寫機(jī)制的自動故障轉(zhuǎn)移。

由于各個段屬于行鍵的一部分，因此包含多個段的報表必然占用更多磁盤存儲空間。在創(chuàng)建報表后，我們也無法對報表內(nèi)的細(xì)分內(nèi)容進(jìn)行添加或刪除。此外，盡管能夠快速轉(zhuǎn)發(fā) FuzzyRowwFilter，但對于基數(shù)很高的報表及大量數(shù)據(jù)而言，整個過程仍然非常緩慢。相信通過在協(xié)處理器中添加并發(fā)機(jī)制，從而并發(fā)執(zhí)行對每種 salt 的掃描(甚至按日期進(jìn)行分區(qū)掃描)，能夠有效解決這個問題。

這套架構(gòu)利用協(xié)處理器執(zhí)行讀取，但不支持利用協(xié)處理器復(fù)制讀取內(nèi)容。接下來，我們可以通過將結(jié)果存儲在高可用性表中實現(xiàn)對緩存層的聚合，從而在一定程度上彌補(bǔ)這種協(xié)處理器復(fù)制能力缺失問題。另外，我們還會在無法從主區(qū)域處讀取數(shù)據(jù)時，執(zhí)行副本讀取操作(利用常規(guī) Hbase 掃描，不涉及協(xié)處理器)。

我們計劃在下一次迭代當(dāng)中解決一部分局限性問題。此外，我們還計劃添加對前 N 項、百分位、按…分組以及 min/max 等函數(shù)的支持。

鳴謝:

感謝 Rob Claire、Chunyan Wang、Justin Mejorada-Pier 以及 Bryant Xiao 為 PinalyticsDB 支持工作做出的貢獻(xiàn)。同樣感謝分析平臺與存儲 / 緩存團(tuán)隊為 Pinalytics Web 應(yīng)用以及 HBase 集群提供的寶貴支持。

原文鏈接：

https://medium.com/pinterest-engineering/pinalyticsdb-a-time-series-database-on-top-of-hbase-946f236bb29a

標(biāo)簽： HBase 時間序列數(shù)據(jù) 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。