微信扫描登录

58赶集通用的实时统计分析平台设计与实践

本篇文章整理自赵健博4月23日在『1024大数据技术峰会』上的分享实录:58赶集通用的实时统计分析平台设计与实践。

enter image description here

今天介绍一下在58赶集做的一个通用的实时统计分析平台,内部代号“飞流”。

按照国际惯例还是要自我介绍一下,我叫赵健博,现在是在58赶集数据平台部,担任架构师的职位,之前在百度和360也待了很长时间,一直做数据平台相关工作。

目前,主要是负责整个58赶集的大数据平台的发展、应用还有研发。主要研究领域主要分布式存储和计算系统。

enter image description here

本次要介绍的内容有几个方面。

首先介绍下实时统计分析的需求,接下来会重点介绍一下飞流在我们这边的设计以及实现,以及飞流在内部的应用,最后会介绍下我们未来的工作。

enter image description here

其实这个需求比较明确,比如说,老板比较关心公司的三端的PV/UV的情况,需要编写代码然后实时展示,但是这还不够。老板有些时候可能还需要看看细分到北京、上海地区的情况怎么样?

这时就需要再写个程序统计相应的指标。甚至,这些PV/UV的统计可能还要细分到具体的产品线,比如房产、招聘业务等。这样还要再次编写程序,上线,展示。比较麻烦。

还有比如看看主站服务质量怎么样?还能不能下钻到具体城市,具体的类别,这些就是我们得到的一些业务反馈的需求。当然还有很多类似的需求。

可以把这些需求可以抽象一下。是什么呢?其实就是一个实时多维分析的需求。抽象之后就是这么一个点。

本次我也会讲一下在58这边是怎么解决这个问题。

enter image description here

先概括一下飞流有四个特点。

第一,释放用户,减少用户开发成本,所以说这个系统是不需要用户编程,只需要登录个网页,点点配置一下,然后等下,数据就出来了。这是很重要的一个点,也是我们想做这个系统的动机。

第二,提供了丰富的分析和统计功能,求和、取平均、最大最小,计数唯一计数,PV/UV的统计非常简单。

第三,提供了强大多维分析能力,针对上面需求可以下到具体的城市或者具体业务来看它的统计指标。

第四,飞流这个平台是基于Kafka、Storm、Hbase。具备很好的可靠性、可扩展性、以及性能

第五,数据接入极其简单,对于日志类数据仅需配置即可接入。

enter image description here

这个图是飞流的架构图,比较清晰。

蓝色曲线是数据流,数据先进入Kafka集群,用Kafka暂时缓存实时数据。我们在Storm集群上实现了飞流的核心,实际上就是一个Storm job,从Kafka集群实时取出来数据,针对这个数据以及用户针对任务配置策略进行多维计算,最终把结果存储到Hbase。

飞流数据处理的就是时序数据,之前报告中好多老师也讲到时序数据储存,我认为Hbase还是很适合的。所以说用Hbase来存储这实时数据是非常合适的。这是一套数据的处理流程。

针对时序数据展示,前端会有一个界面,界面在后面PPT介绍长什么样,会把用户关注数据通过曲线方式展现出来,目前还比较单一,仅有折线图,但是这是目前的情况,后续展现的形态多样化,数据都保存起来,具体怎么展示,就很容易了。

还有一条红色的路径是用户配置路径,那个界面用户可以登录进去,在页面上填写一些信息,添加一些维度和度量,保存后这些任务定义信息会存储在MySQL中,然后飞流核心会从MySQL动态的去取出来任务定义,然后根据任务的定义进行多维的计算。

所以说给用户来看,只要在前端界面配置一下任务,曲线在后端就出来了,这是非常简单。

enter image description here

这个图更加细节的角度展示了飞流核心的组成。

enter image description here

首先最左边是Kafka集群,有很多Kafka的partition,之后有很多Kafka Spout,对应kafka的一个或者多个partition取数据,然后发到下游的extractBolt,这个bolt有多个并发,主要做的工作是根据用户定义的任务的配置来去做多维数据的提取。

具体的时候,多维数据提取就是根据用户所选择的维度做维度之间任意组合,组合完毕之后,夹带上度量的信息,一同当把这些信息发到下游的LogicBolt上,logicBolt进行多维计算,计算完毕后将结果发给saveBolt做存储,整个过程中,从kakfaSpout到ExtractBolt之间是RandomShuffle,从ExtractBolt到LogicBolt以及LogicBolt到SaveBolt之间做的是fieldShuffle,这样能够确保一组维度组合能够最终汇总给一个logicBolt处理,做多维汇聚的计算。

