在讲新一代大数据技术架构前，先讲下大数据特征与大数据技术要解决的问题。

1.大数据特征：“大量化(Volume)、多样化(Variety)、快速化(Velocity)、价值密度低（Value）”就是“大数据”显著的4V特征，或者说，只有具备这些特点的数据，才是大数据。

本人对于大数据学习创建了一个小小的学习圈子，为各位提供了一个平台，大家一起来讨论学习大数据。欢迎各位到来大数据学习群：868847735 一起讨论视频分享学习。大数据是未来的发展方向，正在挑战我们的分析能力及对世界的认知方式，因此，我们与时俱进，迎接变化，并不断的成长，掌握大数据核心技术，才是掌握真正的价值所在。

2.大数据技术要解决的问题：大数据技术被设计用于在成本可承受的条件下，通过非常快速（velocity）地采集、发现和分析，从大量（volumes）、多类别（variety）的数据中提取价值（value），将是IT领域新一代的技术与架构。

介绍了大数据的特性及大数据技术要解决的问题，我们先看看新一代大数据技术架构的数据流架构图：

从这张图中，可以了解到大数据处理过程可以分为数据源、数据接入、数据清洗、数据缓存、存储计算、数据服务、数据消费等环节，每个环节都有具有高可用性、可扩展性等特性，都为下一个节点更好的服务打下基础。整个数据流过程都被数据质量监控系统监控，数据异常自动预警、告警。

新一代大数据整体技术架构如图：

将大数据计算分为实时计算与离线计算，在整个集群中，奔着能实时计算的，一定走实时计算流处理，通过实时计算流来提高数据的时效性及数据价值，同时减轻集群的资源使用率集中现象。

整体架构从下往上解释下每层的作用：

数据实时采集：

主要用于数据源采集服务，从数据流架构图中，可以知道，数据源分为前端日志，服务端日志，业务系统数据。下面讲解数据是怎么采集接入的。

a.前端日志采集接入：

前端日志采集要求实时，可靠性，高可用性等特性。技术选型时，对开源的数据采集工具flume,scribe,chukwa测试对比，发现基本满足不了我们的业务场景需求。所以，选择基于kafka开发一套数据采集网关，来完成数据采集需求。数据采集网关的开发过程中走了一些弯路，最后采用nginx+lua开发，基于lua实现了kafka生产者协议。有兴趣同学可以，另一同事实现的，现在在github上比较活跃，被一些互联网公司应用于线上环境了。

b.后端日志采集接入：

FileCollect,考虑到很多线上环境的环境变量不能改动，为减少侵入式，目前是采用Go语言实现文件采集，年后也准备重构这块。

前端，服务端的数据采集整体架构如下图：

c.业务数据接入

利用通过MySQL的binlog机制实时同步业务增量数据。

数据统一接入：为了后面数据流环节的处理规范，所有的数据接入数据中心，必须通过数据采集网关转换统一上报给Kafka集群，避免后端多种接入方式的处理问题。

数据实时清洗(ETL)：为了减轻存储计算集群的资源压力及数据可重用性角度考虑，把数据解压、解密、转义，部分简单的补全，异常数据处理等工作前移到数据流中处理，为后面环节的数据重用打下扎实的基础(实时计算与离线计算)。

数据缓存重用：为了避免大量数据流(400+亿条/天)写入HDFS，导致HDFS客户端不稳定现象及数据实时性考虑，把经过数据实时清洗后的数据重新写入Kafka并保留一定周期，离线计算(批处理)通过KG-Camus拉到HDFS(通过作业调度系统配置相应的作业计划)，实时计算基于Storm/JStorm直接从Kafka消费，有很完美的解决方案storm-kafka组件。

离线计算(批处理)：通过spark，spark SQL实现，整体性能比hive提高5—10倍，hive脚本都在转换为Spark/Spark SQL；部分复杂的作业还是通过Hive/Spark的方式实现。在离线计算中大部分公司都会涉及到数据仓库的问题，酷狗音乐也不例外，也有数据仓库的概念，只是我们在做存储分层设计时弱化了数据仓库概念。数据存储分层模型如下图：

大数据平台数据存储模型分为：数据缓冲层Data Cache Layer（DCL）、数据明细层Data Detail Layer（DDL）、公共数据层（Common）、数据汇总层Data Summary Layer（DSL）、数据应用层Data Application Layer（DAL）、数据分析层（Analysis）、临时提数层（Temp）。

1）数据缓冲层(DCL)：存储业务系统或者客户端上报的，经过解码、清洗、转换后的原始数据，为数据过滤做准备。

2)数据明细层（DDL）：存储接口缓冲层数据经过过滤后的明细数据。

3）公共数据层（Common）：主要存储维表数据与外部业务系统数据。

4）数据汇总层（DSL）：存储对明细数据，按业务主题，与公共数据层数据进行管理后的用户行为主题数据、用户行为宽表数据、轻量汇总数据等。为数据应用层统计计算提供基础数据。数据汇总层的数据永久保存在集群中。

5）数据应用层（DAL）：存储运营分析（Operations Analysis ）、指标体系（Metrics System）、线上服务（Online Service）与用户分析（User Analysis）等。需要对外输出的数据都存储在这一层。主要基于热数据部分对外提供服务，通过一定周期的数据还需要到DSL层装载查询。

6）数据分析层（Analysis）：存储对数据明细层、公共数据层、数据汇总层关联后经过算法计算的、为推荐、广告、榜单等数据挖掘需求提供中间结果的数据。

7）临时提数层（Temp）：存储临时提数、数据质量校验等生产的临时数据。

实时计算：基于Storm/JStorm，,。主要应用于实时监控系统、APM、数据实时清洗平台、实时DAU统计等。

HBase/MySQL：用于实时计算，离线计算结果存储服务。

Redis：用于中间计算结果存储或字典数据等。

Elasticsearch：用于明细数据实时查询及HBase的二级索引存储(这块目前在数据中心还没有大规模使用，有兴趣的同学可以加入我们一起玩ES)。

Druid：目前用于支持大数据集的快速即席查询(ad-hoc)。

数据平台监控系统：数据平台监控系统包括基础平台监控系统与数据质量监控系统，数据平台监控系统分为2大方向，宏观层面和微观层面。宏观角度的理解就是进程级别,拓扑结构级别,拿Hadoop举例，如：DataNode，NameNode，JournalNode，ResourceManager，NodeManager，主要就是这5大组件，通过分析这些节点上的监控数据，一般你能够定位到慢节点，可能某台机器的网络出问题了，或者说某台机器执行的时间总是大于正常机器等等这样类似的问题。刚刚说的另一个监控方向，就是微观层面，就是细粒度化的监控，基于user用户级别，基于单个job，单个task级别的监控，像这类监控指标就是另一大方向，这类的监控指标在实际的使用场景中特别重要，一旦你的集群资源是开放给外面的用户使用，用户本身不了解你的这套机制原理，很容易会乱申请资源，造成严重拖垮集群整体运作效率的事情，所以这类监控的指标就是为了防止这样的事情发生。目前我们主要实现了宏观层面的监控。如：数据质量监控系统实现方案如下。