従来のデータテーブルの課題

1. 原子性の欠如（部分的な書き込み）

クラスターが50,000件の新しいダイヤモンドレコードを書き込んでいる途中で、停電やネットワーク障害が発生したと想像してください。

結果: 「破損した」ファイルが出来上がります。データの半分は存在し、半分は欠落しており、分析結果は永久に誤ったものになります。従来のファイルには「すべてかゼロか」のルールがありません。

2. スキーマ強制の欠如

従来の環境では、ユーザーが「Price」に数値ではなくテキスト（例：「Expensive」）を誤ってアップロードしても、何も防止されません。

結果: 次に合計や平均を計算しようとすると、「計算」がテキストを処理できないため、パイプライン全体がクラッシュします。生ファイルは「サイレントフェイル」— 不正なデータもエラーなく受け入れてしまいます。

3. 「二人の料理人」問題（同時実行性）

異なる2人のデータエンジニアが、まったく同じタイミングでDiamondsテーブルを更新しようとした場合、どうなるか。

結果: 一方の変更がもう一方の変更を上書きするか、ファイルがロックされて使用できなくなる可能性が高い。従来のファイルシステムは、複数のユーザーが同時に同じデータを読み書きすることを想定して設計されていない。

4. 「元に戻す」ボタンがない

誤ってすべての「Premium」カットのダイヤモンドをデータセットから削除するコマンドを実行した場合、そのデータは失われる。標準的なファイルシステムには、5分前のテーブルの状態を確認できる「履歴」や「元に戻す」ボタンは備わっていない。

進化：Delta Lakeが必要な理由

これらの問題により、企業はData Lakes（単なるファイルのフォルダ）からLakehouseへと移行している。

これらの課題を解決するために、DatabricksはDelta Lakeを開発した。Delta Lakeはファイルに「トランザクションログ」を追加し、次のような高度な会計士の役割を果たす：

• すべての変更を記録する；
• 不正なデータの混入を防ぐ；
• ミスが発生した場合、過去のバージョンに「タイムトラベル」できる。