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

云音乐实时数仓治理实践总结

01 现状和问题

• 业务类型：算法特征开发、索引构建、内容监控、数据报表、线上统计服务等
• 用户规模：700+累计用户，每日UV 100+，覆盖数仓、数据产品、算法、分析师、QA、应用开发等角色
• 任务规模：1500+实时任务、7000+离线调度任务，80%任务为SQL或使用配置开发
• 数据规模：集群规模2000+台物理机器，每日原始日志千亿级别
• 问题：
  • 老埋点体系导致Kafka负载高（高峰水位80%+），下游任务稳定性问题凸显
  • 全新埋点体系带来三倍日志流量增长，技术压力增大
  • 非专业数据开发用户多，实时场景开发门槛高，运维压力大，使用姿势问题多

02 治理规划

• 治理目标：摸清现状，控制增长，有的放矢
• 治理措施：
  • 依托集团smildon服务收集资源使用信息，统计任务成本，实时反馈用户
  • 构建虚拟资源池，按部门/业务线分组控制任务增长，倒推用户自主治理
  • 构建单位处理能力量化标准，统计任务输入流量，量化并发处理消息量
• 高效治理：
  • 无用任务探查与下线（血缘收集：SQL静态解析；下游数据无消费、离职未交接、长期未更新任务）
  • 任务资源配置优化（YARN CPU利用率提升、Rebalance/Rescale优化、状态存储介质调整、分区流表改造、Kafka batch优化）
• 可持续发展：
  • 构建自动化治理平台，化主动收益为被动收益
    • 开发前：辅助配置，上线校验
    • 运行时：自动化发现问题，规范化流程整理
    • 下线后：回收治理效果，红黑榜激励

03 技术优化

• Flink SQL优化：
  • Case1：消息反序列化前置优化（定制消息解析Format，支持前置过滤规则，性能提升50%以上）
  • Case2：索引构建场景优化（完善metrics监控、异步关联配置、定制Kafka connector、IO密集任务CPU配置优化）
• Kafka Batch优化：
  • 构建完善的Kafka监控体系（Prometheus+Grafana）
  • 解决流量均衡问题（Sticky Partitioner策略）
  • 消息发送优化（batch.size、liner.ms、partitioner配置）
• 分区流表优化：
  • 参考HIVE分区，自研分区流表技术
  • 写：按分区字段自动路由到正确分区，SQL无差别
  • 读：按查询条件自动推断分区，避免不必要数据读取，SQL无差别
  • 优势：运维成本低、数据建模一致、使用门槛低、可复用，为批流一体打下基础

04 未来规划

• 容器化改造：
  • 优秀资源隔离能力，防止任务间相互影响
  • 精细化资源配置（CPU可到千分位）
  • 宏观监控体系，快速发现资源不合理任务
  • 灵活资源调度能力，根据任务特点选择机器
• 自动化治理平台：
  • 利用元数据+灵活规则
  • 开发前：辅助配置，上线校验
  • 运行时：自动化发现问题，规范化流程整理
  • 下线后：回收治理效果，红黑榜激励