點擊藍字丨關注我們
背景概述
在互聯網電商平臺上，廣告是提升成交總額（Gross Merchandise Volume）和拉取新客的常見途經。在廣告系統或廣告運營中都需要基於人羣數據分析進行定向的用戶廣告投放。在第三方平臺進行廣告投放，同樣需要使用人羣數據分析計算。根據計算分析方的不同，可以分爲兩類，第一類是基礎數據全部發送給第三方廣告平臺，如抖音，騰訊等，由第三方在投放人羣時候進行人羣計算並作選擇；第二類是人羣計算工作在電商平臺內部完成，推送給第三方的只是單個的人羣包數據（設備數據）。在唯品會，我們目前採用第二類方式進行人羣計算投放。我們每天需要完成數萬的人羣包計算，這些計算都是基於幾張位於HDFS的之上的Hive 表完成，這些表每天通常都需要被訪問上萬次。
原有架構及場景問題分析
在我們原有架構中，YARN與HDFS集羣是計算存儲混布的，即一個節點即是存儲節點同時也是計算節點。支持人羣計算的引擎包括Hive MR和Spark，其中Spark 任務佔比90%左右。所有人羣計算需要的基礎數據是T-1的離線數據。這些基礎數據正常情況下，在每天8:00能夠準備完成。考慮到廣告具有及時性要求，這裏需要在每天人羣計算的20:00前運行完成。
圖1：人羣計算架構現狀(DMP app代表人羣計算的Yarn Container)
原有運行架構如圖1所示。在集羣相對穩定的情況下，一個人羣計算任務的執行時間約3分鐘。在集羣不穩定的情況下，執行時間變化會比較大，具體部分運行時間如下圖2所示。在這種情況下，計算任務的資源消耗比正常情況大很多，大約能達到30/3= 10倍左右，同時人羣計算也難以達到業務時間要求(20:00前運行完成)。
我們將運行不穩定的原因總結爲以下幾方面：
★人羣計算任務的數據本地性不好；
★在單個節點計算熱點數據，交換機上下行帶寬也常常打滿（DN節點雙萬兆網絡）；
★HDFS讀寫本身存在長尾現象。
圖2：人羣數據在HDFS集羣上的運行情況
新的架構方案
爲了更好地滿足熱點數據的計算需求，我們需要取得較好的數據本地性。我們希望能夠達到以下目標：
★計算與存儲同置，這樣數據就不需通過網絡反覆讀取，造成網絡流量浪費。
★減少HDFS讀寫長尾對人羣計算造成的額外影響，同時減少人羣計算對於HDFS穩定性的影響。
★廣告人羣計算介於線上生產任務跟離線任務之間的任務類型。這裏我們希望能保證這類應用的可靠性和穩定性，從而更好地爲公司業務賦能。
爲了達到上述三點目標，我們設計了基於Alluxio部署架構方案，具體如圖3所示。
圖3：Alluxio與Spark 計算節點混布的架構方案
我們基於HDFS的緩存有兩套Alluxio 集羣(另外的團隊也部署了一套Alluxio )。所有人羣計算任務都是基於數據服務調用，所以我們在數據服務計算集羣上面單獨部署了Alluxio集羣。爲了使數據服務的數據訪問在任何情況下都不影響HDFS集羣的數據讀寫，我們採取的方案是新建一張表(庫名不同，表名稱一致)，新建表通過Alluxio UFS指向原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 配置文件中加入：
spark.executor.extraJavaOptions-Dalluxio.zookeeper.address=******:2181, ******:2181,******:2181-Dalluxio.zookeeper.leader.path=/alluxio/leader
-Dalluxio.zookeeper.enabled=true。
數據通過mount UFS 指向HDFS 路徑，在需要將Hive表數據存放到Alluxio時，修改Hive 表的metastore，使其地址指向Alluxio即可。具體地，我們採取的方式是將數據服務Alluxio集羣上Hive Metastore的location設置爲：alluxio://zk@zkHost1:2181;zkHost2:2181;zkHost3:2181/path。
在這樣的配置下，我們能夠實現所有主Alluxio集羣的數據都可以由Hive、Spark、Presto訪問。數據服務Alluxio集羣的數據可以通過Spark進行訪問。但是當前Hive, Presto 還不能訪問數據服務Alluxio集羣的數據。
在新的架構下計算的效果如圖4：
圖4：基於Alluxio 新架構下的部分計算性能展示
線上SQL實驗測試分析
測試環境：1.92T SSD, 40C, 10000M/s 網絡。10臺物理機
★100個線上SQL，每個SQL執行五次。
+-----------+-----+----------+
| 提升百分比 | sql 數量 | sql 數量佔比 |
+-----------+-----+----------+
| above 0 | 26 | 0.270833 |
| above 0.1 | 22 | 0.229167 |
| above 0.2 | 17 | 0.177083 |
| above 0.3 | 16 | 0.166667 |
| above 0.4 | 3 | 0.031250 |
| above 0.5 | 7 | 0.072917 |
| slow | 4 | 0.041667 |
+-----------+-----+----------+
★500個線上SQL，每個執行1次。
+-----------+-----+----------+
| 提升百分比 | sql 數量 | sql 數量佔比 |
+-----------+-----+----------+
| above 0 | 49 | 0.098990 |
| above 0.1 | 109 | 0.220202 |
| above 0.2 | 106 | 0.214141 |
| above 0.3 | 78 | 0.157576 |
| above 0.4 | 68 | 0.137374 |
| above 0.5 | 22 | 0.044444 |
| above 0.6 | 8 | 0.016162 |
| slow | 32 | 0.064646 |
+-----------+-----+----------+
線上測試結論：Alluxio 提速效果還是不錯，基本都能夠達到10 %以上，有些查詢性能甚至能夠提升 30%。
Alluxio帶來的優勢與總結展望
基於Alluxio的新架構解決了HDFS 熱點數據的讀取問題，從而使得廣告人羣計算這類準生產應用也能得以保障，實現了技術賦能業務。另外，計算效率的提升也對帶來了可觀的資源的節約，額爲支撐的硬件只是少量SSD盤。
目前，我們只是利用Alluxio 解決單純的HDFS熱點數據讀取問題。我們通過社區學習到其他公司很多很好的Alluxio使用場景也非常適合我們，後續我們將繼續探索如何更好地結合實際情況來使用Alluxio進行穩定以及加速。當然，文中提到的我們場景下的多Alluxio集羣的互訪問題需要進一步解決。
