原標題：一樣的錢，6倍的性能，就問你心不心動

“百度BigSQL可為用戶提供高性能的即席查詢服務(wù)，它需要大內(nèi)存在計算節(jié)點本地緩存熱數(shù)據(jù)，以減少DFS I/O對查詢性能的影響。我們使用來自英特爾的傲騰持久內(nèi)存，在緩存質(zhì)量得到保證的同時，極大地提升了集群的處理能力，獲得了明顯的TCO收益。”

——百度資深系統(tǒng)工程師黎世勇

在近年來全球數(shù)據(jù)規(guī)模指數(shù)級增長的大背景下，如何滿足用戶對服務(wù)響應(yīng)時間的要求成為了擺在眾多企業(yè)，特別是科技企業(yè)面前的嚴峻挑戰(zhàn)。別看只是響應(yīng)晚一秒鐘，但企業(yè)很有可能流失數(shù)以萬計的客戶，因此沒有哪家企業(yè)敢對客戶體驗掉以輕心。

這也是頂級互聯(lián)網(wǎng)企業(yè)百度面臨的苦惱。用黎世勇的話說，客戶體驗是我們的第一KPI，響應(yīng)時間是客戶體驗好不好最直接的體現(xiàn)之一。為此，百度這些年一直在尋找、嘗試、開發(fā)更好的技術(shù)來改善用戶體驗。

本文要講的百度聯(lián)合英特爾進行的一系列技術(shù)創(chuàng)新，便是其為用戶獲得更好體驗不斷努力的一個縮影。

0 1

軟硬一起抓

Apache Spark是大規(guī)模數(shù)據(jù)處理的快速通用計算引擎，當前應(yīng)用極其廣泛。Spark SQL模塊是Apache Spark專門為大型數(shù)據(jù)中心結(jié)構(gòu)化數(shù)據(jù)處理開發(fā)的功能模塊。百度BigSQL數(shù)據(jù)處理平臺基于Spark SQL開發(fā)，在性能上做了很多優(yōu)化，開發(fā)了不少新功能。

交互式查詢能力就是BigSQL在性能優(yōu)化方面體現(xiàn)非常明顯的一個例證。關(guān)于交互式查詢的重要性，相信不用多解釋了，服務(wù)響應(yīng)快不快，跟它緊密相關(guān)。為實現(xiàn)次秒級的交互式查詢響應(yīng)，百度和英特爾在軟硬兩個層面都下了不少功夫。

軟件層面，百度聯(lián)合英特爾開展了Spark平臺優(yōu)化分析包（OAP）項目合作。其中，OAP 能很好地利用列式數(shù)據(jù)以及選定列上的用戶定義索引，提高數(shù)據(jù)檢索效率。與此同時，OAP還采用了細粒度的內(nèi)存數(shù)據(jù)緩存策略，以此來消除磁盤和網(wǎng)絡(luò)中的 I/O 瓶頸，將性能最大化。

硬件層面，百度與英特爾合作，利用英特爾傲騰持久內(nèi)存替代部分DRAM，部署更具成本效益的解決方案。

百度內(nèi)部測試顯示，與使用傳統(tǒng)純內(nèi)存的解決方案相比，使用傲騰持久內(nèi)存可有效提高OAP的緩存性能及成本效益，大幅提升業(yè)務(wù)成效，例如幫助百度即席查詢服務(wù)圖靈減少工作負載、降低平均查詢延時等。

具體如何實現(xiàn)的呢？兩步走。

0 2

把常用的數(shù)據(jù)放在更快的存儲里

OAP的核心是使用索引和緩存技術(shù)來加快交互式查詢響應(yīng)的速度。

在此基礎(chǔ)之上，OAP還借助緩存來優(yōu)化索引和數(shù)據(jù)訪問進程。通過將索引和數(shù)據(jù)緩存在內(nèi)存中，來提升索引加載和數(shù)據(jù)掃描速度，縮短從分布式文件系統(tǒng)讀取時磁盤和網(wǎng)絡(luò)的I/O時間。此外，通過將索引和數(shù)據(jù)單獨緩存，其緩存清除和內(nèi)存空間管理實現(xiàn)了彼此獨立。

