一、業(yè)務背景

首先介紹一下業(yè)務背景。

在騰訊金融場景中，數(shù)據(jù)分析主要有兩大入口：

• 第一個是基于 SQL 的分析平臺產(chǎn)品——idex；
• 另外一個是圖形化的分析產(chǎn)品——“全民 BI”。全民 BI 是一款類似于 tableau 一樣，可以通過拖拉拽的方式進行數(shù)據(jù)探索分析的工具，因為不需要編寫 SQL， 所以面向人群更廣，不僅包括數(shù)據(jù)分析人員，還有產(chǎn)品、運營等等，對耗時敏感度也會更高。本次主要介紹全民BI。

為支持日益增長的各類分析場景，今年騰訊金融業(yè)務數(shù)據(jù)團隊進行了大的架構升級，引入了 Presto 加上騰訊 Alluxio 的架構，用來滿足用戶海量金融數(shù)據(jù)的自由探索需求。

?在大數(shù)據(jù) OLAP 分析場景中，我們面臨的挑戰(zhàn)有以下兩個：

首先，既要滿足數(shù)據(jù)的快速增長，又要更快的數(shù)據(jù)探索性能，還要成本低。雖然這些年 SSD 的性能還不錯，但現(xiàn)在HDD 還是有很大的市場。比如在中央存儲系統(tǒng)中，由于數(shù)據(jù)量巨大，全換成 SSD 成本會難以接受。

第二個挑戰(zhàn)是在多種計算任務的 workload 當中 ，OLAP 分析的性能如何在 IO 瓶頸中突圍。常見大數(shù)據(jù)計算的兩種負載就是 ETL 和 OLAP。OLAP 主要是用在對數(shù)據(jù)的多維度分析上，特點是僅涉及少量的數(shù)據(jù)列，但可能涉及較大的數(shù)據(jù)范圍。雖然 ETL 的峰值可能在凌晨，但是其實白天也會有各種各樣的任務在不斷的執(zhí)行，這兩種任務的負載會相互影響，再加上中央存儲的底層是硬盤，所以其 IO 性能會受到硬盤的約束。所以對于 OLAP 分析的特點，硬盤的 IO 是隨機碎片化的， SSD 更適合。?

?針對上述挑戰(zhàn)，一種比較流行的解決方案為，把需要的熱數(shù)據(jù)復制到專用的存儲當中，這樣可以解決 IO 的競爭問題。就比如有一個中央的 HDFS，又搭建了一個 HDFS，把里邊的數(shù)據(jù)拷到這個搭建的 HDFS 中，這樣 IO 就天然隔離了。

小的集群里面存儲的都是熱數(shù)據(jù)，所以其實也可以用 SSD 進一步加速 OLAP 性能。但是這樣又會引來一些新的問題，比如數(shù)據(jù)的邊界問題，以及數(shù)據(jù)認證鑒權一致性的問題。?

數(shù)據(jù)的邊界問題：因為數(shù)據(jù)需要提前復制，如果需要臨時分析超出約定范圍的數(shù)據(jù)，就會導致只能降級到中央存儲上面去執(zhí)行查詢，這樣不僅涉及到存儲的切換，也涉及到計算引擎的切換。

數(shù)據(jù)認證鑒權一致性問題：因為要復制到另一個存儲系統(tǒng)，就可能存在一致性問題，另外數(shù)據(jù)的屬主、permission mode ， 以及認證鑒權方式等都要完全一樣才行。對于金融這樣一個強監(jiān)管行業(yè)，不能出一點差錯。

顯然這個方案無法解決我們的問題，所以我們就采用了另外一種解決方案：Alluxio。

Alluxio 需要滿足兩個需求。如上圖所示，因為 Alluxio 是一個中央存儲的透明緩存層，擁有完整的中央存儲文件系統(tǒng)的視圖，文件的權限屬主以及認證鑒權的策略都是與底層一致的，并且可以采用 SID 或內(nèi)存盤作為緩存熱數(shù)據(jù)集的介質(zhì)。這樣 IO 也隔離了，性能也高了，并且數(shù)據(jù)的認證和鑒權也都是一致的。所以我們認為它是一個更好的解決方案。

