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月份開始投入開源的擁抱。
在消費端做除了拖以外、還提供了推的模式。類似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在收集端、消費端、監控等仍有非常多的點需要提高。