关于后端:基于-Apache-Flink-的实时计算数据流业务引擎在京东零售的实践和落地

39次阅读

共计 5218 个字符,预计需要花费 14 分钟才能阅读完成。

摘要: 本文整顿自京东批发 - 技术研发与数据中心张颖 & 闫莉刚在 ApacheCon Asia 2022 的分享。内容次要包含五个方面:

  1. 京东批发实时计算的现状
  2. 实时计算框架
  3. 场景优化:TopN
  4. 场景优化:动线剖析
  5. 场景优化: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

正文完
 0