共计 5218 个字符，预计需要花费 14 分钟才能阅读完成。
摘要： 本文整顿自京东批发 - 技术研发与数据中心张颖 & 闫莉刚在 ApacheCon Asia 2022 的分享。内容次要包含五个方面：
- 京东批发实时计算的现状
- 实时计算框架
- 场景优化：TopN
- 场景优化：动线剖析
- 场景优化：FLINK 一站式机器学习
点击查看更多技术内容
一、京东批发实时计算的现状
1.1 现状
- 技术门槛高、学习老本大、开发周期长。行业内实时开发能力只有多数人可能把握的现状；
- 数据开发迭代效率比拟低，反复逻辑重复的开发短少复用；
- 测试运维难，简单业务逻辑难以部分测试。
1.2 能源
- 降本增效、节俭人力，助力高效开发；
- 多角色数据开发，不同角色对应不同的开发方式，非数据人员也能做数据开发的工作。
1.3 指标
- 升高数据开发门槛，通过标准化积木式的开发，实现低代码配置化数据加工，进一步实现图形化清晰表白数据流转；
- 通过算子库组件的积淀，晋升开发效率，进步复用性，一站式加工；
- 通过单元测试以及积淀用例，进步开发品质。
二、实时计算框架
2.1 为什么做数据流框架
- 数据流框架：9N-Tamias/9N-Combustor，数据流框架基于计算引擎之上，提供一种易用高效的数据开发方式，包含：tamias，是基于 Flink 的引擎的开发框架；combustor：基于 Spark 引擎的开发框架。基于 9N-Tamias 和 9N-Combustor 提供数据流开发工具；
- 反对实时离线对立的表白；
- 多种应用形式：图形化、配置化、SDK 等；
- 算子、组件复用：数据流算子、转换算子、自定义算子、指标源算子，灵便的组合，积淀罕用的算子组合，组件化包含数据流组件和自定义组件，通过数据流开发积淀数据流组件，同时也凋谢自主开发自定义组件形式，通过算子、组件的复用，进步开发效率。
数据流框架下层各业务场景基于数据流组件化，实现业务数据的加工，包含样本核心、京享值、搜寻等一些业务。
2.2 怎么做实时计算框架？
实时计算框架分成四层：
- Function 层：实现比方 Json 解析、RPC 调用、以及数据流的链接；
- Process 层：对 Flink 引擎、Data Stream、Data Set、SQL 等 API 进行封装；
- Function 和 Process 组合生成 Operator，对具体的解决逻辑进行封装，比方实现 Source、Sink、Filter、Join 等罕用的算子；
- 一个或者多个 Operator 形成不同的场景，比方多流拼接导数的 Top N、动线剖析，这些形成了 JSON 的配置文件，而后再通过通用的引擎解析配置文件提交工作。
2.3 实时框架：专用 Ops 和 Function
数据接入 Source 和 Sink 层：实现了实时离线、近线罕用的数据源；
数据解析 Function：是为了将专用的计算逻辑进一步细化，在算子里封装多个 Function，进行灵便实现业务的逻辑；
算子 Template：如多流拼接、TopN、Count Time Window，业务本人实现会比较复杂，因而框架提供了这些算子的 Template，业务只须要在 Template 的根底上减少业务代码即可，不须要再对这些通用的算子进行学习、开发、调试等工作；
业务算子：能够基于 Template 已有的业务算子，重写失去新的业务算子，也能够自定义组合 Function，造成业务算子。
长处如下：
- 开发标准化：基于框架提供的专用算子，组合实现业务标准化的开发；
- 易用性晋升：框架提供一些罕用且难以实现的算子，使业务的开发变得简略；
- 开发迭代效率晋升：业务只须要关注业务逻辑，从而进步开发迭代效率品质的晋升；
- 品质晋升：框架提供的公共算子都是通过严格的测试，并通过长期的业务验证，从而进步开发品质。
三、场景优化：TopN
3.1 复用算子
首先不仅仅是 TopN，包含所有业务场景，数据接入和数据写出都是能够共用的，比方针对流计算，像 Kafka 或 JMQ 的接入和写出，都是能够复用的。
而后是数据解析的算子，包含 JSON 解析、CSV 解析都是能够复用的，然而如果每一个 JSON 解析和 CSV 解析都形象成一个 Operator，会须要很多的 Operator，因而形象了 Function 概念，而后 Function 能够组合成专用的算子。
【案例】以榜单计算为例，首先用订单榜单的一个元素值作为一个计算，而后 KeyBy 时用榜单 ID 加元素，接下来再进行一次订单榜单元素值的计算，把榜单 ID 和元素值进行一次 KeyBy，产生的 TopN 的排序。
在这里须要 KeyBy 两次，因为在京东的固有的场景下，有业务上的数据歪斜，只能采纳屡次聚合，或者是屡次排序的形式来解决问题。
3.2 工作优化
HDFS 小文件的问题：因为数据量十分大，因而在写 HDFS 时，如果 Rolling 策略设置不合理，会导致 HDFS 产生很多的小文件，可能会把 HDFS Name Node 的 RPC 申请队列打满。通过源码及其工作机制发现，HDFS 的文件 Rolling 的策略与 Checkpoint 的工夫以及 Sink 的并行度相干，因而正当设置 Checkpoint 的工夫和 Sink 的并行度，能够无效解决 Sink HDFS 的小文件的问题。
RocksDB 优化：通过查看官网文档能够发现，针对 RocksDB 相干的优化有很多，然而如何无效优化 RocksDB 的设置，外围就在于正当地设置 BlockCache 和 WriteBuffer 的大小，还能够增加 BloomFilter，相应调整这些参数，具体采纳哪些配置都能够。
Checkpoint 优化：次要是超时工夫、间隔时间、最小进展工夫。比方超时工夫是半个小时，这个工作产生了 Fail 了，如果它是在 29 分钟的时候，进行 Failover 的时候，须要从上个 Checkpoint 开始复原，须要很快生产前 29 分钟的数据。这种状况下如果数据量十分大，对工作是一个不小的冲击。然而如果把 Checkpoint 的工夫设置为更适合的 5 分钟或者 10 分钟，这个冲击量会少很多。
数据歪斜：造成数据的歪斜的状况有很多种，比拟难解决的是数据源中引发的数据歪斜问题，因而能够采纳屡次聚合或者屡次排序模式解决；另外一个是机器问题，是因为某台机器问题造成的数据歪斜，通常的体现是这台机器上所有的 Subtask 或者 TM 都会产生问题。
四、场景优化：动线剖析
4.1 什么是动线
用户点击以及页面展示的浏览门路称之为是动线；以搜索词举例，在京东平台首先搜寻台灯，而后又搜寻台灯学习，最初搜寻儿童学习护眼台灯，从台灯到台灯学习，到儿童学习护眼台灯，这样搜索词的线称为搜索词动线。
动线剖析的作用：寻找决定转化的要害门路点以了解用户决策习惯；常常相邻查问的搜索词通过导流工具串联，发现趋势动线；同一个用户对不同排序策略的接受程度，最终从细分的用户类型，提出个性化的导购布局和策略倡议；
4.2 数据建模
波及到串联相邻的搜索词问题，须要从宏观的角度进行数据建模。
首先在京东每天 PB 数据量的动线数据分析下，现有的图构造是没有方法解决这个问题。目前最罕用的一个分析方法，是把大批量的这种数据全副同时灌到数据库里，而后等离线数据运行一段时间，拿到剖析的后果从后果下来剖析。
以后业界在线图数据库进行这种大数据量的图剖析，会重大地影响数据库的运行和对外提供服务，因而引入 Flink Gelly 技术栈，通过相似 MySQL 与 Hive 的模式，解决这种大规模图剖析问题。
解决方案： 首先是把图的源数据通过 Flink SQL 从 Hive 里取出数据，通过 Left Join 把每个 Session ID 上面的 Query 链连起来，而后导入到 HDFS 里；从 HDFS 里读动线的数据，并且把动线的数据生成一个 Graph，依据数据科学家提出的剖析条件，将图的剖析的后果，间接灌到 OLAP 里进行多维的剖析；数据流实时计算的框架，从 Hive 或者 HDFS 里读数据，而后通过数据的 Join，包含写 HDFS、Graph Generate、Graph Analyse 等以可配置化的模式，生成专用算子放到算子库里，对于搜寻、举荐或者是广告等所有波及到动线剖析的部门，都能够用到。
4.3 模型建模
如果要对用户进行细分和个性化的剖析，就波及到模型建模。
首先是样本生产的过程，须要把数据从 Hive 里拿到，针对搜索词动线剖析须要拿到用户搜索词的表，而后和相应的订单表里决定下单的 Query 进行左连贯，生成样本放到 HDFS 里。
训练任务是从 HDFS 里把这些数据灌到 Alink 里进行 Shaply Value 建模，最终的 Query 重要度写到 Hive 里。
全链路是以专用算子的形式提供，目前京东采纳这种离线训练的形式，相当于是天级，之后心愿天级训练的模式实时化，做成分钟级的或者流式的 Join。
五、场景优化：FLINK 一站式机器学习
机器学习能够从四个方面来形容：特色、样本、训练、预估，而每个方面都有相应的问题（如上图）。
5.1 特色
从生成的角度，特色分为实时特色和离线特色；从特色的个性分为动态特色和动静特色。
- 动态特色是绝对变动不太大的特色，比方用户的年龄、店铺评分、商品金额，能够把动态特色和离线特色绝对应；
- 动静特色比方近一个小时内的点赞量，或者近一个小时内的点击量，动静特色和实时特色绝对应。
离线特色能够分为特色的整体生成过程。
- 特色个别是放到 Hive 里，会波及到一些特色的解析以及计算，最终生成一个特色的大宽表，而后把这些特色放到 Redis 里，如果是实时特色，波及到数据接入以及数据解析行为。
- 特色生成能够认为是业务化的过程，特色写入能够间接写入 Redis 里。
- FeatureOPS 次要是专一于特色生成，如果特色解析波及到业务算子，也能够用 FeatureOPS 来做。
5.2 样本
样本分为实时样本拼接和离线样本拼接两个链路；针对样本的个性，有离线的样本和实时的样本两个链路。
- 离线的样本拼接：通过 Join 存到数仓里，从数仓里拿取用户的曝光以及行为日志后，通过一系列的 Join 操作，造成样本的宽表，每个业务能够从样本宽表拿到属于本人的样本进行模型的训练。
- 实时的链路拼接也是雷同的，区别是样本拼接为实时的。Flink 样本基本上都是双流的，采纳 Unit 和 Timer 模式，适配多流的样本拼接，会波及到大状态的优化，大状态目前用的 State Backend 是 Roll SDB。Watermark 更新机制是采纳最慢的工夫作为更新的机制，如果某一个行为流的数据量比拟少，则会导致 Watermark 不更新的问题。
- 实时样本拼接针绝对离线的样本拼接更加艰难，包含一个窗口的抉择、一些业务上的样本拼接等。
Sample OPS 做样本品质的校验：首先在样本生成的阶段，须要做样本的散布，如正负样本的散布；其次在做实时样本或者是离线样本拼接时，须要对拼接率做监测；察看工作的延时率，即每一条样本的延时状况。
模型降级定义为只有模型进行模型校对时，才会认为它降级了，而增量训练不是模型降级。
5.3 模型 online learning
模型 online learning 是指数据迷信方向，并非大模型的方向。依照特色和样本实时离线的 Template，把模型分为实时和离线两种。
实时训练波及到模型实时参数的更新，但并非每一条数据训练一次，由超时工夫 CountWindow 解决这个问题，比方 Count 达到 1 万条或者超时工夫 5 分钟，来解决 Mini Batch 的问题。
针对 Online Learning，目前没有方法离线地做 AB，因而当一批数据进来时，能够先训练出一个模型，同样用这一批数据做 AB，以达到训练和 AB 的一体化。同时用离线的大数据量训练进去的模型，去及时校对实时训练进去的模型，避免模型训偏了；而后工作外部采纳 Keyby 形式实现数据并行，解决模型分布式的问题。
举例，如 Profit 模型，是采纳报警维度指标来设置，同时在模型产出时将模型推到模型库，而后 Parameter Server 会不停地在模型库外面把以后的模型的参数快照打到模型库里。
5.4 预估
Flink 做预估目前有两种计划：
计划 A 是将模型如 Tensorflow 或者 PyTorch 模型，通过 RPC 的形式或者 HTTP 的形式部署 Server，由 Flink Task 去近程 Invoke RPC 或者 HTTP，会有网络的开销。因为 Flink Task 可能是实时的，也有可能是离线的，所以在 invoke RPC 时，不可能让它随着 Flink 工作的启动而启动，或者随着 Flink 工作的进行而进行，须要有人来运维该 Server。
计划 B 是将模型 Load 到 Flink TM 外部，即在 Flink TM 外部 Inference 该模型，其长处是不必去保护 RPC 或者 HTTP 的 Server，从资源的角度缩小了网络开销，节俭了资源。
点击查看更多技术内容
更多内容
流动举荐
阿里云基于 Apache Flink 构建的企业级产品 - 实时计算 Flink 版现开启流动：
99 元试用 实时计算 Flink 版（包年包月、10CU）即有机会取得 Flink 独家定制卫衣；另包 3 个月及以上还有 85 折优惠！
理解流动详情：https://www.aliyun.com/product/bigdata/sc