• ARTICLE
  • STRING
  • CONVERTER
  • ENCRYPT
  • NETWORK
  • MORE
    CHART
    MATH
    COORDINATE
    IMAGE
    FILE
  • ARTICLE
    STRING
    CONVERTER
    ENCRYPT
    NETWORK
    MORE
    CHART
    MATH
    COORDINATE
    IMAGE
    FILE
logo Online Tools
All Chinese English Newest Hottest
12 search results Contribute

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的压力。

11 Technology lddgo Shared on 2024-04-09

理想汽车基于Flink on K8s的数据集成实践

16 Technology lddgo Shared on 2023-12-28

在软件开发的世界中,开源已成为普遍关注的话题。越来越多的企业和开发者认识到开源的重要性,并开始积极拥抱开源、贡献开源。自2017年开始,字节跳动流式计算团队开始尝试使用 Apache Flink 作为流式计算引擎,并逐步加大对开源社区的关注和投入。 近两个月来,团队方勇、胡伟华两位同学先后受邀成为 Apache Flink Committer。本文将对两位新晋 Committer 参与开源的心路历程进行专访。

22 Technology lddgo Shared on 2023-08-30

随着阿里云Flink实例的迁移下云以及新增需求接入,自建Flink平台规模逐渐壮大,当前总计已超4万核运行在自建的K8S集群中,然而 Flink 任务数的增加,特别是大状态任务,每次Checkpoint 时会产生脉冲式带宽占用,峰值流量超过100Gb/s,早期使用阿里云OSS作为Checkpoint数据存储,单个Bucket 每 1P数据量只有免费带宽10Gb/s,超出部分单独计费,当前规模每月需要增加1x w+/月。 为了控制这部分成本,得物开展了自建HDFS在Flink Checkpoint场景下的落地工作,实现年度成本节省xxx万元。 此次分享自建HDFS在实时计算checkpoint场景的实践经验,希望能为读者提供一些参考。

26 Technology lddgo Shared on 2023-06-19

在数仓分层架构体系中,从 ODS层到 DWD层数据转换需要进行数据清洗、脱敏、列式压缩等步骤。在B站用户行为埋点数据 ODS到 DWD层转换过程中,为了解决日增千亿条、20+TB/天增量规模下数据重复摄取带来的资源严重消耗的问题,引入了北极星(B站用户埋点行为分析链路)分流,按照部门进行分表。在埋点设计中使用spmid模型,将事件类型拆分为浏览 pv、曝光 show、点击 click等多个事件类型,并以这些事件类型作为除天、小时分区以外的第三级分区,再以事件类型产品来源作为四级分区。通过基于部门业务区分按照埋点事件类型+产品来源以多表多分区控制的形式,最大程度降低下游任务文件数据摄取数量以减少资源消耗。

23 Technology lddgo Shared on 2023-04-06

在日常Flink使用过程中,我们经常遇到Flink任务中某些Slot或者TM负载过重的问题,对日常的资源调配、运维以及降本都带来了很大的影响,所以我们对Flink的task部署机制进行了梳理和调研,准备在后续的工作中进行优化。由于jobGraph的生成以及任务提交流程因任务部署方式而不同,对我们后续的分析也没有影响,这里忽略前置流程,直接从Dispatcher出发,重点关注submit后executionGraph构建以及后续的任务部署过程。

22 Technology lddgo Shared on 2023-03-23

Blink提交采用进程模型(包装flink info/run命令)进行作业执行计划的生成和作业的提交,这个基本是大数据计算引擎jstorm/spark/flink的共识,采用该方式的优点在于: 简单: 用户只需在自己的jar包中进行逻辑处理 引擎client负责以方法调用形式调用用户main方法,然后编译、提交 干净 进程模型用户包用完销毁,引擎版本包通过目录隔离,不用考虑多版本问题。 但这也带来了缺点,每次都得走一遍大量class 加载、校验等jvm启动全流程。同时,大多数作业的的执行计划生成耗时是在20秒以内,也就是说此时瓶颈不在编译阶段,此时jvm启动开销就成为了瓶颈。尤其当这些操作极其高频时,带来的开销不容小视。

28 Technology lddgo Shared on 2023-01-12

以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的工作范围。

42 Technology lddgo Shared on 2022-11-30

本文主要介绍了端侧通过Blink任务对埋点数据进行实时聚合和清洗,解决端侧日志时效性问题,并基于实时日志搭建线上监控运维体系,从而提升端侧整体的稳定性。

34 Technology lddgo Shared on 2022-11-24

本文主要分享字节跳动在使用 Flink State 上的实践经验,内容包括 Flink State 相关实践以及部分字节内部在引擎上的优化,希望可以给 Flink 用户的开发及调优提供一些借鉴意义。

93 Technology lddgo Shared on 2022-08-15