網劇、網綜早已成為人們的“休閑佳品”，除了精彩內容，還有各種貼片廣告推送。細心的你也許會發現，這些廣告仿佛知你所想，懂你所思，常常能擊中你的喜好，這是為什么呢？因為這些廣告背后，涉及了機器學習與多維時序預測等技術和場景。要講清楚這背后的故事，首先，我們要了解什么是廣告庫存。
什么是廣告庫存？
在計算廣告中，庫存指的是廣告投放機會的存量，廣告投放機會由兩個要素構成：媒體與流量。媒體是內容與廣告的載體，以視訊、音頻、文字等不同形式提供內容與廣告位；流量則關乎廣告投放機會的存量與價值，廣告機會的價值取決于流量本身，由高消費潛力用戶構成的流量價值自然更高些；廣告機會的存量則很大程度由用戶的觀看習慣、瀏覽習慣所決定，舉例來說，一集50分鐘的《后翼棄兵》，媒體平臺以前貼片、中貼片和后貼片的方式總共設置4個廣告位，如下圖所示，
廣告機會示意
對于任何一個觀看這集《后翼棄兵》的用戶，視訊中的廣告位都是如此設置，但是，至于這 50 分鐘的視訊到底能提供多少個廣告投放機會，那就因人而異了，比如有兩個用戶，李雷和韓梅梅，李雷將視訊從頭看到尾，甚至把正片結束后 30 秒的后貼片廣告也看完了，那么李雷提供的廣告投放機會就是 4；韓梅梅則沒那么有耐心，視訊看了 1/3，看到第二個廣告之后便把視訊關掉，那么韓梅梅提供的廣告投放機會是 2，即便后面 2/3 的視訊內容中還有兩個廣告位，但是已經沒有機會展示出來了，
在計算廣告業務中，庫存預測扮演著重要角色，對于品牌廣告，買賣雙方交易撮合的前提是不同定向條件下廣告庫存的準確預測；效果廣告中，對于交易價格隨時間波動的媒體流量，如果能夠有效預測其在未來一段時間的概率分布，那么作為買方的市場參與者在預算固定的情況下對于流量的競買會更加游刃有余，
預測廣告庫存：多維時序預測
基于上面的示例，應該更容易理解：本質上，廣告庫存是不同用戶畫像下廣告投放機會的存量。那么，廣告庫存該如何預測呢？既然廣告庫存取決于流量且按照定向條件（用戶畫像）劃分，那我們自然想到將這個業務問題轉化為多維時序預測，一旦有了技術方向，剩下的就是技術選型問題了，無論是從用戶視角出發的用戶畫像，還是從廣告主視角出發設置的定向條件，本質上都是不同維度的交叉組合。例如，給定性別、年齡、所在省份三個刻畫維度，至少有 2x100x52 種組合來刻畫不同的人群，如果以小時為單位統計不同人群貢獻的廣告庫存，那么每一個人群都有與之對應的庫存序列，顯然，有多少人群，就有多少廣告庫存序列——這也正是多維時間序列名字的由來，對于多維時序預測場景，計算廣告公司 FreeWheel至少有 3 種技術方案，如下圖所示，
不同技術方案優缺點
在 FreeWheel 的業務場景中，我們需要基于種類眾多的定向條件（內容來源、地理位置、播放設備、用戶畫像等）以小時為粒度預測未來 3 個月的廣告庫存。這樣的業務需求至少面臨 4 個方面的挑戰：
-
眾多定向條件的交叉組合造成維度爆炸，維度爆炸又帶來數據分布的長尾效應；
-
維度爆炸帶來的工程復雜度。如果為每個序列構建時序模型，那么工程與運維成本無法想象；
-
超長時間序列。在傳統的金融時序預測中，預測周期往往不超過 120 個時間單元，但在 FreeWheel 的場景中，需要向前預測 2160（24×90）個時間單元；
-
海量數據挑戰，FreeWheel 日投放廣告量達到10億級規模，為了向前預測2160個時間單元，至少需要回溯同樣長的時間周期，也就是說至少要回溯3個月的數據，數據規模可想而知。
機器學習團隊的主要職能在于利用機器學習算法賦能業務，團隊的核心競爭力在于算法，專注于機器學習在計算廣告業務中的應用與落地。與專職算法研究不同，算法的應用與落地要求團隊同時具備算法鉆研與實現、模型調優、工程交付等多方面的能力。受限于團隊規模與有限的人力資源，FreeWheel 無法承受龐大的工程與運維成本，因此上表的方案1被迅速排除，
方案2雖然在一定程度上降低了工程成本，但是訓練階段先聚類再時序預測、推理階段先預測再反歸一化的非端到端流程依然比較繁瑣，非端到端解決方案的主要痛點在于工程耦合組件較多，耦合組件過多帶來的副作用就是端到端的穩定性較差，為了將后期運維成本降至最低，我們最終還是選擇了上表中的方案3。盡管方案3涉及的深度模型復雜度較高、調優挑戰較大，但這正是團隊的核心價值所在。
技術方案敲定后，接下來需要考慮的是采用哪些技術棧。眾所周知，端到端機器學習流水線至少囊括以下環節：
FreeWheel 通常使用 Presto 分布式資料庫來拉取數據源，然后利用高效的分布式計算引擎 Apache Spark（Databricks商業版本）來進行數據預處理、特征工程和樣本工程，就機器學習算法來說，Spark 的 ML 算法庫提供了豐富的經典算法實現并且支持大規模樣本量下的分布式模型訓練。不過，對于參數量動輒百萬甚至上億的深度模型來說，模型并行是剛需，Spark 基于數據并行的實現方式便有些力不從心，超大規模的深度學習模型在單點中的存儲與更新已然超出硬件資源上限，從而導致模型訓練無法順利完成，鑒于此，FreeWheel 采用支持模型并行機制的 TensorFlow 來實現自定義的深度學習模型。得益于 Keras Functional API，FreeWheel 很快便實現了定制化的深度網路結構并在單機環境中跑通了訓練流程，接下來便是基于3個月體量的大規模樣本在分布式環境下不停地迭代、調優模型。對于算法人員來說，網路結構調整、超參調優是“家常便飯”，周而復始的迭代對分布式訓練環境的穩定性與運行效率提出了較高要求，就目前來說，TensorFlow 的分布式部署主要有如下幾種方式：
三種部署方案各有千秋，基于 Spark 或 YARN 的部署方式適合已經部署 Hadoop 生態的數據和算法團隊；而基于 Kubernetes 的部署方式則非常有利于離線模型訓練與在線模型服務的融合與統一，不過，對于這三種部署方案，我們不難發現這其中的每一種都需要 TensorFlow 與底層框架的集成與耦合，對于FreeWheel 機器學習團隊來說，沒有額外的時間和精力來搭建這樣的分布式訓練集群，對于一個規模小、專注于算法研究與落地的團隊來說，FreeWheel 最需要的是“召之即來、揮之即去”的分布式訓練環境，按需而用，用完即棄。于是，FreeWheel 調研了多種云原生的分布式機器學習平臺，并最終選擇了Amazon SageMaker 來實現分布式模型訓練、調優、部署，從而打通整條端到端大規模機器學習流水線，
為什么選擇AmazonSageMaker？
Amazon SageMaker 從開發到部署，以開箱即用和深度定制化兩種方式提供了完備的分布式功能集合。在開發方面，AmazonSageMaker 提供的 Jupyter notebook 與腳本模式允許開發者根據業務需要充分定制深度模型，開發者僅需幾行框架代碼（Skeleton code）即可將現有的 TensorFlow 代碼遷移至Amazon SageMaker，僅需幾個有限的參數即可按指定機型、數量自由啟停分布式訓練集群。對于分布式模型訓練，Amazon SageMaker 在模型并行方面支持兩種實現方式：參數服務器與 Horovod，在硬件資源方面支持 CPU 與 GPU，這種開放性允許開發者結合業務場景（圖像識別、分類回歸、時序預測等）靈活地構建運行時環境，
在模型訓練過程中，Amazon SageMaker console 提供的可視化面板讓開發者可以及時監測模型訓練過程、收斂情況、擬合能力、泛化能力，從而使開發者在下一輪迭代中做到有的放矢，對于模型調優，算法人員最頭疼的無疑是超參調優、網路結構變更、激活函數、學習率、優化函數等等，不一而足。對于深度模型，網格搜索和隨機搜索逐漸淡出視野，超參調優的趨勢是利用機器學習來調優機器學習，即用機器學習的方法來選擇超參數；值得一提的是，在Auto ML如火如荼發展的當下，作為其中一個門類，超參調優被應用得最為廣泛。AmazonSageMaker的Auto Pilot為自動超參調優賦能，允許開發者以開箱即用的方式充分享受Auto ML發展的紅利，
部署方面，Amazon SageMaker 提供的 API 允許開發者以按需方式啟停分布式訓練集群，按需而用、按需付費、用完即停，不僅如此，Amazon SageMaker 自 2017 年底開始支持 Spot 機型，這一機型的支持使 FreeWheel 的云上成本在現有的基礎上又降低了至少 50%。Amazon SageMaker 為開發者提供的功能集合完備而全面，鑒于篇幅有限，難以一一陳述，
那么，Amazon SageMaker 如何助力 FreeWheel 實現大規模多維時序預測？效果與收益如何？2021年1月13日，亞馬遜 re:Invent2020 計算廣告與營銷主題專場會議《Distributedmachine learning for digital video and TV ad serving》（Session ID: ADM302）中，AWS 資深開發者布道師王宇博聯袂FreeWheel 機器學習團隊負責人吳磊，為您傾情講述個中細節，敬請期待！
程式員如何避免陷入“內卷”、選擇什么技術最有前景，大陸開發者現狀與技術趨勢究竟是什么樣？快來參與「2020 大陸開發者大調查」，更有豐富獎品送不停！
