魅族大数据运维平台实践

摘要：一大数据平台介绍大数据平台架构演变如图所示魅族大数据平台架构演变历程年底，我们开始实践大数据，并部署了测试集群。因此，大数据运维的目标是以解决运维复杂度的自动化为首要目标。大数据运维存在的问题大数据运维存在的问题包括部署及运维复杂。

一、大数据平台介绍

1.1大数据平台架构演变

如图所示魅族大数据平台架构演变历程：

2013年底，我们开始实践大数据，并部署了测试集群。当时只有三个节点，因为我们起步比较晚，没有赶上Hadoop1.0，直接是用YARN来跑的大数据集群，而且默认就上了HA功能；

2014年9月节点增加到20个，数据日增30GB；

2015年6月上线Spark和Hbase，同时节点达到100个，数据日增10T；

2016年5月实现数据异地灾备；

现在我们主要在做大数据安全方面，包括用户认证和授权。目前规模已达到近千台服务器，存储30PB，日增60TB，每天跑2万个计算任务，业务包括搜索、广告、推荐、统计分析、用户画像、崩溃跟踪等等，今年还准备上线一个新机房，专门用来跑大数据业务。届时节点将达到2000个以上。

上图展示的是魅族大数据的整体架构，组件很多，组件之间相互关联，提供的应用也很多。

1.2 大数据运维的挑战

运维这样一个大规模的平台要面对哪些挑战呢？

首先来看大数据运维的特点。

l 集群规模、数据量大，且爆发式增长。大数据从字面上理解就是“大”，数据量大、规模大，而且是爆发式增长。

l 组件多，相互关联，关系复杂。

l 组件批量部署、上下线。部署上线的时候一般都是批量进行的，如果用传统方式（比如脚本工具）操作的话效率非常低，且容易出现问题。

大数据运维的特点决定了大数据运维的核心问题主要体现在两个方面：

l 一是如何管理好如何大规模的集群；

l 二是如何为用户提供高质量的服务。

因此，大数据运维的目标是：

l 以解决运维复杂度的自动化为首要目标。自动化能够提升稳定性，机器的操作比人要靠谱，固化的操作交给机器去做，可以降低人为造成的一些错误，提高线上的稳定性；；另一方面，自动化能够提高效率，把大部分操作交给机器之后，把运维人员从日常繁琐的操作中解放出来，我们就有更多的时间完成更加有意义、有价值的事情。

l 以预测和自动决策为目标的智能化。大数据运维的趋势正在从以解决运维复杂度为目标的自动化，向以预测和自动决策为目标的智能化转变，所以我们先要做好自动化才可以拥抱智能化。

1.3大数据运维存在的问题

大数据运维存在的问题包括：

l 部署及运维复杂。

l 重复监控、重复告警、监控分散。

l 权限控制、安全审计、任意跑任务。我们没有对用户的权限进行限制，一个用户拿一个账号就可以访问整个集群的数据，安全审计方面我们无法得知该用户是否访问敏感数据。另外，在Hadoop官网上也没有完善的用户管理体系和开箱即用的安全设置，需要我们摸索和实践。

l 无法查询业务资源使用、任意申请资源。在资源使用上，我们不知道业务每天用了多少存储、多少计算资源，业务要扩容也只是口头说资源不够了，而且运维他也没有足够的理由不给。

二、大数据运维平台建设

2.1 平台选型

首先要选择一个适合自己需求的平台进行开发。现在比较有代表性的平台选型是Cloudera和Hortonworks，当然我们也可以自己进行组件开发。基于公司的现状，用商业产品成本太大，完全照搬开源产品又不能满足我们的需求。

对比来看商业化产品和开源产品：

l 商业化产品，优点是安装部署非常简单，界面功能齐全；缺点是更新比较慢，因为它是非开源的，我们无法对其进行优化，而且一般商业化产品占用系统资源也比较高。

l 开源产品，优点是非常开放、自由，有强大的社区支持，安装部署方便；缺点是稳定性比较差，功能比较固定。

