データレイクをオンラインサービスとして使う時代へ
多くの企業がデータレイクに膨大なデータを蓄積していますが、オンラインサービスやAIエージェントが特定のユーザーデータを低レイテンシで参照する必要がある場合、データレイクは必ずしも適していませんでした。分散SQLエンジン(TrinoやBigQuery)は、単一行のルックアップでも数秒のスケジューリングとクエリプランのオーバーヘッドが発生します。
Spotifyはこの問題を解決するために、RAP(Random Access Parquet) という独自のアプローチを開発しました。本記事ではRAPの核心的なアイデアと、データレイクをオンラインサービスとして活用するための実践的な手法を解説します。
なぜ従来の方法は遅いのか？
Spotifyの例を考えてみましょう。AIエージェントが「去年の夏、何を聴いていた？」という質問に答える必要があるとします。ユーザーの再生履歴は、数十億人のデータを含む大規模なファイル群です。1日1,000ファイル生成されるとすると、夏の90日間で約90,000個のParquetファイルが生成されます。
従来の方法では、特定のユーザーのデータを見つけるために各ファイルを開く必要があります。パーティショニングやブルームフィルタ(Bloom Filter)で候補ファイルを減らすことはできますが、ファイル内のデータを特定するには複雑な読み取りチェーンが必要です。ファイルのフッターを読み取り、行グループメタデータを解析し、キー列をスキャンし、ページインデックスを確認するなど、依存的な読み取りチェーンが発生します。このチェーンの各ステップは、クラウドストレージへの個別のラウンドトリップを必要とし、レイテンシとコストを増加させます。
RAPの核心: 外部インデックスで依存的な読み取りを排除
RAPの核心は**外部インデックス(external index)**です。このインデックスは、各キーを特定のファイルと行番号に直接マッピングします。キーが与えられると、インデックスを参照して正確なファイルと行を取得し、キャッシュされたファイルメタデータを使用してページ位置を特定し、必要なバイトだけを正確に読み取ります。このプロセスはもはや依存的な読み取りチェーンではなく、並列実行可能な精密な範囲読み取りです。
インデックスはマルチマップ形式で、1つのキーが複数のファイルやパーティションに存在することができます。各エントリは、キー、ファイル、行番号、値の数(オプション)で構成されます。概算として、テラバイト規模のデータをインデックス化すると、ギガバイト規模のインデックスが生成されます。
この外部インデックスは、Parquetの標準機能であるPageIndexやブルームフィルタとは異なります。それらは確率的でスキャン範囲を絞り込むだけですが、外部インデックスは決定的です。キーが与えられると、正確なファイルと行を返すため、スキャン自体を排除します。
主要な最適化テクニック3つ
RAPは変更されていない既存のParquetファイルでも動作しますが、書き込み時にファイルを準備することでより大きな効果が得られます。最適化は主に3つのカテゴリに分けられます: キーデータの集中、読み取りバイトの削減、読み取り操作の削減。
1. キーデータの集中
- キーによるソート: ファイル内で同じキーのすべての行が連続するようにソートします。多くのパイプラインはすでにソートされた出力を生成しています。
- ハッシュバケッティング: Spark、Scio SMB、Iceberg bucket transformを使用すると、各キーがパーティションごとに1つのファイルに決定的にマッピングされます。
- 共同グループ化: スキーマを設計して、各キーが1回だけ出現し、値が繰り返しまたはネストされた列に配置されるようにします。例:
SELECT user_id, ARRAY_AGG(STRUCT(timestamp, track_uri, duration_ms)) FROM streams GROUP BY user_id - より粗いパーティショニング: 日次パーティショニングの代わりに週次パーティショニングを使用すると、キーがまたがるファイル数が減ります。
2. 読み取りバイトの削減
- キーごとに1ページ: キーが変わるたびにページを分割して書き込みます。ページ全体を読み取るだけでそのキーのデータを取得できます。この場合、ページ位置をインデックスに直接格納できます。
- ZSTDフレームリセット: キーごとにデータを個別のZSTDフレームとして圧縮します。インデックスには各フレームのオフセットとサイズを格納します。ただし、デルタエンコーディングや実行長エンコーディングは使用できません。
- ストレージアライメント: ZSTDスキッパブルフレームを使用してキー間にパディングを追加し、読み取りがストレージブロック境界をまたがないようにします。
3. 読み取り操作の削減
- BlobまたはVariantの単一列: JSON、Protobuf、Parquet Variantなど、ポイントクエリに必要なフィールドを1つの列に格納すると、ファイルごとに1回の読み取りで済みます。
- 列のインターリーブ: 複数の列を物理的に隣接させ、ZSTDスキッパブルフレームで列間を接続します。RAPリーダーは、キーに対するすべての列を1つの連続した範囲読み取りで取得できます。
- カバリングインデックス: インデックスビルダーはビルド時にすべての行を訪問するため、小さな値はインデックスエントリに直接ホイストして、ストレージ読み取りを完全に排除できます。
実際の適用における注意点と制限
RAPは非常に強力な技術ですが、いくつか注意点があります。
- インデックスサイズ: インデックスが大きくなると、追加のストレージコストが発生します。
- 書き込みの複雑さ: 書き込み時にファイルを準備するには、パイプラインの変更が必要です。
- 互換性: 一部の最適化は、既存のリーダーとの互換性の問題を引き起こす可能性があります。例えば、インターリーブされた列を読み取る通常のリーダーは、他の列のデータも読み取る必要があるため、I/Oが増加します。
- 分析ワークロードとのトレードオフ: 一部の最適化は、分析クエリのパフォーマンスを低下させる可能性があります。例えば、Blobとして保存すると、フィールドごとのプルーニングが不可能になります。
まとめと次のステップ
RAPの最大の利点は、既存のデータレイクのParquetファイルをそのまま使用できることです。別のコピーやETLは不要です。これにより、オンラインサービスで使用できるデータの範囲が劇的に拡大します。AIエージェントは、数ヶ月前、数年前のデータを含むデータレイク全体をコンテキストとして使用できるようになります。
RAPを実際に適用してみたい場合は、まずデータレイクのポイントクエリパターンを分析し、どの最適化テクニックが最も効果的かを判断してください。データレイクインデックスの原文を参照すると、より詳細な技術情報を確認できます。また、SageMaker AIデータ漏洩防止、3層アーキテクチャで80%のコスト削減を実現した実践ガイドなどの資料から、データレイクのセキュリティとコスト最適化に関する洞察も得られます。
あわせて読みたい
