一、業(yè)務(wù)背景

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

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

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

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

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

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

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

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

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

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

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

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

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

Alluxio 有兩種使用方式：

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

二、Alluxio 方案

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

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

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

為了解決這個問題，我們又采用了以下兩個關(guān)鍵的策略。第一個是基于時間范圍的庫表白名單策略，在庫表白名單的橫向限制的基礎(chǔ)上，又增加了一個縱向的基于分區(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 構(gòu)建起了一個保護墻，讓 Alluxio 在更合理?的數(shù)據(jù)范圍內(nèi)進行數(shù)據(jù)的管理，而不是全局的，從而提升了緩存的利用率。而且采用這樣的策略部分直接走 HDFS 的流量，不管是耗時還是對 Alluxio 內(nèi)存的壓力都會有所降低。

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

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

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

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

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

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

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

三、運行效果

下面展示一下運行效果。

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

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

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

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

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

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

?第一個是我們采用 KonaJDK 中的一個工具 Kona- profiler 來定位了高并發(fā)訪問 Alluxio master FGC 的問題。當(dāng)來自業(yè)務(wù)的海量的請求一塊到來的時候，Alluxio master 的 Java 虛擬機的垃圾回收器出現(xiàn)了一個現(xiàn)象，就是回收對象的速度跟不上創(chuàng)建對象的速度，那最終會導(dǎo)致 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)比較耗時。進一步去看，所有的類或?qū)ο蟮囊藐P(guān)系，最后找到了 rocksdb 中的 ReadOptions 對象，它的祖先類里面確實是重寫了這個函數(shù)，并且邏輯也過于復(fù)雜，還會調(diào) native 還會調(diào)回?來，所以拖慢了對象的回收速度，7.0 以后版本已經(jīng)修復(fù)了。但我們當(dāng)時用的是 6.X 版本，所以我們的一個思路是把 rocksdb 升級。

另外一個思路，是去定位它為什么要去這么高頻的調(diào)這個 ReadOptions 對象，把它創(chuàng)建出來，最后又釋放掉。通過看 Alluxio 相關(guān)的一些代碼，我們找到了原因是底層的塊 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 連接不暢導(dǎo)致一個叫優(yōu)雅關(guān)閉的時間設(shè)置的太久了。這個默認值是 45 秒，只需要縮小就可以了。

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

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

五、總結(jié)展望

最后進行一下總結(jié)。

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

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

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

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