由于采用列式緩存，OAP 只需緩存查詢所需的列?；谧罱钌偈褂茫↙RU）策略，當緩存達到最大容量時，那些最近最少使用的數(shù)據(jù)項將被淘汰，為緩存最新數(shù)據(jù)釋放空間。依照該策略，BigSQL啟用了一個高級緩存管理器，可以主動填充熱點列，并清除緩存中不再需要的列。

0 3

讓更快的存儲空間再大一點

顯而易見，OAP的本質(zhì)是將熱數(shù)據(jù)放在更快的內(nèi)存中，從而起到加速的目的。但由此也帶來了新的問題：一、內(nèi)存是不可能無限擴展的，二、超過一定內(nèi)存容量后，成本是呈指數(shù)級上漲的。

這也是硬件層面采用傲騰持久內(nèi)存的根本出發(fā)點。眾所周知，傲騰持久內(nèi)存是一種將高容量、經(jīng)濟實用性和數(shù)據(jù)持久性相結(jié)合的突破性技術(shù)，其擁有兩大特點：一、大容量和更低的成本，二、適合順序讀。

進一步展開，傲騰持久內(nèi)存擁有兩種工作模式：內(nèi)存模式和應(yīng)用直接訪問模式。在“內(nèi)存模式”下，應(yīng)用程序能利用傲騰持久內(nèi)存作為擴展的易失性系統(tǒng)內(nèi)存，無需重新編寫軟件，而DRAM將起到緩存的作用。在“應(yīng)用直接訪問模式”下，經(jīng)過專門改進的應(yīng)用程序可獲得更大的持久性容量。

鑒于OAP緩存具有索引和輸入數(shù)據(jù)的特定目的，因此OAP采用了“應(yīng)用直接訪問模式”。

為更好地利用傲騰持久內(nèi)存代替 DRAM，英特爾還對OAP進行了擴展，加入內(nèi)存管理器插件，并采用支持傲騰持久內(nèi)存的內(nèi)存管理器。這樣一來，用戶可以在DRAM和傲騰持久內(nèi)存間自由切換，甚至兩者兼用，例如使用 DRAM 緩存索引，而使用傲騰持久內(nèi)存緩存數(shù)據(jù)。

除此之外，為確保傲騰持久內(nèi)存與百度獨特的OS環(huán)境無縫集成，百度還與英特爾在硬件、操作系統(tǒng)和庫等領(lǐng)域進行了一系列合作優(yōu)化。

0 4

6倍性能提升

為驗證OAP項目及傲騰持久內(nèi)存的性能表現(xiàn)，百度分兩步進行了多次評估和內(nèi)部測試：第一步是決策支持基準測試，第二步真實查詢測試。

在決策支持基準測試中，首先將數(shù)據(jù)集大小控制為1TB，并使用相同容量的DRAM和傲騰持久內(nèi)存。 測試結(jié)果表明，兩者都能容納所有的緩存數(shù)據(jù)，傲騰持久內(nèi)存的性能略微低于 DRAM（11.7％），但成本卻明顯更低。

當數(shù)據(jù)集達到 3TB，且使用相同成本的DRAM和傲騰持久內(nèi)存時，前者的容量已不足以緩存所有數(shù)據(jù)。相比之下，傲騰持久內(nèi)存不僅能緩存所有的數(shù)據(jù)，性能也超出DRAM 高達 6 倍。

此時的 DRAM 性能較差是因為：當數(shù)據(jù)規(guī)模大大超過緩存容量時，DRAM 需要頻繁地從后端存儲讀取數(shù)據(jù)，由此延長了響應(yīng)時間。決策支持基準測試清楚的表明，在成本相同的情況下，傲騰持久內(nèi)存可提供比DRAM更高的容量和更出色的性能。

