未加星标

数据科学热到爆,如何让数据成为运维的大脑?

字体大小 | |
[大数据技术 所属分类 大数据技术 | 发布者 店小二03 | 时间 | 作者 红领巾 ] 0人收藏点击收藏

时下数据科学是一个热点话题,各个行业里面也有一些比较成熟的应用,在这个大的背景下,我们在大约一年前就开始有意识地把数据技术、数据分析、数据挖掘这些技术融合到运维领域的应用。

数据科学热到爆,如何让数据成为运维的大脑?
数据科学热到爆,如何让数据成为运维的大脑?

在这个过程中,我们做的时间其实不长,比较短,目前只是做了一些相对来说较为简单的一些事情,但取得的成果在公司内部感觉还是比较好的。

今天跟大家分享一下我们在应用开发过程中的一些案例,即如何让数据技术在运维实践中得到充分的应用,希望对大家的工作有一些参考价值。

分为四个部分进行分享:

数据处理技术应用
数据分析技术应用
数据挖掘技术应用
应用生态建设及规划

在运维中我们会碰到各种各样的问题,如下图:

数据科学热到爆,如何让数据成为运维的大脑?

但有些问题我们经常重复遇到,并且形成了一些提问范式,如:

“有问题或故障发生吗?”,这个提问转换成数学问题就是建立“异常检测”模型。
当我们确认有问题时,我们本能地会问“哪里出了问题”,这便是一个“根因分析”问题。
对于一家电商公司来说,促销前总是要对线上系统进行容量评估和扩容,这里便有一个“预测”模型需要被建立。
当我们每做完一个项目,需要对项目需要达成的目标进行定量的评估,这便是一个“绩效分析”的问题。

目前各类数学模型的输出在我们的具体工作中主要被用作辅助决策,有两个原因使我们还不能直接把结果自动地用于决策:

我们对数据的使用能力还不能做到面面俱到,很多业务知识还无法用算法描述。
算法的输出结果一般都是有概率的,在很多需要“绝对正确”的场合只能作为参考。

在实际工作中,算法和业务规则库都会进行建设,用来帮助运维人员更容易和正确地做出决定。

今天给大家重点介绍“数据处理技术”、“数据分析技术”、“数据挖掘技术”这三个方面在唯品会的应用实践,主要会讲到一些应用场景,最后谈下“数据技术”在运维的生态建设和一些规划。

数据处理技术应用

对于数据处理技术来说,我们主要解决以下五个方面的问题:

数据的准确性、及时性
海量数据的实时计算
多维数据的实时监控
多维数据的展示
A/B 测试实现方法

这里有些问题在行业里已有比较成熟的解决方案,有些可能不是每个公司都会碰到。

数据采集

数据科学热到爆,如何让数据成为运维的大脑?

首先我们看数据采集,对唯品会来说,我们主要是两类数据:

日志数据
数据库数据

对于日志数据来说,我们有两类采集:

客户端的日志采集
服务器端的日志采集

对于服务器端的日志采集,实际上是比较简单的,一般来说就是落到本地盘之后,通过 Flume 传送到公司的 Kafka 集群,然后大家在上面消费。

对于客户端行为的采集,分成两种:

Web 端的采集,一般来说就是通过异步请求在 Nginx 上落日志。
APP 端的采集,一般是通过一个接口调用的方式,把这些数据落到服务端,再由服务端把这个数据收集起来。

对于数据库的采集,实际上我们也是有两种方法:

直接在从库上来做这种指标的计算。
对于复杂的应用,我们会把 DB 的 Binlog 做一些解析,解析完了之后放到一个消息总线上,实际上就放到 Kafka 上,然后让大家来进行一个消费,每个应用都是根据自己的特点,重构自己的数据结构。

有些会还原数据库,有些就直接用消息来计算指标,具体要根据情况进行分析。

上图主要描述了唯品会用到的一些主要开源产品,基本上是这样。

数据计算

数据科学热到爆,如何让数据成为运维的大脑?

数据计算是比较重要的一环,实际上要兼顾性能和灵活性两个方面。

对日志的处理,会有一个日志解析程序来消费 Kafka 的消息,“日志解析”实现一个实时 ETL 的过程,我们会根据配置(基本配置也跟 ETL 差不多)去生成预定义的标准格式,后续就交给 Spark 做聚合。