Alluxio 有兩種使用方式：

• 一種是傾向于使用 Alluxio 的緩存加速，把 Alluxio 跟計算引擎親和性地部署在一起，可以換取更好的 IO 本地性，從而提升性能。
• 另外一種使用方式是更看中 IO 隔離的特性。不一定把Alluxio和計算做一個完全親和本地性的部署，也可以做分離的部署，這樣可以獨立的擴展。如果是1比1的時候，其實受限于機器上面的資源，比如 SSD的大小，可能 Alluxio 的機器沒辦法承擔那么大的緩存的資源量，緩存容量受限那么緩存的能力也就受限了。所以我們希望是混合部署，加上分離部署。

二、Alluxio 方案

?引入 Alluxio 面臨的第一個挑戰(zhàn)是，我們只想把 Alluxio 用于 OLAP 引擎，不想修改 HIVE 的元數(shù)據(jù)，我們由 Pretro 團隊去做了一些改動，改動的思路就是引入了一個 Alluxio 庫表的白名單模塊，相當于做了一個路徑的轉換。然后就可以在用戶無感，并且 HIVE meta store 里邊也沒有太多改動的情況下，就可以把一些特定庫表的一些訪問走到Alluxio里邊，而一些較大的庫表或者不需要緩存加速的，就不走 Alluxio 這里邊了。

另外，作為 Alluxio 開發(fā)團隊，我們開發(fā)了 Alluxio（DOP）自適應客戶端功能。把 Presto 做的所有事下沉到 Alluxio 這個客戶端里邊。不光是 Presto， Spark、 Flink 等其它計算引擎，想去用這樣的一個黑白名單，或者限制一些表按時間范圍等，都可以接到自適應客戶端里邊。?

?第二個挑戰(zhàn)是避免隨意的大范圍查詢導致其他數(shù)據(jù)被大面積驅逐。我們之前使用白名單對 Alluxio 存儲的數(shù)據(jù)有一個橫向的限制，但是依然會有這樣的風險，就是用戶可能突然提交一個很大范圍的查詢，進而導致很多其它庫表的數(shù)據(jù)被清理掉。因為我們采用的是 CACHE 讀策略，所以只要是數(shù)據(jù)不在 Alluxio 里面，就會觸發(fā) Alluxio 的數(shù)據(jù)加載，就會導致其它的數(shù)據(jù)被清理掉。

為了解決這個問題，我們又采用了以下兩個關鍵的策略。第一個是基于時間范圍的庫表白名單策略，在庫表白名單的橫向限制的基礎上，又增加了一個縱向的基于分區(qū)的時間的限制機制。上圖中所示的幾個片段就是這個意思。第二方面就是降低 Alluxio worker異步緩存加載的最大線程數(shù)。默認情況下, async.cache.manager.threads.max 默認是 CPU 的 2 倍，這個可能還是太大了，所以我們把它調(diào)成 1/2 的 CPU 或 1/4 的 CPU 。這樣查詢突增的 load cache 請求就會被 reject ，這樣就可以降低對存量數(shù)據(jù)的影響。

這樣實際上就是為 Alluxio 構建起了一個保護墻，讓 Alluxio 在更合理?的數(shù)據(jù)范圍內(nèi)進行數(shù)據(jù)的管理，而不是全局的，從而提升了緩存的利用率。而且采用這樣的策略部分直接走 HDFS 的流量，不管是耗時還是對 Alluxio 內(nèi)存的壓力都會有所降低。

第三個挑戰(zhàn)是異構存儲機型，緩存請求分配策略如何選擇？我們現(xiàn)在就是異構的機型，有一些是混部的，有一些是分開的，就是獨立的 Alluxio 的 worker。

這種情況下 Alluxio 已有的一些塊選擇策略就不適合了。比如 RoundRobinPolicy 和 DeterministicHashPolicy 都是均衡策略。

