无锡网站建设制作方案,网页设计实训报告模板图片,宣传推广费用预算,博兴专业做网站简介#xff1a; 本文介绍了Flink 在有赞的实践和应用#xff0c;内容包括#xff1a;Flink 的容器化改造和实践、Flink SQL 的实践和应用、未来规划。
作者#xff1a;沈磊
一、Flink 的容器化改造和实践
1. 有赞的集群演进历史
2014 年 7 月#xff0c;第一个 Storm…简介 本文介绍了Flink 在有赞的实践和应用内容包括Flink 的容器化改造和实践、Flink SQL 的实践和应用、未来规划。
作者沈磊
一、Flink 的容器化改造和实践
1. 有赞的集群演进历史
2014 年 7 月第一个 Storm 任务正式上线2016 年引入 Spark Streaming 运行在 Hadoop Yarn2018 年引入了 Flink作业模式为 Flink on Yarn Per Job2020 年 6 月实现了 100% Flink Jar 任务 K8s 化 K8s 作为 Flink Jar 默认计算资源Flink SQL 任务 On YarnFlink 统一实时开发2020 年 11 月Storm 集群正式下线。原先的 storm 任务全部都迁移到了 Flink2021 年我们打算把所有的 Flink 任务 K8s 化。2. Flink 在内部支持的业务场景
Flink 支持的业务场景有风控埋点的实时任务支付算法实时特征处理BI 的实时看板以及实时监控等等。目前的实时任务规模有 500。 3. 有赞在 Flink on Yarn 的痛点
主要有三部分
第一CPU 没有隔离。Flink On Yarn 模式CPU 没有隔离某个实时任务造成某台机器 CPU 使用过高时 会对该机器其他实时任务造成影响第二大促扩缩容成本高。Yarn 和 HDFS 服务使用物理机物理机在大促期间扩缩容不灵活同时需要投入一定的人力和物力第三需要投入人力运维。公司底层应用资源统一为 K8S单独再对 Yarn 集群运维会再多一类集群的人力运维成本。4. Flink on k8s 相对于 Yarn 的优势
可以归纳为 4 点
第一统一运维。公司统一化运维有专门的部门运维 K8S第二CPU 隔离。K8S Pod 之间 CPU 隔离实时任务不相互影响更加稳定第三存储计算分离。Flink 计算资源和状态存储分离计算资源能够和其他组件资源进行 混部提升机器使用率第四弹性扩缩容。大促期间能够弹性扩缩容更好的节省人力和物力成本。5. 实时集群的部署情况
总体上分为三层。第一层是存储层第二层是实时计算资源层第三层是实时计算引擎层。 存储层主要分为两部分 第一个就是云盘它主要存储 Flink 任务本地的状态以及 Flink 任务的日志第二部分是实时计算 HDFS 集群它主要存储 Flink 任务的远端状态。 第二层是实时计算的资源层分为两部分 一个是 Hadoop Yarn 集群另一个是 Flink k8s 集群再往下细分会有 Flink k8s 和离线的 HDFS 混部集群的资源还有 Flink k8s 单独类型的集群资源。最上层有一些实时 Flink Jarspark streaming 任务以及 Flink SQL 任务。
我们考虑混部的原因是离线 HDFS 集群白天机器使用率不高。把离线 HDFS 集群计算资源给实时任务离线使用内部其他组件的弹性计算资源从而提升机器使用率更好的达到降本效果。 6. Flink on k8s 的容器化流程
如下图所示
第一步实时平台的 Flink Jar 任务提交Flink Jar 任务版本管理Docker Flink 任务镜像构建上传镜像到 Docker 镜像仓库第二步任务启动第三步yaml 文件创建第四步和 k8s Api Server 之间进行命令交互第五步从 Docker 镜像仓库拉取 Flink 任务镜像到 Flink k8s 集群 最后任务运行。这边有几个 tips 作业模式为 Flink Standalone Per Job 模式每个 Flink Jar 任务一个镜像通过任务名称 时间截作为镜像的版本JobManager 需要创建为 Deployment 而不是 Job 类型Dockerfile 指定 HADOOP_USER_NAME与线上任务保持一致。7. 在 Flink on k8s 的一些实践
第一个实践是解决资源少配任务无法启动这个问题。 先来描述一下问题Flink on k8s 非云原生无法做到实时任务资源按需申请。当用户在平台配置的资源少于实时任务真实使用的资源时比如用户代码写死并发度但用户配置的并发度小于该值会出现实时任务无法启动的问题。 针对这个问题我们内部增加了一种 Flink Jar 任务并发度的自动检测机制。它的主要流程如下图所示。首先用户会在我们平台去提交 Flink Jar 作业当他提交完成之后在后台会把 Jar 作业以及运行参数构建 PackagedProgram。通过 PackagedProgram 获取到任务的预执行计划。再通过它获取到任务真实的并发度。如果用户在代码里配置的并发度小于平台端配置的资源我们会使用在平台端的配置去申请资源然后进行启动反之我们会使用它真实的任务并发度去申请资源启动任务。 第二个实践是 Flink on k8s 任务的资源分析工具。 首先来说一下背景Flink k8s 任务资源是用户自行配置当配置的并发度或者内存过大时存在计算资源浪费的问题从而会增加底层机器成本。怎么样去解决这个问题我们做了一个平台管理员的工具。对于管理员来说他可以从两种视角去看这个任务的资源是否进行了一个超配 第一个是任务内存的视角。我们根据任务的 GC 日志通过一个开源工具 GC Viewer拿到这一个实时任务的内存使用指标第二个是消息处理能力的视角。我们在 Flink 源码层增加了数据源输入 record/s 和任务消息处理时间 Metric。根据 metric 找到消息处理最慢的 task 或者 operator从而判断并发度配置是否合理。管理员根据内存分析指标以及并发度合理性结合优化规则预设置 Flink 资源。然后我们会和业务方沟通与调整。右图是两种分析结果上面是 Flink on K8S pod 内存分析结果。下面是 Flink K8S 任务处理能力的分析结果。最终我们根据这些指标就可以对任务进行一个资源的重新调整降低资源浪费。目前我们打算把它做成一个自动化的分析调整工具。 接下来是 Flink on K8s 其他的相关实践。 第一基于 Ingress Flink Web UI 和 Rest API 的使用。每个任务有一个 Ingress 域名始终通过域名访问 Flink Web UI 以及 Resti API 使用第二挂载多个 hostpath volume解决单块云盘 IO 限制。单块云盘的写入带宽以及 IO 能力有瓶颈使用多块云盘降低云盘 Checkpoint 状态和本地写入的压力第三Flink 相关通用配置 ConfigMap 化、Flink 镜像上传成功的检测。为 Filebeat、Flink 作业通用配置创建 configmap然后挂载到实时任务中确保每个 Flink 任务镜像都成功上传到镜像仓库第四HDFS 磁盘 SSD 以及基于 Filebeat 日志采集。SSD 磁盘主要是为了降低磁盘的 IO Wait 时 间调整 dfs.block.invalidate.limit降低 HDFS Pending delete block 数。任务日志使用 Filebeat 采集输出到 kafka后面通过自定义 LogServer 和离线公用 LogServer 查看。8. Flink on K8s 当前面临的痛点
第一JobManager HA 问题。JobManager Pod 如果挂掉借助于 k8s Deployment 能力JobManager 会根据 yaml 文件重启状态可能会丢失。而如果 yaml 配置 Savepoint 恢复则消息可能大量重复。我们希望后续借助于 ZK 或者 etcd 支持 Jobmanager HA第二修改代码再次上传时间久。一旦代码修改逻辑Flink Jar 任务上传时间加上打镜像时间可能是分钟级别对实时性要求比较高的业务或许有影响。我们希望后续可以参考社区的实现方式从 HDFS 上面拉取任务 Jar 运行第三K8S Node Down 机 JobManager 恢复慢。一旦 K8S Node down 机后 Jobmanager Pod 恢复运行需要 8分钟左右主要是 k8s 内部异常发现时间以及作业启动时间对部分业务有影响比如CPS实时任务。如何解决平台端定时检测 K8s node 状态一旦检测到 down 机状态将 node 上面有 JobManager 所属的任务停止掉然后从其之前 checkpoint 恢复第四Flink on k8s 非云原生。当前通过 Flink Jar 任务并发度自动检测工具解决资源少配无法启动问题但是如果任务的预执行计划无法获取就无法获取到代码配置的并发度。我们的思考是 Flink on k8s 云原生功能以及前面的 1、2 问题如果社区支持的比较快速的话后面可能会考虑将 Flink 版本与社区版本对齐。9. Flink on K8s的一些方案推荐 第一种方案是平台自己去构建和管理任务的镜像。 优点是平台方对于构建镜像以及运行实时任务整体流程自我掌控具体问题能够及时修正。缺点是需要对 Docker 以及 K8S 相关技术要有一定了解门槛使用比较高同时需要考虑非云原生相关问题。它的适用版本为 Flink 1.6 以上。 第二种方案Flink k8s Operator。 优点是对用户整体封装了很多底层细节使用门槛相对降低一些。缺点是整体使用没有第一种方案那么灵活一旦有问题由于底层使用的是其封装的功能底层不好修改。它的适用版本为Flink 1.7 以上。 最后一种方案是基于社区 Flink K8s 功能。 优点是云原生对于资源的申请方面更加友好。同时用户使用会更加方便屏蔽很多底层实现。缺点是K8s 云原生功能还是实验中的功能相关功能还在开发中比如 k8s Per job 模式。它的适用版本为Flink 1.10 以上。二、Flink SQL 实践和应用
1. 有赞 Flink SQL 的发展历程
2019 年 9 月我们对 Flink 1.9 、1.10 SQL 方面的能力进行研究和尝试同时增强了一些 Flink SQL 功能。2019 年 10 月我们进行了 SQL 功能验证基于埋点实时需求验证 Flink SQL Hbase 维表关联功能结果符合预期。2020 年 2 月我们对 SQL 的功能进行了扩展以 Flink 1.10 作为 SQL 计算引擎进行 Flink SQL 功能扩展开发和优化实时平台支持全 SQL 化开发。2020 年 4 月开始支持实时数仓、有赞教育、美业、零售等相关实时需求。2020 年 8 月新版的实时平台才开始正式上线目前主推 Flink SQL 开发我们的实时任务。2. 在 Flink SQL 方面的一些实践
主要分为三个方面
第一Flink Connector 的实践包括Flink SQL 支持 Flink NSQ Connector、Flink SQL 支持 Flink HA Hbase Sink 和维表、Flink SQL 支持无密 Mysql Connector、Flink SQL 支持标准输出社区已经支持、Flink SQL 支持 Clickhouse Sink第二平台层的实践包括Flink SQL 支持 UDF 以及 UDF 管理、支持任务从 Checkpoint 恢复、支持幂等函数、支持 Json 相关函数等、支持 Flink 运行相关参数配置比如状态时间设置聚合优化参数等等、Flink 实时任务血缘数据自动化采集、Flink 语法正确性检测功能第三Flink Runtime的实践包括Flink 源码增加单个Task 以及 Operator 单条记录处理时间指标修复 Flink SQL 可撤回流 TOP N 的BUG。3. 业务实践 第一个实践是我们内部的客服机器人实时看板。流程分为三层 第一层是实时数据源首先是线上的 MySQL 业务表我们会把它的 Binlog 通过 DTS 服务同步到相应的 Kafka Topic实时任务的 ODS 层有三个 Kafka Topic 在实时 DWD 层有两个 Flink SQL 任务。 Flink SQL A 消费两个 topic然后把这两个 topic 里面的数据去通过 Interval Join根据一些窗口的作用关联到对应的数据。同时会对这个实时任务设置状态的保留时间。Join 之后会去进行一些 ETL 的加工处理最终会把它的数据输入到一个 topic C。另外一个实时任务 Flink SQL B 消费一个 topic然后会对 topic 里面的数据进行清洗然后到 HBase 里面去进行一个维表的关联去关联它所需要的一些额外的数据关联的数据最终会输入到 topic D。在上游Druid 会消费这两个 topic 的数据去进行一些指标的查询最终提供给业务方使用。 第二个实践是实时用户行为中间层。用户在我们平台上面会去搜索、浏览、加入购物车等等都会产生相应的事件。原先的方案是基于离线来做的。我们会把数据落库到 Hive 表然后算法那边的同学会结合用户特征、机器学习的模型、离线的数据去生成一些用户评分预估再把它输入到 HBase。 在这样的背景下面会有如下诉求当前的用户评分主要是基于离线任务而算法同学希望结合实时的用户特征更加及时、准确的提高推荐精准度。这其实就需要构建一个实时的用户行为中间层把用户产生的事件输入到 Kafka 里面通过 Flink SQL 作业对这些数据进行处理然后把相应的结果输出到 HBase 里面。算法的同学再结合算法模型实时的更新模型里面的一些参数最终实时的进行用户的评分预估也会落库到 HBase然后到线上使用。 用户行为中间层的构建流程分为三个步骤 第一层我们的数据源在 Kafka 里面第二层是 ODS 层在 Flink SQL 作业里面会有一些流表的定义一些 ETL 逻辑的处理。然后去定义相关的 sink 表、维表等等。这里面也会有一些聚合的操作然后输入到 Kafka在 DWS 层同样有用户的 Flink SQL 作业会涉及到用户自己的 UDF Jar多流 JoinUDF 的使用。然后去读取 ODS 层的一些数据落库到 HBase 里面最终给算法团队使用。这里有几个实践经验 第一Kafka Topic、Flink 任务名称Flink SQL Table 名称按照数仓命名规范。第二指标聚合类计算Flink SQL 任务要设置空闲状态保留时间防止任务状态无限增大。第三如果存在数据倾斜或者读状态压力较大等情况需要配置 Flink SQL 优化参数。4. 在 HAHBase Connector 的实践
社区 HBase Connector 数据关联或者写入是单 HBase 集群使用当 HBase 集群不可用时实时任务数据的写入或者关联会受到影响从而可能会影响到业务使用。至于怎么样去解决这个问题。首先在 HBase 方面有两个集群主集群和备集群。它们之间通过 WAL 进行主从的复制。Flink SQL 作业先写入主集群当主集群不可用的时候自动降级到备集群不会影响到线上业务的使用。 5. 无密 Mysql Connector 和指标扩展实践
左图是 Flink 无密 Mysql Sink 语法解决的问题包括三点
第一Mysql 数据库用户名和密码不以明文方式向外进行暴露和存储第二支持 Mysql 用户名和密码周期性更新第三内部自动根据用户名鉴定表权限使用。这样做最主要的目的还是保证实时任务数据库使用更安全。
然后是左下图我们在 Flink 源码层面增加 Task 和 Operator 单条消息处理时间 Metric。目的是帮助业务方根据消息处理时间的监控指标排查和优化 Flink 实时任务。 6. Flink 任务血缘元数据自动化采集的实践
Flink 任务血缘元数据采集的流程如下图所示平台启动实时任务后根据当前任务是 Flink Jar 任务还是 Flink SQL 任务分别走两条不同的路径来获取任务的血缘数据再把血缘数据上报元数据系统。这样做的价值有两点
第一帮助业务方了解实时任务加工链路。业务方能够更清晰的认知实时任务之间的关系和影响当操作任务时能够及时通知下游其他业务方第二更好的构建实时数仓。结合实时任务血缘图提炼实时数据公共层提升复用性更好的构建实时数仓。三、未来规划
最后是未来的规划包括四点
第一推广 Flink 实时任务 SQL 化。推广 Flink SQL 开发实时任务提升 Flink SQL 任务比例。第二Flink 任务计算资源自动优化配置。从内存、任务处理能力、输入速率等对任务资源进行分析对资源配置不合理任务自动化配置从而降低机器成本。第三Flink SQL 任务 k8s 化以及 K8s 云原生。Flink 底层计算资源统一为 k8s降低运维成本Flink k8s 云原生更合理使用 K8s 资源。第四Flink 与数据湖以及 CDC 功能技术的调研。新技术的调研储备为未来其他实时需求奠定技术基础。关键词Flink SQLFlink on YarnFlink on K8s实时计算容器化
原文链接
本文为阿里云原创内容未经允许不得转载。
