大數據那些事(28):卡夫卡們的故事

人生亦有涯，而知也無涯。把莊子的話改吧改吧放上來作為開頭，就是想和大家說，現在的這個大數據的世界裡，數據太大，而我自己懂的東西很有限。除了analytics以外的其他領域就是典型的半瓶醋了。連八卦都不說。

然而作為一個系列，連Kafka都不提一下，顯然是說不過去。所以我也就硬著頭皮的來提一下卡夫卡以及其他的消息隊列們。當然嚴格的講，卡夫卡不算是一個嚴謹的消息隊列。它並不提供一入一出這樣嚴謹的語義。所以嚴格一點講卡夫卡算是一個基於pub/sub（中文叫發布/訂閱？？）的消息系統。

消息系統的作用在現代網站和電商裡面很重要了。我記得自己在Bing的時候，老一代的爬蟲系統和索引建立的系統都是手寫的，一切東西搞在一起，所以做到incremental build特別難。而Google發布咖啡因的新一代系統以後，就使得Bing的整個業務體系架構顯得很落伍。一條新聞CNN出來，近而被用戶能在搜索引擎搜到，可能Google只需要秒級別的延遲，到了Bing可能是分鐘級別的。這當然就顯得非常的不好。於是，當時Bing就不得不新修一套了。然後新修這套的時候，為了整個業務體系能夠適應多變的環境和業務規模，就準備搞一套消息系統，基於pub/sub的。

那個時候我記得內部曾經有過各種演講，資料。大致上來說，使用了消息系統有那麼幾個好處，一是對業務邏輯的耦合程度就要求沒那麼高了，不管是消息發布方還是消息的訂閱方的邏輯都可以進行更改。二是這樣一來對於用多少資源去處理消息就會很靈活，峰值或者有需要特殊的時候比如感恩節，就可以多加機器，平時就可以少加。

這個項目持續了很多年，最後的結果好像是黃了。應該是2016年的時候給撤銷了。但是不管怎麼說，理論上講，消息系統是很有意義的，無論隔離業務邏輯，永久存儲消息，提供冗餘，以及因對業務規模的增加和減少的時候的資源使用率，都是很好的。這我想是最初LinkedIn決定做卡夫卡的原因吧。

有關技術構架我就不講了，雖然說論文也讀過，我只能說自己理解不夠深刻，講出來誤人子弟的可能性比較高。但是一個八卦是卡夫卡的開發者，其中那個中國人，我正好有過幾周之緣。在IBM實習的時候對方是同樣一個研究小組裡面最早開始做Hadoop的幾個人之一。只是這個小組的人後來各奔東西，都成了挺牛的人，但是最牛的顯然還是這位了。今時不同往日的感覺。只是可惜了IBM。

卡夫卡之前之後其實消息隊列不少，RabbitMQ是最有名的一個吧。我是個C++寫得比較腦殘的人，所以不管是Erlang還是Scala在我眼睛裡看起來都比較奇怪，但是這些消息隊列好像都是用這些奇奇怪怪的語言寫出來的。傳說裡面大家會覺得卡夫卡不夠scalable不夠穩定等等之類的抱怨。當然，應該比起RabbitMQ是要更好一些了。關於卡夫卡的故事之一是我前段時間和AWS裡面做Kinesis的人聊天。對方信心滿滿的覺得自己的產品肯定比卡夫卡好用，無論是scabaility還是穩定性上。最著名的例子是它們搶下了美國某在線視頻直播廠商的業務，鑒於保密需要就不點名了，大家自己腦補很容易知道我說誰的。卡夫卡的另外一個八卦是MapR覺得卡夫卡性能不夠好的原因之一是它們沒有文件系統層面的支持。所以MapR決定又一次的開干，在它們的最新版本裡面集成和卡夫卡介面兼容的自己的實現。雖然說MapR成於文件系統，但是是不是任何東西最後都成了文件系統，這就見仁見智了。在CTO跳槽去Uber，幾個主創人員另外組局開公司去推廣Drill的今天，我想MapR可能也是快要掛了。

後來MQ產品就很多了，最近這個領域最大的新聞是阿里巴巴開源了自己的消息隊列RocketMQ。聽名字就很霸氣了。當然現在還在孵化中，不知道將來會怎麼樣。從我能看到的資料來看，RocketMQ是Java開發的，對用戶比較友好，對於峰值的支持經過天貓這麼多次雙11的洗禮可謂很牛逼。網上有好事的人做了一些比較，總之的出來的結論就是大天朝的阿里巴巴出品威武，卡夫卡在很多方面都缺了功能或者性能。現在唯一阻礙RocketMQ飛越的主要還是文檔和社區了。當然我們必須說RocketMQ的主要目的是基於電商的業務，而卡夫卡的服務範圍更多是系統日誌。文檔缺好像是中國人開源項目的通病了。而不維護更是阿里的現象，因為阿里特定級別需要升上去就有若干貢獻指標，其中開源了多少東西很重要。所以阿里就很重視開源但是不重視開源以後的維護。我不知道RocketMQ會不會和阿里的其他開源項目一樣。要是能和JStorm那樣的努力就真的給中國人長臉了。