Delta Lakeとは

2016年にDatabricksによって最初に開発されたDelta Lakeは、オープンテーブル形式であり、既存のファイル形式の上にメタデータ層を構築するオープンソースの表形式データ向けフレームワークです。Delta Lakeは、データ・ストレージにParquetテーブルを使用します。その他のオープン・テーブル形式には、Apache IcebergやApache Hudiがあります。

メタデータ層により、Delta Lakeやその他のオープン・テーブルは、検索クエリーの最適化や、多くの標準的なテーブル形式では対応できない高度なデータ・オペレーションをサポートできます。組織は、データレイクをより信頼性が高く直感的にするために、Delta Lakeを活用することがよくあります。

Delta Lakeの誕生は、データレイクのストレージとデータウェアハウスの性能を組み合わせたデータレイクハウス・アーキテクチャーの発展において、クリティカルな一歩となりました。

Delta Lakeとデータレイクはよく一緒に語られますが、これらのテクノロジーはそれぞれ異なるものであることを理解することが重要です。

データレイクは、あらゆるデータの種類や形式に対応し、大規模なデータセットを処理できるよう設計された、低コストのデータ・ストレージ環境です。ほとんどのデータレイクは、Amazon Simple Storage Service（S3）、Microsoft Azure Blob Storage、またはIBM® Cloud Object Storageなどのクラウド・オブジェクト・ストレージ・プラットフォームを利用しています。

Delta Lakeは、組織がデータレイクやその他のデータ・ストアで使用できる表形式のデータ・ストレージ形式です。

Delta Lakeはデータレイクの一種でも、その代替でもありません。むしろ、データレイクが「どこ」であるのに対し、Delta Lakeは「どのように」であると考えることができます。

• データをどこに保管していますか。データレイク内。
• データはどのように保管されていますか。Delta Lakeのテーブルとして。

Delta Lake形式は、データレイクをより管理しやすく、効率的にするのに役立ちます。

データレイクには多くのメリットがありますが、通常、組み込みのデータ品質管理機能がなく、データレイクへの直接クエリーは困難です。そのため、組織はしばしばデータレイクからデータを取り出し、クリーンアップを行い、使用可能にする前に、別のデータウェアハウスやデータ・マートにロードする必要があります。

メタデータ層を導入することで、Delta Lakeは組織に対し、スキーマの適用、変更の追跡とロールバック、ACIDトランザクションのサポートを可能にします。

ユーザーは、データレイク上で直接、構造化クエリー言語（SQL）のクエリー実行、分析ワークロードの処理、その他の作業を行うことができ、Business Intelligence（BI）、Data Intelligence（DI）、人工知能（AI）、機械学習（ML）の効率化を実現します。

Delta Lakeには2つのコアコンポーネントがあります。それは、データを含むデータファイルと、これらのデータファイルに関するメタデータを格納するトランザクションログです。

• Delta Lakeのデータファイルは「Delta Lakeテーブル」または「Deltaテーブル」と呼ばれ、列指向のParquetファイル形式を使用します。
  
  
• トランザクション・ログは、最近の活動をJSONログ・ファイルに保管し、古いメタデータをParquetファイルにアーカイブします。このログは、データ・ファイルとともにデータレイクに保管されます。

トランザクション・ログは、データ・ファイルに関する情報（例えば、列名や最小値・最大値）と、ファイルに加えられた変更（変更内容、変更日時、変更方法、変更者）を記録します。

このログが、Delta Lakeを標準的なParquetファイルと異なるものにしています。トランザクション・ログは本質的に管理層として機能し、データレイク内のすべての活動に対する指示セットとして作用します。これにより、ACIDトランザクション、タイム・トラベル、スキーマ進化などの主要な機能が実現されます。

通常のParquetファイルは不変であり、一度作成されると変更することはできません。書き換えのみが可能です。Delta Lakeのトランザクション・ログは、物理的なアクション（データに直接行われたアクション）と論理的なアクション（メタデータに対して行われたアクション）を分離することで、Parquetファイルを実質的に、もしも文字通りではなくとも、変更可能にします。

