データ基盤

データレイクは、何でも安く置く代わりに何を先送りしたか

2026/10/5 シリーズ「データ基盤はなぜ作り直されてきたか」 第4回 / 全5回

🤖 AIが執筆しています

故障が当たり前の安い機械に、巨大なファイルを置く仕組みが生まれた

データレイクの土台は、Google が 2003 年と 2004 年に発表した二つの論文である。Ghemawat らは Google File System（GFS）の論文で、設計の前提として次のような観察を挙げた¹。安い汎用の部品で作った数百から数千台の機械では、部品の故障は例外ではなく日常であること。ファイルは従来の基準で巨大で、数 GB のファイルが普通であること。ファイルの多くは上書きではなく末尾への追記で変わること。論文は、小さなファイルも扱えるようにはするが、そのための最適化はしないと書いている。

Dean と Ghemawat は MapReduce の論文で、大量の生のデータを多数の機械で処理する方法を示した²。利用者は、データの各部分に当てる処理（map）と、その結果をまとめる処理（reduce）だけを書く。データの分割、機械への仕事の割り当て、機械の故障への対処、機械の間の通信は、仕組みの側が引き受ける。約 1,800 台の機械で 1 TB のデータを並べ替えるのに 891 秒かかり、途中で 1,746 個の作業用のプロセスのうち 200 個を止めても（機械そのものは動いたまま）、933 秒で終わった。

これらの考え方を公開のソフトウェアにしたのが Hadoop である。Hadoop の初期の文書は、その分散ファイルシステム（HDFS）を、大きなファイルを多数の機械に確実に置くためのもので、Google File System に着想を得たと説明している³。現在の HDFS の文書も、安い汎用の機械で動かすことを前提に、ファイルは一度書いて何度も読む使い方を想定すると書いている⁴。

生のデータを形を決めずに置き、読むときに解釈する

Facebook の Thusoo らは 2009 年に、Hadoop の上で SQL を使えるようにする Hive を発表した⁵。論文は動機を、分析に使うデータの量が急に増え、従来のデータウェアハウスの製品では費用がかかりすぎるようになったことだと書く。一方で MapReduce の書き方は低水準で、分析のたびに専用のプログラムを書く必要があった。Hive では、ファイルの中身をどう解釈するかを表ごとに指定でき、すでに置いてあるファイルをそのまま表として扱える。データを置くときではなく読むときに形を当てはめるこのやり方を、スキーマオンリードと呼ぶ。入れる前に形を決めるやり方は、スキーマオンライトと呼ぶ。この呼び名を使う Databricks の著者らは、データレイクは何でも安く置ける身軽さと引き換えに、データの品質と管理の問題を下流に回したと書いている⁶。Thusoo らの 2009 年の論文の時点で、Facebook の Hive には数千の表と 700 TB を超えるデータがあり、1 日に 5,000 を超える問い合わせが流れていた。Hive は、表ごとの形と統計を記録する目録（Hive-Metastore）も最初から持っていた。一方で、当時の Hive は既存の表の行の更新と削除に対応していなかった。

データ分析の製品を作る Pentaho の Dixon は、自社の Hadoop 対応製品の発表に合わせた 2010 年のブログで、データレイクという考えを作ったと書いた⁷。Dixon は、従来の方法では関心のある項目だけを選んで集計し、データマート（特定の部門や用途向けに切り出した小さなデータの集まり）に入れていたので、あらかじめ決めた問いにしか答えられず、細かい単位の情報が失われると書いた。そのうえで、データマートを洗って詰めた瓶入りの水に、データレイクを自然のままの大きな湖にたとえた。Dixon が想定した湖の水は、多くの場合一つのシステムから流れ込むものだった。Dixon は 2014 年のブログで、多くのシステムのデータを Hadoop に集めて互いに結合するものは自分の言うデータレイクではないと書き、語の広がり方に不満を述べている⁸。本稿が扱うのは、多くの出どころを一か所に集める、この広い意味のデータレイクである。

取り込みは速いが、読むたびに解釈の費用を払う

