最新記事 builders.flash とは Developer Live Show リソースメンバー登録

データレイク解説シリーズ第 1 回 : データレイクってなに ?

2020-03-02

ビジネスxクラウド

Author : 下佐粉昭

はてブ »

こんにちは。今回から 4 回の予定でデータレイクについての連載をスタートします。現在データレイクの書籍を 4 名で執筆中なのですが、そこからエッセンスとなるポイントを抜き出し、builders.flash を読んでいただいている皆様にコンパクトにお届けします。第一回は「データレイクってなに？」です。

データレイクを一言で表すならば、多様なデータを一元的に、大量に保存して置ける場所です。データベースに入っているような構造化されたデータも、ソーシャルメディアのメッセージも、画像や音声ファイルも一箇所に集めたデータ置き場という意味です。

これを読んでいる皆様は「データベースでは駄目なの ?」と思われるかもしれませんね。巨大なデータを扱うという意味ではデータウェアハウスもありますが、これとはどう違うのでしょうか？

今回はデータレイク理解の最初の一歩として、データレイクは、データベースやデータウェアハウスとどう違うのかを見ていきましょう。

この連載記事のその他の記事はこちら

データレイク解説シリーズ第 1 回 : データレイクってなに ?
データレイク解説シリーズ第 2 回 : データレイクのアーキテクチャ
 データレイク解説シリーズ第 3 回 : AWS でデータレイクを作ってみよう

汎用のデータ処理基盤として普及したリレーショナルデータベース

蓄積したデータを高速に読み書きし、分析するためのソフトウェアとしては、リレーショナルデータベースが広くつかわれています。このリレーショナルデータベースを管理するソフトウェアを RDBMS (Relational Database Management System) と呼びます。RDBMS は正規化されたデータ (列ごとにデータの形式がそろったデータ) を高速に読み書き、演算するためのソフトウェアです。処理内容にもよりますが 1 つのサーバで稼働する RDBMS あたり、数百 GB～1TB 程度のデータを保持し、演算することが可能です。こういった高速処理が実現できるのは、データを検索する事に特化したデータ保存形態 (データをメモリ上にキャッシュする仕組みやインデックス)、更新速度を維持する仕組み (ログ) があるためです。また RDBMS は複数人からの同時の更新・読み取りをデータ整合性を維持しつつ実現する仕組み (トランザクション処理) を持っています。

クリックすると拡大します

RDBMS の実装は多数存在しますが、操作するための言語 (SQL) や、通信プロトコル (JDBC や ODBC) は共通化されています。SQL にはデータを合算したり、平均値を求める等といった分析に必要な機能も含まれています。言語や API が共通化されてるため、現在は多くのソフトウェアが RDBMS を前提に作られており、分析用のソフトウェアも多数用意されています。

RDBMS は現在も機能面・性能面で進化し続けていますが、万能ではありません。特に 1 台の RDBMS で取り扱えるサイズを超えるような大規模データ分析ニーズへの対応は課題の 1 つでした。

巨大データの分析に特化したデータウェアハウス

多くのシステムで RDBMS が利用されるようになった後に、データウェアハウス (Data Warehouse) の概念が生まれました。その名前はデータの倉庫という意味から来ています。複数のシステム (RDBMS) のデータを集め、統合的に分析を行うための保存場所（倉庫）であり、そのサイズと保存されるデータの形態に特徴が有ります。データウェアハウスは 1 TB を超えるような、RDBMS 単体では扱うのが困難なサイズのデータを分析するために利用されます。昨今では 1 PB を超えるようなデータウェアハウスも存在しています。

現在のデータウェアハウスの実装は SQL で操作するよう作られているものがほとんどです。つまり多くのデータウェアハウスは一種の RDBMS でもあります。汎用の RDBMS との違いはより巨大なデータを分析することに特化した作りになっている事にあります。例えば、複数のサーバで分散処理することでパフォーマンスを向上させたり、巨大データの読み取り速度を上げるためにデータを圧縮したり列指向 (カラムナ) フォーマットで保存すること等が行われます。これらの仕組みは、大量データの読み取り速度を向上させる一方で、小さいデータを読み書きする性能を低下させる傾向があります。つまり RDBMS の内部的な作りを分析用の巨大データ読み取りに特化させたものが現在のデータウェアハウスといえるでしょう。こういった特徴をもつ環境としては、AWS では Amazon Redshift が挙げられます。Apache Hadoop 上に Apache Hive や Presto 等で SQL や類似の言語を実行できる環境を構築してデータウェアハウスとしている例も多くあります。

