Data Lake

データレイクは、データベースのエクスポートやJSONログから画像、動画、音声、文書まで、データを生のネイティブ形式のまま一元的に保存するリポジトリです。通常は低コストのクラウドオブジェクトストレージに保存し、データを読み取るときにのみ構造を適用します。当時Pentahoの最高技術責任者だったJames Dixonが、データマートを、精製して包装したボトル入りの水にたとえ、多くの利用者が自然な状態のまま利用できる大量のデータと対比するため、2010年にこの用語を作りました。事前にモデル化する必要がないため、データレイクには組織が収集したすべてのデータを保持でき、機械学習に適しています。明日のモデルのトレーニングデータは、保存時には用途が分からなかった生データであることがよくあります。

データレイクの仕組み#

データレイクではストレージとコンピューティングを分離します。ファイルはAmazon S3、Google Cloud Storage、Azure Data Lake Storageなどのオブジェクトストレージに置き、Spark、Trino、Pythonプロセスなどのエンジンが直接読み取るため、各チームはデータをコピーせずに独自のコンピューティングリソースを拡張できます。表形式データは通常、Apache Parquetなどのオープンな列指向形式で保存し、画像や動画は一般的なファイルとして保持します。多くの場合、メタデータやラベルを格納するJSONまたはParquetのマニフェストも併せて保存します。

ほとんどのデータレイクは、整備の度合いに応じたゾーンに分けて構成されます。Databricksがメダリオンアーキテクチャと呼ぶ方式では、raw（ブロンズ）ゾーンに受け取ったままのデータを、cleaned（シルバー）ゾーンに検証・重複排除済みデータを、curated（ゴールド）ゾーンにレポートやトレーニングにすぐ使えるテーブルやデータセットを格納します。AWS Glue Data Catalog、Hive Metastore、Unity Catalogなどのメタデータカタログには、各データセットの内容、所有者、読み取り権限を記録します。カタログとデータクリーニングのないデータレイクは「データスワンプ」に陥り、見つけられず、信頼できず、安全に削除できないファイルがあふれます。

読み取り時スキーマ#

データレイクではデータの読み取り時にスキーマを適用し、これを読み取り時スキーマ（schema-on-read）と呼びます。2つのソースでフィールドが一致しない場合でも、データが存在すればすぐに書き込め、読み取り側は必要な列と型をそれぞれ選択できます。この例では、異なるフィールドを持つ2つの生のJSONファイルを書き込み、Polarsを使って同じスキーマで両方を読み込みます。

import json
from pathlib import Path

import polars as pl

# Rawゾーン: 2台のカメラがそれぞれ独自のフィールドを持つ検出イベントをJSON Lines形式で書き込みます
Path("lake/raw").mkdir(parents=True, exist_ok=True)
Path("lake/raw/dock-1.jsonl").write_text(json.dumps({"label": "forklift", "conf": 0.91}))
Path("lake/raw/dock-2.jsonl").write_text(json.dumps({"label": "person", "conf": 0.62, "lux": 120}))

# 読み取り時スキーマ: この読み取り側は、ファイルをクエリするときに列と型を選択します
schema = {"label": pl.String, "conf": pl.Float32, "lux": pl.Int32}
events = pl.scan_ndjson("lake/raw/*.jsonl", schema=schema, include_file_paths="source")
print(events.collect())

結果には、label、conf、lux、sourceの列を持つ2行が含まれます。最初のカメラはluxを記録していないため、その値はnullとして返され、sourceには各行の読み込み元となった生ファイルが記録されます。別のジョブで、ファイルを書き換えずに異なるスキーマを使って同じファイルを読み込むこともできます。

データレイク、データウェアハウス、レイクハウスの比較#

• データウェアハウス: 固定スキーマに適合するよう、読み込み前（schema-on-write）にデータを整形します。通常は抽出、変換、ロード（ETL）の工程を経て、クリーンで構造化されたテーブルを保存します。Snowflake、BigQuery、Redshiftなどのデータウェアハウスは、SQLやビジネスインテリジェンスのクエリに高速で応答しますが、画像、テキスト、その他の非構造化データへの柔軟性は低くなります。
• データレイク: あらゆる形式のデータを低コストで保存し、読み込み後にデータを変換（ELT）するため、探索、データマイニング、機械学習に適しています。通常のデータレイクファイルにはトランザクション機能がないため、同時書き込みによって読み取り側が未完成の結果を参照する可能性があります。
• レイクハウス: Apache Iceberg、Delta Lake、Apache Hudiなどのオープンテーブル形式を介して、データレイクのストレージにデータウェアハウスの機能を追加します。これらの形式は、ACIDトランザクション、スキーマの適用、テーブルの過去のバージョンへのタイムトラベルを実現します。Databricksの研究者は、2021年の論文でこのアーキテクチャを説明しました。

機械学習におけるデータレイク#

コンピュータービジョンチームにとって、データレイクにはすべてのカメラフレーム、撮影時のメタデータ、アノテーション、そしてデプロイ済みモデルが生成した予測が格納されます。自動運転車の開発では、車両群の走行ログをアップロードしてマイニングし、雨の夜道を歩く歩行者などの希少なシーンを見つけ、ラベル付けしてトレーニングセットに追加します。医療では、1つのデータレイクに集めた匿名化済みのスキャン画像やレポートが、医用画像解析モデルのデータになります。本番環境の予測をレビューと再ラベル付けのためにデータレイクへ戻すことで、データフライホイールが形成されます。また、テーブルスナップショットやDVCなどのツールを使うと、各モデルのトレーニングに使用した正確なデータバージョンを固定できます。特徴量ストアやベクトルデータベースはデータレイク上に構築されることが多く、生ファイルから抽出した特徴量や埋め込みを提供します。

Ultralytics Platformでは、Amazon S3、Google Cloud Storage、Azure Blob Storage内のフォルダーを、コピーをアップロードせずにトレーニングデータセットにできます。読み取り専用の認証情報を使い、インポートごとに最大500,000個のオブジェクトをその場でインデックス化し、画像と同じ場所にあるYOLOの.txtラベルファイルを解析して、フォルダー名からtrain、val、testの分割を割り当てます。各インデックス画像はオブジェクトのバージョンに固定されるため、データレイク内でファイルが上書きされた画像があれば、Platformは処理を安全側に停止します。