“日志解析”由于日志之间没有相关性,可以 Map 之后并行计算,吞吐量和资源的投入是成正比的,这样效率就没有什么太多的问题。

对于 Spark 的聚合配置,一般来说我们会把日志解析完的数据进行定义,定义各个字段是维度或是指标,然后会做一个全维度的聚合。

这里面实际上也是有个要求的,我们要求所有的指标在各个维度上都具有累加性。

如果不具备累加性(比如百分比这种指标),我们在 Spark 里是不做聚合的,只是在展现的时候重新计算,计算好的数据会放到一个 OLAP 和 MOLAP 的数据库里。

还有一种情况,是通过脚本在数据库从库上直接进行指标的计算,一般用于只有时间维度的指标计算,配置好的计算脚本,我们会用公司开源的一个产品 Saturn 来进行一个分布式调度。

Saturn 这个东西还是不错的,推荐大家去尝试一下。对于日志的详细查询,我们还是放到 ES 里,通过全文检索的方式来查询。

数据展现

数据科学热到爆,如何让数据成为运维的大脑?

数据展现是最终的结果输出,实际工作中,我们对结果数据的查询效率要求比较严苛,因为这些结果数据不仅用于前端,还用于告警输出等各个方面。

对于告警的数据我们需要做到毫秒级响应,前端界面一般要求是在 3 秒内渲染完成。

为了完成这个要求,我们构建了一个 ROLAP 数据库,还有一个 MOLAP 的数据库,在 ROLAP 的数据库里,一般只存当天的多维数据,而在 MOLAP 的数据库里,会存历史数据。

对于 MOLAP 数据库的检索,由于应用主要是切片方面的需求,基本上都是 K-value 模式的一个检索,所以它比较快。

mysql 里一般是存放单维度指标,应该这么讲,它不是多维数据。Redis 缓冲里,一般会存放我们的秒级数据,还有一些配置信息。

这个架构中,最后通过 Application Server 进行一个数据的整合,来满足前端数据的一个展示要求。

多维分析界面案例

数据科学热到爆,如何让数据成为运维的大脑?

这是一个多维分析案例的界面,左边是我们的分析平台,右边是我们的实时监控平台。

从这上面大家能看到,我们实际提供的功能主要是对数据切片的能力,这个能力基本可以满足我们目前所有的需求。

A/B 测试实现

对于数据分析来说,基于 A/B 测试的对比分析是一种重要的方法,因为 A/B 测试对比的结果容易被业务理解,如果没有 A/B 测试,你说我做了一件事情,这件事情带来了一个好的效果,还是很难经得起挑战的。

在 A/B 测试中,它需要一些技术来支撑的,因为我们在线上同时会有很多 A/B 测试的案例同时在跑,你自己的 A/B 测试不应该被别人干扰。

在这种情况下实际上是要求各个 A/B 测试之间的用户分布得具有正交性,也就是说别人的 A/B 测试集用户应该平均分布在你的 A/B 测试集上。

这种实现我们大约有两种方法,一种是会在 APP 端设置开关,每个开关管理一个 A/B 测试的实验。

更多的 A/B 测试,是统一请求后端的 A/B 测试分组服务,这个服务通过算法来保证各个试验之间相互独立。

一般来说,当客户端发起 A/B 测试场景的时候,就会向 A/B 测试分组服务发个请求,然后 A/B 分组服务会返回这个用户是属于 A 组还是 B 组,一般是这样的。

数据科学热到爆,如何让数据成为运维的大脑?

数据分析技术应用

这部分会简单介绍具体的分析方法,并主要说下应用场景和案例。我们的运维数据分析技术主要是用于解决两方面的问题:

绩效分析
根因分析

绩效分析

以前我们做了挺多的项目,这些项目一般来说 WBS 分解之后,我们会对项目的结果做一个简单的跟踪,只是说做完了,还是没做完,一般也不会对它做一些定量的分析或者说对这个质量有一个看法。

这种情况在我们的项目中非常常见,这种项目一般来说比较小,都是靠个人技术能力就能控制住。

数据科学热到爆,如何让数据成为运维的大脑?

但在大型项目中这种做法就很困难,它会面临更多的一个挑战,尤其是跨部门合作等情况,因为大家的沟通手法不仅仅是技术的,可能还有一些管理上的,这时就需要大家用数据在各个部门之间作为一个沟通的桥梁。

绩效分析-全站 HTTPS 项目案例

