勿談大，且看Bloomberg的中數(shù)據(jù)處理平臺(tái)

摘要：中數(shù)據(jù)意味著數(shù)據(jù)體積已經(jīng)超越單服務(wù)器處理的上限，但也無需使用數(shù)千臺(tái)節(jié)點(diǎn)組成的集群——通常是TB級(jí)，而不是PB級(jí)的。這里，我們不妨走進(jìn)Bloomberg的用例，著眼時(shí)間序列數(shù)據(jù)處理上的數(shù)據(jù)和體積挑戰(zhàn)。

中數(shù)據(jù)意味著數(shù)據(jù)體積已經(jīng)超越單服務(wù)器處理的上限，但也無需使用數(shù)千臺(tái)節(jié)點(diǎn)組成的集群——通常是TB級(jí)，而不是PB級(jí)的。這里，我們不妨走進(jìn)Bloomberg的用例，著眼時(shí)間序列數(shù)據(jù)處理上的數(shù)據(jù)和體積挑戰(zhàn)。

以下為譯文

在Bloomberg，我們并不存在大數(shù)據(jù)挑戰(zhàn)。取而代之，系統(tǒng)正在遭遇“中數(shù)據(jù)（Medium?data）”的威脅，而當(dāng)下許多行業(yè)的機(jī)構(gòu)基本上都面臨著這種威脅。對(duì)Bloomberg來說，在企業(yè)級(jí)低延時(shí)場(chǎng)景下，Hadoop和Spark這樣的系統(tǒng)既沒有效率，也難以維護(hù)。時(shí)至今日，高核心數(shù)、SSD以及海量?jī)?nèi)存已并不稀奇，但是當(dāng)下的大數(shù)據(jù)平臺(tái)（通過搭建商用服務(wù)器集群）卻并不能完全利用這些硬件的優(yōu)勢(shì)，存在的挑戰(zhàn)也不可謂不大。同時(shí)，當(dāng)下很多分布式組件也深受Java的影響，很難達(dá)到預(yù)期的低延時(shí)性能。

一個(gè)實(shí)際用例

債券時(shí)間序列數(shù)據(jù)通常包括一個(gè)債券（比如IBM）、一個(gè)字段（比如price）、一個(gè)時(shí)間和一個(gè)值。

通常情況下，數(shù)據(jù)會(huì)被拆分成兩個(gè)部分：當(dāng)天數(shù)據(jù)和歷史數(shù)據(jù)——處理當(dāng)天數(shù)據(jù)的系統(tǒng)通常會(huì)捕獲一天中的所有行為，而處理歷史數(shù)據(jù)的系統(tǒng)需要負(fù)責(zé)前一段時(shí)間所積累的數(shù)據(jù)。在過去，統(tǒng)一這兩種數(shù)據(jù)是不可能實(shí)現(xiàn)的，因?yàn)樗麄冇兄煌男阅苄枨?#xff1a;當(dāng)天數(shù)據(jù)的處理系統(tǒng)必須可以承受大量的寫入操作，而歷史數(shù)據(jù)處理系統(tǒng)通常是每天一次的批量更新，但是數(shù)據(jù)體積更大，而且搜索次數(shù)也更多。

在債券時(shí)間序列數(shù)據(jù)上，在總量為一年的數(shù)據(jù)上，某個(gè)字段的響應(yīng)時(shí)間需要控制在5毫秒。同時(shí)，這些數(shù)據(jù)每天會(huì)被訪問數(shù)十億次，峰值期間大約50萬每秒。對(duì)于Bloomberg來說，這個(gè)系統(tǒng)非常重要，一旦發(fā)生故障，很可能就會(huì)擾亂到資本市場(chǎng)。

問題隨之而來，類似Portfolio?Analytics等應(yīng)用往往會(huì)同時(shí)需求大量的數(shù)據(jù)。一個(gè)債券組合很可能包括數(shù)以萬計(jì)的債券，而類似歸因（attribution）這種計(jì)算往往需要每個(gè)源每天40個(gè)字段的數(shù)據(jù)。從而，在多年數(shù)據(jù)上計(jì)算一個(gè)債券組合的歸因需要上千萬的數(shù)據(jù)點(diǎn)（datapoint）。因此，即使在命中率為99.9%的高效緩存中，仍然存在大量緩存未命中的情況。這樣一來，如果底層系統(tǒng)使用磁盤介質(zhì)的話，這個(gè)操作往往會(huì)造成成千上萬的磁盤尋道。同時(shí)，基于用戶的數(shù)量，系統(tǒng)中存在著大量的請(qǐng)求。因此，不難想象，這會(huì)給現(xiàn)有價(jià)格歷史系統(tǒng)造成什么樣的挑戰(zhàn)。