l 还有第三种选择，就是自研，我们独立研发产品，这样就可以实现定制化，功能灵活丰富，但同样存在缺点：耗时耗力，研发成本非常高。

我们的做法是集中三者的优点，在投入较低成本的情况下，获得功能丰富、可定制化、稳定迭代的管理平台，在出现问题的时候我们又可以依靠强大的社区得到快速解决。

2.2组件版本选型

基于业务发展需求，以及考虑到组件本身的稳定性和安全性，我们需要在不同阶段对组件的版本进行迭代和微调，由此可见商业方案和开源方案是走不通的，这些方案的版本都比较固定。

2.3运维规范制定

在平台化建设之前，我们做了很多技术规范，通过标准化来规范运维操作，平台化来落地标准化。

l 系统规范，主要是约束系统的版本、内核、系统账号等；

l 部署规范，主要是约束组件的版本、配置等；

l 扩容和升级规范，主要是用来制定扩容的窗口期等；

l 任务运行规范，比如说一个任务不能一天24小时跑下去；

l 监控标准，我们尽可能的避免规范造成的事故。

我们通过制定规范来约束人员操作，最大限度避免因不规范造成的运维事故。

2.4平台建设历程

上图是我们整个平台建设的历程。

l 首先通过平台将固化操作自动化，并通过平台化落地规范。

l 然后是建立统一的监控与告警平台。

l 第三是建立全面的安全防护。

l 最后是实现资源使用可视化、成本化。

2.4.1 平台化、自动化

如图，以一个集群的生命周期展示大数据运维是如何做到平台化和自动化的。

装机平台&云平台 

第一步是初始化，也就是系统的安装。根据机器的不同，分为物理机和虚拟机。物理机有装机平台，在平台上可以批量安装物理机操作系统，规范系统版本和账号。虚拟机也有云平台，可以批量创建并初始化云主机，可用于跑一些临时任务或实验性的集群。

集群管理

集群管理方面，之前说到的商业化产品也好，开源产品也好，一般都是针对单个集群来进行管理的。如果有多个集群，就必须部署多套平台来进行管理，这在一定程度上增加了运维的复杂度。

我们的做法是将多套集群统一管理起来，它们又拥有各自独立的空间互不干扰。在产品层面上实现前群分组管理，降低了运维难度，提高了运维效率。

主机管理

在平台上可以查看主机状态、过滤主机列表、执行主机级操作，比如为一些主机进行开关机操作，还可以删除主机、添加主机做机架管理、机架展示等。

主机列表

在主机列表页面，可以方便地看到主机详情和组件状况，健康状态、使用状态，包括CPU、内存、磁盘等方面的情况。

主机的健康状态主要分为四种，如果图标是红色，表示主机上至少有一个master组件挂掉了；橙色表示至少有一个Stave组件是挂掉的；黄色表示主机三分钟没有上报心跳了；蓝色则表示主机运行状态正常。

组件运维

在组件运维方面，可以看到所有的组件概述和状态，也可以实施组件级别的启停操作、添加删除组件、修改组件配置、执行组件的操作。集群完整的生命周期应该包括下线，就是回收阶段，这部分也比较好理解，基本上就是把上面的四步倒过来操作就可以了。

通过平台化我们落地了标准化，自动化又大大降低了大数据集群部署的难度，提高了运维效率，保证了集群的稳定性。

2.4.2 统一监控和统一告警

监控数据收集架构（时序指标）

前面提到传统大数据监控是比较分散的。我们的方案是用AMBARI指标监控系统，它可以统一监控平台各类服务及主机的运行情况，提供各类服务及主机的相关指标，从而达到判断集群健康情况的目的。整个流程包括监控指标的采集、存储、聚合及指标获取。

数据的收集流程

首先是位于主机上的AMS Client会不断的收集集群相关的各项指标和性能数据发送到ams的 metric collector，metric collector会将收集到的数据分别存到两张表里面

一张是以主机为单位的指标信息表，一张是以集群为单位的指标聚合信息表。