用户增加一个统计任务或者减少一个统计任务,都是动态完成,所有发现都是extractBolt以及logicBolt从MySQL周期轮询,根据最新的全量任务定义信息,进行增删任务的操作。

这里面详细再说一下,刚才也提到了, 首先ExtractBolt周期加载用户配置的任务信息,可支持任务的动态变更。根据任务信息对数据源进行维度和度量的匹配与提取。以及行的过滤,使用的是“黑白名单”机制。

LogicBolt,周期从mysql中轮询用户配置信息,根据这些信息清理或增加相应统计计算的模式。然后它主要做的就是接收来自于上游Bolt(ExtractBolt)传递过来的维度组合进行多维计算。

enter image description here

SaveBolt接到到logicBolt传递过来的聚合结果,组成成时序数据,进行数据的持续化到Hbase中。

任务定义预配置模块。用于管理用户定义的任务。

enter image description here

实施多维模型,维护+度量+时间。

单维护统计:单维度,单个数据列 + 统计计算。

多维护组合,多个数据列,计算所有维度组合,计算度量统计结果,就是一个多维计算,关于度量支持很多种统计方式。

enter image description here

所有维度任意组合,加上度量统计结果以及一个时间窗口信息形成了时序的数据,存储在Hbase中。具体的rowkey组成为:“任务ID+维度1名+维度1值名+维度2名+维度2值名+….+度量“。

在前段展示页面查询时,指定任务ID,多个维度名以及维度值名的组合,最后指定一个开始时间以及结束时间,组合成一个Hbasescan请求,然后从hbase把这段时间的数据获取出来。这个获取速度是相当快的。

enter image description here

这里面还要说一下维度值的提取,目前处理都是日志,但日志格式千差万别,首先针对日志里面提取某些列,这个列的提取可以根据分隔符,还可以使用正则的方式进行提取。提取出一个列之后,还可以进一步进行匹配,匹配的方式包括:定值/正则/范围/集合等。最终确定该行归属于具体的哪一个维度值名。

关于度量值的提取,就相对比较简单了,首先是列值提取,可以使用分隔符还可以使用正则。目的就是取出来需要进行计算的数值。

enter image description here

之后还有一个时间的概念。关于时间或时间窗口。这里面涉及到一个统计时间的选取,如果你按照日志的到达时间做统计很可能你的统计不是准确的,所以建议基于日志里面的时间字段去做统计。比如,PV流量统计,如果数据延迟达到了,则统计的PV不是一个准确的数值。建议日志中的时间作为时间考量。

在具体计算度量时,实际上我们保持了一个时间窗口(包含了多个统计间隔)内统计数据,如果数据延迟到达,只要是在这个窗口内能够达到,则可以保证统计数据的准确性。

时间窗口可以理解为:如果当前时间为T,则会保留从[T-W,T]内的统计聚合数据(W为时间窗口)。这样每次都会把超出时间窗口的统计结果保留在Hbase。

enter image description here

我这里面举了一个例子,之前讲得过于抽象,举一个例子方便大家理解。

假设这是一个日志,有六个列,第一是cookie,第二是时间,第三是请求类型(GET/PUT/POST),第四是站点(例如北京的58主站,还是上海的58主站),第五列是请求处理时间,最后一列是请求的返回码(200/404)。当然这个数据不是真实的,做了下处理。

针对这个数据,假如用户想要查看一下服务的请求时延,这个是度量。同时还需要细化到不同地区,不同请求返回值的情况,所以站点以及返回码这两列是维度列。统计的时间间隔为5秒钟。如图所示,初始有4行的数据,分别为北京地区已经上海地区的请求情况。

经过第一轮处理会变成什么样?假如这个任务的ID是199,针对初始的4行数据进行维度和度量的提取,提取结果为:

第一个维度名为地区,根据第一行的记录,地区维度下的维度值名为北京,第二个维度名为返回码,返回码维度下的维度值名为200。提取出请求响应时间作为度量,并获取到统计方式,为平均值。组成了如下形式:Key:199地区北京返回码_200平均值,Value:0.01。剩余三行的处理方式相同。

针对上面四条记录,直接转化过来就是这么一个样子,其中包含两条上海数据,两条北京数据,只不过有一些差别,针对返回码是有差别,这是第一步维度的提取和组合,同时会把value,服务的时延也提取出来。

再往下,logciBolt做的延时的平均值聚合计算,针对上海地区返回码为200的这个组合,有两条记录满足,进行聚合后算出来为平均值0.008,这就是一个多维计算。剩下两条记录,没有额外的记录进行合并,就直接保留下来,这就是多维计算过程。

