Table of Contents

1. Algorithm
2. Review
   1. 梗概
   2. AVA Discovery View 介绍
   3. AVA Discovery View 例子
      1. 故事情节
      2. 重要的特征
      3. 敏感
      4. 环境
   4. 挑战
      1. 算法质量
      2. 建议排位
      3. 算法反馈
      4. 跨多个算法的交叉查询
   5. 技术架构
      1. Discover View 插件架构
      2. Discovery 统一接口
      3. 资产反馈微服务
   6. 媒体理解平台
   7. 影响
   8. 未来的工作
      1. 消除重复
      2. 改进帧质量
      3. 构建用户信任
3. Tips
4. Share

Algorithm

Leetcode 835: Image Overlap

https://dreamume.medium.com/leetcode-835-image-overlap-1091d20617ee

Review

AVA Discovery View: Surfacing Authentic Moments

梗概

在 Netflix，我们创建了数百万个插图来表现我们的标题。每个插图阐述了它想表达的一个故事。从我们的广告资产测试中，我们知道哪些资产有高的表现哪些没有。这样，我们的团队发展了一种对哪些类型标题有好的视觉和主题插图特征的直觉。一些广告插图在某些地区对某种类型反响强烈，或对特定的粉丝。这些因素的复杂性使得对即将出版的标题难以给出最好的策略

我们的资产通常通过直接从我们的源视频中选择静态图像。为改进它，我们决定投资创建一个媒体理解平台，在我们的创新工具从媒体中提取有意义的洞察。在本文中，我们将深入探讨这些工具之一，AVA Discovery View

AVA Discovery View 介绍

AVA 市一个内部工具从视频内容中获取静态图像。工具提供了一个创新的有效方式（图片编辑，插图设计等）来从视频内容推出验证呈现标题的叙述主题，主要特征和可视化特征的时刻。这些静态时刻被多个 Netflix 团队用来作为插图（在 Netflix 平台或其他），发布，市场，社交团队等

静态图像用来作为商品、发布验证标题，提供一系列入口点来记住观看的不同原因。例如，对标题“星期三“，一个用户观看原因是他们喜爱神秘事物，另一用户个是喜爱成年故事或哥特审美。另一个用户是喜欢天才。工具的任务是从这些观点中选择图像。静态图像可通过加强和组合来创造更符合的插图。对许多团队和标题，静态图像是必要的 Netflix 广告资产策略

观看所有内容来找到最好的图像和手动选择会耗费太多时间，且这个方法通常是不能扩展的。当图像可从视频内容中手动保存，AVA 提供获取验证图像的功能 - 它建议最好的创造时刻：进入 AVA Discovery View

AVA Discovery View 例子

AVA 图像收割算法预选择和分组相关帧为目录如故事情节，主要特征和环境

让我们进一步深入一个标题的不同面如何显示 Netflix 的最大点 - “星期三”

故事情节

“星期三”标题包含一个用超自然能力侦探解决秘密的特征。标题有一个昏暗富有想象的带智慧和幽默的阴影语调。设定是一个特别的高校，注册的都是有超自然能力的年轻人。主要是关于一个年轻人和她与父母的关系问题

以上段落提供了一个标题的简介。从这个信息中找到验证时刻来构建插图设计基础是不平凡的且需要长时间的创造力

这是 AVA Discovering View 出现和作为创造帮手的原因。使用标题的信息提供的故事情节，它找到关键时刻，不止提供一个好的可视化总结也提供标题主题和它的可视化的快速预览

点击任意情节可看到最好的反映情节和标题论调的时刻。例如，如下图像阐述了它如何显示想象论调的时刻

重要的特征

天才是我们的标题主要的刻画，且我们的观众想要看到标题的特征来选择是否他们想要看那个标题。给定知道一个标题的主要特征且然后找到最好的时刻是一个艰难的任务

用 AVA Discovering View，所有标题的重要特征和它们最好的时刻会呈现出来。可看到一个特征怎么在标题中和找到包含多个特征和最好的静态图像来代表它们

敏感

我们不想要 Netflix 主屏幕使观众受惊吓或冒犯，所以我们致力于避免插图带有暴力，裸体，受伤或相似属性

为帮助我们的创造工具理解内容敏感，AVA Discovering View 列出包含受伤，暴力，亲密，裸体，吸烟等内容时刻

环境

设定和电影位置通常提供类别线索和形成喜爱插图基本。从一个主题可见设定或需要一个可视化扫描主体所有片段的实际电影定位来找到时刻。现在，AVA Discovering View 显示建议的时刻

例如，对标题“星期三”，工具呈现“永不再的学术“作为建议的环境

挑战

算法质量

AVA Discovering View 开始时包括几个不同的算法，在发布时，我们扩展支持了附加的算法。每个算法需要一个评估进程且在 AVA Discovering View 中调节得到结果

