背景概述
在互聯網電商平臺上，廣告是提升成交總額（GrossMerchandise Volume）和拉取新客的常見途經。在廣告系統或廣告運營中都需要基於人群數據分析進行定向的用戶廣告投放。在第三方平臺進行廣告投放，同樣需要使用人群數據分析計算。根據計算分析方的不同，可以分為兩類，第一類是基礎數據全部發送給第三方廣告平臺，如抖音，騰訊等，由第三方在投放人群時候進行人群計算並作選擇；第二類是人群計算工作在電商平臺內部完成，推送給第三方的只是單個的人群包數據（設備數據）。在唯品會，我們目前採用第二類方式進行人群計算投放。我們每天需要完成數萬的人群包計算，這些計算都是基於幾張位於HDFS的之上的Hive表完成，這些表每天通常都行需要被訪問上萬次。
原先架構及場景問題分析
在原先的架構中，我們的YARN與HDFS集群是計算存儲混布的。一個節點即是存儲節點同時也是計算節點。支持人群計算的引擎包括HiveMR和Spark，其中Spark任務佔比90%左右。所有人群計算需要的基礎數據是T-1的離線數據。這些基礎數據正常情況下，在每天的8:00能夠準備完成。考慮到廣告具有一定的及時性要求，這裡需要在每天人群計算的20:00前運行完成。
圖1：人群計算架構現狀(DMPapp代表人群計算的YarnContainer)
原有運行架構中如圖1所示。在集群相對穩定的情況下，一個人群計算任務的執行時間約3分鐘。在集群不穩定的情況下，執行時間的變化會比較大，具體部分運行時間如下圖2所示。在這種情況下，計算任務的資源消耗比正常情況大很多，大約能達到30/3=10倍左右，同時人群計算也難以達到業務時間要求(20:00前運行完成)。
我們將運行不穩定的原因總結為以下幾個方面：
- 人群計算任務的數據本地性不好。
- 在單個節點計算熱點數據，交換機80G上下行帶寬也常常打滿（DN節點雙萬兆網絡）。
- HDFS讀寫本身存在長尾現象。
圖2：人群數據在HDFS集群上的運行情況
新的架構方案
為了更好地滿足熱點數據的計算需求，我們需要取得較好的數據本地性。因此，我們希望能夠達到以下目標：
1) 計算與存儲同置，這樣數據就不需通過網絡反覆讀取，造成網絡流量浪費。
2) 減少HDFS讀寫長尾對人群計算造成的額外影響，同時減少人群計算對於HDFS穩定性的影響。
3) 廣告人群計算介於線上生產任務跟離線任務之間的任務類型。這裡我們希望能保證這類應用的可靠性和穩定性，從而更好地為公司業務賦能。
為了達到上述三點目標，我們設計了基於Alluxio部署架構方案，具體如圖3所示。
圖3：Alluxio與Spark計算節點混布的架構方案
我們基於HDFS的緩存有兩套Alluxio集群(另外的團隊也部署了一套Alluxio)。所有人群計算任務都是基於數據服務進行調用的。所以我們在數據服務的計算集群上面單獨部署了Alluxio集群。為了使數據服務的數據訪問在任何情況下不影響HDFS集群的數據讀寫。我們採取的方案是新建一張表(庫名不同，表名稱一致)，新建的表通過AlluxioUFS指向原hive表在同一個HDFS物理地址，避免數據拷貝以及不一致性。通過在運行SQL前對SQL進行改寫，使其能夠讀取數據服務計算集群的Alluxio的數據。進一步地，我們還希望兩套Alluxio集群上的數據能夠互相訪問。當前官方(
https://docs.alluxio.io/ee/user/stable/en/deploy/Running-Alluxio-On-a-HA-Cluster.html)並沒有給出類似HDFS federation如何兼容兩套Alluxio集群的配置方式，因此我們採用瞭如下方式進行了部分workaround。首先，我們的主Alluxio集群的配置基於官方標準進行，在spark配置文件中加入：
<code>spark.executor.extraJavaOptions-Dalluxio.zookeeper.address=******:2181, ******:2181,******:2181-Dalluxio.zookeeper.leader.path=/alluxio/leader-Dalluxio.zookeeper.enabled=true。/<code>
數據通過mount UFS指向HDFS路徑，在需要將Hive表數據存放到Alluxio時，修改Hive表的metastore，使其地址指向Alluxio即可。具體地，我們採取的方式是將數據服務Alluxio集群上HiveMetastore的location設置為：
alluxio://zk@zkHost1:2181;zkHost2:2181;zkHost3:2181/path。
在這樣的配置下，我們能夠實現所有主Alluxio集群的數據都可以由Hive、Spark、Presto訪問。數據服務Alluxio集群的數據可以通過Spark進行訪問。但是當前Hive,Presto 還不能訪問數據服務Alluxio集群的數據。
在新的架構下計算的效果如圖4，
圖4：基於Alluxio新架構下的部分計算性能展示
線上SQL實驗測試分析
測試環境：1.92TSSD, 40C, 10000M/s 網絡。10臺物理機
（1）100個線上SQL，每個SQL執行五次。
（2）500個線上SQL，每個執行1次。
線上測試結論：Alluxio 提速效果還是不錯，基本都能夠達到10 %以上，有些查詢性能甚至能夠提升 30%。
Alluxio帶來的優勢與總結展望
基於Alluxio的新架構解決了HDFS熱點數據的讀取問題，從而使得廣告人群計算這類準生產應用也能得以保障，實現了技術賦能業務。另外，計算效率的提升也對帶來了可觀的資源的節約，額為支撐的硬件只是少量SSD盤。
目前，我們只是利用Alluxio解決單純的HDFS熱點數據讀取問題。我們通過社區學習到其他公司很多很好的Alluxio使用場景也非常適合我們，後續我們將繼續探索如何更好地結合實際情況來使用Alluxio進行穩定以及加速。當然，文中提到的我們場景下的多Alluxio集群的互訪問題需要進一步解決。