第一個是把請求轉圈的分配給所有 worker，另外一個是按照 block ID 做一個哈希散列分配到所有的 worker 上。對于同樣配置的緩存節(jié)點其實還是可以的，但是異構機型場景就不適合了。因為有的存儲容量大，有的存儲容量小，對于存儲容量較小的 worker 其數(shù)據(jù)淘汰率就會更高。這樣就無法使所有 worker 在同樣的繁忙度上去運行。

另外一個是 MostAvailableFirstPolicy ，這也是一個在很長一段時間都非常流行的策略。是選擇在剩余空間較多的 worker 上面去讀數(shù)據(jù)。這會導致一開始請求就會堆積到大容量的 worker 上，分配就不均衡了，其它的 worker 都閑著，但是要把所有的 worker 全都灌滿以后，那 most available也就失去意義了。

?所以騰訊設計貢獻了一個基于容量的隨機塊選擇策略。這里有兩個關鍵詞，一個是基于容量，另一個是隨機。就是根據(jù) worker 的容量，給不同的 worker 分配不同的分發(fā)概率。這個概率是隨機的。我們做了一個測試實驗，可以看到，異構的情況下，worker的使用量和總空間量都是按照一定比例去增長的，還算比較均衡。

另外為了優(yōu)化pretro 查詢導致多副本的一個問題。我們設計了CapacityBaseRandomPolicy。有某一個塊已經(jīng)分配給某一個 worker 了，那接下來再來到這個客戶端上，還要對這個塊做一個讀請求，那還是會分配到那個 worker 里邊，因為我們已經(jīng)緩存了這個塊跟 worker 位置的一個映射。這樣就避免了同一個 block 在高并發(fā)的時候，會被分配到多個 wo?rker 上，那就會產(chǎn)生很多的副本。

上圖是最終的方案， Presto + Alluxio 混合部署的集群，并且額外申請了帶 7T SSD 的一些機器作為 Alluxio 的 worker ，這個架構就具備了存儲和計算獨立擴展的能力。

三、運行效果

下面展示一下運行效果。

這個測試并沒有像以往一樣找一些基準測試，而是采用真實的某一個工作日線上的執(zhí)行查詢的一些歷史，我們把這個歷史作為一些回放，是完全隨機的。這樣更靠近真實場景，因為完全隨機的時候可能會有一部分不一定走 Alluxio 里邊，我們可能限定了有些查詢是走底層的，可以綜合的去看其性能。

測試的時候我們選了兩個時段，第一個是周末下午，500 個查詢。這個時段是一個閑時。HDFS 大集群負載也比較低，這個時候考察的就是 SSD 的加速能力。第二個是工作日的早上，屬于忙時，300 個查詢，在這一時段， ETL 、畫像標簽、推薦、特征等任務都在執(zhí)行著，所以 HDFS 集群繁忙度還是比較高的，這時主要考察的是 IO 的隔離性。測試結果如上圖左下表格所示，可以看到，閑時有 68% 的性能加速，而忙時有 300% 左右的性能加速。

四、優(yōu)化調(diào)優(yōu)

最后介紹一下我們的優(yōu)化實踐。

首先我們采用了騰訊的 KonaJDK 加上經(jīng)過騰訊優(yōu)化的 G1GC。我們只是將底層的 GM 下的一些基礎設施換成了騰訊 KonaJDK + GGC。我們就看到 GM 還有平均的一些延時都降得很低，性能表現(xiàn)都特別好，這里非常感謝 GM 團隊給我們的支持。

這里分享一下我們解決的一些問題。

?第一個是我們采用 KonaJDK 中的一個工具 Kona- profiler 來定位了高并發(fā)訪問 Alluxio master FGC 的問題。當來自業(yè)務的海量的請求一塊到來的時候，Alluxio master 的 Java 虛擬機的垃圾回收器出現(xiàn)了一個現(xiàn)象，就是回收對象的速度跟不上創(chuàng)建對象的速度，那最終會導致 OOM 。我們用 Kona-profiler 做了一個分析，這個分析的輸入就是 OOM 的時候出現(xiàn)的一個 hip dump 文件。最后我們得到了上圖所示的一個餅圖，一個對象的分布圖?？梢钥吹酱蟛糠值亩际?finalizer 這樣一個對象。