數(shù)年前，解決這個(gè)問題的途徑是將一切都放到內(nèi)存和固態(tài)硬盤上，同時(shí)將高度壓縮的blobs分割到多個(gè)數(shù)據(jù)庫(kù)中。這是一個(gè)巨大的飛躍，系統(tǒng)速度提升了2到3個(gè)數(shù)量級(jí)，然而這并不是我們想要的——跨多數(shù)據(jù)庫(kù)壓縮blobs分割是非常麻煩的。

時(shí)間序列數(shù)據(jù)通常會(huì)轉(zhuǎn)化為非常極端的并行問題，往往會(huì)出現(xiàn)這樣一個(gè)情況：當(dāng)為一個(gè)組合取數(shù)以千萬計(jì)的數(shù)據(jù)點(diǎn)時(shí)，工作可以根據(jù)需求被任意拆分到數(shù)以千萬的主機(jī)上。這樣看來，并行似乎是最好的解決方案。而在單主表的分布式處理上，理論中HBase應(yīng)該是個(gè)非常契合的計(jì)算框架。

當(dāng)然從理論上講，理論和實(shí)踐應(yīng)該是一致的，然而在實(shí)踐中往往并不是一直如此。數(shù)據(jù)集確實(shí)可以達(dá)到一定的效果，但是在性能、效率、期滿及彈性上都存在一定的障礙。這樣一來，問題就在于如何移除這些障礙。

當(dāng)一個(gè)節(jié)點(diǎn)發(fā)生故障后，數(shù)據(jù)并不會(huì)丟失——因?yàn)閿?shù)據(jù)已經(jīng)通過HDFS備份到多個(gè)節(jié)點(diǎn)上。但是這里仍然存在一個(gè)非常大的缺點(diǎn)，在任何給定時(shí)間，到給定region的讀寫操作只被一個(gè)region服務(wù)器控制。如果這個(gè)region掛掉，故障將會(huì)被發(fā)現(xiàn)，故障轉(zhuǎn)移會(huì)自動(dòng)的進(jìn)行。但是，直到這個(gè)故障被處理前，它負(fù)責(zé)的任何讀寫都不可能繼續(xù)進(jìn)行。

在故障轉(zhuǎn)移上，HBase社區(qū)的發(fā)展可以說是日新月異，需求的時(shí)間也是愈來愈少，但是這里仍然存在一個(gè)巨大的漏洞。分布式系統(tǒng)中的故障往往通過設(shè)置期滿判定，通過心跳或者其他機(jī)制來感知。這樣一來，如果超時(shí)被設(shè)置的太短，很可能就會(huì)產(chǎn)生誤報(bào)，但是如果時(shí)間被設(shè)置太長(zhǎng)，則會(huì)造成更長(zhǎng)時(shí)間的不可用。

在Bloomberg用例下，SLA是毫秒級(jí)的。但是，超時(shí)的設(shè)置卻是秒級(jí)的，這樣一來，即使故障被偵測(cè)后的處理時(shí)間無限接近于0，HBase故障轉(zhuǎn)移所造成的延時(shí)完全不可行。

在與多個(gè)Hadoop提供商交流后，我們也得到了幾個(gè)可行的解決方案，其中大部分是通過給數(shù)據(jù)庫(kù)做多個(gè)備份來解決問題。鑒于Bloomberg系統(tǒng)可以應(yīng)對(duì)整個(gè)數(shù)據(jù)中心丟失的大方針，使用這個(gè)途徑無疑需要給每個(gè)數(shù)據(jù)庫(kù)配置多個(gè)同時(shí)運(yùn)行的副本，在我們看來這么做太復(fù)雜了。最終，我們對(duì)這個(gè)替代方案并不滿意，并決定嘗試修改。

