时下数据科学是一个热点话题，各个行业里面也有一些比较成熟的应用，在这个大的背景下，我们在大约一年前就开始有意识地把数据技术、数据分析、数据挖掘这些技术融合到运维领域的应用。在这个过程中，我们做的时间其实不很长，比较短，目前只是做了一些相对来说较为简单的一些事情，但取得的成果在公司内部感觉还是比较好的。今天我就跟大家分享一下我们在应用开发过程中的一些案例，也就是说，如何让数据技术在运维实践中得到充分的应用，希望对大家的工作有一些参考价值。

 

    分享目录：

 

    1.数据处理技术应用

 

    2.数据分析技术应用

 

    3.数据挖掘技术应用

 

    4.应用生态建设及规划

 

 

    在运维中我们会碰到各种各样的问题，但有些问题我们经常重复遇到，并且形成了一些提问范式，如：

 

    

 

 

    目前各类数学模型的输出在我们的具体工作中主要被用作辅助决策来使用，有两个原因使我们还不能直接把结果自动地用于决策：一是我们对数据的使用能力还不能做到面面俱到，很多业务知识还无法用算法描述；二是算法的输出结果一般都是有概率的，在很多需要“绝对正确”的场合只能作为参考。在实际工作中，算法和业务规则库都会进行建设，用来帮助运维人员更容易和正确地做出决定。

 

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

 

 

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

 

 

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

 

 

    

 

    首先我们看数据采集，对唯品会来说，我们主要是两类数据，一类是日志数据，一类是数据库数据。

 

    对于日志数据来说，我们有两类采集，一类是客户端的日志采集，一类是服务器端的日志采集。对于服务器端的日志采集，实际上是比较简单的，一般来说就是落到本地盘之后，通过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测试集上。

 

    这种实现我们大约有两种方法，一种是会在APP端设置开关，每个开关管理一个A/B测试的实验。更多的A/B测试，是统一请求后端的A/B测试分组服务，这个服务通过算法来保证各个试验之间相互独立。一般来说，当客户端发起A/B测试场景的时候，就会向A/B测试分组服务发个请求，然后A/B分组服务会返回这个用户是属于A组还是B组，一般是这样的。

 

 

 

    这部分会简单介绍具体的分析方法，并主要说下应用场景和案例。总的来说，我们的运维数据分析技术主要是用于解决两方面的问题，一方面是“绩效分析”，一方面是“根因分析”。

 

 

    以前我们做了挺多的项目，这些项目一般来说WBS分解之后，我们会对项目的结果做一个简单的跟踪，只是说做完了，还是没做完，一般也不会对它做一些定量的分析或者说对这个质量有一个看法。这种情况在我们的项目中非常常见，这种项目一般来说比较小，都是靠个人技术能力就能控制住。

 

 

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