スキーマオンライト

データを格納する前にスキーマ（構造の定義）を決め、それに合うよう変換・検証してから書き込む方式。リレーショナルデータベースやデータウェアハウスで採られ、データの品質と問合せの性能を確保しやすいが、新しい種類のデータを取り込むにはスキーマの設計変更が要る。

データソースから抽出（Extract）したデータを、変換せずにまずデータレイクやクラウド型のデータウェアハウスに格納（Load）し、格納先の処理能力を使って必要に応じて変換（Transform）する方式。ETLと処理の順序が逆で、大量のデータを速く取り込め、元のデータを残したまま用途に応じた加工ができる。

データソースから抽出したデータを、変換せずにいったんデータレイクやクラウドDWHに格納（Load）し、格納先の計算資源を使ってSQLなどで変換（Transform）する方式。生データが残るので後から別の目的で変換し直せ、MPPやストレージとコンピュートの分離による拡張性を生かせる。格納前に変換するETLと処理の順序が逆になる。

構造化データに加え、ログ、JSON、画像、音声などの半構造化・非構造化データを、加工せずに元の形式のまま大量に蓄積するリポジトリ。スキーマオンリードで利用時に構造を解釈するため、用途を決めずに取り込めて機械学習の素材にもなるが、メタデータやデータカタログで管理しないと中身の分からないデータスワンプになる。

複数の業務システムのデータを、分析しやすいように主題別に統合・整理して時系列で蓄積するデータベース。履歴を保持し、原則として更新せずに追記していく点が業務システムのデータベースと異なる。スキーマオンライトで事前に構造を定めるため、品質の揃ったデータを全社で横断的に集計・分析するのに向く。

DWHのデータから、特定の部門や用途に必要なものだけを抽出・集計して切り出した小規模なデータベース。利用者が扱うデータを絞り、目的に合わせた形に整えておくため、BIツールでの集計や定型レポートを高速に行える。

データレイクの安価なオブジェクトストレージの上に、DWHが持つトランザクション管理（ACID特性）、スキーマの管理、高速な検索などの機能を加えたデータ基盤のアーキテクチャ。Delta Lake、Apache Icebergなどのオープンなテーブル形式を使い、1つの基盤でBIの集計と機械学習の両方に同じデータを使えるようにする。