Abstract: This article is compiled from the speech delivered by Lin Jia, head of Billing Real-time Platform and SDK Technology at Netease Interactive Entertainment Technology Center, at the Flink Forward Asia 2021 industry practice session. This article is mainly divided into three parts:
- Start with an in-app purchase payment
- Two-line development of real-time SDK and platformization
- Towards real-time full correlation
Click to view live replay & speech PDF
When it comes to NetEase Interactive Entertainment, the first thing that comes to mind is definitely games. As one of NetEase's core business lines, it is naturally the top priority that the game business can run stably and reliably, and the most important thing in the game business is the reliability of the in-app purchase service. The sharing of this article starts with an in-app purchase.
1. Start with an in-app purchase payment
The player's operation of purchasing items in the game will first trigger the client behavior to communicate with the channel provider and the billing center to complete the order and payment. The billing center also interacts with channel providers to verify the legitimacy of client orders and payment status. The game service will only be notified of the shipment if the order is legitimate. After this whole process, the logs, data monitoring points, etc. generated by each participant may have different sources, data structures, and time steps. In addition, there are communication networks, databases, monitoring systems, etc. involved in this process, which makes the whole process very complicated.
The continuous and massive generation of data, the association of sessions between data, the heterogeneity between data sources, the heterogeneity of data structures, and the inconsistency of time pacing are all reasons why we choose to use real-time processing.
Before 2017, our processing method was relatively backward, and there were some old processing methods, such as network disk, rsync, T+1 processing offline tasks, etc.
Numerous components, fragmented technology stacks, low timeliness, and rough resource usage will prevent resources from being used evenly. Energy efficiency is relatively low.
The above picture is a schematic representation of the resource situation of our previous offline computing business operation, and the data report of the previous day is calculated in the early morning. Before the popularity of streaming computing, this was a very large-scale use model, using a large number of machines to perform Spark offline tasks in the early morning to calculate the results of the previous day. In order for reports to be delivered on time, the entire offline cluster requires large computing power, stacking a large number of machine resources, and these machine resources are idle for many periods of time, resulting in low resource energy efficiency.
如果这类计算任务可以被实时化，那么它所需要的算力即可被分摊到每一个时间片上，避免在凌晨的时候资源使用严重倾斜。这些机器算力可以被托管在资源管理的平台上，所以它们也可以被其他业务所使用，进而提升能效。
那么如何选择实时化的框架？经过深刻的调研和尝试之后，我们最终选择了 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 行，日志中有用户从客户端下单到渠道回调等支付过程的记录，对它们分别关联即可分析出对应服务模块的情况。
进一步可以把各个模块情况产生的链路再进行关联合并，最终得到整个支付环境上的关联分析结果。
For example, there is a possible abnormality. After the data log is shipped, there are many cases where the number of data logs plummets or there are many error codes, so the operation and maintenance personnel can quickly find out that there is an abnormality in the delivery service. The above figure shows the situation of this type of correlation analysis. In some complex scenarios of the generation environment, this full correlation analysis framework processes data from nearly ten heterogeneous sources, and correlates and analyzes dozens of business scenario sessions. Based on the ability of correlation analysis, real-time reports on many payment environments are made to assist operations to fix problems, guide products to formulate strategies, and ultimately improve revenue.
The improvement of resource energy efficiency and data energy efficiency brought about by the real-time data service is obvious to all, and the high timeliness brings a burst of new data usage inspiration, which is also the new big data future brought by Flink.