一、業務背景

首先介紹一下業務背景。

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

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

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

?在大數據 OLAP 分析場景中，我們面臨的挑戰有以下兩個：

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

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

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

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

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

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

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

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

Alluxio 有兩種使用方式：

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

二、Alluxio 方案

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

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

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

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

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

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

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

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

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

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

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

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

三、運行效果

下面展示一下運行效果。

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

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

四、優化調優

最后介紹一下我們的優化實踐。

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

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

?第一個是我們采用 KonaJDK 中的一個工具 Kona- profiler 來定位了高并發訪問 Alluxio master FGC 的問題。當來自業務的海量的請求一塊到來的時候，Alluxio master 的 Java 虛擬機的垃圾回收器出現了一個現象，就是回收對象的速度跟不上創建對象的速度，那最終會導致 OOM 。我們用 Kona-profiler 做了一個分析，這個分析的輸入就是 OOM 的時候出現的一個 hip dump 文件。最后我們得到了上圖所示的一個餅圖，一個對象的分布圖。可以看到大部分的都是 finalizer 這樣一個對象。

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

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

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

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

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

五、總結展望

最后進行一下總結。

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

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

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

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