咻咻的筆記小站

簡述：使用 Kafka 作為傳遞資料的水管(pipe) 關鍵字： # unix   # philosophy   # Apache_Kafka   # Kafka   # pureFunction 文章中先引述了，工程師們使用很久的 unix 工具以及法則來說明背後的強大之處，例如：awk, sort, grep,uniq ，都希望只做一件事情，不讓事情太過龐大，並且使用 command 來做例子，awk | sort > file，見文中圖片，這是他的組合性，工具本身不知道資料哪裡來，也不管資料往哪裡走，處理完也不會產生其他問題，只要每個工具只做一件事情，而且使用 |(pipe) 來接在一起，就可以組合出強大的功用。 這樣的概念與這一兩年風潮流行的 pure function 不是相同嗎？ 1. 不產生 side effect 2. 每次輸入相同，會得到相同輸出 配合其組合性就變成其他的 operator ，這也是 Rx 家族在說的事情，希望至此你已經懂這邊的 philosophy 了。 ＝＝＝＝＝ 回到主題，用這件事情來看待資料庫時呢？可以明顯發現到資料庫本身做了許許多多的事情，備份/搜尋/預測/分析等等事情，philosophy 已經在那邊了，技術到這邊了，我們常使用的資料庫怎麼還沒變化呢，文章開始分析資料庫問題所在，並且指出現有的工具早已存在，缺的是那個 pipe ，而目前最接近的工具就是 Apache Kafka 。 推薦影片： https://www.youtube.com/watch?v=Gqdr0DiNh5g 文章與圖源選自： https://www.confluent.io/…/apache-kafka-samza-and-the-unix…/

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