如果故障轉(zhuǎn)移檢測(cè)和恢復(fù)過程不能被加速，那么某個(gè)region服務(wù)器發(fā)生故障后，這里必須存在可以立刻被查詢的備用節(jié)點(diǎn)。根據(jù)這個(gè)思路，我們擬定了短期解決方案：數(shù)據(jù)必須在多個(gè)不同的地方進(jìn)行存儲(chǔ)，雖然在傳輸上可能會(huì)存在一定的延時(shí)，但是在這種存在大量批處理更新場(chǎng)景的類似價(jià)格歷史日結(jié)系統(tǒng)中卻完全可行——在備用region服務(wù)器上使用這個(gè)策略可以保證事件接收的順序，提供了時(shí)間序列上的一致性，即使延時(shí)很高。

時(shí)間序列一致性備份region服務(wù)器被作為JIRA-10070的一部分添加到HBase中。

結(jié)論和下一步

除下故障轉(zhuǎn)移，HBase還存在大量其他的問題。仔細(xì)地檢查了瓶頸的來源，進(jìn)行了大量的優(yōu)化后（比如使用同步垃圾回收機(jī)制），系統(tǒng)性能得到了顯著提升：

• PORT寫入性能提升1000倍
• Read檢索速度較之前提升3倍

通過HBase實(shí)驗(yàn)，我們將運(yùn)行時(shí)響應(yīng)時(shí)間縮短到原來的四分之一，并為將來提升留下了足夠的發(fā)展空間。同時(shí)，更快的機(jī)器也有利于縮短響應(yīng)時(shí)間。通過使用開源平臺(tái)，我們認(rèn)真思索來自多個(gè)提供商的意見，在中型數(shù)據(jù)處理上，我們可以看到很大的發(fā)展空間。

更重要的是，我們的收獲不只是性能一個(gè)特性，我們更可以通過開源技術(shù)連接到一個(gè)更廣泛的發(fā)展空間。

附錄：HBase分配圖解

性能1：分布和并行

性能2：同址計(jì)算

即使故障得以解決，在原始性能和一致性上仍然存在問題，這里我們將詳述性能上的3個(gè)實(shí)驗(yàn)和結(jié)果。實(shí)驗(yàn)應(yīng)用在一個(gè)合適的集群上，擁有11臺(tái)搭載SSD的主機(jī)，每臺(tái)主機(jī)配備了兩個(gè)志強(qiáng)E5處理器以及128GB內(nèi)存。在講義的右上角顯示了兩個(gè)數(shù)字，第一個(gè)是實(shí)驗(yàn)初始時(shí)的平均響應(yīng)時(shí)間，另一個(gè)則是進(jìn)行改進(jìn)后的響應(yīng)時(shí)間，平均請(qǐng)求時(shí)間來自20萬個(gè)記錄上做隨機(jī)的鍵值查詢。

使用HBase，用戶可以在大的Portfolio文件上做拆分，并且分配到集群中的多個(gè)主機(jī)上進(jìn)行處理。這也是為什么要托管備用的region服務(wù)器以應(yīng)對(duì)故障——如果請(qǐng)求發(fā)送到每個(gè)服務(wù)器，其中一個(gè)服務(wù)器在1分鐘或者更多的時(shí)間內(nèi)沒有反應(yīng)，很明顯這個(gè)服務(wù)器已經(jīng)出現(xiàn)問題，一個(gè)服務(wù)器產(chǎn)生故障將拖累集群中所有作業(yè)的處理時(shí)間。

因此，下一個(gè)需要著重對(duì)待的就是分配和并行。第一個(gè)工作就是如何平均的將作業(yè)拆分：在一個(gè)指定的大數(shù)據(jù)集上，集群中每臺(tái)機(jī)器獲得的chunk大小都是相同的？理想狀態(tài)中，對(duì)1000行的數(shù)據(jù)進(jìn)行拆分，每臺(tái)服務(wù)器都應(yīng)該獲得100行。然而在一個(gè)簡(jiǎn)單的架構(gòu)中，這點(diǎn)根本無法實(shí)現(xiàn)：如果原始鍵是債券名+XXX，那么所有IBM債券將放在同一個(gè)region中，同時(shí)，IBM將比其他債券更經(jīng)常得到訪問，這種現(xiàn)象也被稱為hotspotting。

