簡要分析Kafka Stream有意思的點
kafka歷史背景
Kafka是2010年Kafka是Linkedin于2010年12月份開源的消息系統(tǒng)，我接觸的不算早，大概14年的時候，可以看看我們14年寫的文章《高速總線kafka介紹》。
消息總線一直是作IT系統(tǒng)集成的核心概念，IBM/oracle等傳統(tǒng)廠商都有相關(guān)中間件產(chǎn)品。傳統(tǒng)消息中間件解決是消息的傳輸，一般支持AMQP協(xié)議來實現(xiàn)，如RabbitMQ。AMQP的主要特征是面向消息、隊列、路由(包括點對點和發(fā)布/訂閱)、可靠性、安全。AMQP協(xié)議更多用在企業(yè)系統(tǒng)內(nèi)，對數(shù)據(jù)一致性、穩(wěn)定性和可靠性要求很高的場景，對性能和吞吐量的要求還在其次。
Kafka上來劍走偏鋒，追求高吞吐量，所以特別適合，大數(shù)據(jù)的數(shù)據(jù)收集和分發(fā)等功能。高吞吐的原因核心是kafka的一些獨特的涉及，包括直接使用linux cache/zero-copy/數(shù)據(jù)存放方法等，這方面的分析很多，我前面的文章《高速總線kafka介紹》第4節(jié)也簡單寫了下。Kafka一直缺乏一個商業(yè)公司來推動，所以發(fā)展并不是很快。幾年過去了，自己看了看，還是0.10版本，特性也發(fā)展比較慢。
Kafka一直缺乏一個商業(yè)公司來推動，這個問題現(xiàn)在要稍稍改變一些了，原LinkedIn Kafka作者離職后創(chuàng)業(yè)Confluent Inc來推動kafka商業(yè)化，并推出Kafka Stream。
詳細的設(shè)計理念，概念，大家看看slidershare上的PPT，講的比較清楚，不詳細展開了：https://www.slideshare.net/GuozhangWang/introduction-to-kafka-streams。
kafka stream
今天只講kafka stream幾個有意思的點：
1. 首先是定位：
比較成熟度的框架有：Apache Spark, Storm(我們公司開源Jstorm), Flink, Samza 等。第三方有：Google’s DataFlow，AWS Lambda。
1)現(xiàn)有框架的好處是什么?
強大計算能力，例如Spark Streaming上已經(jīng)包含Graph Compute，MLLib等適合迭代計算庫，在特定場景中非常好用。
2)問題是什么?
A、使用起來比較復(fù)雜，例如將業(yè)務(wù)邏輯遷移到完備的框架中，Spark RDD，Spout等。有一些工作試圖提供SQL等更易使用模式降低了開發(fā)門檻，但對于個性化ETL工作(大部分ETL其實是不需要重量級的流計算框架的)需要在SQL中寫UDF，流計算框架就退化為一個純粹的容器或沙箱。
B、作者認為部署Storm，Spark等需要預(yù)留集群資源，對開發(fā)者也是一種負擔(dān)。
Kafka Stream定位是輕量級的流計算類庫，簡單體現(xiàn)在什么方面?
C、所有功能放在Lib中實現(xiàn)，實現(xiàn)的程序不依賴單獨執(zhí)行環(huán)境
D、可以用Mesos，K8S，Yarn和Ladmda等獨立調(diào)度執(zhí)行Binary，試想可以通過Lamdba+Kafka實現(xiàn)一個按需付費、并能彈性擴展的流計算系統(tǒng)，是不是很cool?
E、可以在單、單線程、多線程進行支持
F、在一個編程模型中支持Stateless，Stateful兩種類型計算
編程模型比較簡潔，基于Kafka Consumer Lib，及Key-Affinity特性開發(fā)，代碼只要處理執(zhí)行邏輯就可以，F(xiàn)ailover和規(guī)模等問題由Kafka本身特性幫助解決。
2. 設(shè)計理念和概念抽象
強調(diào)簡單化，Partition中的數(shù)據(jù)到放入消費隊列之前進行一定的邏輯處理(Processor Topology)提供一定的數(shù)據(jù)處理能力(api)，沒有Partition之間的數(shù)據(jù)交換，實現(xiàn)代碼9K行。
數(shù)據(jù)抽象分兩種：
1)KStream：data as record stream, KStream為一個insert隊列，新數(shù)據(jù)不斷增加進來
2)KTable: data as change log stream, KTable為一個update隊列，新數(shù)據(jù)和已有數(shù)據(jù)有相同的key，則用新數(shù)據(jù)覆蓋原來的數(shù)據(jù)
后面的并發(fā)，可靠性，處理能力都是圍繞這個數(shù)據(jù)抽象來搞。
3. 支持兩種處理能力
1)Stateless(無狀態(tài))：例如Filter，Map，Joins，這些只要數(shù)據(jù)流過一遍即可，不依賴于前后的狀態(tài)。
2)Stateful(有狀態(tài))：主要是基于時間Aggregation，例如某段時間的TopK，UV等，當(dāng)數(shù)據(jù)達到計算節(jié)點時需要根據(jù)內(nèi)存中狀態(tài)計算出數(shù)值。
Kafka Streams把這種基于流計算出來的表存儲在一個本地數(shù)據(jù)庫中(默認是RocksDB，但是你可以plugin其它數(shù)據(jù)庫)
4. 未來支持exactly once
未來0.11版本會支持exactly once ，這是比較牛逼的能力。(提前預(yù)告)
https://www.confluent.io/blog/exactly-once-semantics-are-possible-heres-how-apache-kafka-does-it/
1)at most once: 消費者fetch消息，保存offset，處理消息
消費者處理消息過程中出現(xiàn)意外，消費者恢復(fù)之后，將不能恢復(fù)處理出錯的消息
2)at least once: 消費者fetch消息，處理消息，保存offset
消費者處理消息過程中出現(xiàn)意外，可以恢復(fù)之后再重新讀取offsert處的原來的消息
3)exactly once: 確保消息唯一消費一次，這個是分布式流處理最難的部分。
“processing.guarantee=exactly_once”
這個是怎么實現(xiàn)的，去看看《分布式系統(tǒng)的一致性探討》http://blog.jobbole.com/95618/
和《關(guān)于分布式事務(wù)、兩階段提交協(xié)議、三階提交協(xié)議》
http://blog.jobbole.com/95632/。
5. 主要應(yīng)用場景
kafka的核心應(yīng)用場景還是輕量級ETL，和flink/storm更多是一個補充作用。
Building a Real-Time Streaming ETL Pipeline in 20 Minutes
https://www.confluent.io/blog/building-real-time-streaming-etl-pipeline-20-minutes/
最后希望kafka在商業(yè)公司的推動下有個更大的發(fā)展。
【本文為51CTO專欄作者“大數(shù)據(jù)和云計算”的原創(chuàng)稿件，轉(zhuǎn)載請通過微信公眾號獲取聯(lián)系和授權(quán)】