例えば、ユーザーはParquetテーブルから単一の列を削除することはできません。その場合、ファイル全体を書き換える必要があります。一方、Delta Lakeでは、テーブルのメタデータを変更してその列を削除済みとしてマークすることで、実質的にその列を削除できます。列はファイル内に残りますが、その後のすべてのクエリー、更新、書き込みはメタデータを参照し、列を存在しないものとして扱います。

「ACID」は「原子性、一貫性、独立性、耐久性」を意味し、信頼性の高いデータ・トランザクションの重要な特性です。

• 原子性とは、データへのすべての変更が単一のオペレーションとして実行されることを意味します。
  
  
• 一貫性とは、トランザクションが開始される時と終了する時にデータが一貫した状態であることを意味します。
  
  
• 分離性とは、トランザクションの中間状態が他のトランザクションから見えないことを意味します。
  
  
• 耐久性とは、データへの変更が永続的であり、元に戻されることがないことを意味します。

StandardデータレイクはACIDトランザクションをサポートできません。ACIDの保証がない場合、データレイクはトランザクションの失敗や部分的な書き込み、その他の問題によりデータが破損する可能性があります。

Delta Lakeのトランザクション・ログは、ACIDの原則に従ってトランザクション情報を記録できるため、データレイクはストリーミングデータ・パイプライン、Business Intelligence、分析、その他のユースケースにおいて、より信頼性の高いものになります。

管理者はトランザクション・ログでスキーマの要件を設定でき、これらの要件はデータの取り込み時にすべてのデータに適用されます。スキーマの要件を満たさないデータは拒否されます。

管理者はトランザクション・ログを使用して、既存のファイルのスキーマを変更することもできます。例えば、新しい列を追加したり、列の型を変更したりすることができます。このプロセスは「スキーマの進化」と呼ばれます。

トランザクション・ログは従来のインデックスではありませんが、クエリーがデータをより速く効率的に取得するのに役立ちます。

例えば、ユーザーがある列で特定の値を検索しているとします。トランザクション・ログのメタデータを使用することで、ユーザーのクエリーはターゲット値が存在し得ないファイルをスキップできます。最小値がターゲット値より高い場合や、最大値がターゲット値より低い場合、そのファイルをスキップすることができます。

トランザクション・ログには、ファイル・パスも保管されます。データレイク全体をスキャンする代わりに、クエリーはこれらのファイルパスを使用して、関連するファイルに直接アクセスすることができます。

Delta Lakeは、Zオーダリングのような技術を使用して、似たデータをディスク上で近くに保管することができます。これにより、関連性のないファイルをスキップし、関連するファイルを見つけやすくなります。

通常のParquetファイルは不変ですが、ユーザーはメタデータ層を通じてDeltaテーブルを操作することができます。Delta Lakeは、列の追加や削除、エントリーの更新、ファイルのマージなど、あらゆる種類のデータ・オペレーションをサポートしています。

トランザクション・ログはDeltaテーブルで発生したすべてのイベントを記録するため、各テーブルのバージョン履歴を事実上維持します。ユーザーは過去のバージョンをクエリーしたり、「タイム・トラベル」、つまり変更をロールバックして以前のテーブル・バージョンを復元したりすることができます。

Delta Lakeには堅牢なコネクターのエコシステムがあります。この形式は、Apache Spark、Apache Hive、Apache Flink、Trinoなど、さまざまなコンピュート・エンジンで使用できます。Delta Lakeには、Python、Java、Scalaなどの言語向けのアプリケーション・プログラミング・インターフェース（API）が用意されており、開発者はプログラムでDeltaテーブルを管理し、クエリーを実行できます。

Delta Lakeはネイティブにセキュリティ制御を強制するわけではありませんが、データ・セキュリティーやデータ・ガバナンスのツールと統合できますこれらのツールは、トランザクション・ログのメタデータを活用して、アクティビティの監査、変更の追跡、およびロールベース・アクセス制御（RBAC）ポリシーの適用を行うことができます。

