阅读了 Kafka 官方网站的 Introduction 的笔记

2016年11月22日当前,读了《Apache Kafka》介绍的笔记。

Kafka是一个分布式流处理平台。这具体意味着什么?

话题与记录

分发

    • ログのパーティション群は Kafka クラスタの中で複数サーバーに分散され、それぞれのサーバーが割り振られたパーティションについてデータ・リクエストを扱う

 

    • それぞれのパーティションは耐障害性のため設定可能な数の複数サーバーへと複製される

 

    • それぞれのパーティションは “leader” として機能する 1 サーバーと、0~複数台の “followers” サーバーを持つ

 

    • leader はそのパーティションのすべての read/write リクエストを処理する

followers は受動的に leader を複製する

leader が死ぬと、followers のうちの 1 サーバーが新しい leader となる
それぞれのサーバーはいくつかのパーティション群の leader かつ、別のパーティション群の follower として機能する

クラスタ内ではいいバランスとなる

制造商

    • producer は自分で選んだトピックにデータを発行する

 

    • producer はトピック内のどのパーティションにレコードを割り当てるかを選ぶ責任がある

負荷対策のために単純な round-robin で行うこともできる
また、(レコードのキーのような) なんらかの意味がある分割のやり方にしたがって行うこともできる

パーティションの利用についてはこのあとすぐ説明する

消费者

保证

    • 高いレベルで Kafka は下記を保証している

producer から特定の topic パーティションへ送信されたメッセージは、送信された順番で append される

すなわちレコード M1 と M2 が同じ produducer から送信され、M1 が先に送信されたなら、M1 は M1 よりも値の小さい offset を持ち、ログのより最初のほうに現れる

consumer はログに蓄積された順番にレコードを見る
レプリケーション・ファクター N のトピックについて、N-1 台のサーバーが死んでも、ログにコミットされたレコードは失われず、障害に耐えうる

これらの保証の詳細についてはドキュメントの “design” セクションに書いてある

卡夫卡作为一种消息传递系统

    • Kafka のストリームの概念は伝統的なエンタープライズ・メッセージング・システムとどのように比べてどうだろうか?

 

    • メッセージングには伝統的に 2 つのモデル queuing と publish-subscribe がある

queue ではプールされた consumer がサーバーから読み出し、それぞれのレコードは consumer のいずれかに届く
publish-subscribe ではレコードはすべての consumer に届く

2 つのモデルにはメリットとデメリットがある

queuing のメリットはデータの処理を複数の consumer にまたがって分割し、処理をスケールさせることができること
残念なことに queue は複数のサブスクライバーを持てない、つまり 1 つのプロセスがデータを読むとデータは消えてしまう
publish-subscribe なら複数のプロセスすべてにデータを送ることができるが、すべてのメッセージはそれぞれのサブスクライバに送信されてしまうため、スケールさせる方法がない

Kafka の consumer group の概念はこの 2 つの概念を一般化したものだ

queue に関して、consumer group なら処理をいくつかのプロセス (= consumer group のメンバーたち) に分割することができる
publish-sbscribe に関して、Kafka なら複数の consumer group すべてに対してメッセージを送信することができる

Kafka のモデルの利点は、すべてのトピックが両方の性質を持っているということだ

処理をスケールさせることもできるし、複数のサブスクライバーを持たせることもできる
どちらかをえらぶ必要はない

Kafka は伝統的なメッセージング・システムよりも強力に順番を保証している
伝統的な queue はサーバー上で順番を保持したレコードの一覧を保持しており、複数の consumer が queue から consume した場合にはサーバーは保存された順番にレコードを分配する

しかし、サーバーは順番通りにレコードを分配するのだが、レコードが consumer に非同期的に分配されてしまうので、ことなる consumer 群に届くころには順番が乱れてしまっている
これは並列的な consume を行うとレコードの順番が失われてしまうことを意味している

メッセージングシステムでは、「排他的な consumer」の概念を持つことでこの問題を回避してきた
* 1 つのプロセスだけが 1 つのキューから consume できるようにするというもの
* しかし当然ながら並列的な処理は不可となってしまう
Kafka ならもっとうまくやれる

トピックに並列性 (= パーティション) の概念を持たせることで、Kafka は順番の保証もできるし、プールされた consumer プロセス間で負荷分散を行うこともできる

これはトピック内のパーティションを consumer group 内の consumer に割り当て、それぞれのパーティションが必ず group 内の 1 つの consumer にだけ consume されるようにすることで、実現されている

これを行うことで、その consumer だけがパーティションを読んでおり、順番にデータを consume していることを保証できる

