Lyft 市场中流媒体管道的演变

22-10-17 banq

Lyft 撰写了有关其基于 Apache Beam 的流式管道架构的演变。该博客讲述了初始版本是如何从 cron 作业开始的,以及为简化管道创建而进行的持续改进。

背景
2017 年,我们 Marketplace 组织内的 Lyft 定价团队使用基于 cronjob 的有向无环图 (DAG) 来计算行程的动态定价。DAG 中的每个单元将在每分钟的顶部运行,从前一个单元获取数据,计算结果,并将其存储到下一个单元。这种范式有几分钟的固有延迟。
随着产品迭代速度随着时间的推移而增加,这种较旧的基础架构无法支持更快的开发周期,主要是因为所有 ML 功能生成都需要编写需要数周时间才能开发的自定义逻辑。
团队需要更好的基础设施来使动态定价系统更具反应性,原因如下:

  1. 减少端到端延迟,这将使系统对市场不平衡更具反应性。
  2. 减少开发时间,提高产品迭代速度。


MVP
经过深思熟虑,我们决定流式引擎更适合我们的要求,并选择了Apache Beam。由于这是一个全新的框架,我们必须提出一种管道设计,以确保与现有系统的功能相同。第一个版本旨在使用事件、将数据转换为 ML 功能、编排模型执行以及将决策变量同步到各自的服务。

实现管道很简单,几乎不需要自定义逻辑,因为流结构倾向于提供各种功能,例如数据分片、聚合、连接等,开箱即用,可以直接在管道中使用。与旧系统 (10K LOC) 相比,这显着减少了整体代码大小 (4K LOC),并将 ML 功能开发时间缩短了 50%。
在推出之前,我们添加了指标奇偶校验和各种警报以避免意外。尽管如此,我们最初的推出并不完全顺利。我们遇到了数据偏斜和更高的内存利用率问题,但我们能够克服这些问题并将其推广到较小的市场,并展示了 100% 的数据奇偶性和 60% 的端到端延迟降低。

详细点击标题