摘要：大數據計算服務(MaxCompute，原名ODPS)是一種快速、完全託管的TB/PB級數據倉庫解決方案。MaxCompute向用戶提供了完善的數據導入方案以及多種經典的分布式計算模型，能夠更快速的解決用戶海量數據計算問題，有效降低企業成本，並保障數據安全。在本文中北京多點在線高級架構師楊洋分享了基於MaxCompute構建Noxmobi全球化精準營銷系統。
本文內容根據演講視頻以及PPT整理而成。
多點在線屬於泛娛樂行業的公司，主打產品是Nox夜神模擬器，其主要用於在PC端玩手游，該產品目前已經穩居國內市場占有率第一兩年多的時間了，處於行業領導者的地位。Nox下面主要有兩個品牌：Noxmobi和Influencer。
PPT材料下載地址：https://yq.aliyun.com/download/2727
視頻地址：https://edu.aliyun.com/lesson_1010_8791?spm=5176.10731542.0.0.UvzDru#_8791
產品地址：https://www.aliyun.com/product/odps
演講嘉賓簡介：
楊洋，多點在線高級架構師。
本文分享將主要圍繞以下三個方面：
一、行業及公司背景介紹
二、廣告業務和系統
三、相關技術及MaxCompute應用
一、行業及公司背景介紹
行業介紹：什麼是數字營銷
目前全球廣告市場規劃約6000億，其中約30%為網際網路和移動網際網路廣告，所以這塊蛋糕也是很大的。數字營銷、網際網路廣告、在線廣告、計算廣告、程序化廣告等所說的基本上都是同一件事情，這些主要解決的問題就是如何在網際網路媒體上投放廣告的問題。
行業介紹：什麼是數字營銷？
數字營銷主要有三方參與者：廣告主、媒體和中間商。
廣告主（需求方）：其需求往往是面對流量和庫存的，其最大需求就是如何成本更低，效果更好。而效果的定義往往是不同的，一般分為品牌和效果兩種。對於品牌而言，比如可口可樂打廣告，人們看到廣告可能不會立即去買一瓶喝，但是品牌廣告會深植在人們的心裡，進而產生長期的效應；而效果廣告比如在頭條上看到一個廣告，用戶當時看到有興趣可能就會點擊之後進行下載了，這樣就能發生直接的轉化效果，這種就叫做效果廣告。
媒體（供應方）：其需求比較簡單，就是如何收益更高。收益具有長期和短期之分，媒體往往不能因為短期的高利益而放棄媒體的形象，這樣才能讓長期的利益更高。
中間商：主要就是通過連接供需來賺差價。有些廣告宣傳的中間商不賺差價基本上是不可能的，只不過是怎麼賺和什麼時候賺的問題。賺取差價的主要手段就是規模效應和壟斷，而無論是廣告主和媒體只要能夠壟斷就能夠具有更高的議價權。
總而言之，數字營銷就是應用最新的網際網路技術來提高營銷效率，會應用比較前沿的人工智慧、機器學習、經濟學上的博弈論等。廣告主會追求減少浪費，讓最合適的人看到廣告，這也是數字營銷相比傳統營銷的特點。媒體則是將廣告為賣給最需要的人，最需要的人則將會通過出價體現自己的需要。中間商則是高效地撮合交易。如下圖所示的是廣告行業的簡單生態圖，圖中的DSP大概就是前面提到的需求方，也就是廣告主。其右邊是流量方也就是媒體，下面這部分則是賺取差價的中間商。
二、廣告業務和系統
Nox夜神介紹：Three major product systems support to capture high-LTV users with low cost
上圖中最左邊是Noxmobi廣告平台；中間的是Influencer，在國外基本上就是網紅；最右邊的NoxPlayer和NoxCleaner就是Nox自有的媒體流量，多點在線的廣告也主要會投放在這些廣告上。
Nox夜神介紹：Manage Every Marketing Stage
如上圖所示的是夜神在發行前期、中期和後期所應該使用的相應產品。
Nox夜神介紹：Pre-Launch and Launch Marketing
如上圖所示的就是Nox流量上的廣告位，圖中右側是模擬器的啟動圖和Launcher部分的廣告位，這些廣告也不會非常影響用戶的體驗。Nox主要是做海外的生意，而國內和海外的廣告市場是不同的，所以也是分開來做的。
NoxInfluencer示例
如上圖所示的是目前主推的Influencer，目前也有一波流量紅利，找網紅推送APP，右圖是Nox為Keep做的廣告，比如在健身教練所發出的視頻或者直播，給教練一些收益，一起來做視頻，也可以看到Keep的廣告收益也是非常好的。目前Nox也對於自己的流量端產品用Influencer進行營銷，花費大約10萬，使得自然新增達到了每天1萬，APP開發者都知道這其實是一個非常可觀的數字，因為自然新增能夠將應用在GooglePlay上的排名推到很高的位置，使得NoxCleaner在一些國家直接達到工具排行榜的前三。
廣告業務流程介紹：Online advertising
在線廣告業務的基本流程可以從用戶的訪問開始，用戶首先打開一個APP或者訪問一個頁面，當發生了用戶訪問行為之後，一般在APP裡面會有廣告的SDK，之後SDK就會觸發展示然後去請求廣告的內容。SDK一般會與一個SSP關聯，屬於某一家SSP，然後去SSP上請求廣告。SSP再對接ADX，也就是之前所提到的中間商，其主要負責撮合交易。ADX又會對接很多的DSP，並向很多的DSP發起競價邀請，DSP則將會代表廣告主決定是否需要投廣告以及廣告的出價是多少，並在ADX進行多家的比較，做一次競價的拍賣，價高者得，但是按照第二高價收費，再將獲勝者一步步返回給用戶，用戶最終就會看到贏得本次競價的廣告。廣告後續還會發生一些點擊、下載、安裝等行為，並進行進一步跟蹤。
Nox廣告系統演進
如上圖所示的是Nox廣告系統的演進情況，首先可能與小開發者一樣直接集成第三方的SDK，而第三方的SDK的廣告是完全不能被控制的，只不過會每天給Nox一定的收益，而在這個階段其實收益也是比較低的。後來，Nox就自己做了一個廣告展示模塊，由業務同學去接國外的離線Offer，在國外某些廣告主或者品牌會放出來一些離線的Offer，這樣的收益就比第一階段高出了很多，這個階段的系統會自己在客戶端做展示模塊，而在業務Server裡面則會有相應的展示控制模塊，再往後就是在接到Offer之後做一些簡單的CTL預估，之後再做一些比較並將收益比較高的投放出去。第三個階段系統展現圖中的中心部分就是廣告業務，最外層的兩個模塊就是原來的業務系統，最外層兩個模塊之間的連接就會變得很細，基本上只做流量切分的工作，而中心部分就是前面所提到的DSP、SSP以及集成的ADX模塊，從而形成一個完整的廣告生態。在這裡，除了自己本身的DSP還會和第三方的DSP進行競價保證流量的收益最大化。此外，SDK還可以做成融合的，雖然其不開放，但是將做成展現其他第三方SDK也會產生一些收益。
三、相關技術及MaxCompute應用
DSP 系統數據流及相關服務
SSP和ADX相對而言比較簡單，因此在這部分將會重點講述一下DSP系統數據流。Rtb就是Runtime Bidding，也是DSP裡面比較重要的一個部分，主要是做實時競價的。所以廣告流程一般而言就是從Rtb模塊開始，在競價的過程中會產生Bidding的Event，並將Bidding的Event都輸入到Kafka裡面，Kafka裡面會有訂閱的消息，一直更新大的Cache，這裡面的數據會通過流式計算做成feature再反饋給Rtb系統。Pixel就是事件服務，比如發生了展現或者安裝之後就會訪問到這個服務，而這個服務將會Tracking到本次廣告的所有Session，這樣的數據也會流入Kafka，同樣由Updater和流式計算進行處理。而從Kafka裡面會另外分出來一隻數據流通過高速通道回流到中心節點，也就是MaxCompute上面。MaxCompute會進行一些離線的報表計算和特徵，報表就會輸出到DSP Report上面（比如RDS）。
其實Nox設計的所有廣告的核心數據將會走這樣的一套比較複雜的流程，而一些運營相關的非核心數據則會主要使用了自己搭建在阿里雲上的神策這款BI服務，其也屬於企業級的應用服務。
流式計算Spark Streaming應用
流式計算Spark Streaming主要用於實現實時的報表以及實時特徵的計算。因為業務的主要要求是必須穩定並且能夠實現7*24小時的可用。可以接受秒級延遲，比如廣告投出去了，晚10秒鐘展現在報表里也是沒問題的。可根據吞吐量橫向擴展，比如突然新接了幾家SSP，突然變得流量很大，不能在這個時候讓系統掛掉。此外，因為業務在全球都有，所以需要全球的聚合任務，需要通過一個平台看到各個國家的數據。
Nox選擇的方案就是：Spark Streaming能夠將上面幾項需求全部滿足，另外就是配合Kafka、RDS以及Redis做輸出。在部署上面，需要實現小集群獨占，這裡所用到的就是阿里雲EMR，其可以幫助客戶託管集群，Nox只需要在阿里雲EMR上面申請一個小集群，比如三到五台機器，這些機器申請之後就不再釋放掉了，會一直獨占著，並且7*24小時地跑流式計算任務。原始日誌壓縮流式回傳，這個是因為Nox在各個數據中心都有Bidder或者Pixel的服務，會產生很多數據，之前的一種方案是在每個中心先將數據計算成半成品，之後在進行回傳，這樣所用的帶寬就會比較小，但是如果採用這樣方案，那麼所有的功能都需要開發兩套，在本地先計算，之後傳回來再進行聚合計算，這樣就會比較複雜，因此最終決定將日誌進行壓縮，以流式方式進行回傳，這樣的方案在驗證之後發現所占的帶寬不是很大，而因為是流式傳輸，因此帶寬也比較平穩，雖然這裡所用的帶寬屬於高速通道帶寬，因此成本也可以接受。而壓縮則使用了Kafka，其是能夠支持壓縮協議的。此外，中心節點部署能夠方便開發。
上圖中最底層就是阿里雲的EMR託管服務，在其上是DSP平台和SSP平台，他們的集群是分開的，如果流量特別大，某一個平台被打掛掉了，另外一個平台是不會受到影響的。而託管服務的好處就是能夠託管很小的集群，對於企業而言也沒有什麼成本。Kafka裡面輸入的就是Event的Topic，之後還會輸出回Kafka，這樣Updater再將Kafka裡面的數據放到Redis或者RDS用於構建模型和計算報表。這樣的設計的唯一問題就是比較依賴於高速通道，這樣穩定性和擴展性就有可能受到限制。
離線計算MaxCompute應用
離線計算部分，Nox主要使用了MaxCompute。幾乎使用了MaxCompute來解決各類數據計算問題，BI數據、廣告報表、反作弊、標籤抽取、特徵數據計算、統一用戶標識、爬蟲數據處理等。其實在一開始，Nox也是自建Hadoop集群，購買了阿里雲的ECS搭建集群，從最開始的6台一直到後來的十幾台，這時候實在扛不住了，機器經常宕機，因為使用的是Spark，因此內存很容易占滿，某一天用戶突然增多了，數據就沒了。此外，這樣的成本也非常高，因為當時主要運行BI數據，所以基本上都是在晚上運行的，而白天機器則處於空閒狀態，因此成本很高。後來採用了EMR的按量付費集群，晚上申請之後跑數據，但是白天能夠釋放掉，但是這樣的過程則是比較漫長的，需要10到20分鐘。後來Nox開始接觸到MaxCompute，使用起來非常好，其帶來了很多優勢。首先，不再需要運維集群了，此外其計算速度很快，雖然說Spark的計算速度很快，但是小集群的Spark和大集群的Hadoop是無法比擬的，所以大集群的Hadoop其實計算速度是很快的。MaxCompute是真正的按量付費，因此成本也能夠大大降低，而自建Hadoop、使用EMR以及使用MaxCompute的成本是成量級降低的。差距也是非常大的。主要使用SQL開發，效率比較高，也便於調試，文檔也比較清晰。此外，MaxCompute還提供了一個還不錯的調度系統，如果是自己搭建這樣調度系統還是比較困難的。
對於數據的導入和導出而言，因為Nox有很多海外的服務，有些服務是不能覆蓋到的。所以Nox採取的策略是優先使用數據同步服務，而流式數據則使用SDK，當數據同步和SDK都不合適就寫腳本+tunnel導入和導出數據。
如上圖所示的文件數據主要是爬蟲，因為一些服務的日誌是達到OSS上的，並且有一些外部數據也是先上傳到OSS上面的。RDS則是什麼都有的，廣告業務數據就是前面所提到的，這些數據會選擇合適的方式統一進入到MaxCompute的分區表裡面。SQL計算基本上都會用到，MaxCompute則是在SQL寫起來很費力或者運行很慢的情況下使用。圖計算使用的並不多，只是會在計算同一用戶UUID的情況下使用，這裡應用了最小連通域的算法，比如一個用戶使用了多個設備，則需要將這些設備統一地關聯到同一個用戶身上。而PAI平台對於廣告的CTL預估非常重要。
特徵計算和標籤抽取
如下圖所示的某第三方DMP的對外標籤體系的示例，大概分了幾類，比如人口學、設備信息等大類，在每個大類下面還會有多個標籤。特徵一般而言就是連續值，標籤則是指將連續值做一些規則之後所打的標籤。舉例而言，定義特徵，最近一周內活躍天數，則有0~7的取值。而定義標籤規則，則是一周內活躍0天、1天、2~3天、4~5天、6~7天的分別是不活躍、低活躍、中活躍、高活躍、極高活躍用戶。當在做好定義之後，就要看大家的SQL寫的是好是壞了。之前在不支持with的時候，SQL代碼一般都要寫很大一堆，而且很難改動。此外，在寫SQL的時候注意代碼分隔還是很重要的。另外的一些建議就是優先使用內建函數，雖然一些內建函數和UDF的功能差不多，可能一個UDF能夠實現兩三個內建函數的功能，但是效率卻相差了很多，雖然使用內建函數會讓代碼看起來丑一些，但是絕對比UDF運行速度要快得很多，所以在內建函數無法滿足需求的時候再去考慮UDF，實在不行就可以用MapReduce實現，比如對一大批特徵做等頻離散化。
上述這些都是DMP的標準功能，但是Nox目前還沒將其實現平台化，都是使用標籤寫的。而阿里雲上有標籤服務，目前也在考慮使用。
Targeting
所謂Targeting就是人群定向，相對於把特徵輸入模型而言，標籤式Targeting主要是方便人來操作，使用投放人的經驗通過標籤定向的方式來優化表達。比如在廣告投放初期可以比較好地縮放盲打範圍。另外一種則是Look-alike方式，Look-alike方式的定向為尋找相似的人，種子用戶為正例，從所有用戶中找到正例機率較大的人群。以上就是定向的兩種主要方式。
如上圖所示的定向的主要做法就是將內部和外部的數據輸入到MaxCompute裡面，經過各種計算將標籤化的數據或者用機器學習標註好的數據同步到線上並緩存好。之後在進行實時競價RTB裡面查詢緩存，命中之後就在DSP裡面由廣告主配置，命中了就投放廣告，否則就不投放。
Ctr預估
Ctr預估是Nox投入比較多的一項工作。Ctr預估並不一定是預估Ctr，還可能去預估Cvr甚至是Ctr和Cvr的乘積，這些統稱為Ctr預估。其作用是首先計算Ecpm的值，Ecpm就是每次展現的期望收益，期望是一個機率論上的概念，其等於用單價乘上本次收益可能的機率。Ecpm也將指導絕大部分投放相關策略。
如上圖所示，主要分為兩條線，一條是離線數據會走MaxCompute，而在線則會走Spark Streaming。總體最後會輸入到標籤和特徵的大Cache裡面，Cache中的數據有一部分直接加載到內存裡面，另外一部分比如用戶特徵無法加入內存就會在Inference服務查詢緩存，這裡就會組合出一個特徵的向量，用來計算Ctr的值，並將值返回給Rtb的Bidder，在Bidder做一系列的策略，最終得出競價的決策。競價完成之後，是否參與、是否競價成功以及是否展現等日誌都會灌入回MaxCompute或者Spark Streaming進行模型訓練，最終對已有模型進行更新，形成一個整體的閉環。Online model需要使用Spark Streaming，而Deep learning就需要用TensorFlow等了。
Pacing
Pacing比較複雜一些，其就是不止考慮單次展現的收益，而要在單次競價時考慮對全局收益的影響，比如考慮一天之內總收益如何，比如可能將轉化率最高的Offer在一天開始的兩小時內都投完了，但是其他的Offer都沒有投出去，這樣計算下來總收益並不如將全部廣告都投完的收益高。Pacing的整體思路就是通過對流量分層和分時的統計和預估，用數學方法來保證全局收益的最大化。Nox則根據Yahoo的論文實現了自己的方案，這裡面最核心的就是將Ctr估算準確，並將分層和分時的各種統計值計算好，然後按照其策略執行即可。
Nox目前也在尋求更多的合作夥伴，希望更多與具有出海意向的開發者進行深入合作。
如需了解更多關於MaxCompute產品和技術信息，可加入「MaxCompute開發者交流」釘釘群；
群號11782920，或掃描如下二維碼加入釘釘群。
更多行業上雲案例敬請關注【阿里云云棲號】
本文為阿里雲原創內容，未經允許不得轉載。