形を決めずに置く方式と、並列データベースを比べた測定がある。Pavlo らは 2009 年に、100 台の機械の上で Hadoop と二つの並列データベースを同じ仕事で比べた⁹。並列データベースは分析の仕事で Hadoop の 3.1 倍から 6.5 倍速かった。一方で、データの読み込みは Hadoop のほうが速く、Vertica より最大 3 倍、もう一つのデータベースよりほぼ 20 倍速かった。Hadoop は、実行のたびに入力の記録を解釈し直すので、同じ仕事で常に多くの CPU を使っていた。著者らも、一度しか読み込まないデータでは、データベースに読み込んで整える費用は割に合わないかもしれないと書いている。この論文の著者には、前年に MapReduce を批判した DeWitt と Stonebraker が含まれ、比べた Vertica は Stonebraker らの研究のデータベース C-Store を製品にしたものである。

Google の Dean と Ghemawat は 2010 年に反論した¹⁰。同じ測定の多くで、並列データベースにデータを読み込む時間は、Hadoop で分析する時間の 5 倍から 50 倍だった、と二人は読む。多くのデータは作られて一度か二度処理されて捨てられるので、読み込みに時間をかけるより、そのまま処理するほうが速いという主張である。一方で二人は、複数のアプリケーションが同じデータを共有するにはスキーマが役立つと認め、Google の MapReduce はほぼすべてのデータを、型を記述した二進の形式で読み書きしていると書いた。比べた測定の Hadoop は文字の形式のデータを読んでおり、二人の測定では一件の解釈に文字の形式で 1,731 ナノ秒、Google の形式で 20 ナノ秒かかった。読むたびの解釈の費用は、ファイルの形式で大きく変わる。読む回数が少なく、読む人が少ないデータでは後払いが得になり、多くの人が何度も読むデータでは前払いが得になる。

意味と品質を管理しないと、置いたデータは探せず信じられなくなるおそれがある

形を決めずに置く方式の危うさは、早くから指摘されていた。DeWitt と Stonebraker は 2008 年のブログで、MapReduce にはデータに不正な値が入るのを防ぐ仕組みがなく、新しいアプリケーションを書く人はそのたびに記録の構造を調べなければならないと批判した¹¹。調査会社の Gartner は 2014 年の発表で、データレイクは管理なしに何でも受け入れるので、データを説明するメタデータ（データについてのデータ）とそれを保つ仕組みが無ければ、データの沼（データスワンプ）になる危険があると警告した¹²。メタデータが無ければ、分析をする人はデータを使うたびに一から始めることになるという。この発表は意見であり、測定の数字は示していない。Dixon は同じ年に、元の定義では一つの出どころのデータしか受け入れないので「何でも」は当たらないと反論した⁸。一方で Dixon も、多くの出どころを一つの湖に集めるとメタデータの問題がずっと大きくなると認めている。

Stonebraker は 2014 年の別の記事で、データを集めて使えるようにする作業を五つに分けた¹³。取り込み、変換、スキーマの統合、データクレンジング（食い違いや誤りを見つけて直す作業）、同じ実体の突き合わせである。Stonebraker によれば、取り込みは残りの四つに比べればごく小さな作業で、整えていないデータの沼に取り込んだ時点では、仕事の大部分が残っている。

Hive の目録が記録するのは表の形であり、データの意味や来歴ではない。大規模に使った会社は、複数の保存先と処理系にまたがって、データの説明と来歴を集める仕組みを作った。LinkedIn は 2016 年の記事で、HDFS の 25,000 を超えるデータセットや Teradata の表の説明と来歴を集める仕組みを公開し、処理系や保存先が多様になると、正しいデータセットを探すのに時間がかかり生産性が下がりうると書いた¹⁴。Netflix は 2018 年の記事で、Pig のように自分の目録を持たない処理系と Hive の間で、データの説明を共有するために Metacat を作ったと書いている¹⁵。

Uber の 2018 年の記事は、データレイクが解いたものと壊れたものを一社の中で示している¹⁶。Uber は、それ以前のデータウェアハウスで、形の取り決めのない JSON のデータが生産側の変更で壊れる問題に悩んでいた。Hadoop のデータレイクでは、生のデータを変換せずに一度だけ取り込むようにし、同時に JSON から列ごとに保存するファイルの形式である Parquet へ移して、スキーマを一か所で管理する仕組みを作った。Uber のデータレイクは、何でも置ける湖ではなく、形を管理した湖として動き始めた。それでも、上流の保存先が中身を確かめずに書いた値は Hadoop に入り込み、そのデータを使う人すべてに影響した。Uber は、型を確かめるだけでは値の正しさは確かめられないとして、値の意味を確かめる検査をスキーマの管理に足す方針を書いている。

この記事はAIが執筆しています。内容には誤りが含まれる可能性があります。ご注意ください。