手机与电脑访问同一网站时，视频下载功能是否有所不同？

做的网站电脑上跟手机上不一样吗,提供视频下载的网站,域名解析官网,wordpress公益摘要#xff1a;本文整理自京东零售-技术研发与数据中心张颖闫莉刚在 ApacheCon Asia 2022 的分享。内容主要包括五个方面#xff1a; 京东零售实时计算的现状实时计算框架场景优化#xff1a;TopN场景优化#xff1a;动线分析场景优化#xff1a;FLINK 一站式机器学… 摘要本文整理自京东零售-技术研发与数据中心张颖闫莉刚在 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从资源的角度减少了网络开销节省了资源。 点击查看更多技术内容