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启动开销就成为了瓶颈。尤其当这些操作极其高频时，带来的开销不容小视。