对可视化搜索

• 我们发现模型被图像中的文字影响。例如，静态文字通常会被拿出并推荐给用户。我们添加了一个步骤使得静态文字的结果会被过滤并不在搜索中呈现
• 我们也发现用户那些有一个使用自信阙值剪掉的结果

对最要特征

• 我们发现我们当前算法模型不能很好地处理动态面部。这样，我们通常对动态内容返回可怜的或没有建议

对敏感时刻

• 我们发现设定一个高自信度阙值是有帮助的。算法原始是发展为对血腥场面敏感，且当应用到烹饪和绘画场景时，通常会有错误的正反馈

一个挑战是我们统计是重复的建议。相同场景的多个建议能被返回且导致多个可视的相似时刻。用户更喜欢只看到最好的帧且一个各式各样的祯系列

• 我们添加一个排位步骤到一些算法中来标注帧太可视化相似于更高排位的帧。这些重复的帧会从建议列表中过滤掉
• 然而，不是所有算法有这个处理。我们探索使用场景边界算法来分组相似时刻作为单个建议

建议排位

AVA Discovering View 呈现多层的算法建议，且一个挑战是帮助用户从最好的建议中导航且避免选择坏的建议

• 建议目录基于我们用户的相关工作流呈现。我们显示故事线，重要特征，环境，然后是敏感
• 在每个建议目录，我们显示建议基于结果数和自信度阙值限制来排位

算法反馈

在我们运行 AVA Discovering View 的初始算法集之后，我们的团队面试了用户关于它的体验。我们也构建机制用工具获得直接或间接的用户反馈

直接反馈

• 对呈现给用户的每个算法建议，用户可点击一个赞成或反对来给出直接反馈

间接反馈

• 当一个算法建议被利用时（下载或发布用在 Netflix 广告上）我们跟踪启动检测
• 这个间接反馈更容易收集，虽然它不是对所有算法起作用。例如，敏感建议表示观看的内容不应该使用于广告。结果，这个在间接反馈中表现不好，因为我们不期望下载或发布这些建议的行为

这个反馈容易被我们的算法合作人访问且用于训练模型的改进版本

跨多个算法的交叉查询

几个媒介理解算法返回剪切或短视频建议。我们计算时间码使得一系列已知高质量帧作为最好的帧呈现

我们也依赖交叉查询来帮助用户缩短一个特定时刻的大集合系列帧。例如，从一个搜索查询中返回两个或多个重要特征或只过滤室内场景的静态图像

技术架构

Discover View 插件架构

我们构建 Discovery View 为可插件化这样可以快速扩展支持更多算法和其他类型建议。Discovery View 通过 Studio Gateway 对 AVA UI 和其他前端应用程序做杠杆是有效的

Discovery 统一接口

所有 Discovery View 行实现相同的接口，且它扩展简单且容易插件化到现存的 View

1. 可扩展目录

   在 Discovery View 特性中，我们基于算法结果动态隐藏目录或推荐。如果没有发现推荐则目录可被隐藏。另外，对大量建议，只提取顶部建议且用户有能力获取更多建议

2. 优雅地错误处理

   对用户体验来说我们独立加载 Discovery View 建议

资产反馈微服务

我们确定资产反馈在我们的生态系统中是一个有用的功能，所以我们觉得为它创造一个独立的微服务。该服务对静止图像质量获得反馈且给予到算法中。这个信息对个人和我们的算法合作者的聚集水平都有效

媒体理解平台

AVA Discover View 依赖媒体理解平台（MUP）作为算法建议的主接口。这个平台的关键特性是

• 统一的查询接口

  宿主媒体理解平台（MUP）上 AVA Discover View 的所有算法，使它作为产品集成时建议查询对每个算法相似

• 丰富的查询特性集

  我们可对每个算法测试不同的自信度阙值，交叉算法建议和不同域的顺序建议

• 快速算法上线

  每个算法上线少于两周，且平台确保新的标题转发到 Netflix 会自动产生算法建议。我们的团队能够在 AVA Discover View 上花费更多的时间评估算法性能和快速迭代

影响

以有效可扩展的方式发现真实时刻对 Netflix 和创建团队有巨大的影响。AVA 变成获得标题洞察和发现资产的地方。它提供在主情节、可视化语言和标题重要特征上一个简介。一个 AVA 用户可快速轻松地找到相关并可视化的帧且作为一个内容收集工具进行调节

未来的工作

为改进 AVA Discovering View，我们的团队需要平衡返回的帧数和建议的质量使得创造性对特性更加信任

消除重复

AVA Discovering View 经常把相同的帧放入多个目录，导致创建视图和评估相同的帧多次。我们如何解决有吸引力的帧为多个组的一部分而不使每个组被重复帧撑爆？

改进帧质量

