オライリーのKafka。Kafka自体はちらほらと聞きつつも、MQ、JMSなどの所謂メッセージングとの違いがさっぱり分からなかったものの、一方でレプリケーションソフトとして使いたい話もあり、体系的に整理したかったところ。
その点、まえがきに整理されていました。
Kafkaはもともと、Linkedin社内のインフラシステムとして始まりました。私たちが思っていたのは、実に単純なことでした。データベースといったデータをストアするためのシステムはたくさんありましたが、自分たちのアーキテクチャにはデータの連続的なフローを処理するのに役立つものがかけていたのです。Kafkaを作る前、メッセージングシステムからログ集約／ETLツールまで、出来合いのソフトをいろいろと試してみたのですが、どれも求めていたものではありませんでした。
結局、私達はゼロから作ることにしました。リレーショナルデータベース、キーバリューストア、検索インデックス、キャッシュなどのように膨大なデータの保存にフォーカスするのではなく、連続的に生成されて成長し続けるストリームとしてデータを扱うことにフォーカスしました。
（中略）
私たちはKafkaをストリーミングプラットフォームとして考えるようになりました。ストリーミングプラットフォームとは、データの発行（Publish）と購読（Subscribe）、保存、処理を可能にするシステムであり、Apache Kafkaはまさにそのために作られています。
（中略）
Kafkaはメッセージングシステムと似ています（中略）、違いは３つあります。第一にKafkaはクラスタとして動作するモダンな分散システムです。拡張することで、超巨大な企業であってもすべてのアプリケーションを扱うことができます。（中略）対ににKafkaは好きなだけデータを保存できるように作られた、真のストレージプラットフォームです。真の配送保証を提供しているため、接続レイヤとして使うと大きなメリットがあります。データは複製され、永続化され好きなだけ手元においておけます。最後に、ストリーム処理の世界は抽象化のレベルを大きく高めてくれます。ほとんどのメッセージングシステムではメッセージの配信しかしてくれません。それに対して、Kafkaのストリーム処理は、はるかに少ないコートであなたのストリームから派生したストリームやデータセットを動的に計算することができます。
（中略）
わたしたちがKafkaを設計／構築する際の森ベーションの１つだったのは、KafkaをHadoopのリアルタイムバージョンと考えることでした。
（中略）
Kafkaと比較される領域の最後は、ETLあるいはデータ統合ツールです（中略）。Kafkaは、あるシステムからデータを取り出して、別のシステムに入れるためのツールではありません。リアルタイムのイベントストリームを中心としたプラットフォームです。つまり、出来合いのアプリケーションやデータシステムに接続できるだけでなく、同じデータストリームをトリガにした独自のアプリケーションを構築して動かせるのです。
内部の仕組みは明るい資料があった。
めざせ！Kafkaマスター ～Apache Kafkaで最高の性能を出すには～
事例としてはMQ代替が多く、まえがきのコンセプトと合致しないのが多数だっだけれども、以下が腑に落ちる。
大手ヘルスケアIT企業 Cerner社のKafka活用事例
さて、読書。。。