把上面这个值加时间戳信息以及时间窗口信息发送给saveBolt,最后持久化到HBase中。前端模块实时刷新时,能够知道需要获取从那个时间点到那个时间点的数据,直接从HBase中获取出最新的数据进行展示。

enter image description here

这是前端界面,第一部分配置一些基本信息包括任务名字,例如Kafka topic,处理时间间隔,多长时间统计一个点,然后还有这个数据能允许谁看,敏感信息不允许所有人看到,追加一个任务描述,这是第一个部分。

第二个部分,相当于黑白名单配置,用户很容易过滤一些数据或者保留一些数据,如果用户选择黑名单,并设置了切分规则,并针对选取的列进行匹配,最终可以过滤掉无用的行。

enter image description here

第三部分是维度配置,这里面可以看用户添加一个维度,添加多个,最后一部分就是度量的添加,也是有四个部分,分别是分隔符,列选择,正则方式,最后有一个度量方法,用户可以选择很多。

具体添加一个维度,首先要配置一个维度名,针对上面例子维度名要么是返回码要么是城市,这是用户需要关注的维度信息。

enter image description here

用户可以指定一个维度名,然后指明该如果进行维度列的解析,例如选择的分隔符,选择第几列,或者填写一个正则表达式进行匹配,正则匹配后选择第几个匹配组。在进行维度列提取规则设置完毕后,还可以进一步设置列值的匹配规则,首先设置一个维度值名,然后进一步可以设置“等值、范围、正则、集合”的匹配形态。

比如之前提到地区维度,在这个维度下,包括了维度值为北京的设置,这个维度值为北京的匹配规则是该列值等于“bj.58.com”这样。

enter image description here

这个图是我自己配置的演示,请求访问时延,选择Kafka的话题,这里面30秒统计一个表,是白名单过滤的,匹配你第六列为如下正则表达式,这是我设置的一个白名单。

在维度里面添加三个维度,跟上面例子稍稍有些区别,第一个地区,在这个地区里面,我配置了多个维度下的维度值的配置,你可以看到由北京、上海、广州、深圳还有其它,其他表示除了这上面四个之外剩下所有的。

方法就是get、gost还是put。返回码是200还是404。

度量,用杠分割,第八列,后面选择不配置,指标选择了看平均值,这是我整体配置过程。这个过程,也就5到10分钟就可以完成了。

enter image description here

配置完之后用户看到这张图表,首先也是选择一个Kafka话题,选择数据源,选择之前我的定义的任务名,这里看的是整体的请求延时。维度中有一个变量是“全部”,这是个默认匹配,表示去掉这个维度的统计结果。如果所有维度都选择“全部”,则统计的是整体的情况。

点查询,这里面就是一个整体的服务访问情况,可以看到平时还比较稳定,这块有个小波峰,我想弄明白这是怎么导致的呢?这个涉及到分析的概念了。

enter image description here

首先可以选择返回值为200看一下它的时延还存在波峰,然后想看具体哪个城市造成这个问题?选择了北京,这波峰依然存在,很可能这个波峰是北京这个城市的请求贡献了一部分。

enter image description here

可以再看一下上海,如图,从上海这个组合可能,相对平稳一些,所以说它对这个时延贡献不太多。

这有利于帮助运维团队或者服务质量的监控团队做的一些细致的工作,很容易知道这个问题可能是哪个部分导致,进行进一步的分析,这个平台可以干这种事情。

enter image description here

应用来说目前只有两个,一个是监控,很明显,这个系统面向大量的监控,主站三端,全在上面,包括服务三端质量,请求时延是怎么样的,通过飞流承载。另外对服务调用量的监控等等。

大部分的数据已经实时化了,所以业务的统计需求的数据很可能已经在Kafka系统里,简单在飞流上配置一下,他们的需求就可以满足了。最重要它还具备多维分析能力,它是一个多维分析的平台,刚才举的例子,地区、业务线或者来源,当然业务线我那块还没有配置,可以任选维度看一下这个指标情况,所以说可以做精细化的运维,发现一些潜在问题。

整体来说,这是我们飞流设计,非常简单,也比较有效果。

enter image description here

未来会支持以下的效果,刚才看界面还是比较单一,前期没有在界面上做改进,后续会支持Dashboard,展示多样化。饼图、热力图、柱状图,多种周期形式的曲线。

扩展度量类型。另外让目前飞流的用户配置任务还是稍微复杂一点,有些用户希望写一些SQL,我们把SQL用到我们平台上。

最后,我们是站在业务角度来看平台发展,飞流就是一个很典型的平台,还包括我们内部系统云窗平台,也在做这个工作。此外,我们这边还有更多平台,Spark、Yarn、Kylin、Kafka、flume等等。