最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

腾讯网络干货分享:大数据在服务器运营中的应用

[复制链接]
发表于 2014-10-31 13:15:53 | 显示全部楼层 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
编者按:大数据在业界的应用当属BAT领先,来看看腾讯网络干货分享:大数据在服务器运营中的应用。 201410301818001ea08.jpg 前言
腾讯公司从2012年开始,通过对服务器运营流程、工具系统的建设,服务器从一线到三线的运营基本转入线上自动化。在服务器静态配置、动态的运行状态和生命周期各个节点的运营这几个方面,产生了大量的运营数据,这些信息像滚雪球一样,以几何量级快速增长。数据越来越多,该如何着手处理呢?这就像刚入门的厨子一样,在农贸市场里面对堆积如小山般的食材,无从下手。到2013年,建立网平的大数据平台,把所有的基础架构运营数据统一接入和管理,从此,我们开始了在数据矿山中挖掘金矿的历程。
大数据的处理
经过长时间的实践和总结,我们发现服务器运营的大数据有以下四个特点,由浅入深,分别是:1)Volume数据体量巨大,特别是腾讯有海量的服务器,综合起来,数据量可以到PB级别,需要大容量、高性能的存储技术,分析的算法也需要最优化;2)Variety数据类型众多,涉及大量的运行日志、部件状态、生产链运营、环境变量等,经常要抽丝剥茧,才能找到有用的数据;3)Value 价值巨大,但并不是每个数据都有价值,需要经过清洗和加工处理后,其产生的效果才能显现,以机房环境温度告警为例,数百万条温度的信息,经过分析对比后,才有可能发现温度异常;4)Velocity数据需要快速处理,特别是告警类的应用,时效性是非常重要的。
下面讲讲我们是怎么收集和存储服务器运营数据的,给我三分钟,给你一个帅气又有营养的答案!
1、运营系统架构
对于海量服务器的管理,我们建立了一套功能强大的运营分析系统,从服务器的带内和带外收集了全面的静态属性和动态运行数据,对服务器的每个关节进行的全方位的数据采集和监控。犹如我们平时体检,把心、肝、脾、肺、肾,甚至每个毛孔,都进行了检查。系统架构如下图所示。