我们喜欢只显示某个时刻最好的帧且消除技术质量低下（一个差的特征表达）或差的编辑质量（跟组不想关，跟情节不相关）。移动不能达到质量标准让用户疲劳的帧

构建用户信任

创造性不想要有对是否在 AVA Discovering View 组上之外更好的东西或从推荐帧中没有的东西的怀疑

当查看一个特殊的组（比如“星期三”），创造性需要信任它不包含不属于这些的任意帧，它们是质量最好的帧，不存在不包含在组中更好的帧。假设一个创造是平衡 AVA Discovering View 和独立手动工作来改进帧质量或检测是否有时刻缺漏。这种情况下，AVA Discovering View 是还没有完全优化用户体验

Tips

English for Career Development

这是一个初级的讲面试的课程，可以对面试有个基本的了解，课程还有一个好处就是视频语速不快，很适合作听力练习，学起来轻松愉快

这个课程为 5 周的课时。每节小课比较简短，几分钟时间即可看完一节

第一周主要介绍了找工作的一些基本概念，确定最适合自己的职业，关键技能，理解职位描述，使用互联网和社交媒体找工作

第二周主要内容为简历。介绍了简历各部分组成及怎么写

第三周主要讲求职信，介绍其格式、如何写及一些建议

第四周主要讲找工作的一些技巧，利用你的网络及如何与人交谈

第五周主要讲面试中的一些问题及注意事项

Share

System Design Interview - Step By Step Guide

这好像是一个波兰的程序员讲解的系统设计，虽然有较重的英语口语，但是内容很经典，很多人推荐，是学习系统设计的好材料

面试官想要理解候选人如何处理分歧。是否你能确定系统关键部分并定义问题范围

系统设计问题是开发式问题，不可能在 45 或 60 分钟面试时间内解决这样的问题。我们应该清楚问题的哪些功能部分是我们需要聚焦的

我们的建议是聚焦于以下 4 个大分类：

1. 用户/客户
2. 扩展（读/写）
3. 性能
4. 成本

当我们说功能性需求时，指的是系统行为或更多明确的 API，一系列系统支持的操作。而非功能性需求，我们指的是系统质量，比如快速，容错，安全

在明确系统要做什么时，你把它写在白板上

通常，面试官不会告诉我们明确的非功能性需求。他会挑战我们要达到某些扩展性和快速等的要求。我们需要找到妥协方案。我的建议是你写下非功能性需求在白板上

下面我们讨论下一步问题：高层架构

我们需要思考要存储什么数据及如何做，或者说我们需要定义数据模型

我们应该问面试官期望的数据延迟。即事件发生和事件处理的时间差。如果时间为几分钟，我们需要单独统计数据，如果时间为几小时，我们可存储原始事件并在后台处理。前一种处理为流数据处理，后一种成为批数据处理。面试官会让我们知道他最感谢的是哪种方式。因为原始事件很多，我们只能存储几天或几周的数据，并清除旧的数据。接下来，我们将主要聚焦于实时统计部分

面试官想要知道具体的数据库名字和为什么我们做出这个选择。如何扩展写？如何扩展读？如何快速读和写？当硬件故障和网络分区时如何不丢失数据？如何达到强一致性？妥协是什么？运行中断时如何恢复数据？如何确保数据安全？未来数据模型改变时如何扩展？在哪里运行（云或内构的数据中心）？成本是多少？

我们可存储数据到一台数据库中，但当单台不够时，我们需要引入更多的机器且在它们之间分割数据。这个过程称为分片或水平分区。每台存储数据的一个子集。因为我们现在有几台机器，连接到数据库的服务需要知道存在多少台机器且从哪台存取数据。一个更好的选项是引入一个轻量的代理服务器，其知道所有的数据库且路由流量到正确的分片。其他想要跟数据库打交道的服务会先跟这个代理联系，它们不需要知道具体数据库细节。代理需要知道分片脱机或由于网络而不可用。且如果新的分片添加了到数据库簇，代理需要知道

为此，我们引入一个新的组件 - 配置服务。配置服务维护一个健康检查连接到所有分片。这样，它知道哪些数据库是有效的。这样，簇代理调用一个特殊的分片。而不是直接调用数据库实例，我们可引入另一个代理 - 分片代理。其位于数据库之前，它可缓存查询结果，监控数据库实例健康和发布度量，终止太长时间的查询

我们称每个存在的分片为主分片，我们可写数据到主分片，但读可从主分片和一个复制节点。我们也把一些复制节点放入数据中心。这样如果整个数据中心无法访问，部分复制节点依然可以访问。当存储数据请求到来时，基于配置服务提供的信息，簇代理发送数据给一个分片。且数据被同步或异步的方式复制到对应的读复制节点。当提取数据请求到来时，簇代理可能从主分片或复制节点提取数据。

