作者：楊洋 北京多點線上 進階架構師
摘要：大資料計算服務(MaxCompute，原名ODPS)是一種快速、完全托管的TB/PB級資料倉庫解決方案。MaxCompute向使用者提供了完善的資料導入方案以及多種經典的分布式計算模型，能夠更快速的解決使用者海量資料計算問題，有效降低企業成本，并保障資料安全。在本文中北京多點線上進階架構師楊洋分享了基于MaxCompute建構Noxmobi全球化精準營銷系統。
本文内容根據演講視訊以及PPT整理而成。
多點線上屬于泛娛樂行業的公司，主打産品是Nox夜神模拟器，其主要用于在PC端玩手遊，該産品目前已經穩居國内市場占有率第一兩年多的時間了，處于行業上司者的地位。Nox下面主要有兩個品牌：Noxmobi和Influencer。
演講嘉賓簡介：
楊洋，多點線上進階架構師。
本文分享将主要圍繞以下三個方面：
一、行業及公司背景介紹
二、廣告業務和系統
三、相關技術及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廣告系統演進
ac2ff3a2bedd0907fbb6783900f38f223619dc56
如上圖所示的是Nox廣告系統的演進情況，首先可能與小開發者一樣直接內建第三方的SDK，而第三方的SDK的廣告是完全不能被控制的，隻不過會每天給Nox一定的收益，而在這個階段其實收益也是比較低的。後來，Nox就自己做了一個廣告展示子產品，由業務同學去接國外的離線Offer，在國外某些廣告主或者品牌會放出來一些離線的Offer，這樣的收益就比第一階段高出了很多，這個階段的系統會自己在用戶端做展示子產品，而在業務Server裡面則會有相應的展示控制子產品，再往後就是在接到Offer之後做一些簡單的CTL預估，之後再做一些比較并将收益比較高的投放出去。第三個階段系統展現圖中的中心部分就是廣告業務，最外層的兩個子產品就是原來的業務系統，最外層兩個子產品之間的連接配接就會變得很細，基本上隻做流量切分的工作，而中心部分就是前面所提到的DSP、SSP以及內建的ADX子產品，進而形成一個完整的廣告生态。在這裡，除了自己本身的DSP還會和第三方的DSP進行競價保證流量的收益最大化。此外，SDK還可以做成融合的，雖然其不開放，但是将做成展現其他第三方SDK也會産生一些收益。
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目前也在尋求更多的合作夥伴，希望更多與具有出海意向的開發者進行深入合作。