Kafka 不只是訊息系統，更偏向於資料庫
src: https://kafka.apache.org/intro 「Message queue system 極簡說明」 在遠端呼叫機制中，有一種 pattern 為 publisher - broker - consumer 的方式，publisher 負責產生資料/consumer 負責消化資料/broker 負責handle 雙方吞吐的狀況，而這基本上也是現在大多數的訊息系統 (Message queue system )所實作的方式。 「Kafka 極簡說明」 Kafka 在 broker 的實作上是這樣，從 publisher 來的資料放置在 topic 當中，以 log 的方式存下來，並讓 consumer 來消化它，期間 broker 不會主動去 push 資料給 consumer，而是等 consumer 自己來 pull ，如此一來，就減少許多處理 ack 的問題。 「將 kafka 作為資料庫」 既然資料都在 topic 上面，那為何還需要對其他 DB 作 Query 呢？topic 與 DB 通常主要差異是在資料存放的方式，前者為 log，後者為 transaction，前者是連續時間，後者是片段時間。舉生活例子來說明，請問你昨天在哪裡？ log的系統會回答"每個時間點"你所在的位置，transaction 只有一個，而且會是最新(最後更動)那個點。 kafka 是可以做為資料庫的，並且以 log 方式貯存資料。 「ktable, kstream, etl, connecter」 “現階段”處理 log 是用 kStream ，如果要取得某個片段時間點資料是用 KTable，如果要和其他ＤＢ作 query 則採用 connector，在這套論點當中，會有些文章提出 ETL(Extract-Transform-Load) is dead 的論述， 我覺得這算是某種程度上的 Buzzword 了，ETL 的概念是會一直跟著的，生活中也一直出現過，數學上也常做表達，他會換個方式活著不會就此停止ＸＤ 例如說：KStream 可以是 T, connecter 可以是 E/L