データウェアハウスのもう一つの特徴が、分析の目的にあわせて事前に加工して保存しているという点です。分析担当者に使いやすい形でデータを届けるため、用途に合わせて先に加工しておくという事です。料理に例えるなら、ある冷蔵庫 (RDBMS) から魚 (データ) を取り出し、切り身にして塩を振ります。また別の RBBMS から西京味噌をもってきて切り身の魚を漬け込むといった形で下ごしらえ (データの加工) をして、倉庫 (データウェアハウス) に保存しています。これでいつでも西京焼きを出すこと (分析を実行すること) ができます。このように最終的な分析の目的 (料理の品目) に合わせて加工して保存しておくことで、スムーズに分析を実行できます。

クリックすると拡大します

多様な生データの保存を重視したデータレイク

データレイクはクラウドの成長に合わせて普及してきた概念です。データウェアハウスもデータレイクもデータを統合的に保存するという意味では同じですが、違いはデータレイクは加工する「前」のデータを保存しているという点にあります。加工される前のデータを一般的には「生データ」と呼びます。釣ったばかりの生の魚をイメージすると分かりやすいでしょう。

例えるなら、生魚や味噌だけでなく、肉や野菜も含めて、多様な生データを一元的に保存するのがデータレイクの役目です。

クリックすると拡大します

分析の前には加工が必要なことは変わりません。分析をする (西京焼きを出す) 場合は事前に加工 (西京焼きの下地作り) が行われ、その加工後のデータもデータレイク上に保存されます。では、加工したデータはどう分析するのでしょうか ? それには色々な方法が考えられますが、データウェアハウスに投入して分析をするという方法も広く使われています。

データレイクでは生データ (生魚) を保存した時点では、西京焼きにするといった目的を決めておく必要がないという点が重要です。加工前の生データをそのまま維持しているため、必要に応じて色々なニーズに対応できます。例えば西京焼きではなく、お刺身で出すことになった場合にも対応できるというわけです。このように新しいニーズが発生した場合に対応できるようにすることが、データレイクが必要になった背景の 1 つです。データウェアハウスは目的に特化したデータしか保存していないため、新しいニーズへの対応が困難です。

データウェアハウスにも多様な生データを残しておけば良いのでは ? と思われるかもしれません。しかし、RDBMS の一種であるデータウェアハウスは正規化されたデータしか保存できないため、多様な種類のデータ全てを保存しておく事ができません。例えば WEB サイトへのアクセスログを分析する場合を考えると、ログから今回の分析に必要と思われる IP アドレスや URL、時刻だけを取り出し、行・列の形に正規化してからデータウェアハウスに投入します。その他の部分はデータウェアハウスには保存されません。一方、データレイクであればアクセスログをそのまま保存しておけます。

また、データウェアハウスのストレージ装置が高価であり、増え続ける生データを全て保存するだめの容量を確保するのが困難という点も生データを全て保存できない理由の 1 つです。

つまりデータレイクには、多様な生データをそのまま保存でき、安価でサイズ上限にも余裕がある事が求められます。AWS では Amazon S3 がその機能を提供していますが、これをクラウド以外で実現するのは難しく、データレイクとクラウドが同時に成長してきた理由でもあります。

まとめ

第一回は、データレイクの特性をデータベースやデータウェアハウスとの比較から説明しました。冒頭で「データレイクは多様なデータを一元的に、大量に保存して置ける場所」と説明しましたが、その目的は将来の新しい分析ニーズに対応できるように備えることです。つまり、変化が速い「分析・活用」と、有効な期間が長いデータの「蓄積」というライフタイムの異なる要素を分離することが、分析システムにデータレイクを取り入れるメリットだと考えていただくのが良いでしょう。

では第二回をお楽しみに！