几个月 前 ， Hyperconnect 团队 第一次 参加了 Flink Forward ，并展示了我们如何利用 Apache Flink 为基于视频的社交发现和通信平台 Azar 执行实时匹配 。 在接下来的部分中，我们将描述我们转向分布式流式架构以实时执行机器学习的动机、选择 Apache Flink 的原因 以及我们匹配流式架构的不同层。
关于 Hyperconnect 和 Azar
Hyperconnect 是一家基于技术的公司，也是世界上第一家开发可用于移动平台的 WebRTC 技术的公司。 基于这项技术，Hyperconnect 开发了 Azar，这是一个利用视频连接来自世界各地的人们的社交发现平台。 Azar 正在使用由机器学习提供支持的技术彻底改变人们结交新朋友和与他人交流的方式。 该应用程序可以在移动设备上访问，并允许您与来自 230 多个国家/地区的人交谈和交朋友。 Azar 在全球的下载量超过 4 亿次，而该平台已完成超过 800 亿场比赛！
为什幺我们选择 Flink 作为我们的婚介服务
Azar 增长非常迅速，该平台现在每天处理超过 1.8 亿的发现（在移动屏幕的实时视频中“向左滑动”的动作）。 为了确保 Azar 的匹配服务能够支持用户活动和参与度的持续增长，我们重新设计了匹配服务，将 Apache Flink 置于其架构的核心。 Flink 被选为首选的数据处理框架，因为它提供了必要的可扩展性、稳定性和容量来处理大量数据的有状态计算。
可扩展性
在高峰时段，我们的系统 每秒 处理超过 5,000 个匹配请求，每秒 处理超过 1,200 万次成对计算 ，为用户提供最佳结果。
稳定性
匹配服务是我们产品的关键任务和核心功能，因此，我们需要 以毫秒为单位的返回结果 的 响应时间， 同时 服务的停机时间 应该 为零， 因为它直接影响我们的业务和我们应用程序中的用户体验。
处理有状态的计算
为了改进我们的匹配算法，必须保持一些
关于用户的 状态
。 我们之前的无状态计算导致了间接的变通方法，这对我们的计算延迟和我们的事件流管道的整体复杂性产生了直接影响。 因此，我们决定从头开始重新设计匹配服务。
“Flink 是解决这些挑战的正确框架，其独特的架构和功能。”
Jaehyeuk (Jacob) Oh
高级软件工程师兼 Hyperconnect
团队负责人
Apache Flink 在执行 低延迟迭代方面 具有独特的优势 ，从而使我们的管道计算的整体反馈周期不到一秒。 此外，Flink 基于算子的松耦合架构 可以支持我们通过评分探索过程添加更多具有多个分数的潜在候选对来提高原始匹配系统的质量。 最后，Flink 对状态管理 的 内在支持 使我们能够通过实现基于 Flink 的状态和内存管理架构执行有状态计算的实时推理管道，为我们的用户提供更多价值。 以上所有内容为我们的实时配对服务提供了一个可扩展且稳定的系统。
用于 Azar 数据驱动匹配的 HyperMatch 架构
为了更好地了解我们系统的架构，让我们解释一下如何在 Hyperconnect 和 Azar 上执行匹配。 传统上，匹配是围绕将两个或更多实体匹配在一起而发展的。 为了在 Azar 进行实时匹配，我们在特定时间窗口收集来自特定个人的匹配请求，并尝试以低延迟匹配他们中的最佳配对。 我们将基于 Flink 的实时匹配系统分为六个步骤：
1. 收集源（数据和输入源）
2. 特征工程
3. 配对生成
4. 评分操作
5. 配对聚合（即“媒人”）
6. 输出到多个接收器
图 1：Hyperconnect 和 Azar 的 HyperMatch 架构
我们的匹配过程从 处理源 开始， 通过自定义 Netty HTTP 源 收集来自不同客户端的匹配请求，使我们能够将系统的响应时间提高到更接近实时。
匹配过程的 第二步 是 特征工程 步骤，包括矢量化、分割和用户标记等过程。 此步骤中的数据在进入匹配周期之前进行预处理，包括用于分割的条件标记（即执行 A/B 测试）或机器学习模型的用户特征向量化，然后由我们的分数匹配操作使用。 在这一步中，我们 Flink 作业的状态后端会管理用户的匹配历史，同时考虑用户的偏好和特征。
我们架构的第三步由 Pair Generator 服务 组成，该 服务收集匹配请求并在传递它们进行评分计算之前生成对。 在这一步中，operator 使用 Flink 的 Window API 和 keyed tumbling window 收集匹配请求 。
我们配对过程的下一步是我们的 计分操作 。 在这里我们并行调整多个评分逻辑以获得优化的结果，因此组织中的多个团队可以参与评分逻辑的推进。 在这一步中，我们全局管理匹配性矩阵，并在每个评分者中使用它来实现 Multi Armed Bandit 以提高匹配质量。 Score Operator 负责计算所有对的分数并及时回复。 为此，我们将每个记分员组并行化。 与每个评分微服务的通信基于 REST API，并利用 Apache Flink 的 AsyncDataStream 操作 。
HyperMatch 系统的第五步是 MatchMaker 服务，它根据评分操作的结果选择最佳配对。 该服务以容错的方式聚合不同评分微服务的结果，并通过实现我们的自定义触发器和驱逐器以及分布式排序算法来选择最佳对，这些算法显着提高了 MatchMaker 服务的性能。 在这里，成功的配对将被传递到匹配结果服务，而剩余的配对将使用 Flink 的 迭代流 功能 重定向回配对生成器（第 3 步） 。
配对过程的最后一步包括 配对结果 服务 该服务具有多种功能，例如将最佳配对作为接收器提供给我们的配对经纪人之一，显示实际的客户端到客户端视频匹配。 该服务还会分发结果并提供反馈以提高未来比赛的表现，或将结果发送给我们的日志记录和指标报告者。
上述基于 Flink 的 HyperMatch 架构部署在我们使用 Kubernetes 作为底层资源管理框架的 生产环境中 。 使用 Kubernetes 可以 通过我们的 Flink 部署 实现 高可用性 (HA) ，并使设置新的临时基础设施以轻松无摩擦地进行性能测试。 为实现此类任务关键型实时数据应用程序的零停机时间，我们基于 蓝/绿架构 配置了部署管道 。
图 2：Kubernetes 上的蓝/绿部署方法
在本文的前几节中，我们解释了为什幺选择 Apache Flink 将我们的匹配服务迁移到实时事件流架构，并实现稳定性和可扩展性以执行大规模机器学习和配对生成。 使用 Flink 使我们能够基于我们重新设计的撮合系统实现有状态撮合，并使我们能够服务于多种训练模型并为我们的用户提供更好的体验。
Be First to Comment