• 52 阅读
  • 1 回复

Kafka在微软的使用

视频在线上传+队列转换FLV+水印+捉图+修复+获时+转3GP(API语言不限,开视频站必备!)

Kafka Summit 2016中有一个微软MS/Bing团队的分享。看了数据给大家分析下。微软有一套服务化的数据管道EventHub,作为云产品售卖。但在Bing、Ads、Office等场景上仍在使用Kafka,在整个公司规模上大概是一半 vs 一半。主要使用Kafka考虑是Kafka与开源流处理系统结合得更好(spark、storm等)。
一些数据
先来看一些基础的数据:

  • 一天500TB,如果协议中带了压缩,一天原始数据量为2.5 PB左右(5倍压缩率),并不是非常大
  • 大约1300台机器,每台机器处理384GB 数据。平均每台机器4MB/S写入流量,峰值约为6-7MB/S。说明效率并不是很高。3份拷贝计算,写入流量平均每台机器峰值20MB左右。
  • Incoming vs outcoming大约是1:3左右,说明数据有3-4个消费者
  • 1.3 Million/S 输入,一天500TB,一个包大小为4.4KB

从一年的变化量上来看,增长还是挺快的,说明微软从15年1月份开始投入开源的拥抱。

架构
微软在Kafka上包了Collector收集器,和消费API,类似LogHub Client Lib (Consumer Group)

在消费端做除了拖以外、还提供了推的模式。类似AWS Kinesis Firehose,LogHub 的Shipper。目标是Kafka 另外Topic,COSMOS(数仓)以及Hadooop。

数据
做了一层Restful API

为了能够使得数据有语义,没有采用Confluent的Schema Center,而是采用了在数据上加了一个Header,通过自描述语义构建了包的类型和版本等。

为了能够支持微软的编程习惯,做了一套Kafka C# SDK,还是蛮拼的
监控
在监控E2E消费时,用了一个挺重的方法来测量延时。既把数据到达时间,消费时间通过Spark Streaming做了Join,显示在ELK上。这个其实大可不必这样,只要能够知道ConsumerGroup 消费的CheckPoint是否是最新的,就能够知道了,何必大费周折。

结尾
微软用Kafka主要目的还是为了更容易使用流计算、ELK等开源软件,从安全性、使用上而言,Kafka在收集端、消费端、监控等仍有非常多的点需要提高。
很多用法、思路微软和我们其实挺像的,有兴趣可以了解下日志服务(LogHub)与Kafka对比,链接




https://m.aliyun.com/yunqi/articles/58974
小鱼的淘宝店铺-多多支持哇