作者：Pinterest Engineering 來源：InfoQ

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

 

 

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

過去幾個月以來，我們著手對 PinalyticsDB 進行重構，希望進一步提高其性能與可靠性水平。在本文中，我們將共同了解 Pinterest 面臨的性能與可擴展性挑戰(zhàn)，以及我們如何通過服務的重新設計構建出更為強大的 PinalyticsDB 新形態(tài)。

Hbase 區(qū)域服務器熱點

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

原有架構設計

原本的行鍵設計方案為：

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

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

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

后綴 = 由段號組成

行鍵由 ASCII 字符表示，其中“|”充當分隔符。

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

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

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

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

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

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

新的架構設計

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

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

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

 

 

鍵內的各個部分都有固定的長度，作為定義行鍵的固定結構，同時也支持模糊行過濾器。

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

對讀取與寫入操作的影響

 

 

Pinalytics DB V2 讀取架構

 

 

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

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

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

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

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

 

 

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

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

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

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

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

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

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

 

 

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

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

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

 

 

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

 

 

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

 

 

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

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

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

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

 

 

Thrift Server 的總 heap 內存為 8G。

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

 

 

用于 PinalyticsDB Thrift Server 的上一代 CMS。

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

 

 

用于 PinalyticsDB Thrift Server 的 Eden 空間。

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

報表元數(shù)據(jù)結構

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

#!/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ù)——而非僅加載我們需要使用的部分。在高負載情況下，jvm leap 可能會很快被填滿，導致 jvm 無法處理洶涌而來的 full GC。

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

 

 

經過增強的 PinalyticsDB V2 報表行鍵結構，分布在多個列族與限定符之間。

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

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

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

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

Thrift Server 輪循池

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

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

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

缺點與局限

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

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

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

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

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

鳴謝:

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

原文鏈接：

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

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

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