于是数据分析人员开始介入来进行分析体系的设计,主要包括:分析指标的设计和分析维度的设计,同时和研发确认数据采集方案、A/B测试方案、统计口径等。

指标主要是根据项目中各项工作都关注什么问题来设计,而维度的设计是从当指标不满意时,可以在哪些方面着手改进来进行。

在这个项目中可预见的是,由于证书握手的原因,TCP 连接时间会变长,可能会影响用户体验,同时也会减少劫持从总体上提高用户体验,所以项目的目标设置为转化率至少不下降,最好能有上升。

我们实际上是做了一个 HTTPS 的全站项目,在项目开始之初,我们就有意识地把数据分析团队和技术人员整合到一起跟进项目,取得了不错的结果。

数据分析人员在项目的初期就已经开始介入,来进行分析体系的设计,主要包括:分析指标的设计和分析维度的设计,同时和研发确认数据采集方案,A/B 测试方案,统计口径等。

分析人员会把这些工作做好,可他们怎么来设计这个项目的一些指标呢?一般来说,在 WBS 分解之后,我们关注什么问题,就会把这个问题变换成一个主要的监控指标。那如何去设定这些维度呢?

数据科学热到爆,如何让数据成为运维的大脑?

实际上这些维度都是我们能解决问题的一些角度,也就是说实际上所有的维度都是我们能控制、能改善的地方。

首先 HTTPS 项目,不知道大家有没有了解,如果了解可能知道 HTTPS 项目,因为 TCP 握手时间会延长,这一点上可能会损失一部分的用户体验,但在防劫持等方面,又会加强整体的用户体验。

在这种情况下,我们项目设立了一个最终的主要目标,也就是保证转化率,这个转化率不能下降,最好还有一点点提升。

在这个主要目标上,我们就控制这个主要目标,不停地灰度放量,不停地调整,这个效果是比较好的。

因为在这个过程中我们发现了很多的问题,同时这个项目持续了大约 8 个月,在 8 个月中我们没有发生过任何重大的故障。

数据科学热到爆,如何让数据成为运维的大脑?

这个案例是对错误率的分析和监控,有一次发现我们的错误码是 HTTPS 的证书认证过不去。

这种情况在某个省某个运营商大规模地发生,我们从分析的角度看这些节点 IP 是不是我们自己的 IP,这样我们就知道在这个地方发生了大规模的 DNS 劫持问题,于是就去协调当地的运营商把这个事情搞定。

数据分析也会发现一些代码中的问题,我们做 HTTPS 项目,可能要对代码进行一些修改,比如说在整个 HTML 里是不能存在 HTTP 协议的硬编码。

但由于历史原因,这种地方还是比较多的,开发人员很难排查完,实际上需要分析人员通过数据分析手段去查,把这些没有改过的代码找出来。

还有一些图片的问题,我们发现一些图片的拼接错误,当然是报了 404。

报了 404 之后,我们对这个错误码分析,发现突然多了,把报错的 URL 做一个排序后发现一些是拼接的错误,还有一些是由于特殊字符引起而导致了无法生成正确的请求。

我们对 TCP 的握手时长也会进行跟踪,在做灰度选型阶段,我们在不同的入口采用了不同的技术类型,通过分析各个入口的握手时长来辅助运维人员进行一个加速卡的选型,还有一些参数调整等工作。

绩效分析-其他案例场景

这个项目进行完成之后,我们总结了很多经验,慢慢地在其他的项目中也逐渐有意识地运用数据分析技术,把数据分析人员和技术人员有效地结合在一起。

这里面也有几个案例:

分页:12
转载请注明
本文标题:数据科学热到爆,如何让数据成为运维的大脑?
本站链接:http://www.codesec.net/view/570507.html
分享请点击:


1.凡CodeSecTeam转载的文章,均出自其它媒体或其他官网介绍,目的在于传递更多的信息,并不代表本站赞同其观点和其真实性负责;
2.转载的文章仅代表原创作者观点,与本站无关。其原创性以及文中陈述文字和内容未经本站证实,本站对该文以及其中全部或者部分内容、文字的真实性、完整性、及时性,不作出任何保证或承若;
3.如本站转载稿涉及版权等问题,请作者及时联系本站,我们会及时处理。
登录后可拥有收藏文章、关注作者等权限...
技术大类 技术大类 | 大数据技术 | 评论(0) | 阅读(38)