Flink模型服务和实时特征生成在Razorpay的实践

 在Flink Forward Global 2020期间,Razorpay团队展示了Apache Flink如何在其“ Mitra”数据平台中使用,以克服围绕功能生成和实时机器学习模型的挑战的方法。

“ Mitra”是一个数据平台,可为Thirdwatch产品提供支持,可通过大规模提供机器学习模型来实时防止欺诈行为。本文中我将解释我们提供机器学习模型的方法,并解释为什么我们使用Flink作为流处理引擎来执行此类任务。

关于Razorpay

Razorpay是印度领先的支付解决方案之一,它使企业可以使用其产品套件接受,处理和支付款项。该技术可以访问所有付款方式,包括信用卡,借记卡,网上银行,UPI和许多流行的钱包。该公司拥有500万以上的商家,年支付额为250亿美元,每笔交易有100多个参数,每天处理大量数据

在2019年,Razorpay进行了首次收购- Thirdwatch,这是一款由AI驱动的解决方案,可帮助企业实时处理交易并检测欺诈行为。

让我们看看Razorpay和Thirdwatch如何利用Apache Flink优化Mitra。

为什么选择Apache Flink

由于多种原因,我们选择Apache Flink作为Mitra Data Platform的核心流处理引擎。首先,Apache Flink是一个真正的,低延迟的流处理框架,可对事件进行实时的实时处理而没有延迟。此外,Flink的状态管理,CEP(复杂事件处理)库以及对事件时间处理的支持帮助我们为业务带来了更多选择性,例如应用预测模型,以不同方式对事件进行排序,处理乱序和确保实时准确,可靠的事件处理。

Flink的Async IO在我们的平台中也得到大量利用,因为对于许多运营商来说,我们需要查询外部服务,例如图形数据库或其他外部系统。

最后,Flink的检查点机制以及Flink的架构演变和State TTL功能的新增强,是使Flink成为我们执行计算的核心部分的决定性原因。

Razorpay的数据科学

由于大量的数据以及我们技术的广度,Razorpay的数据科学团队面临着围绕数据科学,机器学习和实时处理的多个挑战。为了克服这些挑战,团队开发了一个称为Mitra的内部数据智能平台。

Mitra的架构包含三个主要组件,这些组件可以近乎实时地处理工。平台的“客户输入数据”组件使用不同的API,SDK或插件收集数据,然后将这些数据解析到我们平台的“核心引擎”部分,其中包括多个组件(例如Apache Flink)并执行多个功能,例如数据增强,数据验证,ML特征生成,身份聚类等。

我们基础架构的核心处理部分还包括带有Presto和Hive的数据湖,我们的分析师可以在其中执行多个查询。一旦Flink应用程序执行了实时处理,我们便将数据移至系统的“输出”部分,该部分将包含分析仪表板,API和Kafka主题或其他下游。

Mitra数据平台的一些关键功能包括:

  • 在分布式环境中在200毫秒内提供预测结果
  • 使用60多个算子实时生成数百个特征
  • 提供来自多个已部署机器学习模型的结果
  • 将动态规则直接应用于Apache Flink数据流
  • 大量利用Flink的内存状态管理功能来存储功能和数据
  • 使用Flink CEP进行异步事件处理

我们的核心引擎和主要的Flink应用程序(如下图所示),我们看到有两个数据流作为Kafka源:数据源流和控制流。数据源流将来自SDK的所有数据发送到我们的Flink应用程序,而控制流包括用于我们计算的所有控制信号,模型和规则。

kafka中的事件流被摄取到Flink应用程序中,该应用程序针对不同的场景(例如下单,帐户创建等)执行八到十个CEP条件,进而执行不同的联接,维度补充,操作以生成100个实时的机器学习特征用于模型服务和训练。核心引擎的一部分也是应用程序的规则引擎组件,该组件将业务逻辑实时应用于我们的计算。

我们的核心引擎拥有60多种不同类型包含状态的算子,它们生成特征,应用规则,丰富数据流并为模型提供服务。在应用规则并实时提供模型后,Flink应用程序将结果推送到Kafka流和我们的ElasticSearch数据库,以便其他应用程序随后可以使用Kafka的结果。

大规模的机器学习模型训练和部署

我们的系统需要通过动态生成数百个特征并在数毫秒内给出预测结果,因此两个因素变得尤为重要:可伸缩性和低延迟。

我们的机器学习模型动态特征生成和预测在我们的Flink应用程序中有良好可扩展性,而模型服务的可扩展性是一个很大挑战。模型服务器也需要进行扩展以便以低延迟处理更高的数据负载。为了实现这一目标,我们将模型训练与模型服务所在的服务器分开以实现最佳效果:

资源分配:在模型训练期间,我们分配最大数量的资源,因此服务请求受到影响并开始失败。

网络负载:同样,在模型训练期间,我们会大量传递数据,因此应用程序会增加网络的消耗并开始影响服务请求。

单独的可扩展性:分离后,我们可以根据负载和需求扩展训练和服务集群。

尽管我们已经在Mitra中构建了重要的功能,但我们还有更多计划在将来进一步增强平台的功能和可伸缩性。我们期待继续与Apache Flink合作,并利用社区实现的新功能和改进功能,以解决围绕大数据和大规模机器学习的一些令人兴奋的挑战。

往期精选▼

趣头条爬虫(以财经频道为例)

Spark Shuffle调优之调节map端内存缓冲与reduce端内存占比

Spark Shuffle调优之合并map端输出文件

Flink调优法则

5个Hadoop优化技巧

4个角度轻松理解 Flink中的Watermark

Flink中Checkpoint和Savepoint 的 3 个不同点

Flink实现固定时长或消息条数的触发器

Flink方案设计中的4大误区

使用 Broadcast State 的 4 个注意事项

3种Flink State Backend | 你该用哪个?

一文搞定 Flink 异步 I/O

Flink State 使用的4点建议

Flink在开发中的7点建议

扫码关注:

图片

猜你喜欢

转载自blog.csdn.net/yscoder/article/details/111411924