Skip to content

Kafka

Jump to bottom
Sho Iizuka edited this page Jun 18, 2026 · 7 revisions

p.4 Kafka のデータの単位は公式には「メッセージ」。でも Java のクラス名は ProducerRecord

p.23 ログセグメントは log.dirs で指定したディレクトリに保存されるが、複数のディレクトリを指定すると、新しいパーティションは最もパーティション数が少ないディレクトリに保存される。最も容量が少ないディレクトリではない。ある程度均等にしたければ、パーティションサイズの設計に工夫が必要。

p.23 auto.create.topics.enable は練習用途以外では false にすべきである。

p.25 作者の見解ではパーティションサイズは1日あたり 6GB 未満にすべき。1MB/s を標準的な処理速度とすると1日あたり 86400MB 処理できるので、ピークタイムに10倍のトラフィックがあると考えた場合だろうか。

pp.26-27 log.retension.ms や log.retension.bytes による期限切れ削除は log.segment.bytes (=1GB) のセグメントごとに実行される。流量があまりにも小さいパーティションではデータが全然削除されないということが起きる。データ破棄が重要な要件の場合は log.segment.ms を設定するとよいかもしれない。

p.54 schema registry は topic に非互換なスキーマのメッセージが入らないことを保証するためのランタイムな門番としての役割である。どの producer/consumer がどのバージョンのスキーマで読み書きしているか一覧性をもって把握することが運用上重要らしい。

p.82 Kafka メッセージを取ってきて都度処理した結果を DB に exactly-once で書き込みたいとする。この場合は Kafka のオフセットを DB に保存するというテクニックが使える。初期化時に seek でオフセットをずらせばよい。

p.183 kafka-topics.sh には --under-replicated-partitions や --unavailable-partitions 引数によるフィルタリングがある。これはモニタリングしてもよい項目だ

p.210 UnderReplicatedPartitions は通常安定しているはず。ブローカーが壊れれば 0 より大きくなることはあるが、低い値で安定するはず。不安定なら、特定の Broker が in-sync になったりならなかったりしている可能性がある。

p.212 パーティション数、リーダーパーティション数、入出力バイトレート、入出力メッセージレートは Broker 間でバランスがとれていることが望ましい。

p.220 オフラインのパーティション数 (OfflinePartitionsCount) は Broker が全て停止していたり、リーダーになれる in-sync レプリカがいない状態。緊急対応が必要

p.236 Consumer group の遅延のモニタリングは Burrow というツールが紹介されているが、現代ではどうなんだろう…

ストリーム処理におけるウィンドウの種類

Tumbling Window

ウィンドウ同士が重ならない。「日時」や「1時間ごと」などの集計に使う

Hopping Window, Sliding Window

製品によって用語が異なるのでよく確認したほうがよい。以下の2種類ある

  1. ウィンドウの幅は固定で、ウィンドウが前進していく幅も固定。「1分毎に、過去5分間の平均分間アクセス数」
  2. ウィンドウの幅は固定で、イベントが到着する度にウィンドウを作成する「過去5分間の平均分間アクセス数」

マイクロソフトは前者を Hopping Window、後者を Sliding Window と呼んでいる。

Google Cloud Dataflow は前者を Hopping Window と呼んでいる。後者の機能は無い。Apache Beam は前者を Sliding Window と呼んでいる。

Clone this wiki locally