专场18.1-云音乐实时数仓建设以及任务治理实践-汪磊.pdf

《专场18.1-云音乐实时数仓建设以及任务治理实践-汪磊.pdf》由会员分享，可在线阅读，更多相关《专场18.1-云音乐实时数仓建设以及任务治理实践-汪磊.pdf（22页珍藏版）》请在三个皮匠报告上搜索。

1、云音乐实时数仓建设以及任务治理实践汪磊+网易云音乐+数据平台开发专家 云音乐实时相关业务现状和数据规模分区流表技术介绍 数据任务治理实践 未来规划音乐相关业务现状和规模用户量300+用户，覆盖数仓、数据产品、算法、分析师、QA、应用开发，服务音乐主站、心遇、直播等音乐所有业务线任务量1500+实时任务、80%+任务依赖实时数仓使用SQL开发业务类型覆盖数据仓库建设、数据报表开发、线上排行榜积分统计、索引构建、实时特征/样本计算数据规模实时集群：400+台物理机器；每日原始日志千亿级别音乐相关业务现状和规模整体架构：音乐相关业务现状和规模问题：开发门槛高：FLINK本身复杂度问题、存储中间件众多

2、、用户背景问题模型设计问题：按照离线数仓的构建数仓模型，模型设计和任务性能需要权衡任务运维问题：任务指标难以定制，用户理解门槛高；流量波动问题、外部存储问题，机器环境问题，定位问题困难任务状态问题任务治理问题：离职员工任务问题任务价值闭环问题资源配置和性能问题分区流表技术建设模型设计问题：按照离线数仓的思想构建数仓模型，模型设计和任务稳定性之间需要权衡离线：相比实时场景对数据量、资源消耗敏感度较低优化手段多：分区、分桶、数据有序写入等可以高效的过滤掉无效的数据存储稳定性：HDFS等落地存储，数据量的增长对齐稳定性的影响相对较小实时：对任务延迟非常敏感，数据量任务的稳定影响较大，从而导致不任务S

3、LA达不到业务需求优化手段少：以KAFKA为基础的实时流表几乎没有什么过滤数据的高效策略存储稳定性：数据量的增长对KAFKA的稳定性影响较大，多一个消费，KAFKA性能/网络带宽就多一份压力分区流表技术建设整体架构：分区流表技术建设初期架构：使用门槛高：用户需要记住每个表包含的日志内容模型不统一：因为性能，放弃模型的统一复用成本高：开发代价大，复用程度低运维调整困难：分发策略调整代价大分区流表技术建设分区流表：使用门槛低：和HIVE分区表一样，用户只需要关注业务分区字段即可模型统一：和离线模型保持统一，使用分区策略，优化流量和计算成本复用成本低：和HIVE分区表一样，用户配置分区字段的元数据，

4、直接INSERT即可运维难度低：运行时动态新增或者建少分区策略分区流表技术建设产品实现：分区配置技术方案分区流表技术建设效果：效果：易用性：模型统一，使用门槛大大降低，覆盖音乐所有业务线任务稳定性：流量导致延迟问题得到彻底的解决资源节省：历史任务完成分区改造迁移总结节省成本 700W+，单任务最高节省资源90%，流量DOUBLE的情况下Kafka新增机器为 0数据任务治理实践现状清理优化可持续摸清现状，高效治理清理无用任务优化资源配置自动化，可持续降本提效数据任务治理实践摸清现状：数据治理有的放矢存储成本计算成本数据任务治理实践下线：发现可下线任务，可下线表，执行下线操作一键下线：表+任务血缘

5、：发现无用表 发现无用任务运维积极性：报警处理积极性僵尸任务：离职人员、转岗员工、长期不更新任务确认任务血缘：活动下线、下游访问记录数据任务治理实践优化：技术升级、配置优化、资源优化技术升级：历史任务升级到分区流表配置优化：大资源使用任务优化资源优化：模块化任务针对性优化，IO密集型任务、大状态任务定制资源队列配置数据任务治理实践可持续：告别大扫除式治理，数据任务治理常态化、平台化收集任务、数仓、资源等元数据沉淀前期治理经验，落地治理优化规则整合公示开发质量报表，督促任务治理常态化效果开发中：任务配置推荐、上线流程卡点运行中：任务质量扫描、数据/任务下线优化推进下线后：治理效果收集，治理规则持续优化未来规划未来规划1开发门槛问题数据开发门槛高，配置优化困难，涉及中间件多2数据链路追踪从数据收集到数据服务，出口多，难闭环3存储选择优化面对如此多的存储，如何选择，如何规范使用，如何优化性能4开发经验沉淀Lambda架构、存储优化、bitmap使用等未来规划底代码：降低数据开发门槛端到端：从入仓到出仓数据闭环，价值回流批流一体：lambda架构平台化场景化：以业务场景为基础，和下游数据服务深度整合，沉淀数据架构+经验，平台化、工具化未来规划以数据模型为中心配置化为主要开发手段上下游服务、架构、业务逻辑深度整合批流一体任务统计生成调度解决