Kafkaによるデータモデリング？トピックとパーティション

新しいサービス（RDBMS以外のデータストアやメッセージキューなど）を使用するときに最初に考えることの1つは、「データをどのように構造化する必要があるか」です。

私はいくつかの紹介資料を読んで見ました。特に、たとえば、Kafka：ログ処理のための分散メッセージングシステムを例にとります。

• 「トピックは、メッセージが関連付けられているコンテナです」
• 「並列処理の最小単位はトピックのパーティションです。これは、トピックの特定のパーティションに属するすべてのメッセージが、コンシューマーグループのコンシューマーによって消費されることを意味します。」

これを知って、トピックとパーティションの使用方法を示す良い例は何でしょうか？何かがトピックになるのはいつですか？何かをパーティションにする必要があるのはいつですか？

例として、私の（Clojure）データが次のようになっているとします。

{:user-id 101 :viewed "/page1.html" :at #inst "2013-04-12T23:20:50.22Z"}
{:user-id 102 :viewed "/page2.html" :at #inst "2013-04-12T23:20:55.50Z"}

トピックは基づいているべきuser-idですか？viewed？at？パーティションはどうですか？

どうやって決めるの？

Kafkaのデータを構造化する場合、それは実際にどのように消費されるかによって異なります。

私の考えでは、トピックは同じタイプのコンシューマーによって消費される同様のタイプのメッセージのグループなので、上記の例では、単一のトピックがあり、他の種類のKafkaを介してデータを送信する場合、後でそのための新しいトピックを追加できます。

トピックはZooKeeperに登録されています。つまり、100万のユーザーがいて、ユーザーごとにトピックを作成することにした場合など、トピックを追加しようとすると問題が発生する可能性があります。

一方、パーティションはメッセージの消費を並列化する方法であり、ブローカークラスター内のパーティションの総数は、パーティション機能を理解するために、少なくともコンシューマーグループ内のコンシューマーの数と同じである必要があります。コンシューマーグループのコンシューマーは、パーティション化に従ってトピックを処理する負担をそれらの間で分割するため、1つのコンシューマーは、パーティション自体が「割り当てられている」メッセージのみに関与します。

パーティション化は、プロデューサー側のパーティションキーを使用して明示的に設定できます。指定しない場合は、メッセージごとにランダムパーティションが選択されます。

イベントストリームを分割する方法がわかったら、トピック名は簡単になるので、まずその質問に答えましょう。

@Luddは正しいです。選択するパーティション構造は、イベントストリームの処理方法に大きく依存します。理想的には、イベント処理がパーティションローカルであることを意味するパーティションキーが必要です。

例えば：

1. ユーザーのサイト滞在時間の平均を気にする場合は、で分割する必要があり:user-idます。これにより、1人のユーザーのサイトアクティビティに関連するすべてのイベントを同じパーティション内で利用できるようになります。つまり、Apache Samzaなどのストリーム処理エンジンは、単一のパーティション内のイベントを調べるだけで、特定のユーザーのサイト滞在時間の平均を計算できます。これにより、コストのかかるパーティショングローバル処理を実行する必要がなくなります。
2. Webサイトで最も人気のあるページを気にする場合は、:viewedページごとに分割する必要があります。繰り返しになりますが、Samzaは、単一のパーティション内のイベントを確認するだけで、特定のページのビューのカウントを保持できます

一般的に、グローバルな状態（DynamoDBやCassandraなどのリモートデータベースにカウントを保持するなど）に依存せずに、パーティションローカル状態を使用して作業できるようにすることを試みています。これは、ローカル状態がストリーム処理の基本的なプリミティブであるためです。

上記の両方のユースケースが必要な場合、Kafkaの一般的なパターンは、まずで分割し、次に次の処理フェーズに備え:user-idて再分割すること:viewedです。

トピック名について-ここで明らかなのはeventsまたはuser-eventsです。より具体的には、events-by-user-idやと一緒に使用できますevents-by-viewed。

これは質問とは正確には関係ありませんが、トピックに基づいてレコードの論理的な分離をすでに決定していて、Kafkaでトピック/パーティションの数を最適化したい場合は、このブログが役立つかもしれません。

一言で言えば、重要なポイント：

• 一般に、Kafkaクラスター内のパーティションが多いほど、達成できるスループットが高くなります。本番用の単一パーティションで達成可能な最大値をpとし、消費量をcとします。ターゲットのスループットがtであるとしましょう。次に、少なくともmax（t / p、t / c）パーティションが必要です。

• 現在、Kafkaでは、各ブローカーがすべてのログセグメントのインデックスとデータファイルの両方のファイルハンドルを開きます。したがって、パーティションが多いほど、基盤となるオペレーティングシステムでオープンファイルハンドルの制限を構成する必要があります。たとえば、本番システムではtoo many files are open、約3600のトピックパーティションがあるのに、「」というエラーが表示されました。

• ブローカーが不適切にシャットダウンされた場合（たとえば、kill -9）、観測された使用不可はパーティションの数に比例する可能性があります。

• Kafkaのエンドツーエンドのレイテンシは、メッセージがプロデューサーによってパブリッシュされてから、コンシューマーによってメッセージが読み取られるまでの時間によって定義されます。経験則として、レイテンシを気にする場合は、ブローカーあたりのパーティション数を100 x b x rに制限することをお勧めします。ここで、bはKafkaクラスター内のブローカーの数、rはレプリケーション係数です。

トピック名は一種のメッセージの結論であり、プロデューサはトピックへのメッセージをパブリッシュし、コンシューマはサブスクライブトピックを介してサブスクライブメッセージを発行します。

トピックには多くのパーティションがある場合があります。パーティションは並列処理に適しています。パーティションはレプリケーションの単位でもあるため、カフカでは、パーティションのレベルでリーダーとフォロワーも言われています。実際、パーティションは順序付けされたキューであり、その順序はメッセージ到着順序です。そして、トピックは簡単な言葉で1つ以上のキューで構成されています。これは、構造をモデル化するのに役立ちます。

Kafkaは、LinkedInによってログの集約と配信のために開発されました。このシーンは一例としてとても良いです。

Webまたはアプリでのユーザーのイベントは、Webサーバーによってログに記録され、プロデューサーを通じてKafkaブローカーに送信されます。プロデューサーでは、パーティション方法を指定できます。たとえば、イベントタイプ（異なるイベントは別のパーティションに保存されます）またはイベント時間（アプリのロジックに応じて1日を別の期間にパーティション化）またはユーザータイプまたはロジックなしですべてのログのバランスを取ります多くのパーティションに。

問題のケースについては、「page-view-event」と呼ばれる1つのトピックを作成し、ハッシュキーを使用してN個のパーティションを作成して、ログをすべてのパーティションに均等に分散できます。または、パーティションロジックを選択して、ログを精神で分散させることもできます。