解決方案是使用HBase提供的特性來彌補(bǔ)。HBase中的數(shù)據(jù)總會(huì)通過原始鍵進(jìn)行物理劃分，如果原始鍵本身已經(jīng)被哈希，同時(shí)這種哈希被作為一個(gè)前綴，隨后行則會(huì)以不同的方式進(jìn)行分配。想象一下，如果原始鍵是security+year+month+field，取它的MD5，并將之作為一個(gè)前綴，那么IBM這個(gè)債券分配到任何服務(wù)器上的可能性都會(huì)相同。

在一個(gè)完美的分配中，我們將獲得一個(gè)完美的并行性：集群中11個(gè)節(jié)點(diǎn)都會(huì)做相同數(shù)量的作業(yè)。每個(gè)工作不只是負(fù)責(zé)相同的工作量，在每個(gè)請(qǐng)求上也會(huì)同樣平均。毫無疑問，這里需要做的是盡可能地提升系統(tǒng)并行性。

解決這個(gè)問題的一個(gè)方法就是在每臺(tái)主機(jī)上運(yùn)行盡量多的region服務(wù)器，因此需要盡量提升主機(jī)的性能。這將提升總的region服務(wù)器數(shù)量，從而提升并行性的等級(jí)，隨之顯著的減少響應(yīng)時(shí)間。

講義中的圖表顯示了這個(gè)實(shí)驗(yàn)的結(jié)果。如果11臺(tái)服務(wù)器上每個(gè)只搭建一個(gè)region，總計(jì)11個(gè)，平均響應(yīng)時(shí)間是260毫秒。當(dāng)region數(shù)量提升到每臺(tái)主機(jī)3個(gè)時(shí)，也就是總計(jì)33臺(tái)主機(jī)，平均響應(yīng)時(shí)間將下降到185毫秒。每臺(tái)主機(jī)上5個(gè)region服務(wù)器將提升到160毫秒。但是如果每臺(tái)主機(jī)上的region服務(wù)器提升到10個(gè)時(shí)，響應(yīng)時(shí)間反而會(huì)提高，為什么？

出現(xiàn)這種問題后，首先想到的可能就是負(fù)載是否超過了服務(wù)器的性能；每臺(tái)服務(wù)器同時(shí)運(yùn)行10個(gè)region服務(wù)器進(jìn)程，每個(gè)都擁有多個(gè)線程，顯然核心數(shù)量會(huì)不足。但是，根據(jù)研究，這個(gè)并還不足以作為影響系統(tǒng)的原因，真實(shí)的答案非常有意思，但是在揭開它之前，我們先看一下同址計(jì)算。

大數(shù)據(jù)的原理之一就是讓計(jì)算盡可能的靠近數(shù)據(jù)，這么做的理由非常簡(jiǎn)單。舉個(gè)例子，如果你想知道一個(gè)大數(shù)據(jù)集表格中究竟有多少行，你可能需要將每一行都取到本地客戶端，然后循環(huán)訪問并進(jìn)行計(jì)算，如果使用的是傳統(tǒng)數(shù)據(jù)庫(kù)環(huán)境，你還可以使用“select?count(*)?from…”，后者顯然是更加有效的。

說永遠(yuǎn)比做容易。許多問題使用這個(gè)途徑是無法解決的，即使在許多已知的情況下，許多框架都會(huì)出現(xiàn)問題。在海量數(shù)據(jù)分析上，2013年National?Research?Council（國(guó)家研究委員會(huì)）提出了7個(gè)大型并行計(jì)算問題，希望對(duì)分布式計(jì)算系統(tǒng)進(jìn)行良好的分類，比較有意思的是，根據(jù)測(cè)算結(jié)果，Hadoop并不適合所有類型。

幸運(yùn)的是，我們有一個(gè)簡(jiǎn)單的可用的用例，它可以再次減半響應(yīng)時(shí)間。

現(xiàn)在的情況是，這里有數(shù)據(jù)的多個(gè)源，Barclays、Merrill?Lynch和多個(gè)公司都提供了債券計(jì)價(jià)數(shù)據(jù)。相同債券同一天的數(shù)據(jù)也可能出現(xiàn)在其他源中，但是價(jià)格可能不一致。每個(gè)客戶有不同的優(yōu)先順序，每個(gè)請(qǐng)求都包含了某個(gè)源應(yīng)該用在某個(gè)訂單的順序。嘗試從第一個(gè)數(shù)據(jù)源中獲取所有數(shù)據(jù)，如果發(fā)現(xiàn)丟失，則會(huì)嘗試下一個(gè)源。通常情況下，發(fā)現(xiàn)所有數(shù)據(jù)需要訪問5個(gè)這樣的數(shù)據(jù)源。