測試的第二階段使用百度線上業(yè)務(wù)的真實查詢數(shù)據(jù)，依然基于以上兩種情況，但方法略有不同。在第一種情況下，DRAM和傲騰持久內(nèi)存被設(shè)置為緩存50％的常用數(shù)據(jù)列， 此時PMem的緩存速度僅比DRAM低約12％，但由于成本優(yōu)勢更為顯著，因此整體性價比更高。

在第二種情況下（即DRAM和傲騰持久內(nèi)存成本相同），只有傲騰持久內(nèi)存擁有足夠容量來緩存所有熱點數(shù)據(jù)，且性能較DRAM高出22％，同時避免了30％不要的底層系統(tǒng)I/O請求。

數(shù)據(jù)不會說謊，在百度BigSQL 中用傲騰持久內(nèi)存取代DRAM顯然是更具成本效益的緩存解決方案。目前，百度已在BigSQL中成功部署了傲騰持久內(nèi)存，并以此為基礎(chǔ)優(yōu)化了百度即席查詢服務(wù)圖靈。在傲騰持久內(nèi)存的加持下，圖靈集群的工作負載降低了30%，平均查詢延時降低了20%，每個傲騰持久內(nèi)存服務(wù)器實例Spark/OAP的性能提高了50％，而成本僅增加了20％。

0 5

傲騰，還有更多用武之地

除了為Spark SQL輸入數(shù)據(jù)提供緩存加速外，傲騰持久內(nèi)存高容量和高帶寬的優(yōu)勢還能在基于Spark的機器學習和深度學習場景中發(fā)揮更大作用，因為這些場景要求在規(guī)模龐大的數(shù)據(jù)集上反復(fù)進行多次計算。另外，Spark shuffle可以通過優(yōu)化，使用RDMA技術(shù)訪問遠程節(jié)點上的傲騰持久內(nèi)存并將其用作隨機存儲，進一步減少隨機延遲并提高性能。

未來，百度也將與英特爾攜手為Spark進行一系列更深度的優(yōu)化。

事實上，不僅是Spark，包括Redis、Oracle、Aerospike等或開源、或商業(yè)軟件通過使用傲騰持久內(nèi)存都有不同程度的性能提升、成本下降，無數(shù)的客戶已經(jīng)從中受益。

總結(jié)全文，數(shù)字世界正在來臨，數(shù)據(jù)爆炸式增長給企業(yè)帶來了新的挑戰(zhàn)，當下企業(yè)不僅要有能力處理大量增長的數(shù)據(jù)，而且要更快速的處理這些數(shù)據(jù)。這是傲騰的價值所在，提供更快速度的同時，還讓你負擔得起。

生成海報

免責聲明：本網(wǎng)站內(nèi)容主要來自原創(chuàng)、合作伙伴供稿和第三方自媒體作者投稿，凡在本網(wǎng)站出現(xiàn)的信息，均僅供參考。本網(wǎng)站將盡力確保所提供信息的準確性及可靠性，但不保證有關(guān)資料的準確性及可靠性，讀者在使用前請進一步核實，并對任何自主決定的行為負責。本網(wǎng)站對有關(guān)資料所引致的錯誤、不確或遺漏，概不負任何法律責任。任何單位或個人認為本網(wǎng)站中的網(wǎng)頁或鏈接內(nèi)容可能涉嫌侵犯其知識產(chǎn)權(quán)或存在不實內(nèi)容時，應(yīng)及時向本網(wǎng)站提出書面權(quán)利通知或不實情況說明，并提供身份證明、權(quán)屬證明及詳細侵權(quán)或不實情況證明。本網(wǎng)站在收到上述法律文件后，將會依法盡快聯(lián)系相關(guān)文章源頭核實，溝通刪除相關(guān)內(nèi)容或斷開相關(guān)鏈接。