网站建设crm,关键词排名优化技巧,廊坊做网站的电话,网站排名做不上去吗1.爱奇艺 Flink 服务现状爱奇艺从 2012 年开始开展大数据业务#xff0c;一开始只有二十几个节点#xff0c;主要是 MapReduce、Hive 等离线计算任务。到 2014 年左右上线了 Storm、Spark 实时计算服务#xff0c;并随后发布了基于 Spark 的实时计算平台 Europa。2017 年开始…1.爱奇艺 Flink 服务现状爱奇艺从 2012 年开始开展大数据业务一开始只有二十几个节点主要是 MapReduce、Hive 等离线计算任务。到 2014 年左右上线了 Storm、Spark 实时计算服务并随后发布了基于 Spark 的实时计算平台 Europa。2017 年开始引入 Flink用来替代部分 Spark Streaming 场景满足更低延迟的实时计算需求。在这之后相继推出流式 SQL 引擎、实时分析平台、实时数据生产平台等一系列工具用来提升实时计算开发效率。目前公司内 Flink 类型节点机器 15000 多台主要有两种部署模式混部模式Flink、Spark、MapReduce 等服务混合部署15000 多台规模独立模式Flink 服务独立部署用于重要业务约 700 多台规模Flink 作业规模达到 800 个每日数据生产量维持在万亿级别日均 2500 TB。下图所示为爱奇艺实时计算服务体系2.Flink 改进2.1 监控和报警Flink 原有的监控比较简单无法满足业务细粒度的监控报警需求。当计算过程出现问题时无法清晰了解计算作业内部情况不利于进一步分析。因此我们改进了 Flink 监控报警机制增加了很多细粒度的监控指标主要包括三种Job 级别监控指标监控 Job 状态、Checkpoint 状态及耗时当 Job 异常时自动通过实时计算平台重启。Operator 级别监控指标监控 Flink 任务的时延、反压、Source/Sink 流量并对每个 Operator 进行指标聚合以便用户查看。TaskManager 级别监控指标监控 CPU 使用率、内存使用率、JVM GC 等常规指标。2.2 状态管理由于 checkpoint 是 Flink job 内部状态当 job 重启时上一个 job 的状态就丢失掉导致部分数据丢失影响到业务。针对上述问题我们对 Flink 作业状态管理进行了改进。用户提交 Flink job 时会在实时计算管理平台上配置 checkpoint 路径。通过实时计算管理平台重启 Flink job 时先找到上一次成功的 checkpoint从中恢复 job 丢失的状态(flink run -s :checkpointPath/chk-n/_metadata)。改进后解决了状态丢失的问题但带来新的缺陷。对于状态数据很大的作业使用 RocksDBStateBackend 做增量 checkpoint重启后上一个 job 的 checkpoint 被依赖而无法删除。随着 Flink 作业长时间运行且发生多次 job 重启系统中堆积大量无用的 checkpoint。针对该问题我们使用 savepoint 方式打断增量 checkpoint 的依赖链主动重启通过计算平台主动重启 Flink job 前系统会先对 job 进行 savepoint 操作再关闭 job然后从该 savepoint 启动(flink run -s :savepointPath)。异常重启当平台监测到 Flink job 异常时会自动从上次 checkpoint 开始启动该 job。一旦 job 进入到 RUNNING 状态会先做一次 savepoint解除对上一个 checkpoint 的依赖。2.3 StreamingSQL为了便于用户开发流任务爱奇艺自研了支持 Spark、Flink 的流式 SQL 引擎 StreamingSQL。用户只需要通过编写 SQL 即可完成流计算 ETL 任务的开发。同时我们也提供 IDE 编辑器和大量常用的预定义函数。StreamingSQL 定义了 4 种类型数据表流表定义计算逻辑的输入目前支持Kafka维度表静态表用于与流表join比如字典映射临时表定义中间结果简化子查询逻辑结果表定义计算逻辑的输出数据从流表流入通过一系列 SQL 语句描述的计算计算结果写入结果表。对于计算逻辑比较复杂的计算可能需要定义多层嵌套的子查询对计算逻辑进行描述此时可以通过定义临时表将计算逻辑进行拆分降低子查询嵌套的深度。下图展示了 StreamingSQL 例子3.实时计算平台爱奇艺从 2015 年开始陆续推出实时计算管理、实时数据生产、实时数据分析等多个平台满足作业开发、数据生产、数据分析等不同场景下的开发需求提升用户的使用体验和开发效率。3.1 实时计算管理平台实时计算管理平台用于 Spark、Flink 任务的开发与管理。用户可以在 Web IDE 上配置相关参数进行任务的开发、上传、启动、停止等常规操作。计算管理平台提供了大量管理模块以提高用户的操作体验主要包括以下几项文件管理通过平台的文件管理功能用户可以方便的管理任务的 Jar 包及依赖库。函数管理为用户提供了丰富的系统函数并支持用户注册 UDF。版本管理用户可以实现任务、文件的版本对比及旧版本的回滚。系统同时提供了监控大盘、报警订阅、资源审计、异常诊断等多种功能辅助用户实时掌握作业情况。3.2 实时数据处理平台爱奇艺的数据处理平台经历了 3 个阶段的迭代升级从原先的离线数据采集系统一步步演变成支撑千万 QPS 的实时数据生产平台。■ Venus 1.0 – 数据采集系统2015 年开始我们推出了第一代数据采集平台 Venus 1.0。数据来源于两个方面从客户端端收集到的用户观看视频的行为数据及后台服务的日志数据。用户数据从 PC、App 等客户端采集投递给平台后端的 Nginx 接收器并落盘到本地文件中再由 Venus agent 解析文件进行数据采集。服务日志数据是由机器上的 Venus agent 解析 log 文件采集。Venus 采集的数据直接上传到 HDFS 进行后续的离线 ETL 处理生成离线报表供数据分析使用。Venus 1.0 版本主要基于 Apache Flume 框架进行开发并通过 tailgrep、awk、sed 等脚本进行数据过滤。在数据量较小时该平台很好的解决了数据处理的需求。■ Venus 2.0 – 实时数据处理平台在 2017 年随着数据量的增长及实时业务需求的出现Venus 1.0 渐渐变得力不从心。众多业务需求导致 agent 上存在大量过滤规则过多占用机器资源甚至影响到机器上服务的稳定性。同时每次变更都需要重启所有 agents大大提高上线成本及风险。因此我们设计实现了实时数据处理平台 Venus 2.0 版本将实时过滤功能从 Venus agent 迁移到 Flink 中并采用两级 Kafka 结构。改进后的数据平台无需重启即可动态增减数据处理规则数据处理能力也提升了 10 倍以上大大优化了平台的实时效果。■ Venus 3.0 – 实时数据生产平台随着实时业务的大量增加Venus 2.0 也带来了 Kafka 数据冗余、不方便分享等问题我们在 2019 年进行了第三次改造从数据处理升级到数据生产推出了实时数据生产平台 Venus 3.0 版本。用户可以在新平台上配置实时数据处理规则并可自由组合 Filter、Split、Window 等常见算子生产出来的流数据可以存储到流式数仓里。流式数仓是我们参考离线数仓概念打造的基于 Kafka 的数据仓库用于以数据仓库的形式统一管理流数据。借助实时数据生产平台及流式数仓用户可以更加便捷地加工实时流数据并通过业务线间的数据分享来减少流数据的重复生产。3.3 实时数据分析平台RAP(Realtime Analysis Platform)是爱奇艺基于 Apache Druid Spark / Flink 构建的分钟级延时的实时分析平台支持通过 web 向导配置完成超大规模实时数据的多维度分析为用户提供一体化的 OLAP 分析操作流程只需要几步简单的配置即可自动建立 OLAP 模型、生成分钟级延时的可视化报表并提供实时报警功能。RAP 实时分析平台解决了用户在数据分析中遇到的几个困难1.OLAP 选型困难爱奇艺目前提供了 Kylin、Impala、Kudu、Druid、ElasticSearch 等不同的数据存储/查询引擎用户需要了解不同 OLAP 引擎的优缺点花费大量精力学习依然可能选错。RAP 帮用户屏蔽了这层无需考虑中间数据、结果数据存到哪里、怎么查询。2. 开发成本高用户需要写 Spark 或 Flink 代码进行实时流数据处理并进行报表前端开发流程冗长而复杂。在 RAP 实时分析平台上用户无需编写Spark/Flink 程序或 SQL只需要通过 web 配置处理规则、分析规则、报表模板、报警规则即可大幅降低开发门槛提升了开发效率从以往的几天开发一张报表缩短到半小时。3. 数据实时性差从数据产生到数据可被查询中间存在较高时延(从数十分钟到天级别不等)且查询较慢。借助于 Flink 的实时处理能力RAP 实现了端到端分钟级低延时的实时报表功能且支持大规模数据亚秒级查询。维护耗费时间数据源发生改变时修改的范围会覆盖整个流程从数据处理到报表配置全部需要变更很难操作和维护。RAP 提供了自动更新功能帮助用户免去人工维护的麻烦。RAP 实时分析平台架构图4.Flink 业务案例4.1 信息流推荐实时化爱奇艺很早就开始了基于网格式的长视频推荐业务近几年随着短视频的兴起信息流形式的推荐发展迅速。信息流场景里需要在几秒内根据用户的观看行为实时推荐相关性更高的视频对数据的时效性要求更高。原本基于 Spark Streaming 的实时数据处理架构无法满足这类低延迟的需求因此我们协助业务迁移到 Flink 平台上消除了批量数据处理带来的延迟。单个任务的延迟从 1 分钟缩短到 1-2 秒端到端的性能提升了 86 倍显著提升了推荐效果。4.2 使用 Flink 生产深度学习训练数据深度学习大量应用于爱奇艺内部的各项业务帮助业务更好的挖掘数据的价值。在深度学习场景中训练数据的时效性非常关键。我们使用 Flink 帮助业务更加实时地生产训练数据。下图所示为爱奇艺广告点击率预测训练的架构业务原先通过 Hive/Spark 离线 ETL 方式生成训练数据每 6 小时才能更新一次算法模型导致用户特征关联不及时、不精确影响到广告投放效果。我们基于 Flink 进行了实时化改造将最近 24 小时的用户数据实时写到 Kafka 中通过 Flink 与存储在 HBase 中的过去 7 天的用户特征进行实时 join实时产出包含最新用户特征的训练数据将算法模型更新周期缩短到 1 小时以内从而支持更加实时、精确的 CTR (Click-Through-Rate)预估大幅提升广告投放效果。4.3 端到端 Exactly-Once 处理当 Kafka 节点出现故障重启或进行人工运维时Flink 作业会重复消费数据导致数据失准影响后续的数据处理比如模型训练。针对该问题我们设计实现了基于 Kafka Exactly Once Semantics 及 Flink two-phase commit 特性的端到端 Exactly-Once 处理方案。经过我们测试该方案会带来 20% 的计算性能损耗但数据重复率会从原先的最高 300% 降低到 0很好地解决了节点重启带来的数据精确度问题。关于 Exactly-once two-phase commit 的原理可以阅读 Apache Flink Blog 上的详细介绍https://flink.apache.org/features/2018/03/01/end-to-end-exactly-once-apache-flink.html5.挑战与规划随着 Flink 在爱奇艺得到越来越广泛的应用我们在资源管理、稳定性、实时开发等层面面临新的挑战。接下来我们会推进流批一体化进一步完善和推广 StreamingSQL 技术降低开发门槛。同时积极尝试基于 Flink 的机器学习、Flink on Kubernetes、Flink 动态资源调整等前沿方向。