在分離數(shù)據(jù)庫(kù)世界中，不同的源都處于不同的地理位置中，這就意味著嘗試第一個(gè)數(shù)據(jù)庫(kù)，取得所有的數(shù)據(jù)，查詢丟失了什么，構(gòu)成一個(gè)新的請(qǐng)求，并發(fā)布下一個(gè)任務(wù)。

對(duì)于HBase，我們?nèi)匀豢梢垣@得物理分類的優(yōu)勢(shì)，支持上千萬列，并通過協(xié)同處理器進(jìn)行同址計(jì)算。

通過將源和字段列與security和date整合，它們將被混搭在相同的region服務(wù)器上?。協(xié)同處理器的邏輯將變?yōu)椤盀橹付ㄐ邪l(fā)現(xiàn)第一個(gè)源，并進(jìn)行security和date匹配”。

在一個(gè)只包含一些行的小協(xié)同處理器上，平均響應(yīng)時(shí)間將降到85毫秒。

性能3：同步中斷

繼續(xù)上文的話題，增加region服務(wù)器數(shù)量降低性能給我們留下的謎題：為什么響應(yīng)時(shí)間在開始時(shí)有改善，而隨后則會(huì)變得更糟糕？問題的答案涉及到兩個(gè)方面——Java和所有高fan?out分布式系統(tǒng)一些常見的問題。

一個(gè)涉及到不止1個(gè)fan?out的請(qǐng)求中，服務(wù)器訪問越高，fan?out的程度就越高。那么，在一個(gè)有fan?out的請(qǐng)求中，響應(yīng)時(shí)間該如何計(jì)算？

答案就是，響應(yīng)的時(shí)間由最慢的反應(yīng)者決定，當(dāng)給11臺(tái)主機(jī)每個(gè)都配備10個(gè)region服務(wù)器時(shí)，每個(gè)請(qǐng)求需要fan?out?110個(gè)進(jìn)程。如果其中109個(gè)是1毫秒完成，1個(gè)請(qǐng)求是170毫秒，那么響應(yīng)時(shí)間將高達(dá)170毫秒。

這里的罪魁禍?zhǔn)缀翢o疑問就是Java的垃圾回收機(jī)制，它會(huì)凍結(jié)一個(gè)機(jī)器直到回收結(jié)束。Fan-out的程度越高，其中一個(gè)region服務(wù)器在做垃圾回收的可能性就越大。當(dāng)region數(shù)量達(dá)到110個(gè)時(shí)，可能性已經(jīng)開始接近1。

這里的解決方案非常的簡(jiǎn)單。既然在垃圾回收過程中所有的服務(wù)器都會(huì)被凍結(jié)，那么為什么不讓這些region服務(wù)器同時(shí)做垃圾回收？這種情況下，請(qǐng)求將需要更多的時(shí)間，但是毫無疑問的是，在處理的過程中，沒有region服務(wù)器會(huì)做垃圾回收。為此，我們編寫了不能再簡(jiǎn)單的代碼進(jìn)行測(cè)試——system.gc()以及30秒會(huì)調(diào)用一次這個(gè)方法的定時(shí)器。

通過這個(gè)操作，我們首次將相應(yīng)時(shí)間從85毫秒降低到60毫秒。

Java垃圾回收機(jī)制這個(gè)詬病已經(jīng)被廣泛認(rèn)知，這也是Jeff?Dean歸納為Synchronized?Disruption中的一個(gè)問題。任何并行系統(tǒng)中的請(qǐng)求都需要遭受最慢者的摧殘，因此影響個(gè)體機(jī)器的問題將同時(shí)影響到整個(gè)系統(tǒng)。想獲得更多詳情，推薦閱讀“Achieving?Rapid?Response?Times?in?Large?Online?Services”，你將獲得更多關(guān)于高fan?out計(jì)算系統(tǒng)的使用經(jīng)驗(yàn)。

這就意味著，Java當(dāng)下已經(jīng)成為很多高fan?out計(jì)算系統(tǒng)的基礎(chǔ)，其中包括Hadoop、HBase、Spark、SOLR等，同步進(jìn)行垃圾回收將解決非常大的問題。

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的勿谈大，且看Bloomberg的中数据处理平台的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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