Apache Flink 是一个开源的流处理和批处理框架,具有高吞吐量、低延迟的流式引擎,支持事件时间处理和状态管理,以及确保在机器故障时的容错性和一次性语义。Flink 的核心是一个分布式流数据处理引擎,支持 Java、Scala、Python 和 SQL 编程语言,可以在集群或云环境中执行数据流程序。它提供了 DataStream API 用于处理有界或无界数据流,DataSet API 用于处理有界数据集,以及 Table API 和 SQL 接口用于关系型流和批处理。目前 Flink 最新已经迭代至 1.20 版本,在此过程中不光是 Flink 框架,插件本身也有部分 API 以及配置存在变更,本文主要针对较高版本的 1.17 Flink Pulsar 插件进行测试验证
Flink SQL在业务使用中有较多的双流join场景,当左右流的流量都较大,Join的等待时间即使为1小时,Flink Keyed State(Flink State分Operator State和Keyed State,后文所有State均代表后者)的存储大小也很容易达到TB级(内部默认使用的是RocksDBStateBackend)。 在State我们内部[1]之前就做了RT和长度的metric,当State的存储达到TB级别后,会发现State的scan/next/readNull请求RT会变得较高,另外双流Join不仅流量大,Join query的字段也较多,导致State的Value长度也较大,从而使得任务在流量高峰期CPU存在明显的周期性毛刺,根因是RocksDB的compaction引发。我们下面的内容主要是从业务场景跟进到RocksDB的读写行为,来优化RT耗时高的问题,并使用优化方案缓解compaction的压力。
随着阿里云Flink实例的迁移下云以及新增需求接入,自建Flink平台规模逐渐壮大,当前总计已超4万核运行在自建的K8S集群中,然而 Flink 任务数的增加,特别是大状态任务,每次Checkpoint 时会产生脉冲式带宽占用,峰值流量超过100Gb/s,早期使用阿里云OSS作为Checkpoint数据存储,单个Bucket 每 1P数据量只有免费带宽10Gb/s,超出部分单独计费,当前规模每月需要增加1x w+/月。 为了控制这部分成本,得物开展了自建HDFS在Flink Checkpoint场景下的落地工作,实现年度成本节省xxx万元。 此次分享自建HDFS在实时计算checkpoint场景的实践经验,希望能为读者提供一些参考。
在数仓分层架构体系中,从 ODS层到 DWD层数据转换需要进行数据清洗、脱敏、列式压缩等步骤。在B站用户行为埋点数据 ODS到 DWD层转换过程中,为了解决日增千亿条、20+TB/天增量规模下数据重复摄取带来的资源严重消耗的问题,引入了北极星(B站用户埋点行为分析链路)分流,按照部门进行分表。在埋点设计中使用spmid模型,将事件类型拆分为浏览 pv、曝光 show、点击 click等多个事件类型,并以这些事件类型作为除天、小时分区以外的第三级分区,再以事件类型产品来源作为四级分区。通过基于部门业务区分按照埋点事件类型+产品来源以多表多分区控制的形式,最大程度降低下游任务文件数据摄取数量以减少资源消耗。
Blink提交采用进程模型(包装flink info/run命令)进行作业执行计划的生成和作业的提交,这个基本是大数据计算引擎jstorm/spark/flink的共识,采用该方式的优点在于: 简单: 用户只需在自己的jar包中进行逻辑处理 引擎client负责以方法调用形式调用用户main方法,然后编译、提交 干净 进程模型用户包用完销毁,引擎版本包通过目录隔离,不用考虑多版本问题。 但这也带来了缺点,每次都得走一遍大量class 加载、校验等jvm启动全流程。同时,大多数作业的的执行计划生成耗时是在20秒以内,也就是说此时瓶颈不在编译阶段,此时jvm启动开销就成为了瓶颈。尤其当这些操作极其高频时,带来的开销不容小视。