データレイク

概要

データレイクは、組織で発生するあらゆるデータを「加工する前の生の姿のまま」一か所に貯めておくための貯蔵庫です。RDBMSから抽出したテーブルはもちろん、アプリケーションのログ、JSONのイベントデータ、画像・音声・センサーデータのような非構造化データまで、形式を問わず放り込めます。「湖（レイク）」という名前は、加工済みの水をボトル詰めして並べる倉庫（＝データウェアハウス）に対して、源流から流れ込む水をそのまま湛えておく場所、という対比から来ています。

実体としては、Amazon S3 のようなオブジェクトストレージにファイルを貯めていく構成が主流です。クラウドストレージの容量単価が劇的に下がったことで、「使うかどうか分からないデータも、とりあえず全部残しておく」という戦略が経済的に成立するようになりました。機械学習の学習データ置き場や、全社のデータ分析基盤の最下層として登場する語彙です。

なぜ生まれたか

データレイク以前の分析基盤の主役だったデータウェアハウスは、「格納する前にスキーマ（データの型と構造の定義）を決め、ETLで変換してから積む」方式でした。この方式は、分析の目的が事前に分かっているレポーティングには強い一方で、2つの壁がありました。1つは、スキーマに合わないデータ — ログや画像、頻繁に構造が変わるイベントデータ — をそもそも受け入れられないこと。もう1つは、「何に使うか」を先に決めないと格納できないため、後から生まれた分析ニーズに対して「あのとき捨てた生データが必要だった」という事態が起きることです。

2010年代に入り、機械学習の隆盛でこの問題が決定的になりました。モデルの学習には加工前の生データが大量に必要で、どの特徴量が効くかは試すまで分かりません。そこで「変換してから貯める」を逆転させ、「まず生のまま全部貯めて、用途が決まったときに読み解く」という発想 — データレイクが登場しました。安価なオブジェクトストレージと、その上のファイル群を直接処理できる分散処理エンジン（Hadoop、後に Spark）が揃ったことが、この逆転を技術的に可能にしています。

詳細

スキーマオンリード — 「読むとき」に構造を与える

データレイクの核心は「スキーマオンリード」という考え方です。データウェアハウスが書き込み時にスキーマを強制する（スキーマオンライト）のに対し、データレイクは書き込み時には何も検証せず、読み出す側が「このファイル群をこの構造として解釈する」と宣言して初めて構造が与えられます。同じ生データを、レポート用途では日次集計のテーブルとして、機械学習用途では特徴量の素材として、それぞれ違う形で読める — 用途を後から何通りでも重ねられるのがこの方式の強みです。代償として、読み出し時に毎回パースと変換のコストがかかり、データの品質保証も読む側の責任になります。

典型的な構成 — ゾーンで段階的に磨く

実務のデータレイクは、湖の中を「加工度」で区分けするのが定石です。よく使われるのが、流入したままの生データを置く raw（bronze）ゾーン、クレンジング・重複排除を済ませた cleansed（silver）ゾーン、分析用途に集計・整形した curated（gold）ゾーンの三層構成で、ETL（あるいは貯めてから変換する ELT）のパイプラインがゾーン間のデータを段階的に磨いていきます。ファイル形式には、列単位の読み出しに強い Parquet のような列指向フォーマットを使うのが一般的で、これにより「巨大なファイル群へのSQLクエリ」が現実的な速度で動きます。Amazon Athena や Apache Spark のようなクエリエンジンは、まさにこの「ストレージ上のファイルを直接 SQL で読む」役割を担います。

データスワンプ — 湖が沼になるとき

データレイク最大の落とし穴は、「とりあえず貯める」が「貯めただけ」で終わることです。どこに何があるか、誰が作ったか、どのデータが信頼できるかが分からなくなった湖は「データスワンプ（沼）」と呼ばれ、誰も使わないストレージ料金だけがかさむ場所に成り果てます。スキーマオンライトという「書き込み時の門番」を捨てた以上、その代わりとなる統治が必要です。具体的には、データの所在と意味を記録するデータカタログ（メタデータ管理）、データの出自をたどれるリネージ、アクセス権限の管理といったデータガバナンスの仕組みで、これを最初から組み込めるかどうかが湖と沼の分かれ目になります。

レイクハウス — 湖と倉庫の合流

近年は、データレイクの柔軟さとデータウェアハウスの信頼性を1つの基盤で両立させる「レイクハウス」というアーキテクチャが主流になりつつあります。Delta Lake、Apache Iceberg、Apache Hudi といったオープンテーブルフォーマットが中核技術で、オブジェクトストレージ上のファイル群にトランザクションの保証、スキーマの強制と進化、行単位の更新・削除、タイムトラベル（過去時点の読み出し）といった、従来はデータベースにしかなかった性質を与えます。これにより「レイクに貯めてからウェアハウスへコピーする」二重管理が不要になり、1つの湖の上で BI レポートも機械学習もストリーム処理からの書き込みも受け止める構成が可能になりました。Databricks や Snowflake が競う現代のデータ基盤の主戦場は、このレイクハウスの層にあります。