Lyft 市场中流媒体管道的演变
source link: https://www.jdon.com/62905
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Lyft 市场中流媒体管道的演变
Lyft 撰写了有关其基于 Apache Beam 的流式管道架构的演变。该博客讲述了初始版本是如何从 cron 作业开始的，以及为简化管道创建而进行的持续改进。
背景
2017 年，我们 Marketplace 组织内的 Lyft 定价团队使用基于 cronjob 的有向无环图 (DAG) 来计算行程的动态定价。DAG 中的每个单元将在每分钟的顶部运行，从前一个单元获取数据，计算结果，并将其存储到下一个单元。这种范式有几分钟的固有延迟。
随着产品迭代速度随着时间的推移而增加，这种较旧的基础架构无法支持更快的开发周期，主要是因为所有 ML 功能生成都需要编写需要数周时间才能开发的自定义逻辑。
团队需要更好的基础设施来使动态定价系统更具反应性，原因如下：
- 减少端到端延迟，这将使系统对市场不平衡更具反应性。
- 减少开发时间，提高产品迭代速度。
MVP
经过深思熟虑，我们决定流式引擎更适合我们的要求，并选择了Apache Beam。由于这是一个全新的框架，我们必须提出一种管道设计，以确保与现有系统的功能相同。第一个版本旨在使用事件、将数据转换为 ML 功能、编排模型执行以及将决策变量同步到各自的服务。
实现管道很简单，几乎不需要自定义逻辑，因为流结构倾向于提供各种功能，例如数据分片、聚合、连接等，开箱即用，可以直接在管道中使用。与旧系统 (10K LOC) 相比，这显着减少了整体代码大小 (4K LOC)，并将 ML 功能开发时间缩短了 50%。
在推出之前，我们添加了指标奇偶校验和各种警报以避免意外。尽管如此，我们最初的推出并不完全顺利。我们遇到了数据偏斜和更高的内存利用率问题，但我们能够克服这些问题并将其推广到较小的市场，并展示了 100% 的数据奇偶性和 60% 的端到端延迟降低。
详细点击标题
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK