关于flink:网易互娱基于-Flink-的支付环境全关联分析实践

摘要：本文整顿自网易互娱技术核心计费实时平台与 SDK 技术负责人林佳在 Flink Forward Asia 2021 行业实际专场的演讲。本篇内容次要分为三个局部：

1. 从一次 APP 内购买领取聊起
2. 实时 SDK 与平台化的双线倒退
3. 走向实时全关联

点击查看直播回放 & 演讲PDF

说到网易互娱，大家首先想到的必定是游戏。作为网易的外围业务线之一，让游戏业务能够稳固牢靠地运行天然是重中之重，而游戏业务中最重要就是 APP 内购买服务的可靠性。本文的分享，就从一次 APP 内购买聊起。

一、从一次 APP 内购买领取聊起

玩家在游戏内购买道具的操作，首先会触发客户端行为与渠道商、计费核心进行通信，实现下单与领取。计费核心也会与渠道商进行交互，验证客户端订单的合法性以及领取状态。只有订单非法，游戏服务才会被告诉发货。而这一整套流程下来，每一个参与者产生的日志、数据监控点等等，它们的起源、数据结构、工夫步调可能是千差万别的。此外，这个过程中还有通信网络、数据库、监控零碎等的参加，使得整个过程非常复杂。

数据继续而大量地产生，数据之间会话的关联、数据源之间的异构、数据结构的异构还有工夫步调的不统一等等，都是咱们抉择用实时形式去解决的起因。

2017 年之前咱们的解决形式绝对落后，其中还有一些比拟古老的解决形式，比方网盘、rsync、T+1 解决离线工作等。

组件繁多、技术栈的割裂、时效性低、资源应用状况毛糙等，都会使资源无奈被平均地利用，而这正是带来时效性低的起因之一，也使代码能效、数据能效和资源能效都绝对较低。

上图是咱们之前的离线计算业务运行时的资源状况示意，在凌晨的时候去计算前一天的数据报表。在流式计算遍及之前，这是一种十分大规模应用的模式，在凌晨的时候用一大批机器执行 Spark 离线工作去计算前一天的后果。为了使报表能够按时交付，整个离线集群须要大算力，重叠大量的机器资源，而这些机器资源在许多时间段却是闲暇的，这便造成了资源能效低下。

如果这类计算工作能够被实时化，那么它所须要的算力即可被摊派到每一个工夫片上，防止在凌晨的时候资源应用重大歪斜。这些机器算力能够被托管在资源管理的平台上，所以它们也能够被其余业务所应用，进而晋升能效。

那么如何抉择实时化的框架？通过粗浅的调研和尝试之后，咱们最终抉择了 Flink，它所提供的个性，能够说是齐全适配了咱们的场景，下图列举了咱们对于技术架构选型的一些思考。

二、实时 SDK 与平台化的双线倒退

网易互娱从 2018 年开始便制订了双线倒退打算，全面推动数据中心 JFlink 的实时化过程。

通过屡次迭代，目前咱们曾经造成了一个一站式的运维平台 + 一个反对配置化开发的 SDK，且曾经实现了从可用到实用的进阶，下一步就是让用户爱用。

如何进步人力以及代码的效力，是咱们从一开始设计 JFlink 的时候就极其重视的。咱们心愿能够用无限的人力最大化地施展出能效，所以 SDK 的配置化、模块化变得尤为重要，要实现每一个实时作业都能够用一套配置语义来形容。

SDK 中封装了 JFlink SDK 罕用的连接器处理函数以及数据的流转对象，使得能够以配置化的模式来组装和应用它们。SDK 还提供了对立的配置文法，可能将作业以配置的模式形容后，动静地去组织结构 Flink DAG，以实现一个 SDK 程序包笼罩各类数据业务的个性，进步代码的复用和能效。

在 SDK 上，能够通过编写或生成 Kafka source、TiDB sink 以及两头聚合窗口的 UDF，即可拉起一个实时业务，不须要任何额定的开发。

为了配合 SDK 作业的对立文法，咱们也构建了一个一站式的解决平台，数据运维人员能够一站式、便捷、可视化地结构本人的数据业务。

即使 DAG 如此盘根错节，也仍然能够用解析文法来生成。

SDK 化策略实现了性能模块化、作业配置化、数据视图化以及流批一体化，让模块复用成为日常，让每个人都能相互理解彼此的作业，让异构的数据能为每一种写好的 UDF 模块进行解决，更重要的是让历史作业能够过渡到 Flink 上。

SDK 化还为咱们提供了疾速追随社区降级 Flink 版本的能力。SDK 隔离了业务逻辑和 Stream API，且绝大多数扩大性能都是在 SDK 侧对 Flink 原生类的拓展。这在追随 Flink 进行大版本升级时，一方面业务侧能够做到近乎零改变降级，另一方面也解决了外部对于 Flink 的拓展性能须要一直从各个版本的外部分支向新版分支上做合并的微小代价。

而双线倒退打算中的另一侧则是网易互娱的一站式平台，它齐全基于 K8s 实现了作业的独立集群化运行。

上图是平台的技术架构图，它配套的 Nexus、HDFS 等大数据组件来作为基础设施，保护了版本化的软件仓库，外面托管了包含 SDK 以及其余业务 jar 包。运行层面，Flink 应用了 k8s 独立集群的理念，即每一个作业都运行在本人独立的 k8s 命名空间下，领有本人的资源配套以及依赖汇合，实现了业务作业的齐全隔离运行以及资源的精细化调配。

为跟踪业务的迭代、作业的运行以及日志集剖析等等的平台化性能，JFlink 平台还封装好了各种运维接口，通过无状态的 rest 服务节点对外提供。平台还为运维人员提供了可视化创立实时作业的性能，这也正是咱们把平台与 SDK 相互配合而产生的优秀成果。

