近年来，随着云计算、移动互联网、物联网等技术的发展，以及智能手机、平板电脑等终端设备的不断涌现，各种类型的电商、社交媒体等应用快速发展，产生了海量的数据，并且数据量增长的速度越来越快，庞大的数据资源引起了各个行业越来越多的关注，并促进了相关技术的发展与创新，产生越来越重要的价值，“大数据时代”已经悄然降临。
对于电信运营商来说，目前正处在一个转型的关键时期，从以语音、短信通信为核心业务的传统通信时代向移动互联网时代转移，从话务经营转为流量经营，从通信运营商转为信息运营商。因此，探讨如何通过引入大数据及其分析处理技术，规划建设大数据中心，以支撑流量经营，促进运营商战略转型，这对于运营商来说具有非常重要的现实意义。
浙江移动早在2014年就已经逐步开始试点基于分布式架构的大数据平台技术，在局部使用MPP数据库、Hadoop、流处理技术，试运行取得了较好的效果，但是由于缺乏统一的规划和技术演进策略。存在平台重复建设、数据大量冗余，数据质量较低，以及MPP数据库兼容性问题、Hadoop版本不统一、人员不足等问题，严重影响了对大数据的应用，因此亟须在公司层面构建“数据整合、能力共享、应用创新”的企业级大数据平台，对各域数据实现资产化的统一管理，进行持续的业务创新、运营提升、管理优化，推动开放共享，助力数字化服务曲线的发展。
企业级大数据平台一期项目从2014年开始规划设计，经过一年多的努力，截至目前，企业级大数据基础平台建设项目混合云平台建设工作已经完成，并已制定相应资源分配策略，进行了初始的资源分配。在项目建设过程中，遇到了各种技术难题，技术团队百折不挠地进行技术攻坚并取得一些成果，下面我们将把大数据平台建设过程遇到的一些典型问题和解决思路进行分析，以抛砖引玉，欢迎更多的技术交流和探讨。
（Hadoop生态系统）
Hadoop是一个能够对大量数据进行分布式处理的软件框架，具有可靠、高效、可伸缩的特点。Hadoop的核心是HDFS、Mapreduce和YARN等。
Hadoop主要应用于数据量大的离线场景。其特征为：
数据量大：一般线上用Hadoop的，集群规模都在上百台到几千台的机器，数据量从几十T到几千T不等甚至更高。
离线：Mapreduce框架下，很难处理实时计算，作业都以日志分析这样的线下作业为主。另外，集群中一般都会有大量作业等待被调度，保证资源充分利用。
数据块大：由于HDFS设计的特点，Hadoop适合处理文件块大的文件。大量的小文件使用Hadoop来处理效率会很低。
这一部分Hadoop集群主要分为云化ETL、基础分析库、实时查询库三大块，其中云化ETL和基础分析库物理上是一个Hadoop集群，实时查询库独立一个Hadoop集群；资源由云管理平台统一管理，通过多租户机制进行权限控制和资源隔离，通过平台建设，完善数据采集和数据交换平台建设，为大数据的存储、计算、分析和查询提供支撑。
问题一：Hadoop集群访问安全控制
问题描述：大数据Hadoop集群作为一个大的融合平台，会提供多个场景进行数据的存储计算，因此要求不同的厂家能够访问的数据是受限的，只能访问其获得授权的数据。
问题分析：开源版本和CDH版本，要独立搭建KDC，并进行非常复杂的配置，因此在国内基于Hadoop开发的大数据产品，除了FusionInsigh的局点，一般都不会使用安全版本，这个在集群访问安全上存在巨大的隐患。
问题解决：FusionInsight将Kerberos统一集成到版本中，采用RBAC的方式对大数据系统进行权限管理，将系统中各组件零散的权限管理功能集中呈现和管理，对普通用户屏蔽掉了内部的权限管理细节，对管理员简化了权限管理的操作方法，提升权限管理的易用性和用户体验。
问题二：HDFS存储共享计算隔离
问题描述：ETL、基础分析库集群需要由两个不同的部门同时使用，并且需要共享数据。两个部门的业务运行要互不干扰。
问题分析：由于需要共享数据，所以只能部署一套Hadoop集群，数据存放在同一个HDFS中，不同部门的计算业务使用Yarn做资源管理和调度，使用不同的任务队列，并限定队列的容量。但是这样做仍然会出现两个部门的作业运行到一台物理机上的情况，无法保证作业的互不干扰。
问题解决：完全计算隔离的实现采用yarn的标签调度策略（Label based scheduling），该调度策略适用于异构集群。通过该策略，将集群划分为不同的资源池，并打上不同的标签，资源池内按队列划分，同时将主机划分到不同的资源池中。如下图：
将一个Hadoop集群的计算节点划分为多个的resourcepool, 一个计算节点只能属于一个resource pool. 通过引入标签调度能力将不同部门的Yarn 任务队列绑定到不同的resource pool。任务队列中的作业只能在绑定的resource pool节点内运行，这样部门之间的计算任务就完全物理隔离了，保证互不干扰。
问题三：实时查询库Hbase多实例
问题描述：实时查询库有多个不同的应用，应用之间无数据共享，对于请求的响应时间非常高，需要达到毫秒级别，同时应用之间要求资源隔离互不影响。
问题分析：在之前的实践中，每个应用部署一套Hbase集群, 三个应用就需要三套集群，带来极大的维护成本，而且集群的利用率非常低。
问题解决：在一个Hadoop集群中支持部署HBase多实例，每个上层应用对应一个HBase服务实例。服务实例之间的资源通过Cgroup等机制进行控制和隔离，保证每个服务实例的SLA，实现了各Hbase实例之间的资源隔离，而且每个服务实例的资源还可以动态调整，极大的提高了集群的利用率，降低了维护成本。如下图：
问题四：Flume集群高可用
问题描述：目前Flume是非集群模式的，存在单点故障的风险，因此如何保障生产环境下Flume的可靠性，即使在某个Flume节点down掉之后依然能保证正常接收数据、业务不受影响。
问题分析：针对此问题提出采用DNS轮询方式，在SEQ侧通过域名方式连接Flume节点，当一台Flume节点down掉之后，会自动连接其他Flume节点，保证业务连续性。
问题解决：DNS轮询方式就是指将相同的域名解析到不同的IP上，并随机使用其中某台主机的技术。在SEQ节点上配置DNS服务后，每次SEQ节点访问Flume节点都需要一次DNS解析，然后选取可用的主机节点。这里又配置了NSCD服务（NSCD服务就是能实现DNS缓存，其可以在本地缓存DNS解析的结果来加快DNS解析的速度）。具体框架如下图：
问题五：HDFS磁盘检查机制优化
问题描述：目前DataNode所在部分节点，会出现一个磁盘utils占用率持续100%现象，导致HDFS读写速度下降，并在DataNode日志中有很多slow传输和slow写盘的异常。
问题分析：
通过对DataNode的日志持续的分析，发现有114个DataNode不定的频率出现“Noroute to host”异常，频率高的DataNode出现了117次，导致写Block文件失败，频繁触发了DiskChecker，结果出现磁盘utils上升的情况。DataNode部分数据盘IO持续10+s100%，则让client写文件时很慢，最终从业务侧发现查询数据或者写文件都变慢。
可以确定DataNode数据盘读写很慢的原因是磁盘不停的在做DiskChecker所致，进而影响了整个HDFS读写的效率，降低了平台的处理能力。
DiskChecker的存在，是为了解决当DataNode网络或者磁盘异常情况下，HDFS对管理的磁盘做健康检查的线程，最终会将异常磁盘排除，以避免坏磁盘对DataNode的影响。它的检查机制是进入数据盘每个目录下，创建一个目录，测试磁盘的可用性及读写速率（注意是递归的，会递归数据盘下所有的目录），测试完成后再删除之前创建的目录。但是当时DataNode在做DiskChecker时，数据盘的目录达到了6.5W个，这样在检查时耗时且执行频繁，对磁盘IO占用、性能消耗非常大，最终导致了磁盘读写变慢，HDFS读写变慢。
问题解决：
减少平台业务小文件数量；
合入开源优化补丁HDFS-8845，重启DataNode （DiskChecker由遍历数据盘整个文件目录树检查磁盘，改为只检查数据盘的根目录）；
优化的关键代码如下：
实时计算系统一般都是针对海量数据进行的，一般要求为秒级。实时计算主要分为两块：数据的实时入库、数据的实时计算。
主要应用的场景：
数据源是实时的不间断的，要求用户的响应时间也是实时的（比如网站的访问PV/UV、用户访问了什么内容、搜索了什么内容、实时信令、实时人流等，实时的数据计算和分析可以动态实时地刷新用户访问数据，展示实时流量的变化情况，分析每天各小时的流量和用户分布情况）；
数据量大且无法预计，但要求对用户的响应时间是实时的。
（浙江移动大数据平台实时分析系统）
数据实时采集
需求：功能上保证可以完整的收集到所有日志数据，为实时应用提供实时数据；响应时间上要保证实时性、低延迟在1秒左右；配置简单，部署容易；系统稳定可靠等。
目前的产品：Facebook的Scribe、LinkedIn的Kafka、Cloudera的Flume，淘宝开源的TimeTunnel、Hadoop的Chukwa等，均可以满足每秒数百MB的日志数据采集和传输需求。
流处理技术
在流数据不断变化的运动过程中实时地进行分析，捕捉到可能对用户有用的信息，并把结果发送出去。流处理技术具有低延迟、可扩展和容错性等特性。
目前的产品：IBM Streams、Storm、SparkStreaming等。
内存数据库
内存数据库通过将数据放在内存中直接操作的数据库，利用内存的读写速度快速读写、内存随机访问的特点，将数据保存在内存中，在内存中模仿建立表结构和索引结构并针对内存特性进行优化，相比从磁盘上访问，内存数据库能够提高应用的性能。
目前的产品：Redis、SQLfire等。
问题一：多线程模式下提升分布式内存数据库SQLfire的数据导入速率
问题描述：Sqlfire是一款SQL型的内存数据库产品，支持集群模式，具有高吞吐量，可预测的低延迟低延迟，支持动态和线性扩展，支持数据持久化等特点。我们在进行Sqlfire压力测试时发现，向Sqlfire中导入1W条记录需要7.5s的时间，这对于内存数据库来说是有点慢的。
问题分析：测试建立的表为分区表，Sqlfire支持分区表和复制表两种表模式，分区表按照建表时指定的分区字段分区，复制表则在Sqlfire集群每个节点都存有一份数据。一般大表适合建立为分区表，浙江移动场景下，比如客户信息表，产品订购表等大表适合建立为分区表，小表比如产品配置表，地区信息表，套餐维度表等一些维表更适合建立为复制表。建立的测试表为用户信息表，包括用户id，地市，县市，年龄，入网时间等11个字段信息。
浙江移动的Sqlfire集群由90个节点组成，主要使用Docker技术在18台物理机上每台隔离出5个Sqlfire节点，共计90个节点。
首先测试单线程模式下的Sqlfire的导入数据能力，以插入1W条记录为例，测试结果为1W条记录耗时为7.5秒。
然后是多线程模式下测试1W记录做insert操作，以开20个线程为例，测试结果1s。程序中开20个线程，每500条记录开一个线程做insert操作。在这种情况下测试10W条记录的插入，耗时为4s，相当于每5000条记录开一个线程做insert操作，进一步可以使用线程池来进行线程的管理。
以上结果可以看出，在一定线程数范围内提高线程数，可以明显的提高内存数据库Sqlfire的导入数据的速率，但对于多线程模式来说，存在的瓶颈就是当线程数达到一定的数量后，对于一定的硬件条件下可能提高线程数据对提高的导入数据速率并无明显的提高，这是因为线程数达到一定数量后，线程间的线程切换也是一个较大的开销。
问题二：IBM Streams与Kafka连接
问题描述：
IBM Streams与Kafka进行传输时发现，Streams与Kafka并不能连通；
IBM Streams 在与Kafka读写时发现性能不到1万条每秒，这远远没有达到我们设计之初的要求。
问题分析：通过查阅文档发现，Streams确实存在于Kafka传输的接口，进一步查看Kafka代码发现，原来Kafka本身存在缺乏安全机制，为了解决这个问题，我们在Kafka中间层上加入了Kerberos安全认证，所以Streams在连接Kafka时没有进行Kerberos的安全认证，从而导致Stream与Kafka不能连接。
针对读写性能问题，尝试使用多线程，并使性能达到100万条每秒。
问题解决：
Streams加入安全认证的部分代码如下：
多线程以下是部分代码：
问题三：Redis的Slave节点复制Master时，BGSAVE操作存在小概率数据错乱
隐患问题描述：在主从模式下的从Redis如果开启了定期BGSAVE，并且在做主从SYNC的时候，可能存在数据错乱的问题
问题分析：Redis的BGSAVE操作和slaveof触发的同步操作是互不相关的（对于从库），所以就完全有可能同时在进行备份和同步。Slave从Master读取最新的rdb文件后，加载到内存的步骤如下：
将读取回来的临时文件rename成server.rdb_filename文件
调用emptyDb方法清空整个数据库
然后调用rdbLoad(server.rdb_filename)将server.rdb_filename文件加载到内存
加载从master接受到的最新数据
问题在第一步到跟第三步里面的server.rdb_filename文件可能会被覆盖，因为此时如果有后台的BGSAVE进程由于定期事件触发启动备份后（正好大部分主从都是在从库做备份的），正好此备份程序在一和三之间完成（这中间需要清空所有数据，时间较长），于是 BGSAVE进程会覆盖掉server.rdb_filename文件内容。然后再第3步还是继续去加载server.rdb_filename文件到内存，实际上这个文件完全不是刚刚同步回来的文件，而是slave自己bgsave出来的文件。这样数据库的数据就会出现错乱。
问题解决：其实主从在做SYNC全量同步的时候，此时并没有必要做BGSAVE，因为等SYNC完成后，自然就会将同步回来的rdb文件覆盖BGSAVE文件 的：rename(server.repl_transfer_tmpfile,server.rdb_filename)，所以BGSAVE等于白做。
企业级大数据平台通过构建MPP资源池集群侧重于B域数据分析，主要包括核心数据仓库、数据集市）。
核心数据仓库：通过引入MPP数据库取代现有DB2数据库。数据只在核心数据仓库建数据模型，完成之后把数据同步到列存数据分析集市，同时列存数据分析集市作为大数据集市承载目前所有的基于数据库标准SQL开发的应用；仅当核心数据仓库出故障时，列存数据分析集市将接管核心数据仓库，避免两套系统同时跑造成资源浪费。
数据集市：承担核心仓库的容灾，以及数据集市的功能，向上层应用开放。分行存、列存建设。
下面我们介绍MPP集群应用过程中遇到的一些问题及解决措施：
问题：MPP集群装载机高可用实现
问题描述：GBase集群中的三台加载机为三个独立的点，三台机器创建了相同的目录，部署了相同的应用，每台机器人为分配不同的作业，相当于人为实现负载均衡，但是一旦某个点宕机，此节点的作业就被迫停掉。换句话说，加载机无高可用。
问题解决：三台加载机通过赛门铁克高可用软件实现三方互备，以VIP的方式实现业务漂移，可以做到在节点宕机时做到应用无感知迁移。改造后，三台加载机最可实现2台宕机不影响生产（处理能力会有相应下降）。
（示意图）
随着大数据处理和分析技术的不断进步和完善，对大数据的研究和应用必将得到进一步的深化，大数据的价值也可以得到更大程度的挖掘和利用，并在企业运营过程中发挥着越来越重要的作用。
浙江移动通过企业级大数据平台建设，并探讨建设过程的问题和解决方案，解决了大数据平台运行过程中的一些燃眉之急，同时增强了技术能力和知识储备，为未来大数据百放齐放的应用生态打下坚实的基础。
但正所谓“横看成岭侧成峰，远近高低各不同”，以上的问题分析和解决方案也许并不完全正确或完整，欢迎有更多志同道合的朋友一起交流和讨论！大数据平台建设不是一朝一夕的事，路漫漫其修远兮，我们永远都在路上。
如果字段的最大可能长度超过255字节，那么长度值可能…
只能说作者太用心了，优秀
感谢详解
一般干个7-8年（即30岁左右），能做到年入40w-50w；有…
230721