AWS Elastic GenAI Agent Architecture Guidelines

在最近的一篇博客文章中，Netflix的工程师描述了他们如何扩展Muse这个公司内部用于数据驱动创意洞察的应用，使其能处理万亿行数据集。

Muse帮助Netflix的创意和发布团队了解哪些艺术作品和视频资产能够引起观众的共鸣，而公司的业务增长需要它在大规模数据上支持高级过滤和受众亲和性分析。

为了满足这些需求，Netflix报告称它重新设计了数据服务层，将查询延迟减少了约50%，同时保持了准确性和响应性。

Muse最初是一个由Spark驱动的仪表板，背后是一个适度的Apache Druid集群。随着时间的推移，创意团队要求添加异常检测、通知和媒体比较等功能，而数据量增长到了每年数万亿行。满足这些需求需要更低的延迟和更强大的服务层。

一个主要挑战来自于受众亲和性：通过算法推断的标签，将成员按喜好分组，如“角色剧粉丝”或“流行文化爱好者”。将这些多对多关系添加到印象和播放数据中增加了复杂性，达到了原来架构的极限。

Muse应用程序GUI

另一个挑战来自于Muse的两个关键指标，一个是印象，也就是资产被展示的次数，还有一个是合格播放，这将播放事件与印象联系起来。两者都需要计算不同的用户，这在Netflix的规模上是一项昂贵的操作。

为了解决这个问题，团队采用了来自Apache DataSketches的HyperLogLog草图，这些草图提供了大约1%误差的估计。

草图在两个地方构建：在Druid摄取过程中和在Spark ETL作业中，后者将每日草图合并成所有时间的聚合。这种方法将整个组织的常见OLAP模式的查询延迟减少了大约50%。

为了进一步减轻Druid的负载，Netflix转向了Hollow，这是其内部的内存键/值存储库。Hollow提要由Iceberg表构建，生产服务器推送更新，Spring Boot消费者刷新缓存的数据集。这种设置允许Muse直接从内存中提供预计算的聚合，如不同国家的可用性、所有时间资产指标和元数据。

查询时间从数百毫秒降低到数十毫秒，同时也保护Druid免受高并发请求的影响。团队指出，这种权衡是更高的内存使用和更复杂的请求路由，但结果是更大的稳定性和响应性。

当前Muse架构

最后，Netflix还花时间调整了Druid：团队调整了数据在节点之间分割的方式，调整了段的大小以使扫描更有效，并在存储前过滤掉未使用的列。

他们还利用Druid在单个字段中存储多个值的能力，更好地处理受众亲和性。

这些变化，结合早期的改进，将查询时间大致减半，并使系统在重负载下更加一致。

为了确保准确性和信任，Netflix并行运行了遗留和新的度量堆栈，通过自动化的Jupyter比较和突出显示差异的应用程序内工具来验证结果。

推出是分阶段进行的，由影子测试和细粒度的功能标志支持，以实现安全的回滚。

展望未来，Netflix计划将Muse扩展到支持“直播”和游戏，整合概要数据，并完善区分“有效”和“真实”促销资产的指标。

原文链接：