一個小知識， Java 的對象在被回收的時候，都是在最后一刻會被調(diào)用該對象的 finalizer 的這樣一個方法。finalizer 本身是 object 對象的一個方法，所有的是空實現(xiàn)，所有底下的一些類都不需要實現(xiàn)，但是現(xiàn)在卻看到了這個Finalizer方法被調(diào)用，所以顯然是有一些類實現(xiàn)了這個方法，并且實現(xiàn)比較耗時。進一步去看，所有的類或對象的引用關系，最后找到了 rocksdb 中的 ReadOptions 對象，它的祖先類里面確實是重寫了這個函數(shù)，并且邏輯也過于復雜，還會調(diào) native 還會調(diào)回?來，所以拖慢了對象的回收速度，7.0 以后版本已經(jīng)修復了。但我們當時用的是 6.X 版本，所以我們的一個思路是把 rocksdb 升級。

另外一個思路，是去定位它為什么要去這么高頻的調(diào)這個 ReadOptions 對象，把它創(chuàng)建出來，最后又釋放掉。通過看 Alluxio 相關的一些代碼，我們找到了原因是底層的塊 block store 用的是 rocksdb，rocksdb 存的有兩項，第一個是 block 的 meta， 第二個是 block 的 location。而 block location 這個位置信息在去查詢他們的時候要有一個前綴匹配，就要把 ReadOption打開。我們的 block location 并不多，因為在這種 OLAP 查詢底層的這些數(shù)據(jù)都是大塊的，緩存容量也是有限的，一個 Alluxio 集群里，容量這么大，如果都存滿了存的 block location 也不會過億，我們把它都放在內(nèi)存里邊也沒有問題。所以我們就將 block location 放到內(nèi)存里邊，而 block meta 以及inode 等是放在rocksdb?；谶@一優(yōu)化，耗時從 120 秒減少到 28 秒。因此通過一些 GM 調(diào)優(yōu)工具，是可以看到性能的瓶頸的，也可以從根本上去解決問題。

另外一個問題是慢查詢。大部分查詢都是7秒，周期性會出現(xiàn) 50 秒的慢查詢。我們定位問題，發(fā)現(xiàn)是 client 與 worker 連接不暢導致一個叫優(yōu)雅關閉的時間設置的太久了。這個默認值是 45 秒，只需要縮小就可以了。

另外一個就是 master data 頁面卡住的問題。如果往里邊緩存了特別多塊的時候， master 頁面后臺的邏輯是掃描所有的 inode 里邊所有的 block， 看看哪些 block 都在內(nèi)存里，然后展示出來。這個頁面打開就太慢了?，F(xiàn)在優(yōu)化這個問題不光是因為頁面打不開，而是它把 Alluxio 性能也都拖垮了。

所以我們開發(fā)了一個能力，就是在默認情況下不把所有的 Alluxio 的這樣一些數(shù)據(jù)給它在頁面展現(xiàn)出來，只是展示一部分，如果想要更多，那么去做動態(tài)更新這樣的一個配置閾值就可以了。

五、總結展望

最后進行一下總結。

騰訊 Alluxio（DOP）支持 BlockStore 層次化，前端為緩存層，后端為持久層，同時，blockLocation 這種不需要持久化的數(shù)據(jù)，不需要實時寫入后端持久層，只需要在前端緩存層失效的時候才需要溢出到后端，該功能正在內(nèi)部評測。

騰訊 Alluxio（DOP）作為一個中間組件，在大數(shù)據(jù)查詢場景，遇到的性能問題，在業(yè)務側，需要業(yè)務團隊不僅對自身業(yè)務非常了解，對 Alluxio 也需要有一定的了解。在底層 JVM 側，需要 JVM 專業(yè)的團隊采用專業(yè)的技術進行協(xié)作解決，從而最大限度的優(yōu)化，使得整體方案發(fā)揮最優(yōu)的性能。

Alluxio 之所以能夠在我們現(xiàn)有的金融場景里邊落地，是很多個團隊一起協(xié)作，一起去努力的。所以要感謝兄弟團隊們給予的支持。

今天的分享就到這里，謝謝大家。