在一站式平台上，用户能够监督本人的作业实时状态，查阅运行日志，回滚历史版本，甚至能够查阅历史的异样、记录与统计、危险管制、生命周期的具体治理。

除了上述提到的能力，咱们的一站式平台上还有相当多其余性能，所有的性能与 SDK 相互配合独特组成了咱们的实时计算体系。

三、走向实时全关联

接下来，从数据业务的角度登程，剖析论述网易互娱在计费这一要害畛域上发展实时业务的教训与实际。

咱们最早的实际是对计费节点上产生的数据日志进行统计分析。不同起源的日志往往形式各异、千奇百怪，尤其是内部渠道商的回调，更是难以标准其日志格局，应该如何解决这些芜杂的格局，将它们变成一种能够对立解决的数据？这是咱们第一个摸索指标。

为此， SDK 封装了能够通过定义形象语法树来解决半结构化数据的 UDF Message Unified Parse，也制订了一些能够解决 Group By 以及聚合函数的 UDF。这样的需要，以配置文法的模式实现了这个统计业务，并通过封装的 Sink，写入自研的 TSDB 中。

日志剖析监控是从点的角度对计费业务接口、模块的访问量、法规状况和时延等来进行监控，以此实现对业务的无侵入式实时监督，升高了原先通过微批处理的时延以及业务服务器上监控脚本导致的 CPU 开销，也进步了监控发现率，使业务更牢靠。

紧接着，咱们把眼光投向了做通用的 ETL 框架。

异构数据通过 Parser 能够转化为对立的视图和对立的流转对象，随后能够被内置的合乎协定的 UDF 进行解决转换，咱们还实现了一个 Javascript UDF，通过灵便地 JS 脚本的嵌入，实现了轻松便捷地解决数据的转换工作。

通过 Flink 解决的数据流入咱们自研的异构数据仓库中，能够让业务方很不便地应用。还能够间接应用 SQL 来对实时产生的日志进行查问，甚至对这些日志进行聚合。而这些业务是以点的角度，将领取环境上的接口模块产生的数据实时地利用起来，每日解决的数据量大概在 30 Billion 级别，它为后续开展更深一步的数据业务实时化提供了无力的保障。

在 2019 年左右，咱们开始思考如何把这些点关联成有机的线？行将在领取环境上产生的领取，会从头到尾进行一个全链路的关联剖析，这其中的服务是否会产生问题？

这些服务的日志起源千差百怪，可能是来自于客户端的日志，可能是计费的日志，也可能是网关的日志。而针对这些与上下文剖析无关的链路式的日志，其实 Flink 曾经为咱们提供了十分不便的 API，就是 keyed stream + session window。

上图是全链路监控的架构图。链路剖析的常识被封装成了模型，并加载到 Flink 实时剖析的程序中。它会把一条领取链路上的数据进行实时串联，而后写入到咱们自研的图数据库中，供上游持续应用。此外，它还提供了 Daily Spark Job 来解决异样链路，以实现一些链路补全的需要，这也是对于 Lambda 架构的一种实际。

上图展现了全链路串联的成果。一笔领取订单能够被串联和展现，这种形式十分有利于 DBA 和产品去定位领取问题。

2020 年左右，网易互娱开始了对实时数仓的摸索，其中一个很重要的利用就是用户画像零碎。

此前 T+1 的模式展现数据报表，时效性比拟低。将报表降级革新和实时化之后，当初曾经能够通过接口的模式做到即时查问。而这种时效性的晋升使得产品能够去做精细化的经营，更及时地响应营销需要，进而晋升收益。

这些千差万别的计算，也是通过配置 +SDK 的模式来实现的。

尤其是流式的数据打宽，利用 Flink 提供的 Async IO 去表面进行 Lookup Join，都是实时处理数据的得力助手。

实时用户数仓和实时数仓指标为产品提供了玩家级的宏观查问和报表级的宏观查问。这些用户数据能够对接到可视化工具，通过数据可视化直观地进行展现，让产品经营能够发现从数字中无奈发现的法则，进一步挖掘出其中的数据价值。

有了上述实际之后，咱们开始思考，在一笔链路、一个用户的档次上，是否能将整个领取环境上的各种数据都关联起来，实现领取环境的宏观监控。

咱们将领取环境会话上各种异构术语，比方领取数据库 TiDB、领取中间件产生的各种日志数据，都通过 Flink 的 Interval Join 个性来进行关联剖析。

比方在 TiDB 中，存储有下单与付款的数据库 40 行，日志中有用户从客户端下单到渠道回调等领取过程的记录，对它们别离关联即可剖析出对应服务模块的状况。

进一步能够把各个模块状况产生的链路再进行关联合并，最终失去整个领取环境上的关联剖析后果。

例如，存在一种可能的异样，数据日志发货结束后，数量骤减或错误码的状况很多，那么运维人员能够很快发现发货服务存在异样。如上图展现这类关联剖析的状况，在生成环境的一些简单场景中，这套全关联剖析框架解决了近十种异构源的数据、关联剖析出几十种状况的业务场景会话。基于关联剖析的能力做出的许多领取环境上的实时报表，以帮助经营修复问题，领导产品制订策略，最终晋升收益。

数据业务实时化之后带来的资源能效和数据能效的晋升引人注目，而高时效性带来了全新的数据应用灵感的爆发，这也正是 Flink 带来的全新的大数据将来。

点击查看直播回放 & 演讲PDF

更多 Flink 相干技术问题，可扫码退出社区钉钉交换群
第一工夫获取最新技术文章和社区动静，请关注公众号～