然后是指标的获取，Ambari提供了两种方式：一种是通过指标获取中心获取；另一种是通过Ambari Server端获取，前一种方式更接近于原生的指标数据，后一种方式则是更为常用的方式，可以说Ambari上层指标的获取都是通过这种方式来获取的，但本质上还是调用的第一种方式，拿到库中的原生数据，再进行加工及逻辑处理，最后返回到WEB端。

统一告警平台：接收告警并根据规则发送给责任人

有监控的需求就有告警的需求，但告警不能仅仅是对信息的转发，不然会让告警接收人员淹没在茫茫告警信息里面，所有的告警信息必须要有一个统一的平台进行接管，平台对收到的信息进行必要的和按规则设定进行合并再发送。

我们开发统一告警平台的目的解决报警遗漏、对非值班人员的打扰以及减少告警疲劳，确保报警/故障/提醒通告等及时、准确、高效地通知到具体人员。通过优化现有报警处理流程，我们引入值班机制、告警升级机制、告警合并收敛规则，做到故障的准确通知。通过统一监控平台和统一告警平台，降低大数据告警设置的难度，同时也提高了运维人员对告警的敏感度。

2.4.3认证、授权、审计全面防护Hadoop

全面防护Hadoop。我们最早部署Hadoop集群时并没有考虑安全问题，随着集群的不断扩大， 各部门对集群的使用需求增加，集群安全问题就显得颇为重要。通过上图来看从里到外的安全防护体系主要包括哪些方面。

l 最里面的是OS级别的安全，主要是一些账号设置等。

l 第二方面是权限控制，主要是对特定资源和特定访问用户进行授权或拒绝访问。权限控制是建立在安全认证基础上的。

l 第三层次是安全认证，安全认证是对用户的身份进行核对，确保用户是正确的用户，我们用的是Kerberos体系。

l 最后是网络边界安全体系，包括硬件防火墙，VLAN/子网隔离等等。

l 通过这四层，我们保证进来的用户都是通过安全认证的，而且是有权限去操作这个集群的。但用户操作是否合理、到底访问了哪些数据，或者说有没有尝试访问敏感数据，这就要交给审计来做了，安全审计对数据安全也是至关重要的。OS级别的安全和网络安全一般都是统一的，这里不做展开。

安全认证

Hadoop的安全认证是基于Kerberos来做的，Kerberos是一个网络身份验证协议，用户输入自己的验证信息来进行验证，如果验证通过，会获取到ticket，用户拿这些ticket去访问多个接入Kerberos的服务。

它主要解决了服务器到服务器的认证，解决了Client到服务器的认证，但对用户级别的认证没有实现，也就是说它无法限制用户提交作业。

Hadoop本身并不串接用户账号，它主要是通过Kerberos协议对用户的身份进行验证。我们从 YARN 上的 MR 任务提交过程简单说明一下。

在客户端执行任务之前，它会先跟KDC做自我验证，获取TGT，客户端通过TGT向KDC请求服务ticket，KDC 生成 session key 后一并发给客户端，客户端拿到ticket之后，向服务验证自己，完成身份验证。

权限控制

权限控制我们用的是Hadoop系统当中的安全管理框架Apache Ranger来实现，它是一种定义和管理安全策略的集中式组件，里面内置了一些通用的策略防护和策略模型，这些安全策略在Hadoop支持的组件上会被强制执行。

如上图，我们来看一下策略执行过程。

首先用户请求资源，匹配到该资源的所有权限，然后对所有资源进行检查，先看是不是在拒绝访问列表里，如果在就拒绝访问，如果不在就看是不是在允许列表里，如果在就允许访问，如果不在，就拒绝访问，或者做决策下放。Ranger可以选择将决策下放给系统本身的访问控制层。

Ranger架构

Ranger架构主要由三个部分组成：

第一部分是同步用户，它会定期加载用户，然后同步给管理中心；

第二部分是管理中心，管理中心提供接口，同时也执行用户设置的策略。

第三部分是客户端的插件。这些插件会被嵌入到组件执行流程当中，定期向管理中心拉取策略，用来执行这个策略的访问决策。当然它也会定期把这些访问的审计日志记录起来。

