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

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