作者：Pinterest Engineering 來(lái)源：InfoQ

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

 

 

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

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

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

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

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

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

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

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

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

后綴 = 由段號(hào)組成

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

這套方案存在以下幾個(gè)問(wèn)題：

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

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

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

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

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

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

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

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

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

 

 

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

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

對(duì)讀取與寫(xiě)入操作的影響

 

 

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

 

 

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

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

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

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

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

 

 

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

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

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

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

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

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

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

 

 

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

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

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

 

 

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

 

 

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

 

 

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

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

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

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

 

 

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

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

 

 

用于 PinalyticsDB Thrift Server 的上一代 CMS。

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

 

 

用于 PinalyticsDB Thrift Server 的 Eden 空間。

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

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

以下為單一報(bào)表中的元數(shù)據(jù)。報(bào)表元數(shù)據(jù)存儲(chǔ)在一個(gè)專(zhuān)門(mén)的二級(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ù)的存儲(chǔ)與檢索使用

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

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

 

 

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

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

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

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

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

Thrift Server 輪循池

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

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

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

缺點(diǎn)與局限

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

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

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

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

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

鳴謝:

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

原文鏈接：

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

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

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