安全审计

安全防护的最后一环是审计。审计我们用的是Apache Eagle框架，它是一个高度可扩展的行为监控警报平台，采用了灵活的应用框架和经过实践考验的大数据技术，如 Kafka，Hbase和 Storm。提供了基于元数据驱动的告警引擎和高度可定制的告警策略来报告异常行为的发生，实时监控用户的操作行为，实时检测敏感数据访问和恶意数据操作。

Apache  Eagle框架主要由三个部分组成：

l 首先是数据流的接收和存储。Eagle支持任何类型的数据流接收到它的策略引擎中。比如HDFS的审计机制可以通过Kafka将这些资质收集过来，发送到简单的策略执行当中进行处理。

l 第二部分是主机的实时数据处理引擎，Eagle提供一个独立于物理平台的高效流处理API，处理实时发过来的数据。

l 第三个是告警，它提供了灵活的告警框架。

Eagle的应用场景，主要是用来做数据行为监控。

l 监控Hadoop中的数据访问。

l 检测非法入侵和违反安全规则的行为。

l 检测敏感数据访问，防止数据丢失。

l 基于策略的实时检测和预警

l 基于用户行为的异常检测

安全是互联网产品的生命基线，我们通过认证、授权、审计全方位的防护Hadoop的安全，保障了大数据集群的稳定运行。而成本则是最终校验运维效率的标准，如人力成本的节约、业务资源使用的把控都是运维价值的直接体现。

2.4.4资源可视化、成本化

在进行资源可视化、成本化之前，我们常常不知道一个业务资源使用是否合理、资源扩容是否有必要。通过对业务资源的可视化、成本化，可以统计业务资源消费、展示业务消费明晰、任务详细信息，可以提供业务弹性依据，为推动业务优化计算任务提供有利依据。

在这个平台上我们直观给出每个业务系的CPU、内存、存储的占用情况、使用的时长，以及转换的成本，同时也可以通过消费曲线观察异常消费，进行成本优化。

我们还从用户的维度给出消费明细，做到有理有据，便于后面的一些反查。

同时还可以了解到任务详细运行情况。比如任务的类型，什么时候启动，什么时候结束，使用时长等。

以上所述是大数据运维平台建设过程当中所用的一些方法论和技术。

三、总结与展望

3.1 总结

l 在质量和效率上，阐述了大数据运维平台化和自动化的必要性，实现了集群、主机、组件自动化部署与管理；

l 在安全上，解决了谁有权限、有什么权限、做了什么的问题，保证了平台的安全；

l 在成本上，做到了有图有真相，伸缩有依据，优化有目标。

3.2 展望

l 大数据运维的总体目标是用尽可能低的成本来提供足够好的服务质量和用户体验。网络带宽、服务器、维护人力是大数据成本主要的来源，我们希望通过大数据分析技术，对硬件故障的预测和自动化进行管理，对机器的管理实现零投入，最大化利用资源，减少预算开销。

l 提供高质量业务运维服务，我们希望用户可以通过平台申请自动创建交付集群，开展业务运营。

l 同时我们也希望运维团队可以充分利用大数据分析技术提升预测、发现和自动检测的能力，预测分配资源，动态伸缩集群，实现智能预警，自动修复，推动运维向智能化方向发展。

11月9-12日，北京国家会议中心，第六届TOP100全球软件案例研究峰会，魅族科技主题桌面负责人谭林英将分享《手机厂商如何做互联网产品》。

TOP100全球软件案例研究峰会已举办六届，甄选全球软件研发优秀案例，每年参会者达上万人次。包含产品、团队、架构、运维、大数据、人工智能等多个技术专场，现场学习谷歌、微软、腾讯、阿里、百度等一线互联网企业的最新研发实践。

更多TOP100案例信息及日程请前往[官网]查阅。4天时间集中分享2017年最值得学习的100个研发案例实践。本平台共送出10张开幕式单天免费体验票，数量有限，先到先得。