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，还是蛮拼的
- Storm with C# - SCP.NET (http://www.nuget.org/packages/Microsoft.SCP.Net.SDK/)
- Spark with C# - Mobius (https://github.com/Microsoft/Mobius)
- Kafka with C# - C# Client for Kafka (https://github.com/Microsoft/Kafkanet)
- BOND (https://github.com/Microsoft/bond)
监控
在监控E2E消费时，用了一个挺重的方法来测量延时。既把数据到达时间，消费时间通过Spark Streaming做了Join，显示在ELK上。这个其实大可不必这样，只要能够知道ConsumerGroup 消费的CheckPoint是否是最新的，就能够知道了，何必大费周折。
结尾
微软用Kafka主要目的还是为了更容易使用流计算、ELK等开源软件，从安全性、使用上而言，Kafka在收集端、消费端、监控等仍有非常多的点需要提高。
很多用法、思路微软和我们其实挺像的，有兴趣可以了解下日志服务（LogHub）与Kafka对比，链接。
