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启动开销就成为了瓶颈。尤其当这些操作极其高频时，带来的开销不容小视。
以Flink为基础的实时计算在B站有着广泛而深入的应用。目前B站的Flink作业主要运行在三种集群环境下：纯物理机部署的YARN集群、为了提高Kafka集群资源利用率而和Kafka混部的YARN集群以及为了提高线上服务器而和K8S混部的YARN集群（这部分有计划在不远的将来使用Flink On K8S部署方式代替）。其中纯物理机YARN集群使用纯SSD盘的统一机型的服务器，包含1000+台服务器；和Kafka混部的集群目前为Flink提供了2000+ cores；和线上的K8S混部的集群已经使用了6000+ cores，并且还在持续增加。在业务方向上，B站的Flink已经应用在了包括AI、广告、数仓、数据传输和其它的很多业务上。目前B站Flink作业的最大并行度为2000。下图展示了B站实时应用的整体架构及Flink Runtime的工作范围。
