基于Kafka与Spark的实时大数据质量监控平台

微软的ASG (应用与服务集团)包含Bing,、Office,、Skype。每天产生多达5 PB以上数据，如何构建一个高扩展性的data audit服务来保证这样量级的数据完整性和实时性非常具有挑战性。本文将介绍微软ASG大数据团队如何利用Kafka、Spark以及Elasticsearch来解决这个问题。

 

案例简介

本案例介绍了微软大数据平台团队设计和部署的基于开源技术(Kafka、Spark、ElasticsSearch、Kibana)的大数据质量监控平台，这个平台具有实时、高可用、可扩展、高度可信的特性，成为微软Bing、Office365、Skype等年收入270+亿美元的业务在监控数据质量方面的可靠技术保障。

同时，基于业务需要，我们在设计和实现中达成下面一系列的目标：

监控流式数据的完整性与时延;
需要监控的数据管道(pipeline)具有多个数据生产者、多处理阶段、多数据消费者的特性;
数据质量的监控需要近实时(near real time);
数据质量发生问题的时候，需要提供相应的诊断信息来帮助工程师迅速解决问题;
监控平台的服务本身需要超级稳定和高可用, 大于99.9%在线时间;
监控与审计本身是高度可信;
平台架构可以水平扩展 (Scale out)。

背景及问题引入

为了服务微软的Bing、Office 365以及Skype业务，我们的大数据平台需要处理每天高达十几PB级别的海量大数据，所有的数据分析、报表、洞见以及A/B测试都依赖于高质量的数据，如果数据质量不高的话，依赖数据做决策的业务都会受到严重影响。

与此同时，微软业务对于实时数据处理的需求也日益增加，以前监控批处理数据(batch data)的很多解决方案已经不再适用于实时的流式数据的质量监控。

在另外一个层面，基于历史原因，各个业务集团往往使用不同的技术、工具来做数据处理，怎么整合这样异构的技术、工具以及在此之上的数据质量监控也是一个急需解决的问题。

图1是我们数据处理平台的一个概念性架构。从数据生产者这端，我们通过在客户端以及服务端使用通用的SDK，按照通用的schema来产生数据，数据通过分布在全世界的数据收集服务(collectors)来分发到相应的Kafka, 然后通过pub/sub模式由各种各样的计算以及存储框架来订阅。

这样各种团队就可以选择他们最熟悉或者一直以来使用的工具来做处理。例如，从实时处理的角度，各个业务团队可以选用比如Spark或者微软的USQL streaming处理框架，以及其他第三方的工具来做一些特定场景的分析，比如日志分析的Splunk、交互式分析的Interana等。在批处理框架上，用户可以选用开源社区的Hadoop,、Spark或者微软的Cosmos等。

 

 

图1： 整合各个业务集团的异构数据系统的架构

 

 

图2：快速增长的实时数据

如图2所示，我们在迁移大数据到图1架构的过程中，也看到实时流式数据的快速增长。每天峰值消息高达一万亿个以上，每秒处理一百三十万个消息， 每天处理3.5PB流式数据。

数据监控的场景以及工作原理