2、存储和分析
数据收集起来后,除了一部分实时的数据存在本地数据库,几乎全部的历史数据都会存储在公司级的数据平台中。这个数据平台提供了丰富的工具系统,功能全面,涵盖了数据存储、分析、实时计算等。例如,TPG是基于postgreSQL的数据库,用于存放TDW(Tencent distributed Data Warehouse腾讯分布式数据仓库)离线分析后的结果数据,便于系统调用(如服务器利用率分析,故障分析、服务器生命周期等生产数据);Hbase基于No SQL,万亿级的分布式、有序数据存储,用于存放分析后的结果数据(如温度功耗分析结果数据)。整体的架构如下图所示。
大数据的四个实践
大数据的规划分析,决策者和开发者首先要从业务驱动的角度,选择数据生产的业务场景,即要预计数据分析得到的结果能带来哪些效益。根据公司服务器运营的特点,我们在以下四个场景做了大数据的分析和应用,给实际的运营带来的实实在在的好处。
1、硬盘故障预测
硬盘是服务器硬件故障率最高的一个部件,如果能提前预测到硬盘故障,对业务体验、完善备件管理都有莫大的收益。这也是基础架构运营在经历自动化、流程化后,需要进一步提升运营效率、降低运营成本的天然要求。
涉及硬盘的运营数据包括业务IO数据、硬盘内部的SMART和硬盘运行的环境变量数据(温度和湿度)。目前,运营系统对IO数据是每小时采集一次,SMART数据每三小时采集一次,温度和湿度每半小时采集一次,这些数据合计起来每天的记录数上亿条。硬盘故障预测,适合使用分类算法,我们使用了目前较为流行的SVM分类算法,辅以合适的核函数来加快学习计算的效率。
经过了一年多时间的实践,走了不少弯路,也碰到了很多坑,在硬盘故障标准确定、业务IO分类定义等方面吃了不少的亏,我们在基于SMART数据做的故障预测,达到了令人满意的效果。在实际运营环境中验证的结果如下:准确率precision达到98%,预测时间leadtime的整体偏差不超过2天。
需要重点指出的是,我们做的预测结果,除了training阶段用历史数据外,验证的过程是用现网的实时数据来进行的。就是说,经过SVM算法得到的预测模型后,我们是用最新采集的实时数据输入到模型中,得到的ok和fail两种预测结果,在3天、7天、14天后再对预测的结果进行验证。这个比传统的预测方式(训练和验证都是使用历史数据),对现网应用的价值大大提高了。目前在现网环境中,主要的落地场景包括:1)预测出来的结果,经过运营流程,对BG业务提前发出预警,以提高业务运维效率 2)根据预测出来的大规模硬盘故障,对备件进行有效管理。
2、服务器利用率分析
腾讯的业务类型和机型都相当多,机器分配给业务后,使用的情况如何?我们需要跟踪服务器的利用率情况,下图是某业务某机型磁盘IO的利用率统计分析图。分析过程如下:存储类机型,看到一段时间统计出来的IO的利用率并不高,并且是写少读多的应用,是否可以考虑使用IOPS相对不高的廉价硬盘?还是业务的架构存在优化的空间?
服务器利用率分析给运营带来的好处在于:
1)结合业务模型,发现业务应用服务器的短板,在发现并修复系统架构缺陷的同时,提高整体利用率;
2)对机型选型的优化,例如对于磁盘容量使用率不高的机型,在后续的机型定制中减少硬盘的数量。
3、故障率分析
服务器故障分析对服务器的各个部件的故障率都做了分析和监控,包括
1)生成月度故障率报表;
2)故障率异常的实时监控和自动告警;
3)分析外部条件与故障率的关系;
4)与OS的软件告警信息联动起来,及时发现服务器的亚健康状态。
上图是某服务器硬件最近几周的故障率统计信息。按部件给出各个机型的故障率情况,及时发现批次性故障并给出告警
4、环境监控
2013年8月,华东地区遭遇罕见的高温天气,很多机房空调制冷扛不住了,频繁发生服务器高温重启的事件。如果能把机房环境温度有效的监控起来,我们就能在发现异常时发出高温告警,提前采取措施。对服务器入风口温度进行采集和监控是一个较为有效的方案。
上图显示服务器入风口温度变化的异常情况,经过数据的规整和误差修正,产生了高温告警。通过自动化流程,及时知会到机房现场负责人。
一些思考
1、不要被数据误导
人们很容易被大数据忽悠。在很多场合我们都谈了大数据强大的功能和美好的未来,认为可以解决许多社会问题,甚至预测未来。无论大数据如何神奇,若试图用大数据引领未来只会误入歧途,因为大数据背后本就存在着“先天不足”:从本质上看,大数据最大的缺陷就在于试图以确定去“颠覆”混沌与不确定性。之前我们做硬盘故障预测,直观的认为硬盘的读写压力对硬盘老化和故障是有直接关系的,但经过分析,发现业务使用硬盘的随机性太大了,硬盘响应IO的模式也很多变,对于业务的IO读写比例、块大小等,有太多的不确定性,就是前面说的混沌,导致前面基于IO做的预测结果非常糟糕。其实这里要说的就是,目前这个阶段,依靠大数据来指导服务器运营,不靠谱,服务器运营智能化远远没有达到。这里还是要靠运营和开发人员的思维和头脑,把自动化运营先做好。
2、数据质量的把控
数据的质量和字段规范性对后面分析效果的影响很大。但业务开发所设计的数据不是为了运营分析而服务的,很多情况下都是为了功能开发而存在,如果可以在系统构建初期进行介入,其实可用避免很多清洗工作,数据可直接投入分析使用。这里开发人员和数据分析的人员存在一个gap,如果对数据在系统设计中遇上各种约束的话,开发人员会觉得很痛苦,开发效率非常低;而数据分析人员却觉得如果数据能做到工具级定制,就是连数据的表字段的名称,注释,连内部关系,都是由系统统一生成,这样采集完美的。
后来,我们内部经过一段时间的讨论和磨合,形成的共识。我们做的是运营系统,归根到底是为运营服务的,而数据分析是运营的一个重要功能。所以没有办法,这个问题还是需要开发阶段来解决,开发人员只能克服了。
对大数据未来的设想
1、精细化的传感器
对于服务器上传感器的设计,互联网企业有特殊的需求,对上游硬件厂商的依赖是比较高的。腾讯有大量的服务器运营数据,非常希望可以跟业界一起在数据、资源、算法等各个维度可以共享,寻求更多提高运营效率的途径。这里的传感器也可以从广义上来展开,除了服务器物理上的sensor越来越多,在服务器各个运营环节都可以在流程中加入各种采集代码,把服务器部署、搬迁、退役等每个细小的步骤都如实的记录下来。运营系统的不断优化将使“传感器”体积微型化,它将出现在生产的每一个角落,为运营决策提供更科学的数据支撑。
2、数据服务即开即用
随着数据的逐步完善和开放,互联网和企业都将建立起完善的大数据服务基础架构及商业化模式,从数据的存储、挖掘、管理、计算等方面提供一站式服务,将各行各业的数据孤岛打通互联。而且数据应用的生态系统也将变得非常成熟,甚至出现用户与数据服务商之间的算法提供商,他们有专业领域内的精英人才,通过数据挖掘的方式,寻找事物间的联系。用户只需将其原始数据导入,提供商很快的就能在线的将分析结果返回,如水和电一样,即开即用。
Big data,Big future!
来自腾讯网络内部微信公众号“鹅厂往事”的分享。微信号:tencent_network


楼主热帖
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-3-29 02:42

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表