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