基本情報 2022 サンプル問題 問23：テクノロジ系に関する問題

答えは a「あらゆるデータをそのままの形式や構造で格納しておく」 です。

データレイクは名前のとおり「データの湖」。川から流れてくる水（=いろんなデータ）を、整理せずにそのままドボンと貯める巨大な池みたいなものです。

写真・動画・テキスト・センサー値…形がバラバラのままOKで、後から「やっぱりこの分析に使おう」と思ったときに取り出して整える、という使い方をします。

似てる言葉に「データウェアハウス」がありますが、こっちはきれいに整理して棚に並べた倉庫。先に形を決めて入れます。

👉 覚え方：レイク＝生のまま貯める湖／ウェアハウス＝整理した倉庫。

ほかの選択肢：b メタデータ（データの説明書）は普通に格納する／c 形を先に決めて入れるのはウェアハウス／d 形ごとに分けるのもデータレイクの特徴ではない。

なぜこれが正解か

正解は a。データレイク（data lake）は構造化・半構造化・非構造化を問わず、あらゆる形式の生データをそのまま格納できる大規模リポジトリ。スキーマを事前定義せず、利用時に必要な形に整形する「スキーマオンリード」方式が特徴。

各選択肢の解説

• b：メタデータ（データの記述情報）はデータレイク運用に不可欠で、通常はカタログ化して格納する。むしろメタデータ管理がないと「データスワンプ（沼）」化する。
• c：格納前にスキーマを定義するのはデータウェアハウス（スキーマオンライト）の特徴。
• d：データレイクは形式に関わらず一元的に格納するのが特徴。形式別リポジトリ分割は逆。

覚え方・ひっかけ注意

3つを区別：

• データレイク：生データを一元集約、スキーマオンリード
• データウェアハウス（DWH）：構造化済み、分析最適化、スキーマオンライト
• データマート：DWH の部門別サブセット

近年は両者の良いとこ取りの「データレイクハウス」（Databricks 等）も出題に登場し始めている。「データレイク＝生のまま」「DWH＝整形後」と対比で覚える。

理論的背景

データレイクは James Dixon（Pentaho CTO）が2010年に提唱した概念。背景には、従来のデータウェアハウス（DWH）がETL（Extract-Transform-Load）の事前変換コストとスキーマ固定の柔軟性不足で、急増するビッグデータ（特に非構造化データ）に対応しきれなくなった事情がある。データレイクは ELT（Extract-Load-Transform） モデルで、まず生データを格納し、分析時に変換する。

実務での使われ方

• クラウドサービス：AWS S3 + Glue + Athena、Azure Data Lake Storage Gen2、Google Cloud Storage + BigQuery（外部テーブル）が定番構成。
• オープンテーブル形式：Apache Iceberg、Delta Lake、Apache Hudi が ACID トランザクション・タイムトラベル・スキーマ進化を実現し、データレイクと DWH の融合（レイクハウス）を推進。
• データカタログ：AWS Glue Data Catalog、Apache Atlas、DataHub 等でメタデータ管理。これが無いとデータスワンプ化する。
• ガバナンス：個人情報を含む生データを扱うため、アクセス制御（Lake Formation 等）、データ系統（lineage）追跡、GDPR/個人情報保護法対応が論点。

試験での位置づけ

基本情報・応用情報のシステム戦略・データベース・ビッグデータ分野で頻出。OLTP（オンライントランザクション処理）vs OLAP（オンライン分析処理）、ETL vs ELT、Hadoop エコシステム（HDFS・MapReduce・Spark）との関連で出題される。データサイエンティスト・データエンジニア志向の問題が近年増加。

選択肢の発展補足

• b メタデータ：技術メタデータ（スキーマ・型）、業務メタデータ（用語定義）、運用メタデータ（鮮度・品質）の3層で管理するのが現代的。
• c スキーマオンライト：DWH の代表的スター/スノーフレーク スキーマ、Kimball/Inmon 方法論まで体系で学ぶ。
• d リポジトリ分割：オブジェクトストレージ上で形式混在を許容するのがデータレイクの真骨頂。逆にウェアハウスは構造化前提。
• データメッシュ：データレイクの中央集権化への反動として、ドメイン駆動・分散所有のアプローチ。応用情報・PM 試験でも今後出題増加見込み。