不少互联网外企在曩昔 的十年里把分部开到了中国，它们年夜 多半 都是觊觎这里的庞年夜 市场潜力。当然，也有例外。
对于坐落在年夜 洋彼岸的这座北京研发中心而言，它的出生 完全是因为 FreeWheel 奔着这里有丰富 的技术人才资源而去的结果。在这里上班的 300 多小我 中，除去极少数职能部分 员工外，放眼望去基本清一色都是工程师。
依据 公开资料，这家成立于 2007 年，总部位于美国硅谷的视频告白 公司，主要为年夜 型电视媒体和优质内容供给 商提供企业级的视频告白 解决计划 。它的客户主要在北美以及欧洲，包含 ABC, NBC, ESPN 等美国 90% 以上的主流电视媒体和运营商，单日告白 播放量近 10 亿次。当然，这些销售业绩背后的所有重要产品 研发工作几乎都归功于北京研发中心。
凭借其在国际市场上的业务需求， FreeWheel 的产品 范围 在赓续 扩年夜 ，已经从流量端笼罩 到需求端，而背后支撑产品 运营的年夜 型技术平台，可以接入来自不合 内容的设备甚至不合 协议，比如 支持跨 IP 网络和有线电视网络。他们最终要做的是把基于流量端的技术平台转向全栈平台，甚至自运营流量的偏向 拓展。
当然，作为互联网视频告白 肥饶 的掘金地，已扎根中国十年的 FreeWheel 也想在这块东方土地上扩展出自己的商业疆土 ，但这需要获得 这一市场的接纳，以现在的情形看，更重要的也许是让行业对他们所做的事情获得更年夜 范围 内的认知。
由此，AI科技年夜 本营就 FreeWheel 视频告白 的具体业务模式，在直播场景下的技术解决计划 ，以及人工智能技术在互联网视频告白 的应用等问题，与首席架构师孙年夜 伟等四位受访者聊了聊：
孙年夜 伟，FreeWheel 首席架构师，负责预测系统、告白 办事 器系统的研发工作；
张磊，FreeWheel 架构师，负责数据平台和数据产品 的整体技术把控；
陆琴，FreeWheel 高等 开发经理，主要负责线上质量与监控；
牛励诚，FreeWheel 首席工程师，目前专注于告白 办事 器的基础架构以及告白 法度模范 化交易平台的搭建。
以下为对话内容实录（有删减）：
业务合作流程
AI科技年夜 本营：客户投放告白 时与 FreeWheel 的合作是怎么展开的？
孙年夜 伟：分为两部分 内容，一部分 是勉励 接入流量端。比如 ABC, NBC, ESPN, Comcast 等都拥有异常 好的流量，像比较 好的体育赛事或者片子 ，他们会把告白 流量导入到我们的系统平台里。在需求端，我们允许客户自营告白 ，也叫 O&O（Owned & Operated）告白 。
我们支持这个模式的原因是面对高端视频内容，告白 价值也异常 高，天然适合这些品牌类的告白 ，在这样的市场里，这些顶级流量会通过招标售卖告白 。客户把顶级告白 拿过来，在我们的平台上依照 客户定制化的需求去投放这些告白 。
另外一部分 是法度模范 化交易市场。在一些情况下，当流量到来之后没有特别适合的告白 ，我们引入了法度模范 化交易市场的概念。在一些场景下从交易市场拿到的告白 ，可能对于 FreeWheel 或者对于客户，对于流量端，为了业务价值更年夜 化，我们也会引入法度模范 化告白 跟自营告白 或品牌告白 进行竞争。这样使得我们在整个业务流里实现收益最年夜 化，这是我们现在告白 交易两个主要的偏向 。
牛励诚：我们早期更多是媒体方的告白 办事 器，新的 FreeWheel 要做一个新的平台，一方面要办事 于所有的供给 方，这里的供给 方既包含 了 ABC 这样的优质媒体客户，也包含 非 FreeWheel 的客户。
比如 有些客户不一 定用 FreeWheel 的平台治理 他们的内容和告白 ，然则 我们可以通过法度模范 化的交易方法 把第三方流量导入系统，这样的利益 是购买 方可以通过我们的平台达到 更多的不雅 看者，这些不雅 看者并不仅限于我们自己的客户，也可以从上游接入一些互联网告白 交易平台或第三方的卖方平台（SSP），从而让平台里的告白 购买 方获得更多告白 投放的机会。
然后是需求方，我们支持用户在我们的系统里自己预购告白 订单，联系告白 主签订合同，用我们的平台自己治理 告白 这样的直接售卖方法 。此外还有法度模范 化交易方法 ，对接更多的买方平台（DSP）或者下游的需求，最终目的是让上游的供给 方获得更好的流量货币化的方法 。
我们的平台是全栈的，基于这个平台未来还可以做一件事，我们可以创建 自己的告白 市场，相当于我们自己运营的告白 市场，可以从不合 的供给 方购买 流量，我们来决定这些流量卖给什么样的需求方。
告白 市场的创建 相当于有更年夜 的灵活性，我们整个告白 平台收费的模式也有变更 ，因为传统的更多是办事 于我们的媒体方帮他们投告白 ，比如 CPM 收一个固定的比例，但未来收费方法 看运营情况，如果把告白 以更好的价格卖出去，我们可能抽取更高的提成。
AI科技年夜 本营：告白 涌现 涌现 形式是怎样的？
孙年夜 伟：从用户端来看，跟以前我们基于 CTR 预估比较 类似，我们把事件泛化为 X-event，我们内部的优化目标像可视化曝光（Viewable impressions）这些产品 在预测系统和告白 办事 器系统里都在使用，实质 是向客户端投放他们可能更感兴趣或者收费率更高的告白 。
与搜索告白 、直播平台的竞争
AI科技年夜 本营：与传统的搜索告白 形式比较 ，视频告白 投放方法 在产品 设计和技术应用上有什么不合 ？
孙年夜 伟：我们追求给当前的用户看什么告白 ，能够使得转化率有更年夜 的提升。与传统的搜索告白 相比，第一，在搜索告白 里，内容和告白 的相关性是被考虑的重点，它把跟终端用户兴趣等相关的告白 进行推荐，实现更高转化率。但在视频告白 里，我们发明 用户跟视频及告白 的联系关系 水平 ，在告白 效果进献 上远远高于告白 跟视频的联系关系 水平 ，因为视频不雅 看是一个流式，不太会被打断，换句话说如果视频内容或告白 内容足够好，用户一般不太会离开不看。
所以在搜索告白 中用的推荐技术、协同过滤在我们这儿用的比较 少。我们这里用的更多的是基于逻辑回归、GBDT（Gradient Boosting Decision Tree）这样的技术。
另外，在搜索告白 里点击率一般是在10%以下，深度和笼罩 率会受到比较 年夜 的约束。但在视频里，曝光量产生 率是 80% 到 90% 以上，可视化曝光产生 概率也异常 高，一般在 60% 以上。数字的不一 样带来技术上很年夜 的不一 样，比如 我们的调优目标从5%到10%就是一倍的修改 ，效果提高一倍，然则 我从 60% 提高到 65% 只是十二分之一。
正负样本的平衡也不太一样，比如 50%、60% 正负样本以某种方法 是比较 平衡的。还有其他一些症结 技术点，比如 视频流量远远小于搜索告白 流量，有时是基于范围 的限制等等，有时在搜索告白 里做不了的事情反而在视频里能做。但通用的技术还是比较 统一的，只是细节点不太一样。
AI科技年夜 本营：如果我们要开拓国内市场，业务上最直接的竞争敌手 应该是一些视频和直播平台。
牛励诚：在视频或者直播告白 领域，基本上是业务上的区别。对不合 业务的支持导致技术上不合 的挑战，我觉得可以从几个点说一下，一个是 FreeWheel 的客户散布 在全球各地，使得我们在全球各地安排 多个数据中心来支持不合 地区 的业务。多个数据中心带来的问题是在运维上的庞杂 度，包含 数据中心、数据同步如何做很好的支持，这是因为多个数据中心带来的挑战。
还有 FreeWheel 的客户，我们接入的流量很庞杂 ，我们要面临各类 各样的终端流量，比如 来自于台式机、移动设备和这两年比较 火的 OTT 设备，甚至来自于有线电视。对于不合 终端的集成方法 也不一 样，比如 有线电视告白 投放系统和数字投放系统是两个完全不一 样的系统，特别针对直播这种情况，最近几年常用的视频直播技术都是基于流媒体的直播技术。
还有需求方，除了用户直接售卖自己告白 的方法 ，我们还支持法度模范 化的购买 ，法度模范 化实时的向 DSP 发送 Real-time Bidding 收集需求方的告白 。因为我们的告白 后台不仅仅是一个媒体方的告白 办事 器，也包含 SSP，避免不了的是一方面需要更强年夜 的连接治理 。
如果把 DSP 法度模范 化交易的告白 和客户直接售卖的告白 放在一起，我们需要重新设计一套告白 的排期算法，从而包管 把市场上拿到的DSP告白 和用户自己的告白 放在一起，做一个合理的竞价排序。
所以针对这个场景我们一是要做第三方 DSP 告白 实时转码技术，包管 任何一个 DSP 返回的任何一个告白 可以通过实时转码转成不合 的视频格局 ，可以在不合 终端上播放。
此外，我们的客户是优质内容客户，他们对内容的掩护 意识异常 高，所以我们对第三方告白 有告白 审核处理 ，在确认平安 的情况下才会投放到客户端内容上。年夜 概这几点是跟国内其他的视频、直播告白 投放系统的差别 。
技术的高并发与高可用
AI科技年夜 本营：视频告白 系统支持直播赛事最重要的技术特点是高并发和实时性，结合相关案例谈谈 FreeWheel 的技术系统是怎么实现这些要求的？
牛励诚：高并发和实时响应这两个是相关的问题，因为当我们抛开数据范围 、量级去谈系统性能其实没有意义。
FreeWheel 对每个告白 请求的 SLA 是 300 毫秒，其实内部对告白 响应的时间要求要更严格，年夜 多半 告白 请求在 20 到 30 毫秒之间就要完成响应。对于超等 碗我们最年夜 的挑战是系统压力的提升，在超等 碗之前，我们的客户 NBC 给我们的并发流量的估计 是 500 万并发用户。我们事后统计发明 ，其时 真实并发用户峰值是 300 万。比较 历史上 FreeWheel 后端系统遇到最高的并发量是 100 万，技术挑战也是不一 样的。所以在超等 碗之前我们做了很多事，（考虑）针对全新的并发量级怎么进行扩容和架构调剂 。
先说一下在告白 办事 器方面的优化和调剂 。从扩容角度，我们有考虑垂直扩容和水平扩容。垂直扩容是怎样提高单点性能，除了需要 的硬件升级，我们更多精力花费在办事 端的优化。关
于 Linux 办事 器端的优化，比如 非阻塞 IO 的使用，“锁无关”（lock-free）的数据结构，缓存的使用，这些基来源基础 则年夜 家都不陌生，但要注意一点，可能在优化进程 中，一个是要结合我们的业务选择适合 的优化方法 ，另外要避免过度优化，我们需要在系统性能和代码的可读性、可维护性中取折中、平衡。
再者是算法优化，我们针对超等 碗一些特殊的集成方法 有针对性的进行算法优化，比如 效果比较 显著的优化是我们对整个告白 的定向算法做了优化，优化以后整个告白 请求的响应时间年夜 概节省了 30% 左右，但算法优化也一样要避免过早、过度优化，这是我们做的垂直优化。
AI科技年夜 本营：那我们又是如何解决垂直扩容问题的？另外当办事 器赓续 扩容之后，对整个系统来说，造成更年夜 的累赘 ，从而引发新的问题？
牛励诚：跟垂直扩容对应的是水平扩容，这是为了增加整个集群的总体吞吐量。水平扩容这一块最简单、直接的，最容易想到的办法 是我们增加更多的告白 办事 器。
对告白 办事 器的扩容有几个处所 需要特别存眷 。首先，如果我们希望做到一个平滑的、可伸缩的扩容，我们要包管 告白 办事 器是无状态化的办事 ，需要我们把所有的用户状态保存 到进程以外，把日志输出到 Kafka 消息队列下游，再去对消息队列进行流式的处理 ，做到这一点就满足了做动态平滑扩容的一个前提条件。
在此基础上，我们现在有计划把告白 投放办事 迁移到 AWS 的云办事 器上，这个项目在进行中，我们预计今年 6 月份世界杯的时候，会正式在生产环境中采取 基于 AWS 的混合云安排 。当然我们增加更多的告白 办事 器还会带来一些问题。当我们的告白 办事 器扩容以后，所依赖的办事 和外部依赖也需要相应的扩容和架构调剂 来适应它。
举个例子，我们之前是用 Memcached 做数据库前端的缓存，当我们的系统并发量提升以后，发明 Memcached 的局限性显示出来了，比如 它没有一个特别完美的集群计划 ，现在做的集群计划 运营成本异常 高，因为 Memcached 没有原生的集群计划 ，所以这次我们把所有的缓存数据从 Memcached 上面迁移到加倍 成熟的缓存系统 Aerospike 中，它是原生支持集群计划 的，所以集群的扩容对我们的业务和运维是完全透明的状态。
再比如 我们的告白 计费办事 器。今天我们的告白 计费办事 器设计是中心化的架构，我们所有的告白 办事 器需要连接中心化的告白 计费办事 器来同步告白 预算的信息。这次我们告白 集群扩容年夜 概扩了 1.5 倍，会发明 中心节点的告白 计费办事 器有比较 年夜 的性能瓶颈，所以我们短期做了优化，在告白 办事 器和计费办事 器中间加了缓存，从而减少了直接对计费办事 器 CPU 产生 的压力。历久 来看我们会继续做这个计划 ，可能会采取 去中心化计费办事 器架构，这样从基本 上解决了计费办事 器的单点性能问题。
FreeWheel 告白 办事 器架构是全球多半 据中心、异地多活的架构，当我们的办事 器变多、压力变年夜 以后，对数据中心之间的同步也有挑战。现在我们会试图提供更好的网络 QoS，比如 我们会识别不合 应用、数据的优先级，为不合 优先级的数据提供不合 的带宽优先级，这样可以包管 症结 数据的实时性，而对不是那么症结 的数据可以容忍一准时 间的延迟。
我们也担心 系统一直 的扩容会带来其他的问题，所以现在我们尽量希望减少整个办事 器的粒度。今天我们整个告白 办事 器基本上是比较 粗粒度的安排 ，一个进程里从告白 请求到返回告白 响应，很多的工作流程。
此外，我们目前也尽量希望把整个办事 器架构的粒度更精细化，做一些办事 的拆分，这样我们在扩容方面更有灵活性，只要找到有瓶颈的节点，对那个节点做一些扩容就可以了。
AI科技年夜 本营：还有一点是直播进程 中的实时响应问题。
牛励诚：一方面我们的客户是优质视频客户，在直播场景下没有犯错的空间，一旦错过一个告白 间隙，客户的损失可能是百万美元以上，一旦错过没有机会弥补这个损失，所以这对我们办事 的高可用也提出更高的要求。
架构上高可用主要是消除所有的单点问题，我们所有的办事 都冗余化，所有的存储是有主备切换、分区容错。我们支持异地多活的安排 计划 ，这都是事前的准备。我们还要针对超等 碗这样瞬间突然来的高并发做流量控制预案，通过 DNS 技术灵活的把流量在不合 数据中心之间进行分派 。
还有一个很重要的是资源隔离预案。FreeWheel 有很多客户，在办事 超等 碗的同时还有其他客户的流量也在我们的平台上，这样带来一个问题，因为所有的客户是分享同一个告白 办事 器的集合（Pool）。
我们说的资源隔离是通过负载均衡的技术，有能力在短时间内实时、很快的情况下，把客户的某些流量隔离到零丁 的硬件资源上，这样一旦某些流量涌现 问题，我们可以很快的隔离出来，不合 用户的流量不会互相干扰。这是我们事前针对高可用做的预案和准备。
事发进程 中我们会依赖监控系统、各类 标准 （Metric）不雅 察系统健康状态。一旦监控系统有一些警报，我们可能考虑办事 降级。自己 在告白 投放中我们对性能会有问题，或者稳定性上有风险的模块会提供运行时的降级接口，再结合自动化的对象 ，很快、很便利 地做到运行时的一键降级，这是对告白 办事 器高并发的一些处理 方法 。
————————————————
前方高能！「2020 AI 开发者万人年夜 会」强势来袭！此次年夜 会特邀来自微软、英伟达、亚马逊、华为、腾讯、百度、阿里、华为、字节跳动、美团、快手、蚂蚁金服等100+位技术年夜 咖，分享最新AI技术、产品 与行业实施案例、技术实践经验与AI未来成长 趋势。
心动不如行动！私信发送“优惠码”，即可获取报名地址+优惠码，你将免费获取299元门票一张！！ |
