酷狗音乐架构解析
1.大数据技术要解决的问题
大数据技术被设计用于在成本可承受的条件下，通过非常快速（velocity）地采集、发现和分析，从大量（volumes）、多类别（variety）的数据中提取价值（value），将是IT领域新一代的技术与架构。
2.数据流架构如图
从这张图中，可以了解到大数据处理过程可以分为数据源、数据接入、数据清洗、数据缓存、存储计算、数据服务、数据消费等环节，每个环节都有具有高可用性、可扩展性等特性，都为下一个节点更好的服务打下基础。整个数据流过程都被数据质量监控系统监控，数据异常自动预警、告警。
3.整体技术架构
将大数据计算分为实时计算与离线计算，在整个集群中，奔着能实时计算的，一定走实时计算流处理，通过实时计算流来提高数据的时效性及数据价值，同时减轻集群的资源使用率集中现象。整体架构从下往上解释下每层的作用：
1）数据实时采集
主要用于数据源采集服务，从数据流架构图中，可以知道，数据源分为①前端日志②服务端日志③业务系统数据。下面讲解数据是怎么采集接入的。
①前端日志采集接入：前端日志采集要求实时，可靠性，高可用性等特性。技术选型时，对开源的数据采集工具flume,scribe,chukwa测试对比，发现基本满足不了我们的业务场景需求。所以，选择基于kafka开发一套数据采集网关，来完成数据采集需求。数据采集网关的开发过程中走了一些弯路，最后采用nginx+lua开发，基于lua实现了kafka生产者协议，参照如下URL：lua开发：https://github.com/doujiang24/lua-resty-kafka
②后端日志采集接入
FileCollect,考虑到很多线上环境的环境变量不能改动，为减少侵入式，目前是采用Go语言实现文件采集，年后也准备重构这块。
③业务数据接入
利用Canal通过MySQL的binlog机制实时同步业务增量数据。
2）数据统一接入
为了后面数据流环节的处理规范，所有的数据接入数据中心，必须通过数据采集网关转换统一上报给Kafka集群，避免后端多种接入方式的处理问题。
3）数据实时清洗(ETL)
为了减轻存储计算集群的资源压力及数据可重用性角度考虑，把数据解压、解密、转义，部分简单的补全，异常数据处理等工作前移到数据流中处理，为后面环节的数据重用打下扎实的基础(实时计算与离线计算)。
4）数据缓存重用
为了避免大量数据流(400+亿条/天)写入HDFS，导致HDFS客户端不稳定现象及数据实时性考虑，把经过数据实时清洗后的数据重新写入Kafka并保留一定周期，离线计算(批处理)通过KG-Camus拉到HDFS(通过作业调度系统配置相应的作业计划)，实时计算基于Storm/JStorm直接从Kafka消费，有很完美的解决方案storm-kafka组件。
5）离线计算(批处理)
通过spark，spark SQL实现，整体性能比hive提高5—10倍，hive脚本都在转换为Spark/Spark SQL；部分复杂的作业还是通过Hive/Spark的方式实现。在离线计算中大部分公司都会涉及到数据仓库的问题，酷狗音乐也不例外，也有数据仓库的概念，只是我们在做存储分层设计时弱化了数据仓库概念。数据存储分层模型如下图：
大数据平台数据存储模型分为
①数据缓冲层(DCL)
存储业务系统或者客户端上报的，经过解码、清洗、转换后的原始数据，为数据过滤做准备。
②数据明细层（DDL）
存储接口缓冲层数据经过过滤后的明细数据。
③公共数据层（Common）
主要存储维表数据与外部业务系统数据。
④数据汇总层
存储对明细数据，按业务主题，与公共数据层数据进行管理后的用户行为主题数据、用户行为宽表数据、轻量汇总数据等。为数据应用层统计计算提供基础数据。数据汇总层的数据永久保存在集群中。
⑤数据应用层
存储运营分析（Operations Analysis ）、指标体系（Metrics System）、线上服务（Online Service）与用户分析（User Analysis）等。需要对外输出的数据都存储在这一层。主要基于热数据部分对外提供服务，通过一定周期的数据还需要到DSL层装载查询。
⑥数据分析层
存储对数据明细层、公共数据层、数据汇总层关联后经过算法计算的、为推荐、广告、榜单等数据挖掘需求提供中间结果的数据。
⑦临时提数层
存储临时提数、数据质量校验等生产的临时数据。
6）实时计算
基于Storm/JStorm，Drools,Esper。主要应用于实时监控系统、APM、数据实时清洗平台、实时DAU统计等。
7）HBase/MySQL
用于实时计算，离线计算结果存储服务。
8）Redis
用于中间计算结果存储或字典数据等。
9）Elasticsearch
用于明细数据实时查询及HBase的二级索引存储。
10）Druid
目前用于支持大数据集的快速即席查询(ad-hoc)。
11）数据平台监控系统
数据平台监控系统包括①基础平台监控系统②数据质量监控系统数据平台监控系统分为2大方向，宏观层面和微观层面。宏观角度的理解就是进程级别,拓扑结构级别,拿Hadoop举例，如：DataNode，NameNode，JournalNode，ResourceManager，NodeManager，主要就是这5大组件，通过分析这些节点上的监控数据，一般你能够定位到慢节点，可能某台机器的网络出问题了，或者说某台机器执行的时间总是大于正常机器等等这样类似的问题。刚刚说的另一个监控方向，就是微观层面，就是细粒度化的监控，基于user用户级别，基于单个job，单个task级别的监控，像这类监控指标就是另一大方向，这类的监控指标在实际的使用场景中特别重要，一旦你的集群资源是开放给外面的用户使用，用户本身不了解你的这套机制原理，很容易会乱申请资源，造成严重拖垮集群整体运作效率的事情，所以这类监控的指标就是为了防止这样的事情发生。
构建大数据平台的坑
大致可以分为①操作系统②架构设计③开源组件三类，下面举例：
1、操作系统级的坑
Hadoop的I/O性能很大程度上依赖于Linux本地文件系统的读写性能。Linux中有多种文件系统可供选择，比如ext3和ext4，不同的文件系统性能有一定的差别。我们主要想利用ext4文件系统的特性，由于之前的操作系统都是CentOS5.9不支持ext4文件格式，所以考虑操作系统升级为CentOS6.3版本，部署Hadoop集群后，作业一启动，就出现CPU内核过高的问题。经过很长时间的测试验证，发现CentOS6优化了内存申请的效率，引入了THP的特性，而Hadoop是高密集型内存运算系统，这个改动给hadoop带来了副作用。通过以下内核参数优化关闭系统THP特性，CPU内核使用率马上下降。调优关闭THP特性：
echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo never > /sys/kernel/mm/redhat_transparent_hugepage/defrag
关闭前
关闭后
2.架构设计的坑
最初的数据流架构是数据采集网关把数据上报给Kafka，再由数据实时清洗平台(ETL)做预处理后直接实时写入HDFS，如图：更改前
更改后
此架构，需要维持HDFS Client的长连接，由于网络等各种原因导致Storm实时写入HDFS经常不稳定，隔三差五的出现数据异常，使后面的计算结果异常不断，当时尝试过很多种手段去优化，如：保证长连接、连接断后重试机制、调整HDFS服务端参数等，都解决的不是彻底。每天异常不断，旧异常没解决，新异常又来了，在压力山大的情况下，考虑从架构角度调整，不能只从具体的技术点去优化了，在做架构调整时，考虑到我们架构重构的初衷，提高数据的实时性，尽量让计算任务实时化，但重构过程中要考虑现有业务的过渡，所以架构必须支持实时与离线的需求，结合这些需求，在数据实时清洗平台(ETL)后加了一层数据缓存重用层(kafka)，也就是经过数据实时清洗平台后的数据还是写入kafka集群，由于kafka支持重复消费，所以同一份数据可以既满足实时计算也满足离线计算，从上面的整体技术架构也可以看出。KG-Camus组件也是基于架构调整后，重新实现了一套离线消费Kafka集群数据的组件，此组件是参考LinkedIn的Camus实现的。此方式，使数据消费模式由原来的推方式改为拉模式了，不用维持HDFS Client的长连接等功能了，直接由作业调度系统每隔时间去拉一次数据，不同的业务可以设置不同的时间间隔，从此架构调整上线后，基本没有类似的异常出现了。此坑，导致我们的重构计划延期2个月，主要原因是由最初技术预研究测试不充分所导致。
3、开源组件的坑
大数据开源组件坑很多，简直不计其数，以下举例说明：
开源组件坑一：
当我们的行为数据全量接入到Kafka集群(几百亿/天)，数据采集网卡出现大量连接超时现象，但万兆网卡进出流量使用率并不是很高，只有几百Mbit/s，经过大量的测试排查后，调整以下参数，就是顺利解决了此问题。调整参数后网卡流量如图：
a.num.network.threads(网络处理线程数)值应该比cpu数略大
b.num.io.threads(接收网络线程请求并处理线程数)值提高为cpu数两倍
开源组件坑二：
在hive0.14 版本中，利用函数ROW_NUMBER() OVER对数据进行数据处理后，导致大量的作业出现延时很大的现象，经异常排查后，发现在数据记录数没变的情况，数据的存储容量扩大到原来的5倍左右，导致MapReduce执行很慢造成的。改为自己实现类似的函数后，解决了容量扩大为原来几倍的现象。说到这里，也在此请教读到此处的读者一个问题，在海量数据去重中采用什么算法或组件进行比较合适，既能高性能又能高准确性。
开源组件坑三：
在业务实时监控系统中，用OpenTSDB与实时计算系统（storm）结合，用于聚合并存储实时metric数据。在这种实现中，通常需要在实时计算部分使用一个时间窗口（window），用于聚合实时数据，然后将聚合结果写入tsdb。但是，由于在实际情况中，实时数据在采集、上报阶段可能会存在延时，而导致tsdb写入的数据不准确。针对这个问题，我们做了一个改进，在原有tsdb写入api的基础上，增加了一个原子加api。这样，延迟到来的数据会被叠加到之前写入的数据之上，实时的准确性由于不可避免的原因（采集、上报阶段）产生了延迟，到最终的准确性也可以得到保证。另外，添加了这个改进之后，实时计算端的时间窗口就不需要因为考虑延迟问题设置得比较大，这样既节省了内存的消耗，也提高了实时性。
大数据平台搭建前需要考虑的问题
一、平台的定位
交易？解决方案？商城？
二、数据的来源：
自有？第三方渠道？
三、人员的配备
技术驱动？销售驱动？运营驱动？
四、平台的规则
如何保证数据安全？如何给数据定价？如何保证数据质量？数据使用问题如何定则？数据的更新频率。及时。有效性。
五、快速变现
如何教育用户使用？如何让数据流通碰撞？
按照数据处理的顺序可以将大数据平台分为传统型和敏捷型，传统型的是在将数据送入数据仓储里面之前做，存入数据仓储里面的数据已经定义好了事实维度这些模型关系，业务人员可以直接进行查询，但是实时性和灵活性会大打折扣，如果业务人员需要分析一个事先没有的数据的话，需要去跟技术人员反馈，技术人员来完成处理。而敏捷型的则是将数据处理放到了后面，这样业务人员可以根据自己的需要去自助探索式的建模和进行数据分析，但是对系统的性能要求较高。上面只是从产品层面来进行了说明，下面从技术层面来进行对应：首先是数据仓储，一般是基于HDFS，采用分布式的文件系统来进行存储。数据处理和数据分析需要基于大数据处理引擎，如果想要实时的查询则需要用Spark这类的基于内存计算的，如果实时性要求没那么高的则可以用基于MR的这些离线计算的引擎。数据分析需要OLAP以及前端可视化这些技术来进行支撑。
自己搭建大数据平台建议开源技术
底层存储和计算平台的HDFS，Spark，Hive这些都是Apache开源的，OLAP有Kylin，Saiku这些开源工具，可视化有Airbnb开源的Superset，如果在这些基础上进行搭建和开发，相信能够省去一些开发量，但是事物除了有共性还是有个性的，想要绝对的满足需求是没有的，都是需要企业根据自身的需求来进行定制化开发的。
美团大数据平台
链家大数据平台
