经典大数据架构案例：酷狗音乐的大数据平台重构

酷狗音乐的大数据架构本身很经典，而这篇讲解了对原来的架构上进行重构的工作内容，总共分为重构的原因、新一代的大数据技术架构、踩过的坑、后续持续改进四个部分来给大家谈酷狗音乐大数据平台重构的过程。
眨眼就是新的一年了，时间过的真快，趁这段时间一直在写总结的机会，也总结下上一年的工作经验，避免重复踩坑。酷狗音乐大数据平台重构整整经历了一年时间，大头的行为流水数据迁移到新平台稳定运行，在这过程中填过坑，挖过坑，为后续业务的实时计算需求打下了很好的基础。在此感谢酷狗团队成员的不懈努力，大部分从开始只知道大数据这个概念，到现在成为团队的技术支柱，感到很欣慰。【大数据开发学习资料领取方式】：加入大数据技术学习交流群，点击加入群聊，私信管理员即可免费领取

从重构原因，技术架构，踩过的坑，后续持续改进四个方面来描述酷狗音乐大数据平台重构的过程，在此抛砖引玉，这次的内容与6月份在高可用架构群分享的大数据技术实践的有点不同，技术架构做了些调整。

其实大数据平台是一个庞大的系统工程，整个建设周期很长，涉及的生态链很长(包括：数据采集、接入，清洗、存储计算、数据挖掘，可视化等环节，每个环节都当做一个复杂的系统来建设)，风险也很大。

重构原因

在讲重构原因前，先介绍下原有的大数据平台架构，如下图：

从上图可知，主要基于Hadoop1.x+hive做离线计算(T+1)，基于大数据平台的数据采集、数据接入、数据清洗、作业调度、平台监控几个环节存在的一些问题来列举下。

数据采集：
数据收集接口众多，且数据格式混乱，基本每个业务都有自己的上报接口
存在较大的重复开发成本
不能汇总上报，消耗客户端资源，以及网络流量
每个接口收集数据项和格式不统一，加大后期数据统计分析难度
各个接口实现质量并不高，存在被刷，泄密等风险

 

图片发自简书App

数据接入:
通过rsync同步文件，很难满足实时流计算的需求
接入数据出现异常后，很难排查及定位问题，需要很高的人力成本排查
业务系统数据通过Kettle每天全量同步到数据中心，同步时间长，导致依赖的作业经常会有延时现象

数据清洗：
ETL集中在作业计算前进行处理
存在重复清洗

作业调度：
大部分作业通过crontab调度，作业多了后不利于管理
经常出现作业调度冲突

平台监控：
只有硬件与操作系统级监控
数据平台方面的监控等于空白

基于以上问题，结合在大数据中，数据的时效性越高，数据越有价值(如：实时个性化推荐系统，RTB系统，实时预警系统等)的理念，因此，开始大重构数据平台架构。

新一代大数据技术架构

在讲