云音乐实时数仓治理优化实践

输⼊标题Title 2023DataFunSummit 云⾳乐实时数仓治理实践 演讲⼈：汪磊—⽹易云⾳乐—数据平台开发 输⼊标题Title Contents 现状问题治理实践技术优化未来规划 输⼊标题Title 01现状和问题 ⽤户规模 700+累计⽤户，每⽇UV100+覆盖数仓、数据产品、算法、分析师、QA、应⽤开发等⼏乎所有的开发 任务规模 1500+实时任务、7000+离线调度任务、80%任务为SQL或者使 ⽤配置开发 业务类型 算法特征开发、索引构建、内容监控、数据报表、线上统计服务等 数据规模 集群规模：2000+台物理机器；每⽇原始⽇志千亿级别 数据平台思路 业务 直接 平台 整合 技术 间接 让数据⾼效⽤起来 快速准确经济 出发点 易⽤性•平台使⽤⻔槛 •数据使⽤⻔槛 稳定性•流批任务稳定 •基建服务稳定 •算⼒：放⼤效 安全效率 应，极致优化 •⼈⼒：运维⽀持+业务使⽤ •基于集团服务构建，专为⾳乐开发者服务 •⽤户多样，基本所有⻆⾊的开发都会使⽤云村数据平台进⾏数据处理 •组件针对业务需求定制，让⽤户使⽤更少的成本、更低的⻔槛、⾼效安全的使⽤数据 •80%+的任务基于平台定制组件进⾏开发，平台对⽤户任务的可管控度⽐较⼤ ⽼埋点新埋点 基础概念 使用配置 问题 •降本提效⼤背景，倒推资源优化治理 •超⼤的流量导致Kafka负载居⾼不下，Kafka⾼峰⽔位达到80%+，下游任务的稳定性问题凸显 •全新埋点体系上线，带来三倍的⽇志流量增⻓，技术压⼒⼤ •⼤部分⽤户为⾮专业数据开发，特别是实时场景整体开发⻔槛⾼，运维压⼒⼤，使⽤姿势问题多 输⼊标题Title 02治理规划 摸清现状 ⾼效治理 技术优化 持续发展 摸清现状，控制增⻓，治理有的放⽮ •依托集团smildon服务，实时收集资源使⽤信息，统计任务成本 •成本实时反馈给⽤户，让⽤户对成本有直接的使⽤感知 •根据部⻔/业务线分组构建虚拟资源池，控制任务增⻓，倒推⽤户⾃主治理 •构建单位处理能⼒量化标准：根据任务⾎缘收集任务输⼊流量，统计单位并发处理的消息量 ⾼效治理 根据资源使⽤量和任务流量倒排，快速⾼效的收敛资源 1.⽆⽤任务探查,下线 2.任务本身资源配置不合理，导致资源浪费 3.因为业务的场景的收敛，流量的下落，导致的资源的浪费 4.任务本身实现有问题，有⽐较⼤的优化空间：配置优化、技术优化 •yarn.containers.vcores提升cpu利⽤率 •rebalance、rescale优化 •调整状态存储介质 •分区流表改造 •kafkabatch优化 队列资源⽔位 KAFKA线程池闲置率 ⾼效治理 ⽆⽤任务下线： •⾎缘收集：SQL静态解析（80%任务覆盖）；关键⽇志抽取（针对少量的JAR任务） •下线判断 •下游数据⽆消费：Kafka消费监控、Hive⾎缘+⽤户确认 •离职未交接任务：负责⼈、⽆效报警等+直接领导确认 •⻓期不更新、不操作的⽼版本任务+⽤户确认 •确认业务场景已经下线的任务+⽤户确认 可持续发展 未来规划，开发中 任务 ⼈⼈参与治理，化主动收益为被动收益 收集元数据，沉淀规则，发现问题开发治理 治理平台 ⽤户 通知，推进⽤户治理任务 构建⾃动化治理平台，化主动收益为被动收益 输⼊标题Title 03技术优化 FlinkSQL优化 •序列化优化，⽀持配置⼀些前置的过滤规则 •RebalanceRescale优化 •完善metrics监控,VCore资源调整 Kafka使⽤优化 •监控体系完善 •流量均衡问题 •消息Batch优化 分区流表优化 •问题背景介绍 •当前的问题和弊端 •分区流表⽅案介绍和落地效果 FlinkSQL优化 Case1：消息反序列化前置优化 SELECT user_id,action,os,props FROMmagina_dw_online.funclub_ods.ods_music_funclub_ua_logWHERE`action`in('impress','click','playend') ANDosin('iphone',‘android') ANDprops['sence']='user-fm' 背景 •消息格式：”userid\001os\001action\001logtime\001props” •其中props是json格式，⼤部分的⽇志详细信息都存储在props中，包含内容多 SELECT user_id,action,os,props FROMmagina_dw_online.funclub_ods.ods_music_funclub_ua_log *+options( 'format.os.list'=‘iphone,android','format.action.list'='impress,click,playend','format.keyword.include'='user-fm' )*/ WHERE`action`in('impress','click','playend')ANDosin('iphone',‘android') ANDprops['sence']='user-fm' 问题 在FlinkSQL的框架下，不管有⽤没⽤所有的消息都会被解析，在消息体⾮常复杂的情况下，这个带来极⼤的性能损耗 ⽅案 定制消息解析的Format在解析JSON之前，⽀持⼀些前置的过滤规则配置 性能提升明显，极端情况能提升50%以上的性能 FlinkSQL优化 Case2：索引构建场景 处理能⼒受Kafka分区数限制 介绍 •订阅业务库的BinLog,作为数据变更的通知机制 •维度关联BigLog中的维表数据⽣成⼀个⼤宽表,写⼊到索引引擎 问题 •并发能⼒受kafka分区数量限制 •维表关联数量过多时,DB的查询性能对任务性能影响⽐较⼤ 表越多性能越差 FlinkSQL优化 Case2：索引构建场景 ⽅案 •完善metrics监控,添加查询的RT指标监控,Sink性能监控等 •添加异步关联的配置,优化对表关联的关联的配置 •定制Kafkaconnector,添加rebalance,rescale配置,拆分读取和处理逻辑,增加并⾏度 •IO密集任务,通过yarn.containers.vcores配置,降低CPU使⽤,⽐如slot 配置为4,yarn.containers.vcores配置为2,⼀个slot只分配0.5个CPU 优化前 优化后 监控⼤盘 KafkaBatch优化 1.构建完善的Kafka监控体系：参考Kafka社区提供的⽅案，基于 prometheus+grafana构建完善的监控体系 线程闲置率 2.Kafka流量均衡问题：通过监控发现topic流量分布不均问题，导致部分机器的负载过⾼ 3.消息发送优化：考虑分区均衡、消息延迟、以及每次发送的消息体⼤⼩ •batch.size：每次请求的最⼤消息体⼤⼩ 机器负载 •liner.ms：最多能容忍的延迟时间，注：即使配置为0，也会有batch效果，应为kafkaproducer处理每次请求需要时间 •partitioner：升级client版本为2.4以上，引⼊StickyPartitioner策略，参考KIP-480 KafkaBatch优化 在分区均衡、消息体⼤⼩、以及最⼤容忍时间三个点之间做tradeoff •Kafka2.4版本中Kafka的Partitioner接⼝引⼊onNewBatch⽅法，每次创建新的Batch前调⽤ •StickyPartitioner策略： 1.随机选择⼀个分区 2.在onNewBatch⽅法调⽤前⼀直往⼀个分区发送消息 分区流表优化 ●KAFKA压⼒⼤，带宽呈现爆发式增⻓，DWD层以前总出⼝带宽700M*（N+1）,下游⼤流量DWD同样会有类似情况 ●任务资源压⼒⼤，900Core（N+1），相当于9台AMD*（N+1） ●任务稳定性没法保障，任何⼀个⻚⾯的流量波动都会对下游所有任务产⽣影响，运维保障困难 分区流表优化 历史⽅案：添加单独的⽇志分发，根据业务逻辑拆分成多张流表 ●运维成本⾼，⼿动维护分发逻辑和表的关系，难运维，分发粒度太粗，有效果但是仍然有性能问题 ●数据建模不能和离线保持⼀致，使⽤需要⽐较多先验知识，成本⾼，后续批流⼀体基本没可能 ●使⽤成本⾼，难复⽤，下游DWD层难以复⽤这套单独构建分发程序的⽅案，不能持续性的产⽣价值 分区流表优化 分区流表：参考HIVE分区，⾃研分区流表技术 根据SQL调件⾃动推断出需要的分区，避免不必要的数据读取 ⼀张表的按照字段配置分区，每个分区对应⼀个kafka的topic ●运维成本低，分区关系全部维护在表的元数据中，使⽤SQL⾃动推断合适的分区，⽤户基本⽆感知，可以做到精细化的分区配置，线上 ODS⼤表有100+分区 ●数据建模和保持⼀致，使⽤⻔槛低，给后续批流⼀体打了基础 ●可复⽤，分区的读写全部封装在SQL当中，⽤户⽆需单独开发分发程序，只要定好分区字段规则，就可以和常规表⼀样使⽤SQL读写，基本⽆感知，下游⼤流量的DWD层也可以轻松使⽤分区流表来优化流量 分区流表优化 写：按照分区字段内容⾃动路由到 正确分区，SQL和普通流表写⼊⽆差别 读：按照查询条件⾃动推断分区，读 取相应的topic，避免不必要的数据读取，SQL和普通流表读取⽆差别 输⼊标题Title 04未来规划 未来规划 •容器化改造 •优秀的资源隔离能⼒，防⽌任务之间相互影响 •精细化资源配置：CPU资源分配可到千分位 •构建宏观监控体系，快速发现资源使⽤不合理的任务 •灵活的资源调度能⼒，可以根据不同的任务特点，选择不同的机器 •⾃动化治理平台：利⽤元数据+灵活规则 •开发前：辅助配置，上线校验 •运⾏时：⾃动化发现问题，构建规范化流程进⾏整理 •下线后：回收治理效果，红⿊榜激励 输⼊标题Title 2023DataFunSummit —THANKS— 感谢您的观看