【.comExpressTranslation】对于数十亿使用Facebook的人来说，我们的服务可能看起来像是一个统一的移动应用程序或网站。在公司内部，情况有所不同。Facebook是使用数以千计的服务构建的，这些服务可以完成从平衡互联网流量、转码图像和提供可靠存储在内的一切工作。Facebook的整体效率在于将其各种服务的效率结合起来，每项服务通常都以自己的方式进行优化，这种方式可能难以扩大规模或适应快速变化的步伐。我们开发Spiral是为了更有效地优化众多服务，灵活地适应不断变化的、相互关联的内部服务。像Spiral这样的系统充分利用实时机器学习技术，在Facebook规模的环境中自动调整高性能基础设施服务。由于手动调整启发式方法被Spiral取代，我们可以在几分钟而不是几周内优化我们更新的服务。应对规模挑战的新方法在Facebook，变革的步伐很快。Facebook代码库每隔几个小时就会被推送到生产环境——就像前端的新版本一样，作为我们持续部署过程的一部分。在当今瞬息万变的世界中，尝试手动微调服务以保持最高效率是不切实际的。手动覆盖缓存/准入/驱逐策略和其他手动调整的启发式方法实在是太难了。我们必须从根本上改变原有的软件维护观念。为了有效地克服这一挑战，系统需要进行自我调整，而不是依赖于手动硬编码的启发式方法和参数。这种转变促使Facebook的工程师以新的眼光看待他们的工作：工程师现在不再查看系统生成的图表和日志来验证其是否正确有效地运行，而是用代码表达系统如何被认为正确运行并且高效。今天，我们的工程师通过编程为自我调节系统提供反馈，而不是指定如何计算对请求的正确响应。传统的缓存策略看起来像一棵有树枝的树，考虑对象的大小、类型和其他元数据来决定是否缓存它。自动缩放缓存将以不同方式实现。这样的系统可以检查对象的访问历史：如果以前从未访问过该对象，则缓存它可能不是一个好主意。在机器学习的语言中，使用元数据（特征）和相关反馈（标签）来区分对象的系统将是一个“分类器”。该分类器将用于决定将哪些对象放入缓存，系统将不断接受再培训。这种持续的再培训使系统即使在环境发生变化时也能保持最新状态。从概念上讲，这种方法类似于声明式编程。SQL是这种方法的一个很好的例子：工程师不指定如何计算复杂查询的结果，而是指定需要计算的内容，然后引擎找到最佳查询并执行它。对系统使用声明式编程的挑战是确保正确且完整地指定目标。与上述自动调整图像缓存策略一样，如果关于哪些对象应该和不应该缓存的反馈不准确或不完整，系统可以快速学习提供不正确的缓存决策，这会降低性能。由几位Google工程师撰写的这篇论文(https://storage.googleapis.com/pub-tools-public-publication-data/pdf/43146.pdf)详细介绍了这个问题以及其他与使用闭环机器学习问题相关的问题。根据我们的经验，精确定义自动调整的预期结果是开始使用Spiral最棘手的部分之一。然而，我们也发现，在几次迭代之后，工程师们倾向于就一个清晰且正确的定义达成一致。Spiral：轻松集成和实时预测为了让Facebook的系统工程师跟上不断加快的变化步伐，Facebook波士顿办事处的工程师构建了Spiral，这是一个具有最小依赖性的微型嵌入式C++库。Spiral使用机器学习为资源受限的实时服务创建数据驱动的反应式启发式算法。与手动编码的替代方案相比，该系统极大地加快了这些服务的开发和自动维护。与Spiral集成只需向代码中添加两个调用站点：一个用于预测，一个用于反馈。推测性调用站点是用于做出决定的智能启发式的输出，例如“是否应将此条目允许进入缓存？”推测调用被实现为快速本地计算，设计为在每个决策的基础上执行。图1反馈调用站点用于提供偶尔的反馈，例如“由于基本未命中，此条目已从缓存中失效，因此我们可能不应该缓存此类条目。”图2库可以在完全嵌入式模式下运行，或者可以向Spiral后端服务发送反馈和统计信息，它可以显示对调试有用的信息，将数据记录到长期存储以供以后分析，并执行繁重的训练和选择嵌入式模式可用的模型训练下来太耗资源，但运行起来又不太耗资源。图3中发送到服务器的数据采用了反偏采样，避免类别不平衡偏差渗透到样本中。比如我们在一段时间内收到的负样本是正样本的1000倍，我们只需要将这1000个负样本中的1个记录到服务器，并表明其权重为1000，服务器就可以洞察全局分布的数据，通常会产生比任何一个节点的本地模型更好的模型。除了链接到库和使用上面的两个函数之外，这些都不需要任何设置。在Spiral中，反馈一进来就开始学习。随着生成更多反馈，预测质量逐渐提高。在大多数服务中，反馈可在几秒到几分钟内获得，因此开发周期很短。主题专家可以添加新功能，并在几分钟内查看它是否有助于提高预测质量。与硬编码启发式不同，基于螺旋的启发式可以适应不断变化的条件。以缓存权限策略为例，如果某些类型的条目被请求的频率较低，则反馈将重新训练分类器，以降低此类条目在没有人为干预的情况下被允许的可能性。案例研究：自动化反应式缓存启发式Spiral的第一个生产级用例非常符合PhilKarlton的名言：“计算机科学中只有两个难题：缓存失效和命名。”（我们取了一个恰当的名字，所以我们实际上用Spiral立即解决了缓存失效问题。）在Facebook，我们推出了一个反应式缓存，以便Spiral的“用户”（我们的其他内部系统）订阅查询结果。从用户的角度来看，系统提供查询结果和对结果的订阅。只要外部事件影响查询，它就会自动将更新的结果发送给客户端。这减轻了客户端轮询的负担，并减轻了计算查询结果的Web前端服务的负担。当用户提交查询时，反应式缓存首先将查询发送到Web前端，然后创建订阅、缓存并返回结果。除了原始结果外，缓存还接收计算结果所涉及的对象和关联列表。然后它开始监视稳定的数据库更新流，以查找查询访问的任何对象或关联。每当它看到可能影响其中一个活动订阅的更新时，反应式缓存就会重新执行查询并将结果与??缓存的内容进行比较。如果结果确实发生变化，它会将新结果发送给客户端，并更新自己的缓存。该系统面临的一个问题是有大量的数据库更新，但只有一小部分会影响查询的输出。如果查询想知道“我的哪些朋友喜欢这篇文章？”，则无需持续更新“最后看到这篇文章”。这个问题类似于垃圾邮件过滤：面对一封电子邮件，系统应该将其分类为垃圾邮件（不影响查询结果）还是非垃圾邮件正常邮件（影响查询结果）？第一个解决方法是手动创建静态黑名单。这是可能的，因为ReactiveCache工程团队认识到超过99%的负载来自一小组查询。对于低容量查询，他们只是假设所有更新都是普通邮件并重新执行查询，以便查询引用对象的每个更新。对于一小组高容量查询，他们创建了黑名单，为此他们仔细观察查询执行以确定每个对象中的哪些字段实际影响了查询的输出。这个过程通常需要工程师为每个黑名单花费数周时间。使情况更加复杂的是，这组高容量查询不断变化，因此黑名单很快就会过时。每次使用缓存的服务更改其执行的查询时，系统都会更改垃圾邮件过滤策略，这需要工程团队做更多的工作。更好的解决方案：螺旋垃圾邮件过滤重新执行查询后，很容易确定观察到的更新是垃圾邮件还是非垃圾邮件，只需将新查询结果与旧查询结果进行比较即可。该机制用于向Spiral提供反馈，以便它可以为更新创建分类器。为了确保无偏见的采样，反应式缓存维护并仅提供来自一小组订阅的反馈。缓存不会过滤这些订阅的更新；每当修改相关对象或关联时，都会重新执行查询。它将新查询输出与缓存版本进行比较，然后使用它向Spiral提供反馈——例如，告诉它更新“上次查看”不会影响“喜欢计数”。Spiral从所有反应式缓存服务器收集此反馈，并使用它来为每种不同类型的查询训练分类器。这些分类器会定期推送到缓存服务器。为新查询创建过滤器或更新过滤器以响应Web层不断变化的行为不再需要工程团队的任何手动干预。当收到新查询的反馈时，Spiral会自动为这些过滤器创建新的分类器。螺旋：更快的部署和更多的机会使用基于螺旋的缓存失效机制，在反应式缓存中支持新查询所需的时间从几周减少到几分钟。在Spiral之前，反应式缓存工程师必须通过运行实验和手动收集数据来检查每个新查询的副作用。但是使用Spiral，大多数用例（映射到查询）都可以在几分钟内由本地模型自动学习，因此本地推理立即可用。对于大多数用例，服务器能够在10到20分钟内使用来自多个服务器的数据训练模型。一旦发布到所有单独的服务器，这个更高质量的模型就可以用于提高准确性的推理。当查询发生变化时，服务器能够适应变化，一旦收到更新的查询就重新学习新的重要性模式。我们继续致力于自动化后端服务和应用机器学习以获得更好的操作体验。Spiral的潜在未来应用包括使用贝叶斯优化的连续参数优化、基于模型的控制以及用于具有每秒高请求(QPS)和离线（批处理）系统的实时服务的在线强化学习技术。我们将在以后的帖子中继续分享我们的工作和成果。原标题：Spiral:Self-tuningservicesviareal-timemachinelearning，作者：VladimirBychkovsky,JimCipar,AlvinWen,LiliHu,andSauravMohapatra】
