ファイルストレージメカニズム
1. トピックデータの保存機構
トピックは論理的な概念、パーティションは物理的な概念であり、各パーティションはログ ファイルに対応し、ログ ファイルにはプロデューサーによって生成されたデータが保存されます。プロデューサーによって生成されたデータは、ログ ファイルの末尾に継続的に追加されます。ログ ファイルが大きくなりすぎてデータの場所の効率が低下するのを防ぐために、Kafka はシャーディングおよびインデックス作成メカニズムを採用して、各パーティショナーを複数のセグメントに分割します。各セグメントには、「.index」ファイル、「.log」ファイル、timeindex およびその他のファイルが含まれます。これらのファイルは、Xia フォルダーにあります。このフォルダーの命名規則は、トピック名 + パーティション番号です。例: first- 0 1. トピックは
複数のパーティションに分割されます
2、パーティションは複数のセグメントに分割されます
3、.log ログ ファイル
4、.index オフセット インデックス ファイル
4、.timeindex イベント インデックス ファイル
その他のファイルの
説明: インデックス ファイルとログ ファイルは、以下に基づいています。現在のセグメント名の最初のメッセージのオフセット
2. 考える: トピック データはどこに保存されますか?
データフォルダーに存在します。ここがインストールパスにあります
cat cat 00000000000000000000.log
文字化けは
インデックスやログなどの情報を閲覧するツールを使用する必要がある
kafka-run-class.sh kafka.tools.DumpLogSegments --files 00000000000000000000.index
3. インデックスファイルとログファイルの詳細説明
1. ターゲット オフセットに従ってセグメント ファイルを見つけます
。 2. ターゲット オフセット以下の最大オフセットに対応するインデックス項目を見つけます。
3. ログ ファイルを見つけます
。 4. 下にたどってターゲット レコードを見つけます
。 注:
1.インデックスはスパース インデックスであり、ほぼすべてのログ ファイルです。4kb データを書き込むと、インデックスがインデックス ファイルに書き込まれます。
2. インデックス ファイルに保存されるオフセットはオフセットに相対的なものであるため、オフセット値が占めるスペースが大きくなりすぎないことが保証され、オフセット値を固定サイズに制御できます。
| パラメータ | 説明 |
|---|---|
| ログセグメントバイト | Kafka のログはブロックに分割されて保存されます。この構成はログのログ分割のサイズを指します。デフォルトは 1G です。 |
| log.index.interval.bytes | デフォルトは 4kb です。Kafka は注文ごとに 4KB のログ (.log) を書き込み、インデックス ファイルにインデックス (スパース インデックス) を記録します。 |
4. ファイルのクリーンアップ戦略
Kafka のデフォルトのログ保存イベントは 7 日です。次のパラメータ log.retention.hours を調整することで保存時間を変更できます。
最も低い優先順位は時間で、デフォルトは 7 日です
。 log.retention. minutes、
log.retention。 ms、最も高い優先順位はミリ秒です
log.retention.check.interval.ms はチェック期間の設定を担当し、デフォルトは 5 分です。
では、ログが設定時間を超えた場合、どのように対処すればよいでしょうか?
Kafka で提供されるログ クリーニング戦略には、削除と圧縮の 2 種類があります
。1) ログの削除: 期限切れのデータを削除します。
log.cleanup.policy = すべてのデータを削除します。
時間に基づいて削除戦略を有効にします。デフォルトでオープンします。セグメント内のすべてのレコードの最大タイムスタンプをファイルのタイムスタンプとして使用します
サイズに基づいて: デフォルトで無効になっており、すべてのログの合計サイズを超えると、最も古いセグメントが削除されます (log.retention.bytes、
by -1に等しい)デフォルトは無限を意味します。
セグメント内の一部のデータが期限切れで、一部のデータが期限切れになっていない場合、どのように対処すればよいでしょうか?
2) コンパクトなログ圧縮
コンパクトなログ圧縮: 同じキーの異なる値の場合、値の最新バージョンが保持されます
log.cleanup.policy = Compact したがって、
圧縮ポリシーが有効になった後のすべてのデータのオフセットは次のようになります。これらのオフセットからメッセージを受信すると、このオフセットより大きいオフセットに対応するメッセージが取得されます。実際には、オフセット 7 のメッセージが取得され、この位置から消費が開始されます。
この戦略は、特殊なシナリオにのみ適しています。たとえば、メッセージのキーはユーザー ID で、値はユーザーの情報です。この圧縮戦略を通じて、すべてのユーザーの最新情報がメッセージ セット全体に保存されます。