网剧和网络综合体已经成为人们的“最佳休闲产品”，除了精彩的内容，还有各种补丁广告。细心的你可能会发现，这些广告似乎知道你在想什么，明白你在想什么，而且经常击中你的喜好。这是为什么？因为这些广告的背后，涉及到机器学习、多维时间序列预测等技术和场景。要讲清楚这背后的故事，首先要知道什么是广告库存。
什么是广告库存？
在广告的计算中，库存是指广告机会的存量，由媒体和流量两个要素组成。媒体是内容和广告的载体，以视频、音频、文字等不同形式提供内容和广告空间；流量与广告机会的存量和价值有关。广告机会的价值取决于流量本身，由高消费潜力用户构成的流量价值自然更高；广告机会的存量很大程度上取决于用户的观看习惯和浏览习惯。比如在50分钟的一集《弃兵于后翼》中，媒体平台以前贴、中贴、后贴的形式一共设置了4个广告位，如下图所示。
广告机会指示
对于任何一个观看这一集《弃兵于后翼》的用户来说，视频中的广告空间都是这样设置的，但至于50分钟的视频能提供多少广告机会，则因人而异。例如，有两个用户，李雷和韩梅梅。李磊从头到尾都看了视频，甚至在专题片结束30秒后才看完贴片广告。那么李磊提供的广告机会是4个；韩梅梅没有那么耐心。看了三分之一的视频，看到第二个广告后关掉视频，韩梅梅提供的广告机会是2个。即使后三分之二的视频内容中有两个广告位，也没有机会展示出来。
库存预测在计算广告业务中起着重要的作用。对于品牌广告而言，买卖双方交易匹配的前提是对不同定向条件下广告库存的准确预测；在效果广告中，如果能够有效预测交易价格随时间波动的媒体流量的概率分布，作为购买者的市场参与者将能够以固定的预算对流量进行竞价。
预测广告库存:多维时间序列预测
基于以上例子，应该更容易理解，广告库存本质上是不同用户画像下的广告机会存量。那么，如何预测广告库存呢？由于广告库存依赖于流量，并根据方向条件进行划分，我们自然会想到将这个业务问题转化为多维时间序列预测。一旦有了技术方向，剩下的就是技术选择。无论是从用户角度的用户画像，还是从广告主角度设置的定向条件，本质上都是不同维度的交叉组合。例如，给定性别、年龄和省份三个维度，至少有2x100x52个组合来描述不同的人群。如果以小时为单位统计不同人群贡献的广告库存，那么每一群人都有其对应的库存顺序。显然，广告库存序列的数量和人一样多——这就是多维时间序列名称的由来。对于多维时间序列预测场景，计算广告公司飞轮至少有三种技术方案，如下图所示。
不同技术方案的优缺点
在飞轮的业务场景中，我们需要根据各种方向性条件，以小时粒度来预测未来三个月的广告库存。这种业务需求至少面临四个挑战:
多方向条件的交叉组合导致维度爆炸，带来数据分布的长尾效应；
维度爆炸导致的工程复杂性。如果为每个序列建立时间序列模型，工程和运维成本难以想象；
非常长的时间序列。在传统的金融时间序列预测中，预测周期往往不超过120个时间单位，但在FreeWheel的场景中，需要向前预测2160个时间单位；
海量数据挑战。飞轮的日广告量达到10亿。要预测2160个时间单位，至少要回溯同样长的时间段，也就是说至少要回溯3个月的数据，数据规模可想而知。
机器学习团队的主要功能是利用机器学习算法为业务赋能，团队的核心竞争力在于算法，专注于机器学习在计算广告业务中的应用和落地。与专职算法研究不同，算法的应用和落地需要团队具备算法研究与实现、模型优化、项目交付等能力。受限于团队规模和有限的人力资源，飞轮无法承担巨大的工程和运维成本，因此上表中的方案1很快被淘汰。
方案二在一定程度上降低了工程成本，但训练阶段时序预测前聚类和推理阶段反规格化前预测的非端到端过程仍然繁琐。非端到端解决方案的主要痛点在于工程耦合组件数量多，耦合组件过多带来的副作用是端到端稳定性差。为了尽量减少后期的运维成本，我们最终选择了上表中的方案3。尽管选项3中涉及的深度模型很复杂，调优挑战也很大，但它是团队的核心价值。
技术方案敲定后，接下来要考虑什么技术栈。众所周知，端到端机器学习管道至少包括以下几个环节:
飞轮通常使用Presto分布式数据库拉取数据源，然后使用高效的分布式计算引擎Apache Spark做数据预处理、特征工程和样本工程。就机器学习算法而言，Spark的ML算法库提供了丰富的经典算法实现，支持大样本下的分布式模型训练。但是对于参数数百万甚至上亿的深度模型，只需要模型并行，Spark基于数据并行的实现有些不足。单点超大规模深度学习模型的存储和更新已经超过了硬件资源的上限，导致模型训练失败。鉴于此，飞轮采用支持模型并行机制的TensorFlow，实现定制化的深度学习模型。得益于Keras Functional API，飞轮快速实现了定制化的深度网络结构，并在单机环境下贯穿了训练过程。接下来，基于三个月大小的大规模样本，在分布式环境下迭代优化模型。对于算法人员来说，网络结构调整和超参数调整是家常便饭。重复迭代对分布式训练环境的稳定性和运行效率提出了更高的要求。目前，TensorFlow的分布式部署主要有以下几种方式:
三种部署方案各有优势。基于Spark或YARN的部署方式适合已经部署Hadoop生态系统的数据和算法团队；基于Kubernetes的部署模式非常有利于线下模型训练和线上模型服务的融合统一。但是对于这三种部署方案，不难发现，每一种都需要TensorFlow和底层框架之间的集成和耦合。对于飞轮机器学习团队来说，没有多余的时间和精力去构建这样一个分布式训练集群。对于一个专注于算法研究和落地的小规模团队来说，飞轮最需要的是一个“马上来，马上走”的分布式训练环境，可以按需使用，用后丢弃。因此，cloud调研了多种云原生分布式机器学习平台，最终选择亚马逊SageMaker实现分布式模型训练、优化和部署，从而打通了整个端到端的大规模机器学习管道。
为什么是亚马逊管理制造商？
Amazon SageMaker通过两种方式提供了从开发到部署的一整套分布式功能:开箱即用和深度定制。在开发端，Amazon administraker提供的Jupyter笔记本和脚本模式，让开发者可以根据业务需求充分定制深度模型。开发人员只需要几行框架代码就可以将现有的TensorFlow代码迁移到Amazon SageMaker，只需要几个有限的参数就可以按照指定的模型和数量自由启动和停止分布式训练集群。对于分布式模型训练，Amazon SageMaker在模型并行性上支持参数服务器和Horovod两种实现，在硬件资源上支持CPU和GPU。这种开放性允许开发人员结合业务场景灵活地构建运行时环境。
在模型训练过程中，Amazon SageMaker控制台提供的可视化面板让开发者可以及时监控模型的训练过程、收敛性、拟合能力和泛化能力，以便开发者在下一次迭代中有针对性。对于模型调优，算法人员最头疼的无疑是超参数调优、网络结构变化、激活函数、学习速率、优化函数等等。对于深度模型，网格搜索和随机搜索逐渐淡出视野，超参数优化的趋势是利用机器学习优化机器学习，即通过机器学习选择超参数；值得一提的是，超参数调优作为类别之一，在Auto ML如火如荼的时候应用最为广泛。Amazon management aker的Auto Pilot支持自动超参数调优，让开发人员可以开箱即用地充分享受Auto ML开发的红利。
在部署方面，亚马逊SageMaker提供的API允许开发人员以按需方式启动和停止分布式培训集群，按需使用，按需付费，用完就停。不仅如此，亚马逊SageMaker从2017年底开始支持Spot，在现有的基础上，将FreeWheel的云成本降低了至少50%。Amazon SageMaker为开发者提供了一套完整、全面的功能，由于篇幅有限，很难一一描述。
那么，亚马逊SageMaker是如何帮助flywh实现大规模多维时间序列预测的呢？有什么效果和好处？2021年1月13日，在亚马逊re:Invent2020计算广告与营销“分布式机器学习为数字视频和电视广告服务”专题发布会上，AWS资深开发者传播者王予波和FreeWheel机器学习团队负责人Leo为大家讲述了其中的细节，敬请期待！
程序员如何避免陷入“内卷化”，什么技术最有前途，中国开发者的现状和技术趋势如何？快来参加“2020中国开发者调查”，奖品多多送！
