Kafka の効率的なストレージ設計をコミックで解説

始める前に、Kafka の概念をいくつか思い出させてください。

a.ブローカー: データ ストレージとデータの読み取りおよび書き込みサービス インスタンスを提供します。 Kafka ノードはブローカーであり、複数のブローカーが Kafka クラスターを形成できます。

b.トピック: アプリケーション ログのトピック、アプリケーション ヘルス モニタリング インジケーターのトピックなど、メッセージの種類を表します。

紀元前パーティション: トピックの物理的なグループ化。トピックは複数のパーティションに分割できます。

d.セグメント: パーティションは物理的に複数のセグメントで構成され、各セグメントはファイルです。

e.オフセット: 各パーティションは、パーティションに継続的に追加される一連の順序付けられた不変のメッセージで構成されます。パーティション内の各メッセージには、オフセットと呼ばれる連続したシーケンス番号があり、これを使用してパーティション内のメッセージを一意に識別します。

以下は、Kafka データ ディレクトリ内の 2 つのトピック (page_view、ページ閲覧トラフィック ログ、click_log) のパーティション ストレージ状況です。

 | --ページビュー-0  
          | --ページビュー-1  
          | --ページビュー-2  
          | --ページビュー-3  
          | --クリックログ-0  
          | --クリックログ-1  
          | --クリックログ-2  
          | --クリックログ-3  

次の図は、ファイルがどのように保存されるかを示しています。

• 各パーティション (ディレクトリ) は、同じサイズの複数のセグメント データ ファイルに均等に分割された巨大なファイルに相当します。ただし、各セグメント ファイル内のメッセージの数は必ずしも同じではありません。この機能を使用すると、古いセグメント ファイルをすばやく簡単に削除できます。
• 各パーティションは順次読み取りと書き込みのみをサポートする必要があり、セグメント ファイルのライフ サイクルはサーバー構成パラメータによって決まります。

これを行う利点は、不要なファイルをすばやく削除し、ディスク使用率を効果的に向上できることです。

パーティション内のセグメント ファイルの構成と物理構造は次のとおりです。

• セグメント ファイルの構成: インデックス ファイルとデータ ファイルの 2 つの部分で構成されます。これら 2 つのファイルは互いに対応しており、ペアで表示されます。サフィックス「.index」と「.log」は、それぞれセグメント インデックス ファイルとデータ ファイルを表します。
• セグメント ファイルの命名規則: グローバル パーティションの最初のセグメントは 0 から始まり、後続の各セグメント ファイルは、前のセグメント ファイルの最後のメッセージのオフセット値に基づいて名前が付けられます。最大値は 64 ビット長、19 桁で、埋められていない桁には 0 が埋め込まれます。

1 つのパーティションを持つ topicXXX を作成し、各セグメントのサイズを 500 MB に設定し、プロデューサーを起動して大量のデータを Kafka ブローカーに書き込みます。パーティション ファイルの内容は次のとおりです。

図1

いくつかのインデックス ファイルとログ ファイル間の対応を示す詳細な図もあります。

図2

インデックス ファイルには大量のメタデータが保存され、データ ファイルには大量のメッセージが保存されます。インデックス ファイル内のメタデータは、対応するデータ ファイル内のメッセージの物理オフセット アドレスを指します。インデックス ファイル内のメタデータ 3,497 を例にとると、これはデータ ファイル内の 3 番目のメッセージ (グローバル パーティション内の 368772 番目のメッセージ) を表し、メッセージの物理オフセット アドレスは 497 です。

たとえば、offset=368776 のメッセージを読み取るには、次の 2 つの手順で検索する必要があります。

最初のステップは、セグメント ファイルを見つけることです。図 1 を例にとると、00000000000000000000.index は最初のファイルを表し、開始オフセットは 0 です。2 番目のファイル 000000000000000368769.index の開始オフセットは 368770 = 368769 + 1 です。同様に、3 番目のファイル 000000000000000737337.index の開始オフセットは 737338 = 737337 + 1 であり、後続のファイルについても同様です。これらのファイルは開始オフセットによって名前が付けられ、並べ替えられます。ファイルリストをオフセットに従ってバイナリ検索する限り、特定のファイルをすばやく見つけることができます。オフセット=368776の場合、00000000000000368769.index|logに移動します。

2 番目のステップ (図 2) は、セグメント ファイルを通じてメッセージを検索することです。セグメント ファイルは最初のステップで見つかります。 offset = 368776 の場合、000000000000000368769.index のメタデータの物理的な場所と 000000000000000368769.log の物理オフセット アドレスが順番に配置されます。次に、オフセット = 368776 になるまで、00000000000000368769.log が順番に検索されます。

これを行う利点は明らかです。セグメント インデックス ファイルはスパース インデックス ストレージを採用しており、インデックス ファイルのサイズが削減され、mmap を介してメモリ上で直接操作できます。スパース インデックスは、データ ファイル内の対応する各メッセージのメタデータ ポインターを設定します。高密度インデックスよりも多くのストレージスペースを節約できますが、検索に時間がかかります。

[[347742]]

この記事はWeChatの公開アカウント「朗江ビッグデータ雑談」から転載したものです。下のQRコードからフォローできます。この記事を転載する場合は、朗江チャットビッグデータ公式アカウントまでご連絡ください。