上述说的正是 youtube 在使用的，其数据库用的 MySQL。现在我们看一下 NoSQL 数据库可提供给我们什么

在 NoSQL 数据库里我们也分割数据为簇分片，也称为节点。每个节点角色作用相同。我们不需要配置服务来监控分片的健康。我们让分片互相通信并交换它们的状态信息。为减少网络负载，我们不需要每个分片跟所有其他分片通信。每秒分片会与少量其他分片交换信息，数量不超过 3 个。很快每个节点足够的状态信息会广播到簇。这个过程称为 gossip 协议。这样客户端可调用簇中任意节点且节点能决定如何转发请求

同步数据复制较慢，我们通常异步复制数据。对于主副节点的情形客户端可能会读取到脏数据，但随着数据复制完成最终数据会达成一致。这叫做最终一致性

对一个典型的系统设计面试我们通常不需要知道不同数据库的架构。但我们需要知道它们的优点和缺点及什么时候用什么。NoSQL 还有其他不同的架构

现在我们来说说数据处理。如何扩展？如何获得高吞吐？当处理节点崩溃时如何不使丢失数据？当数据库不工作或慢时怎么办？

我们应该在处理服务中预先统计数据吗？我们有两个选项如何更新统计到数据库。第一个选项是处理服务对每个输入事件增加统计。第二个选项是我们累积处理服务中的数据到内存一段时间，比如几秒。且添加累积值到数据库

把统计数据放入内存中，有两种方式：推或拉。推指一些其他服务发送同步事件给处理服务。拉指处理服务从一些临时存储中拉事件。拉更好一点，它提供更好的容错支持和更容易扩展。这里有个检查点的概念。当用拉的方式时有一个临时存储，当我们处理一些事件并写入数据库之后我们记录到临时存储，如果数据库崩溃另一个数据库可以从检查点处继续进行

另一个重要概念是分区。推时可以把事件发送到多个队列

一个消费服务读取事件，一般是单线程的，如果是多线程，则设置检查点和保留事件顺序的处理会变得复杂。消费服务也帮助消除重复的事件。如果相同的消息多次提交到分区，我们需要一个机制避免多次统计。为此我们使用一个分布式缓存存储唯一事件号 10 分钟。如果几个重复消息在 10 分钟间隔内达到，只有第一个唯一的号会被处理

对数据库写服务也相似，这里第一个概念称为死亡字母队列。这个队列里的消息是那些没有发送到正确目的地的消息。这是为了保护数据库性能或有效性。如果数据库变慢或由于网络我们不能达到数据库，我们简单地把消息放入死亡字母队列。有一个单独的进程从这个队列读消息并发送到数据库。这个概念被广泛使用当你需要在服务不可用时保存数据。另一个切实可行的选项是存储不能转发的消息到处理消息服务所在机器的本地磁盘。第二个概念是数据加强。事件只包含最少的信息，一些其他信息存储在处理服务的本机数据库上，并能被快速获取。最后一个概念是状态管理。当机器故障则内存中的状态丢失。我们可重建状态因内存中的数据只是一个小的时间段。即我们会重处理事件。有时从原始事件重建状态会比较困难，解决方案是定期保存整个内存数据到一个持久化存储。新的机器读取这个状态到内存中

我们现在确定数据吸入流水线。使用分区服务客户端发送请求，一个负载均衡器把数据发送到分区服务，再转发到各个分区。分区服务客户端可使用非阻塞方式、缓存和批处理（把多个请求放在一个请求中），设置超时时间。超时时间分连接超时和请求超时，连接超时一般很短，十几毫秒左右。为选择请求超时时间，我们需要分析延迟百分比。例如我们测量系统中 1% 最慢的请求的延迟，设置这个值作为请求超时时间。这意味着系统中 1% 的请求会超时。对这些失败的请求应该怎么办？我们重试它。为防止同时重试的请求太多，我们应该使用指数回退和 jitter 算法。电路阻断范型防止客户端重复尝试执行一个很可能失败的操作。我们简单统计最近失败了多少个请求且如果超过错误阙值我们停止调用一个下流的服务

如何确定瓶颈？我们需要在重负载下测试，即性能测试。有几种性能测试。我们有负载测试，我们在超过正常操作容量下测试，侵泡测试，测试一个系统在典型产品负载下一段扩展时间（资源泄露）。负载测试为测试能达到期望的扩展。压力测试为确定在系统的一个极限哪个组件先达到瓶颈

如何确定系统是健康的？系统所有组件必须监控它们的健康。测量、仪表板和警告是常用的手段。记住 4 个黄金监控信号：延迟、流量、错误和饱和度

如何确定系统产生精确的结果？这个问题典型地是处理构建一个审查系统，有两种：弱审查系统持续的运行端到端测试，但不能百分百准确（因网络等问题）。强审查系统在主系统之外进行统计