Data Lake Formation:DLF とセルフマネージド FileSystem カタログの比較

FileSystem カタログ：軽量だが本番環境には不向き

FileSystem カタログは、warehouse/dbName.db/tableName のようなディレクトリ構造を使用してテーブルのメタデータを整理します。

ただし、次のような主な制限があります：

• 安全でない同時書き込み：オブジェクトストレージの名前変更操作に依存してコミットをシミュレートします。これらの操作はアトミックではないため、同時書き込み中にデータ損失が発生しやすくなります。

• コンパクションの分離が不可能：一元化されたメタデータ調整機能がないため、コンパクションを書き込みジョブに組み込む必要があり、書き込みリソースを消費し、安定性に影響を与えます。

• 非効率なテーブルライフサイクル操作：テーブルの作成、削除、または名前変更には多数のファイルを走査する必要があり、時間がかかり、失敗しやすくなります。

• 低いメタデータ取得性能：すべてのメタデータ取得はオブジェクトストレージのリスト操作に依存しており、大規模なテーブルでは高レイテンシーと高コストの原因となります。

• UI またはガバナンス機能の欠如：監視、ストレージ概要、アクセス制御、ホット/コールドデータ階層化などの本番環境レベルの機能がありません。

DLF REST カタログ：フルマネージドのメタデータエンジン

Apache Paimon のオリジナルチームが作成した DLF REST カタログは、独立した REST サービスを通じてメタデータ管理を一元化します。コンピューティングとストレージを分離し、大規模で高信頼性の本番環境向けに特別に設計されています。

主なメリットは次のとおりです：

安全性と同時実行性の高い書き込み

• FileSystem カタログ
  オブジェクトストレージはアトミックコミットをサポートしていません。複数の書き込みジョブが同時に同じテーブルを操作すると、ファイル名の変更が競合し、データ損失を引き起こす可能性があります。
  この制約により、コンパクションを書き込みジョブに組み込む必要があり、分離が不可能になり、書き込みの安定性とリソース計画に大きな影響を与えます。
  
  
  
  
  

• DLF REST カタログ
  すべての書き込みは REST インターフェース経由で送信され、メタデータが信頼できる唯一の情報源として機能するため、本質的に同時書き込みの安全性が保証されます。
  コンパクションなどのメンテナンスタスクは、フルマネージドの DLF サービスがバックグラウンドで 自動的に実行します。これらはデフォルトで書き込みジョブから分離されており、安定した効率的な書き込み操作を保証します。
  
  
  
  
  

ストレージの完全自動最適化

• FileSystem カタログ
  コンパクションとクラスタリングは書き込みジョブに組み込む必要があります。
  
  

  • ポリシーの調整は、書き込みジョブの安定性に直接影響します。

  • 頻繁な障害を避けるために、リソースを過剰にプロビジョニングする必要があることが多く、無駄が生じます。

  • 固定バケッティングのみがサポートされています。バケットが少なすぎると書き込みのボトルネックが発生し、多すぎると多数のスモールファイルが生成されるため、パフォーマンスとコストのバランスを取ることが困難です。

• DLF REST カタログ
  フルマネージドの DLF サービスがストレージの最適化を処理し、書き込みジョブから完全に分離します。
  
  

  • コンパクション、クラスタリング、有効期限切れパーティションの処理、有効期限切れスナップショットの処理など、複雑なタスクを自動的に管理します。

  • 遅延バケッティングと適応型マージ を提供し、ユーザーがパラメータを事前に設定したり、リソースを割り当てたりする必要をなくします。

  • バックグラウンドマージはマルチモードスケジューリングをサポートし、ネイティブテクノロジーで高速化されています。

メタデータとパスの分離

• FileSystem カタログ
  テーブルのパスとメタデータは密結合しています。DROP TABLE または RENAME を実行すると、システムはすべてのデータファイルを走査し、個別に削除または移動する必要があります。このプロセスは低速で、特に大規模なテーブルでは失敗しやすくなります。
  
  

• DLF REST カタログ
  メタデータは物理パスから分離されています。DROP TABLE および RENAME 操作はメタデータレコードを更新するだけであり、ミリ秒単位で完了します。これは軽量で信頼性が高く、古いテーブルの残存ファイルが新しいテーブル構造に干渉するのを効果的に防ぎます。
  
  

標準 REST プロトコル

• FileSystem カタログ
  メタデータはファイルシステムのディレクトリ構造に保存されます。メタデータを取得するには、オブジェクトストレージのリスト操作を呼び出してファイルを走査する必要があります。このプロセスは高レイテンシー、高コストであり、基盤となるストレージへの強い依存性がスケーラビリティを制限します。
  
  

• DLF REST カタログ
  標準的でオープンな REST プロトコルを通じてメタデータの読み取りおよび書き込みサービスを提供し、軽量で高速なインターフェースを提供します。オープンソースの Java および Python SDK をサポートしているため、簡単な 多言語統合 が可能になり、ビジネスの複雑さを軽減します。
  
  

可視化と可観測性

• FileSystem カタログ
  グラフィカルインターフェースがありません。すべてのテーブル情報 (行数、ファイル数、ストレージサイズなど) とストレージ概要は、ファイルシステムを手動で走査して取得する必要があります。このプロセスは面倒で時間がかかり、テーブルのステータスをリアルタイムで把握することが困難です。
  
  

• DLF REST カタログ
  テーブルとパーティションのコアメトリクス (行数、ファイル数、総ストレージサイズなど) をリアルタイムで表示する統合コンソールを提供します。また、包括的なストレージ概要を自動的に生成します。
  
  

  • 概要には、現在のテーブルのすべてのバージョンの物理ストレージデータが含まれます。

  • これにより、スモールファイルや冗長なスナップショットなどの潜在的な問題を迅速に特定し、効率的な最適化の決定を下すのに役立ちます。

エンタープライズレベルのアクセス制御

• FileSystem カタログ

  アクセス制御は、基盤となるファイルシステムのアクセス制御リスト (ACL) に依存しており、ディレクトリやファイルへの読み取りおよび書き込みアクセスしか制御できません。テーブルレベルまたは列レベルの権限をサポートしていないため、企業のデータセキュリティおよびコンプライアンス要件を満たすことが困難です。

• DLF REST カタログ

  メタデータに基づいたきめ細かなアクセス制御を提供します。この機能は、テーブルレベルおよび列レベルの権限付与をサポート し、プロジェクトやチーム間での 安全なテーブル共有 を可能にすることで、企業のガバナンス要件を満たします。

ホット/コールドデータ階層化

• FileSystem カタログ

  階層化ポリシーはファイルレベルで動作し、ファイルの変更時刻に依存します。これはビジネスロジックと整合しないため、誤ったデータ階層化や重要なデータの欠落を引き起こしやすくなります。

• DLF REST カタログ

  テーブルレベルおよびパーティションレベルの階層化ポリシーをサポート し、ビジネスセマンティクスに従ってデータライフサイクルを正確に制御します。これにより、ホットデータには高性能を、コールドデータには低コストを確保し、効率とセキュリティのバランスを取ります。