たくさんのパーティションを用意すれば、consumer インスタンス間で負荷を分散させることもできる
しかし、consumer group 内にはパーティションの数より多くの consumer を所属させることはできないことに注意してほしい

卡夫卡作为一种存储系统

    • どんなメッセージキューでも、メッセージの publish が consume と分離されていれば、やりとりされているメッセージにとってのストレージシステムとして機能はするだろう

Kafka がちがうのは、それが非常にすぐれたストレージ・システムであるということだ

Kafka に書き込まれるデータは、ディスクに書かれ、耐障害性のために複製される

Kafka は producer を待たせ、書き込みが完全に複製され、書き込んだ先のサーバーが死んでもデータが生き続けることが保証されてから ACK を送ることができる

Kafka が使うディスク構成はうまくスケールする

Kafka はサーバー上に 50KB の永続的なデータがある場合でも、50TB のデータがある場合でも、同じパフォーマンスを発揮する

ストレージに真剣に取り組み、クライアントが読み出しの位置を制御できるようにしたことで、Kafka は高性能で低レイテンシーなコミットログのストレージを備え、レプリケーション・伝播が可能な、一種の特殊な分散ファイルシステムとして捉えることができる

流处理的卡夫卡

    • 単にストリーム・データを読み、書き、保存するだけでは不十分で、目的はリアルタイムのストリーム処理を行うことだ

 

    • Kafka にはストリームプロセッサー機能があり、連続したストリーム・データを入力トピックから受け取り、その入力に対してなんらかの処理を行い、出力トピックへと連続したストリーム・データを produce する

 

    • たとえば、小売店のためのアプリケーションでは、入力のストリームとして売り上げと出荷のデータを受け取り、そのデータをもとに計算された再注文と価格のデータを出力するだろう

 

    • 直接 producer/consumer API を使うことでシンプルな処理が可能となるが、もっと複雑なデータ変形のために Kafka は完全に統合された Streams API が備えている

これにより、ストリームの aggregations を計算したりストリームを join するといったような難しい処理を行うことができる

この機能はこの種のアプリケーションが直面する難しい問題を解決する助けとなる

ソートされていないデータを扱ったり
コードの変更があるごとに入力を再処理したり
ステートフルな計算を行ったり、等々

streams API は Kafka が提供するコア基本機能をもとに作られている

producer/consumer API が利用され、Kafka のステートフルストレージが利用され、ストリーム・プロセッサーのインスタンス間では consumer group と同じ耐障害メカニズムが利用されている

拼凑碎片

    • メッセージング、ストレージ、ストリーム処理の組み合わせは異常に見えるかもしれないが、streaming platform として Kafka の役割にとっては重要なものだ

 

    • HDFS のような分散ファイルシステムでは、バッチ処理にとって非常に強く静的なファイルを利用することができる

このようなシステムは過去からの歴史的なデータを保存し処理することができる

伝統的なエンタープライズ・メッセージング・システムでは購読したあとに届く未来のメッセージを処理することができる

このように作られたアプリケーションでは届いた順に未来のデータを処理する

Kafka は両方の能力を組み合わせており、この組み合わせは Kafka をストリーミングアプリケーションのプラットフォームとして使うにしても、ストリーミング・データ・パイプラインとして使うにしても重要なものだ
ストレージと低レイテンシーな購読を組み合わせることで、ストリーミング・アプリケーションは過去と未来の両方のデータを同じように扱うことができる

1 つのアプリケーションが、歴史的な保存されたデータを扱い、しかも最後のデータが届いたときに処理が終了するのではなく、未来のデータが届くにつれて処理をしつづけるのだ
これは一般化されたストリーム処理の概念であり、バッチ処理とメッセージ駆動アプリケーションの両方を包含している

同じようにストリーミング・データ・パイプラインにとっては、リアルタイムなイベントの購読を組み合わせることによって、Kafka を非常に低レイテンシーなパイプラインといして使うことができる

しかし、データ保存に信頼性があるので、データ到達性の保証がマストだったり、定期的にしかデータをロードしなかったり、長期間メンテナンスで落ちることがあるようなオフライン・システムとのインテグレーションに使うこともできる
ストリーム処理機能により、データが到達するにつれて変形処理を行うことが可能である

信頼性、API、Kafka が提供する機能についての詳細は、documentation を参照してください

英文單字筆記

    • of one’s choice = 自分で選んだ

 

    • in flight = 飛行中の

 

    • propagation = 伝播

 

    • retail = 小売店

 

    subsume = 包含する
广告
将在 10 秒后关闭
bannerAds