浙江移动大数据平台践行之路（上）
以下文章来源于三墩IT人 ，作者汤人杰
作者
汤人杰 浙江移动大数据资深架构师
项目背景
近年来，随着云计算、移动互联网、物联网等技术的发展，以及智能手机、平板电脑等终端设备的不断涌现，各种类型的电商、社交媒体等应用快速发展，产生了海量的数据，并且数据量增长的速度越来越快，庞大的数据资源引起了各个行业越来越多的关注，并促进了相关技术的发展与创新，产生越来越重要的价值，“大数据时代”已经悄然降临。
对于电信运营商来说，目前正处在一个转型的关键时期，从以语音、短信通信为核心业务的传统通信时代向移动互联网时代转移，从话务经营转为流量经营，从通信运营商转为信息运营商。因此，探讨如何通过引入大数据及其分析处理技术，规划建设大数据中心，以支撑流量经营，促进运营商战略转型，这对于运营商来说具有非常重要的现实意义。
浙江移动早在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集群作为一个大的融合平台，会提供多个场景进行数据的存储计算，因此要求不同的厂家能够访问的数据是受限的，只能访问其获得授权的数据。
问题分析：开源版本和CDH版本，要独立搭建KDC，并进行非常复杂的配置，因此在国内基于Hadoop开发的大数据产品，除了FusionInsigh的局点，一般都不会使用安全版本，这个在集群访问安全上存在巨大的隐患。
问题解决：FusionInsight将Kerberos统一集成到版本中，采用RBAC的方式对大数据系统进行权限管理，将系统中各组件零散的权限管理功能集中呈现和管理，对普通用户屏蔽掉了内部的权限管理细节，对管理员简化了权限管理的操作方法，提升权限管理的易用性和用户体验。
问题描述：ETL、基础分析库集群需要由两个不同的部门同时使用，并且需要共享数据。两个部门的业务运行要互不干扰。
问题分析：由于需要共享数据，所以只能部署一套Hadoop集群，数据存放在同一个HDFS中，不同部门的计算业务使用Yarn做资源管理和调度，使用不同的任务队列，并限定队列的容量。但是这样做仍然会出现两个部门的作业运行到一台物理机上的情况，无法保证作业的互不干扰。
问题解决：完全计算隔离的实现采用yarn的标签调度策略（Label based scheduling），该调度策略适用于异构集群。通过该策略，将集群划分为不同的资源池，并打上不同的标签，资源池内按队列划分，同时将主机划分到不同的资源池中。如下图：
将一个Hadoop集群的计算节点划分为多个的resourcepool, 一个计算节点只能属于一个resource pool. 通过引入标签调度能力将不同部门的Yarn 任务队列绑定到不同的resource pool。任务队列中的作业只能在绑定的resource pool节点内运行，这样部门之间的计算任务就完全物理隔离了，保证互不干扰。
问题描述：实时查询库有多个不同的应用，应用之间无数据共享，对于请求的响应时间非常高，需要达到毫秒级别，同时应用之间要求资源隔离互不影响。
问题分析：在之前的实践中，每个应用部署一套Hbase集群, 三个应用就需要三套集群，带来极大的维护成本，而且集群的利用率非常低。
问题解决：在一个Hadoop集群中支持部署HBase多实例，每个上层应用对应一个HBase服务实例。服务实例之间的资源通过Cgroup等机制进行控制和隔离，保证每个服务实例的SLA，实现了各Hbase实例之间的资源隔离，而且每个服务实例的资源还可以动态调整，极大的提高了集群的利用率，降低了维护成本。如下图：
问题描述：目前Flume是非集群模式的，存在单点故障的风险，因此如何保障生产环境下Flume的可靠性，即使在某个Flume节点down掉之后依然能保证正常接收数据、业务不受影响。
问题分析：针对此问题提出采用DNS轮询方式，在SEQ侧通过域名方式连接Flume节点，当一台Flume节点down掉之后，会自动连接其他Flume节点，保证业务连续性。
问题解决：DNS轮询方式就是指将相同的域名解析到不同的IP上，并随机使用其中某台主机的技术。在SEQ节点上配置DNS服务后，每次SEQ节点访问Flume节点都需要一次DNS解析，然后选取可用的主机节点。这里又配置了NSCD服务（NSCD服务就是能实现DNS缓存，其可以在本地缓存DNS解析的结果来加快DNS解析的速度）。具体框架如下图：
问题描述：目前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由遍历数据盘整个文件目录树检查磁盘，改为只检查数据盘的根目录）；
优化的关键代码如下：
DiskChecker.checkDirs(finalizedDir);//删除checkDirs（finalizedDir）方法
DiskChecker.checkDir(finalizedDir);//调用checkDir(finalizedDir)方法
DiskChecker.checkDir(tmpDir);
DiskChecker.checkDir(rbwDir);
}
to be continued……
将为大家介绍大数据平台实时分析技术（内存数据库和流处理技术）和MPP集群及建设过程中遇到的一些问题和解决方案，敬请期待！