dropbox怎么用(iPad使用dropbox)( 二 ) _iPad

在探索预览优化之前，我们想确保节省的成本能够超过构建机器学习解决方案的成本。我们大致估算了一下 Cannes 项目可以节省的成本。在大型分布式系统中设计和部署机器学习系统，你需要考虑系统的变化随着时间的推移对你的估计产生的影响。我们希望初始的模型尽量简单，这样一来即使相邻系统发生一些很小的变化，成本的影响也不会出现数量级的变化。通过分析训练好的模型，可以让我们更好地了解第一版实际可以节省的成本，并确认这项投资是值得的。
我们利用内部的功能开关服务 Stormcrow，在 Dropbox 流量 1%的随机样本上，针对模型进行了 A / B 测试。我们验证了模型的准确率和预热“节省”的成本符合我们离线分析的结果，这是个好消息！由于 Cannes v1 不再预热所有符合条件的文件，因此我们知道预计缓存命中率会下降。在实验期间，我们观察到缓存命中率比 A / B 测试中的对照组低了几个百分点。尽管百分比下降了，但总体的预览延迟基本上保持不变。
我们非常关心尾延迟（第 90 个百分位数以上的请求延迟），因为缓存未命中会导致尾延迟过高，进而严重地影响用户的预览功能。然而，我们并没有观察到预览尾延迟或总体延迟明显上升，这很让人欣慰。这次实时测试让我们信心大增，我们决定将 v1 模型部署到更多 Dropbox 流量。
大规模的实时预测我们需要一种方法，当某个文件进入预热路径时，实时地告诉Riviera该文件是否需要预热。为了解决这个问题，我们将 Cannes 构建成了预测流水线，负责提取与文件相关的信号，并将其发送给模型，供模型预测未来使用预览的可能性。
图：Cannes的架构

从Rivieraprewarm path（预热路径）接收文件 ID 。Riviera 会收集所有可进行预热的文件 ID 。（Riviera可以预览 Dropbox 存储的大约 98%的文件。只有很少一部分文件的文件类型不支持，或无法预览。）Riviera 发送一条预测请求，其中包含需要预测文件 ID 以及文件类型。
获取实时信号。为了收集预测期间文件的最新活动信号，我们使用了一个名为“Suggest Backend”（建议后台）的内部服务。该服务会验证预测请求，然后查询与该文件相关的信号。信号存储在 Edgestore（Dropbox 主要的元数据存储系统）或 User Profile Service（RocksDB 数据存储，负责聚合Dropbox 活动信号）中。
将信号编码为特征向量。收集到的信号会被发送到 Predict Service（预测服务），由该服务将信号编码为表示文件所有相关信息的特征向量，然后将这个向量发送给模型进行评估。
生成预测。模型使用特征向量，返回该文件可能会被预览的概率。接着，这个预测结果会被发送回 Riviera，并由 Riviera 预热未来 60 天内可能会被预览的文件。
记录请求的相关信息。SuggestBackend（建议后台）会记录下特征向量、预测结果和请求状态，这些都是调查性能下降和延迟问题的关键信息。

其他考虑事项减少预测延迟很重要，因为上述管道位于 Riviera 预热功能的关键路径上。例如，当将这个模型扩展到 25%的流量时，我们观察到了一些极端的情况，导致建议后台的可用性降低到了内部 SLA 以下。
经过分析后，我们发现上述第 3 步出现了超时的问题。因此，我们改进了特征编码处理，并优化了预测路径上的几个问题，降低了这些极端情况下的尾延迟。
优化机器学习在推出机器学习模型的过程期间（及其之后），我们非常注重稳定性，并确保不会对预览界面的用户体验产生负面影响。多个层面的监视和警报是部署机器学习的关键组成部分。
Cannesv1 的指标预测服务基础设施的指标：共享系统有自己内部的 SLA，主要都是围绕正常运行时间和可用性。我们依靠 Grafana 等现成的工具进行实时监控和发送警报。我们监控的指标包括：