经典大数据架构案例：酷狗音乐的大数据平台重构
本文是酷狗音乐的架构师王劲对酷狗大数据架构重构的总结。酷狗音乐的大数据架构本身很经典，而这篇讲解了对原来的架构上进行重构的工作内容，总共分为重构的原因、新一代的大数据技术架构、踩过的坑、后续持续改进四个部分来给大家谈酷狗音乐大数据平台重构的过程。
眨眼就是新的一年了，时间过的真快，趁这段时间一直在写总结的机会，也总结下上一年的工作经验，避免重复踩坑。酷狗音乐大数据平台重构整整经历了一年时间，大头的行为流水数据迁移到新平台稳定运行，在这过程中填过坑，挖过坑，为后续业务的实时计算需求打下了很好的基础。在此感谢酷狗团队成员的不懈努力，大部分从开始只知道大数据这个概念，到现在成为团队的技术支柱，感到很欣慰。
从重构原因，技术架构，踩过的坑，后续持续改进四个方面来描述酷狗音乐大数据平台重构的过程，在此抛砖引玉，这次的内容与6月份在高可用架构分享的大数据技术实践的有点不同，技术架构做了些调整。
其实大数据平台是一个庞大的系统工程，整个建设周期很长，涉及的生态链很长(包括：数据采集、接入，清洗、存储计算、数据挖掘，可视化等环节，每个环节都当做一个复杂的系统来建设)，风险也很大。
重构原因
在讲重构原因前，先介绍下原有的大数据平台架构，如下图：
从上图可知，主要基于Hadoop1.x hive做离线计算(T 1)，基于大数据平台的数据采集、数据接入、数据清洗、作业调度、平台监控几个环节存在的一些问题来列举下。
数据采集：
数据收集接口众多，且数据格式混乱，基本每个业务都有自己的上报接口存在较大的重复开发成本
不能汇总上报，消耗客户端资源，以及网络流量
每个接口收集数据项和格式不统一，加大后期数据统计分析难度
各个接口实现质量并不高，存在被刷，泄密等风险
数据接入:
通过rsync同步文件，很难满足实时流计算的需求
接入数据出现异常后，很难排查及定位问题，需要很高的人力成本排查
业务系统数据通过Kettle每天全量同步到数据中心，同步时间长，导致依赖的作业经常会有延时现象
数据清洗：
注册酷狗ETL集中在作业计算前进行处理
存在重复清洗
作业调度：
大部分作业通过crontab调度，作业多了后不利于管理
经常出现作业调度冲突
平台监控：
只有硬件与操作系统级监控
数据平台方面的监控等于空白
基于以上问题，结合在大数据中，数据的时效性越高，数据越有价值(如：实时个性化推荐系统，RTB系统，实时预警系统等)的理念，因此，开始大重构
数据平台架构。
新一代大数据技术架构
在讲新一代大数据技术架构前，先讲下大数据特征与大数据技术要解决的问题。
1.大数据特征：“大量化(Volume)、多样化(Variety)、快速化(Velocity)、价值密度低（Value）”就是“大数据”显著的4V特征，或者说，只有具备这些特点的数据，才是大数据。
2.大数据技术要解决的问题：大数据技术被设计用于在成本可承受的条件下，通过非常快速（velocity）地采集、发现和分析，从大量（volumes）、多类别
（variety）的数据中提取价值（value），将是IT领域新一代的技术与架构。
介绍了大数据的特性及大数据技术要解决的问题，我们先看看新一代大数据技术架构的数据流架构图：
从这张图中，可以了解到大数据处理过程可以分为数据源、数据接入、数据清洗、数据缓存、存储计算、数据服务、数据消费等环节，每个环节都有具有高可用性、可扩展性等特性，都为下一个节点更好的服务打下基础。整个数据流过
程都被数据质量监控系统监控，数据异常自动预警、告警。
新一代大数据整体技术架构如图：
将大数据计算分为实时计算与离线计算，在整个集中，奔着能实时计算的，一定走实时计算流处理，通过实时计算流来提高数据的时效性及数据价值，同时减轻集的资源使用率集中现象。
版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。
发表评论