摘要：中有一個微軟團(tuán)隊(duì)的分享。微軟有一套服務(wù)化的數(shù)據(jù)管道，作為云產(chǎn)品售賣。結(jié)尾微軟用主要目的還是為了更容易使用流計算等開源軟件，從安全性使用上而言，在收集端消費(fèi)端監(jiān)控等仍有非常多的點(diǎn)需要提高。

Kafka Summit 2016中有一個微軟MS/Bing團(tuán)隊(duì)的分享?？戳藬?shù)據(jù)給大家分析下。微軟有一套服務(wù)化的數(shù)據(jù)管道EventHub，作為云產(chǎn)品售賣。但在Bing、Ads、Office等場景上仍在使用Kafka，在整個公司規(guī)模上大概是一半 vs 一半。主要使用Kafka考慮是Kafka與開源流處理系統(tǒng)結(jié)合得更好（spark、Storm等）。

一些數(shù)據(jù)

先來看一些基礎(chǔ)的數(shù)據(jù)：

一天500GB，如果協(xié)議中帶了壓縮，一天的數(shù)據(jù)量為2.5 PB左右，并不是非常大。

大約1300臺機(jī)器，每臺機(jī)器處理384GB 數(shù)據(jù)。平均每臺機(jī)器4MB/S寫入流量，峰值約為6-7MB/S。說明效率并不是很高。3份拷貝計算，寫入流量平均每臺機(jī)器峰值20MB左右。

Incoming vs outcoming大約是1：3左右，說明數(shù)據(jù)有3-4個消費(fèi)者。

1.3 Million/S 輸入，一天500TB，一個包大小為4.4KB。

從一年的變化量上來看，增長還是挺快的，說明微軟從15年1月份開始投入開源的擁抱。

架構(gòu)?

微軟在Kafka上包了Collector收集器，和消費(fèi)API，類似LogHub Client Lib (Consumer Group)。

在消費(fèi)端做除了拖以外、還提供了推的模式。類似AWS Kinesis Firehose，LogHub 的Shipper。目標(biāo)是Kafka 另外Topic，COSMOS（數(shù)倉）以及Hadooop。

數(shù)據(jù)?

做了一層Restful API

為了能夠使得數(shù)據(jù)有語義，沒有采用Confluent的Schema Center，而是采用了在數(shù)據(jù)上加了一個Header，通過自描述語義構(gòu)建了包的類型和版本等。

為了能夠支持微軟的編程習(xí)慣，做了一套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)

監(jiān)控?

在監(jiān)控E2E消費(fèi)時，用了一個挺重的方法來測量延時。既把數(shù)據(jù)到達(dá)時間，消費(fèi)時間通過Spark Streaming做了Join，顯示在ELK上。這個其實(shí)大可不必這樣，只要能夠知道ConsumerGroup 消費(fèi)的CheckPoint是否是的，就能夠知道了，何必大費(fèi)周折。

結(jié)尾?

微軟用Kafka主要目的還是為了更容易使用流計算、ELK等開源軟件，從安全性、使用上而言，Kafka在收集端、消費(fèi)端、監(jiān)控等仍有非常多的點(diǎn)需要提高。

軟件開發(fā)技術(shù)群

興趣范圍包括：Java，C/C++，Python，PHP，Ruby，shell等各種語言開發(fā)經(jīng)驗(yàn)交流，各種框架使用，外包項(xiàng)目機(jī)會，學(xué)習(xí)、培訓(xùn)、跳槽等交流

QQ群：26931708

Hadoop源代碼研究群

興趣范圍包括：Hadoop源代碼解讀，改進(jìn)，優(yōu)化，分布式系統(tǒng)場景定制，與Hadoop有關(guān)的各種開源項(xiàng)目，總之就是玩轉(zhuǎn)Hadoop

QQ群：288410967?