Delta Lakeはストリーミング・データとバッチ・データの両方を受け入れることができ、Deltaテーブルから接続されたサービスへデータをストリームまたはバッチで送信できます。

次のメジャー・リリースであるDelta Lake 4.0では、以下のような主要な機能の追加が予定されています。

• 複数のテーブルや複数のエンジンからの書き込みを一度に行うプロセスを効率化するための調整されたコミット。
  
  
• 従来のテーブル形式では保存が難しい半構造化データを保管するための新しい「バリアント」データ型。
  
  
• 列のデータ型を変更できるようにする型の拡大。

Apache Icebergは、大規模な分析テーブル向けの高性能なオープンソース形式です。Delta Lakeと同様に、Icebergは既存のテーブル形式の上にメタデータ層を構築し、ACIDトランザクションやその他のオペレーションをデータレイクでサポートします。

IcebergはデータをParquet、ORC、Avroファイルに保管できるのに対し、Delta LakeはParquetのみを使用します。また、IcebergはDelta Lakeのような単一のトランザクション・ログではなく、三層構造のメタデータ層を採用しています

Icebergは多様なクエリー・エンジンとネイティブに統合されており、データレイクにおけるSQLベースの分析で一般的に選ばれる選択肢となっています。

Delta LakeやIcebergと同様に、Hudiもデータ層の上にメタデータ層を保持します。HudiはParquet、HFile、ORCのファイル形式を使用でき、そのメタデータ層は「タイムライン」という形をとり、データ層で発生するすべてのイベントを記録します。

Hudiは増分データ処理向けに設計されており、小規模なバッチデータを頻繁に処理します。この増分処理への特化により、Hudiはリアルタイム分析や変更データ・キャプチャー（CDC）の一般的な選択肢となっています。

Delta Lake形式の開発は、データレイクハウスの作成への道を切り開くのに貢献しました。

長らく、組織は主にデータウェアハウスでデータを管理してきました。データウェアハウスは分析やBIには有用ですが、厳格なスキーマを必要とします。そのため、非構造化データや半構造化データとの相性が悪く、組織がAIやMLへの投資を加速させる中で、これらのデータの重要性が増しており、課題となっています。

2010年代初頭にデータレイクが台頭したことで、組織はあらゆるデータ・ソースからあらゆる種類のデータを1つの場所に集約できるようになりました。

しかし、データレイクには独自の課題があります。品質管理が不十分であることが多く、ACIDトランザクションをサポートしておらず、直接クエリーを実行するのが容易ではありません

データを利用可能にするために、多くの組織は、データレイクからデータウェアハウスへデータを移動させるために、個別のETL（抽出・変換・ロード）データ・パイプラインを構築する必要がありました。

Delta Lakeは2016年に登場し、データレイクにACIDトランザクション、スキーマ強制、およびタイムトラベル機能を追加することで、直接のクエリーや分析に対してより信頼性の高いものにしました。

2019年にオープンソース化されたDelta Lakeは、データレイクの柔軟性とデータウェアハウスの性能を組み合わせたデータレイクハウス・アーキテクチャーの形成において重要な役割を果たした。

多くの組織は、既存のデータレイクの上にDelta Lakeのストレージ層を構築し、SparkやHiveなどのデータ処理エンジンと統合することで、データレイクハウスを構築しています。

データレイクハウスは、データレイクとデータウェアハウスを個別に管理する必要をなくし、データのサイロ化を防ぐことで、データ統合を支援し、データ・アーキテクチャーの効率化を促進します。

このように効率化されたアーキテクチャーにより、データサイエンティストやデータ・エンジニアをはじめとするユーザーが、必要なときに必要なデータへアクセスできるようになります。AIやMLのワークロードは、Delta Lakeを活用したデータレイクハウスの一般的なユースケースです。

データレイクは、それ自体でもこれらのワークロードに有用です。なぜなら、大量の構造化データ、非構造化データ、半構造化データを格納できるためです。

ACIDトランザクションやスキーマ強制といった主要な機能を追加することで、Delta Lakeは標準的なデータレイクでは実現できない方法で、トレーニング・データ品質と信頼性を確保するのに役立ちます。