- 論壇徽章:
- 6
|
中數(shù)據(jù)意味著數(shù)據(jù)體積已經(jīng)超越單服務(wù)器處理的上限，但也無需使用數(shù)千臺節(jié)點組成的集群——通常是TB級，而不是PB級的。這里，我們不妨走進(jìn)Bloomberg的用例，著眼時間序列數(shù)據(jù)處理上的數(shù)據(jù)和體積挑戰(zhàn)。
以下為譯文
在Bloomberg，我們并不存在大數(shù)據(jù)挑戰(zhàn)。取而代之，系統(tǒng)正在遭遇“中數(shù)據(jù)（Medium data）”的威脅，而當(dāng)下許多行業(yè)的機構(gòu)基本上都面臨著這種威脅。對Bloomberg來說，在企業(yè)級低延時場景下，Hadoop和Spark這樣的系統(tǒng)既沒有效率，也難以維護。時至今日，高核心數(shù)、SSD以及海量內(nèi)存已并不稀奇，但是當(dāng)下的大數(shù)據(jù)平臺（通過搭建商用服務(wù)器集群）卻并不能完全利用這些硬件的優(yōu)勢，存在的挑戰(zhàn)也不可謂不大。同時，當(dāng)下很多分布式組件也深受Java的影響，很難達(dá)到預(yù)期的低延時性能。
一個實際用例
債券時間序列數(shù)據(jù)通常包括一個債券（比如IBM）、一個字段（比如price）、一個時間和一個值。
通常情況下，數(shù)據(jù)會被拆分成兩個部分：當(dāng)天數(shù)據(jù)和歷史數(shù)據(jù)——處理當(dāng)天數(shù)據(jù)的系統(tǒng)通常會捕獲一天中的所有行為，而處理歷史數(shù)據(jù)的系統(tǒng)需要負(fù)責(zé)前一段時間所積累的數(shù)據(jù)。在過去，統(tǒng)一這兩種數(shù)據(jù)是不可能實現(xiàn)的，因為他們有著不同的性能需求：當(dāng)天數(shù)據(jù)的處理系統(tǒng)必須可以承受大量的寫入操作，而歷史數(shù)據(jù)處理系統(tǒng)通常是每天一次的批量更新，但是數(shù)據(jù)體積更大，而且搜索次數(shù)也更多。
在債券時間序列數(shù)據(jù)上，在總量為一年的數(shù)據(jù)上，某個字段的響應(yīng)時間需要控制在5毫秒。同時，這些數(shù)據(jù)每天會被訪問數(shù)十億次，峰值期間大約50萬每秒。對于Bloomberg來說，這個系統(tǒng)非常重要，一旦發(fā)生故障，很可能就會擾亂到資本市場。
問題隨之而來，類似Portfolio Analytics等應(yīng)用往往會同時需求大量的數(shù)據(jù)。一個債券組合很可能包括數(shù)以萬計的債券，而類似歸因（attribution）這種計算往往需要每個源每天40個字段的數(shù)據(jù)。從而，在多年數(shù)據(jù)上計算一個債券組合的歸因需要上千萬的數(shù)據(jù)點（datapoint）。因此，即使在命中率為99.9%的高效緩存中，仍然存在大量緩存未命中的情況。這樣一來，如果底層系統(tǒng)使用磁盤介質(zhì)的話，這個操作往往會造成成千上萬的磁盤尋道。同時，基于用戶的數(shù)量，系統(tǒng)中存在著大量的請求。因此，不難想象，這會給現(xiàn)有價格歷史系統(tǒng)造成什么樣的挑戰(zhàn)。
數(shù)年前，解決這個問題的途徑是將一切都放到內(nèi)存和固態(tài)硬盤上，同時將高度壓縮的blobs分割到多個數(shù)據(jù)庫中。這是一個巨大的飛躍，系統(tǒng)速度提升了2到3個數(shù)量級，然而這并不是我們想要的——跨多數(shù)據(jù)庫壓縮blobs分割是非常麻煩的。
時間序列數(shù)據(jù)通常會轉(zhuǎn)化為非常極端的并行問題，往往會出現(xiàn)這樣一個情況：當(dāng)為一個組合取數(shù)以千萬計的數(shù)據(jù)點時，工作可以根據(jù)需求被任意拆分到數(shù)以千萬的主機上。這樣看來，并行似乎是最好的解決方案。而在單主表的分布式處理上，理論中HBase應(yīng)該是個非常契合的計算框架。
當(dāng)然從理論上講，理論和實踐應(yīng)該是一致的，然而在實踐中往往并不是一直如此。數(shù)據(jù)集確實可以達(dá)到一定的效果，但是在性能、效率、期滿及彈性上都存在一定的障礙。這樣一來，問題就在于如何移除這些障礙。
當(dāng)一個節(jié)點發(fā)生故障后，數(shù)據(jù)并不會丟失——因為數(shù)據(jù)已經(jīng)通過HDFS備份到多個節(jié)點上。但是這里仍然存在一個非常大的缺點，在任何給定時間，到給定region的讀寫操作只被一個region服務(wù)器控制。如果這個region掛掉，故障將會被發(fā)現(xiàn)，故障轉(zhuǎn)移會自動的進(jìn)行。但是，直到這個故障被處理前，它負(fù)責(zé)的任何讀寫都不可能繼續(xù)進(jìn)行。
在故障轉(zhuǎn)移上，HBase社區(qū)的發(fā)展可以說是日新月異，需求的時間也是愈來愈少，但是這里仍然存在一個巨大的漏洞。分布式系統(tǒng)中的故障往往通過設(shè)置期滿判定，通過心跳或者其他機制來感知。這樣一來，如果超時被設(shè)置的太短，很可能就會產(chǎn)生誤報，但是如果時間被設(shè)置太長，則會造成更長時間的不可用。
在Bloomberg用例下，SLA是毫秒級的。但是，超時的設(shè)置卻是秒級的，這樣一來，即使故障被偵測后的處理時間無限接近于0，HBase故障轉(zhuǎn)移所造成的延時完全不可行。
在與多個Hadoop提供商交流后，我們也得到了幾個可行的解決方案，其中大部分是通過給數(shù)據(jù)庫做多個備份來解決問題。鑒于Bloomberg系統(tǒng)可以應(yīng)對整個數(shù)據(jù)中心丟失的大方針，使用這個途徑無疑需要給每個數(shù)據(jù)庫配置多個同時運行的副本，在我們看來這么做太復(fù)雜了。最終，我們對這個替代方案并不滿意，并決定嘗試修改。
如果故障轉(zhuǎn)移檢測和恢復(fù)過程不能被加速，那么某個region服務(wù)器發(fā)生故障后，這里必須存在可以立刻被查詢的備用節(jié)點。根據(jù)這個思路，我們擬定了短期解決方案：數(shù)據(jù)必須在多個不同的地方進(jìn)行存儲，雖然在傳輸上可能會存在一定的延時，但是在這種存在大量批處理更新場景的類似價格歷史日結(jié)系統(tǒng)中卻完全可行——在備用region服務(wù)器上使用這個策略可以保證事件接收的順序，提供了時間序列上的一致性，即使延時很高。
時間序列一致性備份region服務(wù)器被作為JIRA-10070的一部分添加到HBase中。
結(jié)論和下一步
除下故障轉(zhuǎn)移，HBase還存在大量其他的問題。仔細(xì)地檢查了瓶頸的來源，進(jìn)行了大量的優(yōu)化后（比如使用同步垃圾回收機制），系統(tǒng)性能得到了顯著提升：
- PORT寫入性能提升1000倍
- Read檢索速度較之前提升3倍
通過HBase實驗，我們將運行時響應(yīng)時間縮短到原來的四分之一，并為將來提升留下了足夠的發(fā)展空間。同時，更快的機器也有利于縮短響應(yīng)時間。通過使用開源平臺，我們認(rèn)真思索來自多個提供商的意見，在中型數(shù)據(jù)處理上，我們可以看到很大的發(fā)展空間。
更重要的是，我們的收獲不只是性能一個特性，我們更可以通過開源技術(shù)連接到一個更廣泛的發(fā)展空間。
附錄：HBase分配圖解
性能1：分布和并行
性能2：同址計算
即使故障得以解決，在原始性能和一致性上仍然存在問題，這里我們將詳述性能上的3個實驗和結(jié)果。實驗應(yīng)用在一個合適的集群上，擁有11臺搭載SSD的主機，每臺主機配備了兩個志強E5處理器以及128GB內(nèi)存。在講義的右上角顯示了兩個數(shù)字，第一個是實驗初始時的平均響應(yīng)時間，另一個則是進(jìn)行改進(jìn)后的響應(yīng)時間，平均請求時間來自20萬個記錄上做隨機的鍵值查詢。
使用HBase，用戶可以在大的Portfolio文件上做拆分，并且分配到集群中的多個主機上進(jìn)行處理。這也是為什么要托管備用的region服務(wù)器以應(yīng)對故障——如果請求發(fā)送到每個服務(wù)器，其中一個服務(wù)器在1分鐘或者更多的時間內(nèi)沒有反應(yīng)，很明顯這個服務(wù)器已經(jīng)出現(xiàn)問題，一個服務(wù)器產(chǎn)生故障將拖累集群中所有作業(yè)的處理時間。
因此，下一個需要著重對待的就是分配和并行。第一個工作就是如何平均的將作業(yè)拆分：在一個指定的大數(shù)據(jù)集上，集群中每臺機器獲得的chunk大小都是相同的？理想狀態(tài)中，對1000行的數(shù)據(jù)進(jìn)行拆分，每臺服務(wù)器都應(yīng)該獲得100行。然而在一個簡單的架構(gòu)中，這點根本無法實現(xiàn)：如果原始鍵是債券名+XXX，那么所有IBM債券將放在同一個region中，同時，IBM將比其他債券更經(jīng)常得到訪問，這種現(xiàn)象也被稱為hotspotting。
解決方案是使用HBase提供的特性來彌補。HBase中的數(shù)據(jù)總會通過原始鍵進(jìn)行物理劃分，如果原始鍵本身已經(jīng)被哈希，同時這種哈希被作為一個前綴，隨后行則會以不同的方式進(jìn)行分配。想象一下，如果原始鍵是security+year+month+field，取它的MD5，并將之作為一個前綴，那么IBM這個債券分配到任何服務(wù)器上的可能性都會相同。
在一個完美的分配中，我們將獲得一個完美的并行性：集群中11個節(jié)點都會做相同數(shù)量的作業(yè)。每個工作不只是負(fù)責(zé)相同的工作量，在每個請求上也會同樣平均。毫無疑問，這里需要做的是盡可能地提升系統(tǒng)并行性。
解決這個問題的一個方法就是在每臺主機上運行盡量多的region服務(wù)器，因此需要盡量提升主機的性能。這將提升總的region服務(wù)器數(shù)量，從而提升并行性的等級，隨之顯著的減少響應(yīng)時間。
講義中的圖表顯示了這個實驗的結(jié)果。如果11臺服務(wù)器上每個只搭建一個region，總計11個，平均響應(yīng)時間是260毫秒。當(dāng)region數(shù)量提升到每臺主機3個時，也就是總計33臺主機，平均響應(yīng)時間將下降到185毫秒。每臺主機上5個region服務(wù)器將提升到160毫秒。但是如果每臺主機上的region服務(wù)器提升到10個時，響應(yīng)時間反而會提高，為什么？
出現(xiàn)這種問題后，首先想到的可能就是負(fù)載是否超過了服務(wù)器的性能；每臺服務(wù)器同時運行10個region服務(wù)器進(jìn)程，每個都擁有多個線程，顯然核心數(shù)量會不足。但是，根據(jù)研究，這個并還不足以作為影響系統(tǒng)的原因，真實的答案非常有意思，但是在揭開它之前，我們先看一下同址計算。
大數(shù)據(jù)的原理之一就是讓計算盡可能的靠近數(shù)據(jù)，這么做的理由非常簡單。舉個例子，如果你想知道一個大數(shù)據(jù)集表格中究竟有多少行，你可能需要將每一行都取到本地客戶端，然后循環(huán)訪問并進(jìn)行計算，如果使用的是傳統(tǒng)數(shù)據(jù)庫環(huán)境，你還可以使用“select count(*) from…”，后者顯然是更加有效的。
說永遠(yuǎn)比做容易。許多問題使用這個途徑是無法解決的，即使在許多已知的情況下，許多框架都會出現(xiàn)問題。在海量數(shù)據(jù)分析上，2013年National Research Council（國家研究委員會）提出了7個大型并行計算問題，希望對分布式計算系統(tǒng)進(jìn)行良好的分類，比較有意思的是，根據(jù)測算結(jié)果，Hadoop并不適合所有類型。
幸運的是，我們有一個簡單的可用的用例，它可以再次減半響應(yīng)時間。
現(xiàn)在的情況是，這里有數(shù)據(jù)的多個源，Barclays、Merrill Lynch和多個公司都提供了債券計價數(shù)據(jù)。相同債券同一天的數(shù)據(jù)也可能出現(xiàn)在其他源中，但是價格可能不一致。每個客戶有不同的優(yōu)先順序，每個請求都包含了某個源應(yīng)該用在某個訂單的順序。嘗試從第一個數(shù)據(jù)源中獲取所有數(shù)據(jù)，如果發(fā)現(xiàn)丟失，則會嘗試下一個源。通常情況下，發(fā)現(xiàn)所有數(shù)據(jù)需要訪問5個這樣的數(shù)據(jù)源。
在分離數(shù)據(jù)庫世界中，不同的源都處于不同的地理位置中，這就意味著嘗試第一個數(shù)據(jù)庫，取得所有的數(shù)據(jù)，查詢丟失了什么，構(gòu)成一個新的請求，并發(fā)布下一個任務(wù)。
對于HBase，我們?nèi)匀豢梢垣@得物理分類的優(yōu)勢，支持上千萬列，并通過協(xié)同處理器進(jìn)行同址計算。
通過將源和字段列與security和date整合，它們將被混搭在相同的region服務(wù)器上 。協(xié)同處理器的邏輯將變?yōu)椤盀橹付ㄐ邪l(fā)現(xiàn)第一個源，并進(jìn)行security和date匹配”。
在一個只包含一些行的小協(xié)同處理器上，平均響應(yīng)時間將降到85毫秒。
性能3：同步中斷
繼續(xù)上文的話題，增加region服務(wù)器數(shù)量降低性能給我們留下的謎題：為什么響應(yīng)時間在開始時有改善，而隨后則會變得更糟糕？問題的答案涉及到兩個方面——Java和所有高fan out分布式系統(tǒng)一些常見的問題。
一個涉及到不止1個fan out的請求中，服務(wù)器訪問越高，fan out的程度就越高。那么，在一個有fan out的請求中，響應(yīng)時間該如何計算？
答案就是，響應(yīng)的時間由最慢的反應(yīng)者決定，當(dāng)給11臺主機每個都配備10個region服務(wù)器時，每個請求需要fan out 110個進(jìn)程。如果其中109個是1毫秒完成，1個請求是170毫秒，那么響應(yīng)時間將高達(dá)170毫秒。
這里的罪魁禍?zhǔn)缀翢o疑問就是Java的垃圾回收機制，它會凍結(jié)一個機器直到回收結(jié)束。Fan-out的程度越高，其中一個region服務(wù)器在做垃圾回收的可能性就越大。當(dāng)region數(shù)量達(dá)到110個時，可能性已經(jīng)開始接近1。
這里的解決方案非常的簡單。既然在垃圾回收過程中所有的服務(wù)器都會被凍結(jié)，那么為什么不讓這些region服務(wù)器同時做垃圾回收？這種情況下，請求將需要更多的時間，但是毫無疑問的是，在處理的過程中，沒有region服務(wù)器會做垃圾回收。為此，我們編寫了不能再簡單的代碼進(jìn)行測試——system.gc()以及30秒會調(diào)用一次這個方法的定時器。
通過這個操作，我們首次將相應(yīng)時間從85毫秒降低到60毫秒。
Java垃圾回收機制這個詬病已經(jīng)被廣泛認(rèn)知，這也是Jeff Dean歸納為Synchronized Disruption中的一個問題。任何并行系統(tǒng)中的請求都需要遭受最慢者的摧殘，因此影響個體機器的問題將同時影響到整個系統(tǒng)。想獲得更多詳情，推薦閱讀“Achieving Rapid Response Times in Large Online Services”，你將獲得更多關(guān)于高fan out計算系統(tǒng)的使用經(jīng)驗。
這就意味著，Java當(dāng)下已經(jīng)成為很多高fan out計算系統(tǒng)的基礎(chǔ)，其中包括Hadoop、HBase、Spark、SOLR等，同步進(jìn)行垃圾回收將解決非常大的問題。
原文鏈接： The Big Problem Is Medium Data （翻譯/童陽 責(zé)編/仲浩）
|
|
免費注冊
發(fā)表于 2014-12-30 09:37
發(fā)表于 2014-12-30 13:39