kafkaクラスタ内のトピックのパーティション数を決定する方法
3478 ワード
kafkaクラスタにおけるtopic,partitionの数をどのように決定するかは,多くのkafkaユーザがよく遭遇する問題である.本文はいくつかの重要な決定要素を列挙して述べて、いくつかの参考を提供します.
1つのトピックtopicの各パーティションpartiton間は並列である.producerとbrokerでは,異なるパーティションを書くことは完全に並列である.そのため、圧縮などの高価な操作では、複数のプロセスがあるため、より多くのリソースを得ることができます.consumerの態様では、1つのパーティションのデータは、1つのconsumerスレッドによってデータを引き抜くことができる.パーティションが多く、パラレルconsumer(同じ消費グループ)も多くできます.そのため、通常、パーティションが多ければ多いほどスループットが高くなります.
スループットに基づいて、大まかな計算式を得ることができます.まず,1つのパーティションのみの場合のProducerのスループット(P)とConsumerのスループット(C)を測定した.では、全体のターゲットスループットがTであれば、max(T/P,T/C)は必要な最小パーティション数である.単一パーティションの場合、Producerのスループットは、bathのサイズ、コピーの数、圧縮フォーマット、ackタイプなどの構成パラメータによって測定することができる.一方、Consumerのスループットは、通常、アプリケーションが毎日のメッセージロジックを処理することに依存します.これらはすべて実際の測定に合わせる必要がある.
時間が経つにつれてデータ量が増加するには、パーティションを増やす必要がある場合があります.Producer者がメッセージを発行してkeyによってハッシュを取得した後、マッピングは指定されたパーティションに配布され、パーティション数が変化するとkeyとパーティションマッピングの関係が変化することに注意してください.一部のアプリケーションはkeyとパーティションマッピング関係に依存し、マッピング関係が変化した場合、プログラムは適切な調整を行う必要があります.このようなkeyとパーティション関係によるアプリケーションの変更を避けるために.したがって、パーティション化の際には、今後1年または2年間のパーティションデータ量の要求をできるだけ事前に考慮します.
スループットに加えて、パーティションの数を決定する際に考慮に値する他の要因もあります.場合によっては、パーティションが多すぎると負の影響を及ぼす可能性があります.
各パーティションはbroker上のディレクトリにマッピングされ、各logクリップには2つのファイル(1つはインデックスファイル、もう1つは実際のデータファイル)があります.パーティションが多ければ多いほど必要なファイルハンドルも多くなり、オペレーティングシステムを構成するパラメータで開くファイルハンドルの数を増やすことができます.
kafkaはプライマリ・バックアップ・レプリケーションをサポートし、より高い可用性と持続性を備えています.1つのパーティション(partition)複数のコピーを持つことができます.これらのコピーは異なるbrokerに保存されます.各パーティションのコピーにはリーダーとして1つがあります.1つのbrokerが失敗すると、このbroker上のリーダーのパーティションは使用できなくなり、kafkaは自動的にリーダーを削除し、そのコピーの中から新しいリーダーとして1つを選択します.ProducerとConsumerはリーダーにのみ接続されます.
一般に、1つのbrokerが正常にシャットダウンされると、controllerは、シャットダウン中のbrokerからLeaderをアクティブに除去する.リーダーを移動するには数ミリ秒しかかかりません.ただし、brokerに異常が発生してシャットダウンした場合、使用できないのはパーティション数に比例します.1つのbokerに2000個のパーティションがあり、各パーティションに2個のコピーがあると仮定すると、このようなbokerには約1000個のリーダーがあり、bokerが異常にダウンタイムすると、同時に1000個のパーティションが使用できなくなります.1つのパーティションを復元するには5 msが必要であり、1000個のパーティションは5 sが必要であると仮定します.
パーティションが多ければ多いほど、brokerが異常にダウンタイムした場合、リカバリに要する時間が長くなり、使用できないリスクが増加します.
この遅延は,2つのboker間のプライマリ・スタンバイ・データ同期に現れる必要がある.デフォルトでは、2つのbokerは、データのコピーを担当するスレッドが1つしかありません.
経験によれば、各boker上のパーティションは100*b*r内に制限される(bはクラスタ内のbokerの数、rはコピーの数を指す).
kafka0.8.2後、新しいProducerはユーザーにバッファを設定し、一定量のデータをキャッシュすることができるという特徴があります.バッファデータが設定された定量的または時間に達すると、データはキャッシュから削除されてbrokerに送信されます.パーティションが多い場合、各パーティションはバッファに一定量のデータ量をキャッシュし、システムメモリを上回るメモリを大量に消費する可能性があります.
Consumerも同様の問題があり、各パーティションからデータが引き戻され、パーティションが多ければ多いほど、必要なメモリが大きくなります.
経験上、各パーティションに少なくとも数十KBのメモリを割り当てる必要があります.
通常、パーティションを増やしてkafkaクラスタのスループットを提供することができる.しかしながら、クラスタの総パーティション数または単一サーバ上のパーティション数が多すぎると、使用不可能および遅延のリスクが増加することも認識されるべきである.
http://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/
1つのトピックtopicの各パーティションpartiton間は並列である.producerとbrokerでは,異なるパーティションを書くことは完全に並列である.そのため、圧縮などの高価な操作では、複数のプロセスがあるため、より多くのリソースを得ることができます.consumerの態様では、1つのパーティションのデータは、1つのconsumerスレッドによってデータを引き抜くことができる.パーティションが多く、パラレルconsumer(同じ消費グループ)も多くできます.そのため、通常、パーティションが多ければ多いほどスループットが高くなります.
スループットに基づいて、大まかな計算式を得ることができます.まず,1つのパーティションのみの場合のProducerのスループット(P)とConsumerのスループット(C)を測定した.では、全体のターゲットスループットがTであれば、max(T/P,T/C)は必要な最小パーティション数である.単一パーティションの場合、Producerのスループットは、bathのサイズ、コピーの数、圧縮フォーマット、ackタイプなどの構成パラメータによって測定することができる.一方、Consumerのスループットは、通常、アプリケーションが毎日のメッセージロジックを処理することに依存します.これらはすべて実際の測定に合わせる必要がある.
時間が経つにつれてデータ量が増加するには、パーティションを増やす必要がある場合があります.Producer者がメッセージを発行してkeyによってハッシュを取得した後、マッピングは指定されたパーティションに配布され、パーティション数が変化するとkeyとパーティションマッピングの関係が変化することに注意してください.一部のアプリケーションはkeyとパーティションマッピング関係に依存し、マッピング関係が変化した場合、プログラムは適切な調整を行う必要があります.このようなkeyとパーティション関係によるアプリケーションの変更を避けるために.したがって、パーティション化の際には、今後1年または2年間のパーティションデータ量の要求をできるだけ事前に考慮します.
スループットに加えて、パーティションの数を決定する際に考慮に値する他の要因もあります.場合によっては、パーティションが多すぎると負の影響を及ぼす可能性があります.
各パーティションはbroker上のディレクトリにマッピングされ、各logクリップには2つのファイル(1つはインデックスファイル、もう1つは実際のデータファイル)があります.パーティションが多ければ多いほど必要なファイルハンドルも多くなり、オペレーティングシステムを構成するパラメータで開くファイルハンドルの数を増やすことができます.
kafkaはプライマリ・バックアップ・レプリケーションをサポートし、より高い可用性と持続性を備えています.1つのパーティション(partition)複数のコピーを持つことができます.これらのコピーは異なるbrokerに保存されます.各パーティションのコピーにはリーダーとして1つがあります.1つのbrokerが失敗すると、このbroker上のリーダーのパーティションは使用できなくなり、kafkaは自動的にリーダーを削除し、そのコピーの中から新しいリーダーとして1つを選択します.ProducerとConsumerはリーダーにのみ接続されます.
一般に、1つのbrokerが正常にシャットダウンされると、controllerは、シャットダウン中のbrokerからLeaderをアクティブに除去する.リーダーを移動するには数ミリ秒しかかかりません.ただし、brokerに異常が発生してシャットダウンした場合、使用できないのはパーティション数に比例します.1つのbokerに2000個のパーティションがあり、各パーティションに2個のコピーがあると仮定すると、このようなbokerには約1000個のリーダーがあり、bokerが異常にダウンタイムすると、同時に1000個のパーティションが使用できなくなります.1つのパーティションを復元するには5 msが必要であり、1000個のパーティションは5 sが必要であると仮定します.
パーティションが多ければ多いほど、brokerが異常にダウンタイムした場合、リカバリに要する時間が長くなり、使用できないリスクが増加します.
この遅延は,2つのboker間のプライマリ・スタンバイ・データ同期に現れる必要がある.デフォルトでは、2つのbokerは、データのコピーを担当するスレッドが1つしかありません.
経験によれば、各boker上のパーティションは100*b*r内に制限される(bはクラスタ内のbokerの数、rはコピーの数を指す).
kafka0.8.2後、新しいProducerはユーザーにバッファを設定し、一定量のデータをキャッシュすることができるという特徴があります.バッファデータが設定された定量的または時間に達すると、データはキャッシュから削除されてbrokerに送信されます.パーティションが多い場合、各パーティションはバッファに一定量のデータ量をキャッシュし、システムメモリを上回るメモリを大量に消費する可能性があります.
Consumerも同様の問題があり、各パーティションからデータが引き戻され、パーティションが多ければ多いほど、必要なメモリが大きくなります.
経験上、各パーティションに少なくとも数十KBのメモリを割り当てる必要があります.
通常、パーティションを増やしてkafkaクラスタのスループットを提供することができる.しかしながら、クラスタの総パーティション数または単一サーバ上のパーティション数が多すぎると、使用不可能および遅延のリスクが増加することも認識されるべきである.
http://www.confluent.io/blog/how-to-choose-the-number-of-topicspartitions-in-a-kafka-cluster/