はじめに
現代のデータ処理において、データ湖屋（Data Lakehouse）は構造化データと非構造化データを統合的に管理するための重要なアーキテクチャとして注目されています。特に、Exabyte（10^18バイト）規模のデータを効率的に処理するためには、高スケーラビリティ、高性能、そして統一されたセキュリティガバナンスが不可欠です。本記事では、Apache OzoneとIcebergがどのようにこれらの要件を満たし、Exabyte規模のデータ湖屋を実現するかを解説します。
データ湖屋の定義と要件
データ湖屋は、データ倉庫の統一されたメタデータ管理とデータ湖の柔軟なストレージ機能を組み合わせたアプローチです。これにより、構造化データ（例：データベーステーブル）と非構造化データ（例：PDF、畫像、動畫）を統合的に管理できます。その核心的な要件は以下の通りです：
- コスト効率：Exabyte規模のストレージを最適化し、計算とストレージの分離を実現
- 多様なデータサポート：構造化データと非構造化データの両方をサポート
- 統一されたセキュリティガバナンス：Kerberos認証、Rangerによるアクセス制御、Bucket層での暗號化
- 高可用性と拡張性：並行アクセス、データ取引、S3 APIとHDFS APIの多協議サポート
- 高速クエリ性能：Hive、Spark、Impalaなどの大規模分析ワークロードへの対応
Apache Ozoneの特徴と優位性
Apache Ozoneは、データ湖屋のストレージレイヤーとして設計された高スケーラビリティなソリューションです。以下にその主な特徴を紹介します。
可擴展性
- 100億アイテムのストレージサポート：メタデータ空間が4TBに達し、Exabyte規模のデータを処理可能
- ストレージコンテナ設計：5GBのサイズ制限でブロックマッピングの階層抽象を実現
性能最適化
- 原子的なリネームと削除操作：HiveやSparkなどの分析エンジンの性能向上
- SSDでのメタデータストレージ：HDFSに比べて復舊時間が短縮
- S3 APIとHDFS APIの両方の互換性：既存のツールチェーンとの統合
高可用性
- Raftプロトコルによる三重複製：外部依存なしの自己管理メタデータ一貫性
- スナップショットとタイムトラベル：データバージョン管理の実現
データの整合性とセキュリティ
- Erasure Codingと三重アプリケーション：データの信頼性確保
- ACLとKerberos認証：靜的暗號化と転送暗號化のサポート
Ozoneのアーキテクチャ進化と技術的違い
HDFSからOzoneへの移行
- メタデータ管理の分離：FS ImageをOzone Managerに移し、ブロックマッピングをStorage Containerに委譲
- ブロックストレージの最適化：ブロックマッピングの抽象階層を向上させ、HDFSのブロック數制限（1000萬ブロック）を迴避
- 分散設計：ZooKeeper依存の削除と、自己管理のメタデータ一貫性の実現
主な技術的違い
- メタデータストレージ：HDFSのNameNodeメモリストレージ → OzoneのSSDストレージによる拡張性向上
- ブロック管理：HDFSのブロックマッピング → OzoneのStorage Container抽象による大規模データセットへの対応
- 一貫性プロトコル：HDFSのZooKeeper + Journal Node → OzoneのRaftプロトコルによるアーキテクチャの簡素化
IcebergとOzoneの統合
メタデータ最適化
- Icebergのメタデータストレージ：Ozoneに統合し、クエリ範囲制限（Data File Range）によるクエリ性能の向上
- タイムトラベル：複數データセットのバージョン管理を可能に
移行と適用場面
- 既存ワークロードの移行：アプリケーションの大幅な変更なしにOzoneへの移行
- 多協議サポート：S3 APIとHDFS APIの併用により、分析エンジン（HDFS協議）とBIツール（S3 API）の統合
実踐例とデモ
Exabyte規模クラスタのシミュレーション
- Ozoneストレージレイヤーの拡張性と性能の検証：5,000ノードのシミュレーションで1 Exabyte規模のデータを生成
- ワークロードテスト：SparkやHiveなどのツールがOzone上で実行される性能の検証
- 移行戦略：データのOzoneへの移行手順とベストプラクティスの提示
技術アーキテクチャと拡張性
- 10倍の拡張性：ストレージコンテナを複製単位として、HDFSのブロック管理を代替し、10倍のスケーラビリティを実現
- NameNode依存の削除：Journal NodesとZooKeeperの依存を除去し、Raftプロトコルによるメタデータの一貫性管理
- ストレージコンテナ管理：ストレージコンテナマネージャー（SCM）がキャッシュと狀態管理を行い、クライアントはOzone Managerを通じてデータノード情報を取得
S3サポートとメタデータ管理
- S3ゲートウェイ：AETトランスレートレイヤーによりRESTfulな無狀態S3ゲートウェイを提供
- メタデータ構造：Volumes（S3のBucketに類似）、Buckets（オブジェクトストレージとファイルシステム最適化の2モード）、ファイルシステム最適化Bucket（HDFSのディレクトリ構造）、オブジェクトストレージBucket（フラットなKey空間）
データエンジニアリングとストレージ最適化
- ストレージノード規模：RocksDBのOff-HeapストレージによりNameNodeのHeap使用量を削減し、起動時間を短縮
- データ移行戦略：Hadoop DistCpやカスタムソリューションによるデータ移行、S3互換インターフェースでの既存HDFSやクラウドストレージとの統合
Icebergと大規模分析
- IcebergとOzoneの統合：IcebergのOpen TableフォーマットによりPB規模の分析をサポート、Hive Metastoreなどの外部ディレクトリサービスを必要としない
- 特徴：隠蔽パーティション、スキーマ進化、タイムトラベル、データ圧縮、トランザクションサポートにより、データの重複書換えなしに更新やマージ操作を実現
模擬テストと規模検証
1EB規模のデータシミュレーション
- 5,000ノードのシミュレーション：40,000ストレージコンテナ（各5GB）で1 Exabyteのデータを生成
- Recon監視ツール：69億コンテナ、5,000ノード、各ノード200TBのデータを監視
- SCMメモリ使用量：140-150GBで1EBデータを処理、CPU使用率平均15%未満
- ハートビートメッセージ：毎分10,000件、コンテナレポート毎分35件、20時間で40,000件のコンテナレポートを累積
ワークロードデモ
- Icebergによるテーブル作成：単一の日付フィールドから複合パーティション（アプリケーション名を含む）への進化
- タイムトラベル機能：特定の時間點（例：1分前）へのデータ狀態の戻し、未完全読み込み時のクエリ結果行數の減少
- Spark計算クラスタ：PythonスクリプトによるSpark SQLタスクの実行、データの即時挿入とクエリ結果の可用性、Ozone內のデータとメタデータディレクトリ構造の可視化
結論
IcebergとOzoneの統合により、Exabyte規模のデータ処理が可能となり、高スケーラビリティ、高性能、柔軟なデータ管理が実現されています。データ湖屋の実裝において、これらの技術はコスト効率とセキュリティを両立させ、大規模な分析ワークロードに対応するための強力な基盤となります。