データ活用やDXがどんどん解る用語集　　
データレイク

データレイク（Data lake）とは、さまざまなシステムから生成される多種多様なデータを、湖が水を溜めるようにそのまま受け止めて格納できるデータ基盤（データリポジトリ）のことを言います。
IT活用が進むにつれ、従来よりもはるかに多種多様なデータを取り扱う必要が生じてきました。従来のデータ基盤が前提とした「事前に整えてあるデータ」（構造化データ）だけでなく、そうでないデータ（JSONやXMLなどの半構造化データや、電子メールのテキストなど非構造データ）をデータ分析に用いるニーズ、さらには昨今では機械学習（AI）での活用が進む画像や動画などのバイナリデータなどのデータ活用のニーズも生じてきました。

このような、従来のデータベースやDWHにそのまま格納しづらいデータを、湖が水を受け入れるように、元のデータのまま溜めて利用できるようにするデータ基盤がデータレイクです。

データ分析をするための「データを溜めておく基盤」としては、分析用のデータベースの一種である「DWH」が、データレイクよりも前に普及しており広く利用されてきました。まず、DWHが利用されていたのにデータレイクがどうして利用されるようになったのか、どのような違いがあるのかについて説明をします。

「DWH」は事前に決めた形式でデータを格納する

「データベース」と通常呼ばれているもの（RDBやDWH）にデータを格納する場合、データベースにデータを格納する前に、格納するデータがどういう形式なのかを「事前に定義しておく」必要があります。

例えば、社員一覧のデータを格納したいなら、「氏名（文字列）」「社員番号（整数）」「所属部署（部署ID）」など、どういう形式のデータを格納するのかを事前に定義して「データを入れる場所」を確保してから、その形式に合わせてデータを整えて格納する必要があります。

「DWH」のメリットとデメリット

事前にデータの形式を決めておくやり方にはメリットがあります。必ず決まった形式でデータが格納され「データが全て整えられている」ことが期待できるため、格納済みのデータを利活用しやすくなります。

しかしながら、様々なデータが日々どんどん生まれる時代になると、事前にデータを定義して整えないと格納すらできないことがデメリットとして目立ってきます。「このデータは今すぐ活用したい」と思えても、データスキーマ（どういう形式のデータを格納するのか）を定義し、それによりデータを入れる場所を確保して、決まりに合わせてデータを前加工して、ようやくデータを格納できます。データ活用はそれらが終わってからになります。

特に、クラウド時代になって大量のデータが発生する時代になってくると、「どんどん新たなデータが発生する」というのに「格納するだけで手間取る」のでは、データ活用が滞ってしまうことが多くなってきました。そこで、データを整えなくてもとりあえず格納できるデータ基盤である「データレイク」が開発され利用されるようになりました。

TOPへ

次に、このようなデータレイクの特徴がデータ活用をどのように変えることができるのかを見てみましょう。

「生データ」の格納場所として

データレイクにはDWHと比べて、データの発生源から届いたそのままのデータ、いわば「生データ」をそのまま保存しやすい特徴があります。

「データを前処理」するということは、元のデータに手を入れるということです。元のデータが保持している情報のうち、一部の情報を捨ててしまうことでもあります。データを前処理して、用途に合わせて一部の情報を捨てる処理はいつでもできますが、捨ててしまった情報は戻すことはできません。

データを資産として大事に取り扱うのなら、後になって思わぬデータが必要になることにも備えている方が良いはずです。データの可能性をすべて生かすためには、すべての情報が損なわれていない最初の「生データ」を「そのまま残しておく」方が無難です。データレイクは、生データをそのまま保存しておく手段として利用できます。

データ活用のハードルを下げる

例えば、自社で社内のデータを集めたデータ基盤を作ろうとしていたとします。そのような取り組みを始めることは難しく、取り組みを社内に定着させることも容易ではありません。現場がとりあえず何かやってみようと思ってくれるだけでも、例えばが稚拙でも業務の現場データを集めようと動いてくれるだけでもまずはありがたいはずです。

そういう状況で「データは必ず指定の形式に整えてからDWHに入れてください」とか「ルール通りに整えられていないデータは格納できません」「格納しないと活用できません」とか言ったならどうなるでしょうか。協力してくれる人は減ってしまうのではないでしょうか。多くのデータが捨てられてしまうとか、事前加工に時間がかかりすぎてデータの鮮度が落ちてしまうような問題も起こるかもしれません。

データを整えること自体は「目的ではなく手段」だと考えるなら、「とりあえず格納できる」データ基盤の方が、データ活用を進めるためには、ありがたいことがあると思います。

「スキーマオンリード（Schema on Read）」と「スキーマオンライト（Schema on Write）」

データを分析作業で利用するのだとします。DWHを利用してもデータレイクを利用しても、実際に分析作業に取り掛かる段階では作業に適した形（あるいは支障のない程度）にデータが整えられている必要があります。つまり、データを整える作業はいずれ必要になります。

この観点では、データレイクは「データをデータスキーマにあわせる作業」を「後回しにする」考え方であり、DWHは「最初に義務付けてきれいなデータだけ保持する」考え方であると考えることができます。つまり、データをどう運用するか、考え方を選べるようにする「選択肢を増やす」手段だと考えることができます。

DWHでは、データをどのように利用するか事前に把握してデータスキーマを定義し、データを「書き込む（格納する）時点」で用途にあわせて望ましいデータ形式にすることを要請しています。このような、書き込む時点でデータスキーマを強制する特徴を「スキーマオンライト（Schema on Write）」と呼ぶことがあります。

一方でデータレイクは、書き込む時点ではデータスキーマの適用を強制しません。このことにより、事前にデータがどのように活用されるのかを把握する必要なく、前作業をする手間もなく、とりあえず格納してしまうことができます。データスキーマの適用は、データを利用するために「データレイクから読み込んだ後」に行うことになります。このような特徴を「スキーマオンリード（Schema on Read）」と呼ぶことがあります。

TOPへ

では、データレイクは具体的にどのような技術を用いて実現するのでしょうか。通常のデータベース（RDB）であるなら、PostgreSQLなど広く知られたデータベースエンジンやクラウドサービスがあって、それを利用するイメージがあると思います。一方で、データレイクと聞いても製品名が思い浮かばないかもしれません。でも実は、よく知られている技術でデータレイクを作ることができます。

今やデータレイクの基盤となった「Hadoop」

まず、一時期（2010年過ぎくらい）に大ブームになった「Hadoop」を基盤としてデータレイクを構築することができます。Hadoopと聞くと「ビッグデータ」を思い浮かべる人が多いと思いますが、今ではデータレイクの基盤として活躍しています。

Hadoopが生まれたのは、クラウド時代になって「かつてないほど大量で多種多様なデータ」が発生するようになり、そのようなデータを従来のRDBやDWHのような技術で処理することは（その当時は）難しかったので、新時代のデータ基盤が必要とされて開発されたものです。

新たなデータがどんどん発生する状況では、事前にデータを整える前提のデータ基盤ではやはり十分ではありませんでした。そこで、多種多様なデータをそのまま格納でき、ものすごい量のデータでも格納できて処理可能なデータ基盤として開発されたものです。現在ではHadoop系のプロダクトがデータレイクの構築に用いられていることがあります。

「Amazon S3」などのオブジェクトストレージ

また、各社クラウドサービスでデータレイクの基盤として適したサービスが提供されています。Amazon S3などのオブジェクトストレージのサービスです。

クラウド上でデータベースを利用できるサービス（Amazon RDSなど）などと比べて、Amazon S3（オブジェクトストレージ）は何に使うものなのかイメージしづらいかもしれません。しかし、「とりあえずなんでも入れておける」「障害などを起こさず安心して保管できる」「入れておけばクラウド上の大半のサービスから便利に利用できる」ことから、クラウドサービス全体におけるデータの基盤として活躍する重要なサービスとなっています。

データの種類を問わずにそのまま安心して保管できる、データサイズが非常に巨大であっても保管でき、AWSの大半のサービスから読み書きできるように整備されていることから、「データを取り扱うときにはとにかくAmazon S3に保存しておく」サービスになっています。

オブジェクトストレージは、DWHの考え方に対するサービスとして作られたわけではないのですが、データレイクが備えているべき性質は結果的に整備されています。そのため、例えばAmazon S3を用いてデータレイクが構築されることがよくあります。

TOPへ

ここまではデータレイクの意義や良いところについて書いてきましたが、データレイクは「データの沼地（Data Swamp）」を招く考え方であるとして非難されることがあります。

自由にデータを受け入れた結果、データが乱雑に格納され、どこに何のデータがあるのか解らなくなった状況のことを「湖ではなく沼」として、「データレイクの実態とはデータスワンプ（データの沼地）」ではないかという批判です。

この言葉は、事前にデータを整えるDWHでは、そのような状況には陥りにくいことから「だからデータレイクはダメ（でDWHを利用すべき）」としてポジショントーク的に使われることもありますが、データレイクは注意して利用しなければいけないことを諭すためにも使われます。

データカタログの整備

「データの沼地」にしないためには、データを管理して格納するよう注意する必要があります。さらには、どういうデータが入っているのかが見えるようにする（データカタログ）、どういう経緯でデータが来たのか（データリネージュ）を確認できるようにするなど、データレイク内のデータを「見える化」する仕組みを整えることも望まれます。

データの分析や集計の能力に劣ることが多い

またデータレイクでは、格納されているデータに対する検索や集計の能力が劣っていることがあります。SQLがフル機能で使えないシステムが多いなど、自在なクエリで検索ができず検索能力に制限があることや、検索できても処理時間がかかるなど性能が悪いことがあります。

TOPへ

つまり、データレイクはDWHに対して一方的に優れているわけではありません。

組み合わせて利用する

ここまで説明してきたように、DWHとデータレイクにはそれぞれ良し悪しがあります。用途に応じて使い分ける、あるいは組み合わせて利用することが望まれます。例えば、

• データはまず、生データをそのまま保管する場所として「データレイク」に格納する
• データレイクに格納した生データを前処理して「DWH」に流し込む
• データ分析はBIツールを用いて「DWHに格納されたデータ」に対して行う

このようにすれば「データを受け止めるデータレイクの能力」と「効率的にデータを取り扱えるDWHの能力」をうまく生かすことができます。自社の事情や必要に応じて、さらに作りこむこともでき、例えば以下のような仕組みとすることもできます。

• データレイク：原本の生データをともかくそのまま保管する場所
• データレイク：そのままでは利用に支障があるデータを整えて保管する場所
• DWH：分析に適した形にしたデータの保管庫
• DWH：分析をするデータを置く場所
• BIツールや機械学習：必要に応じてDWHやデータレイクを参照する

TOPへ

データレイクをうまく活用するためには「データ連携」が必要

そもそも一昔前にはデータレイクは存在しませんでしたし、今後もデータに関する技術の状況は変化するはずです。自社のITシステムや保有するデータの状況も変化するでしょう。さらには、自社のビジネスの状況が変化してデータに関する状況やニーズも変化するはずです。

そうであれば、自社にとってのデータ基盤の「あるべき姿」も変化し続けるはずです。将来にわたる「正解」はないなら、状況に合わせてDWHやデータレイクを必要に応じて自在に組み合わせて利用できるようにし、今後の技術的状況の変化やニーズの変化に継続的に対応できるようにした方が、今後に備えたことになるはずです。

DWHとデータレイク、外部のデータやシステムとの「自在なデータ連携」が必要

また、DWH利用の現実の苦しみからETLによるデータ連携の課題とニーズが発見されたように、データレイク自体の利用にとっても「外部のデータやシステムとのデータ連携」の手間を解決するデータ連携手段はそもそも必要性があります。

さて、データレイクをうまく活用するために、データレイクと外部をデータ連携する手段には何が求められるでしょうか。

• データレイクへデータを持ってくる手段：
  データは社内やクラウドの様々なシステムに、多種多様な形式で存在します。
• データレイク上のデータを加工する手段：
  デデータは事前に加工されていないことが多々あります。利活用の前にデータ形式を整えるなどのデータ加工が必要になることが当然あります。
• 溜まっているデータを取り出して外部で活用する手段：
  データレイクからデータを取り出しでDWHに流し込む、外部システムで利用するなど、外部システムで利用できる必要があります。さらには複数のデータレイクを組み合わせて利用することもあるでしょう。

よって以下のような特性を実現しているデータ連携ツールが必要になります。

DWHとデータレイクの違いは何でしょうか。行と列があるような整ったデータしか扱えないのでは、データレイクの導入目的が果たせません。もっと多種多様なデータ形式に対応している必要があります。

多種多様なデータは多種多様な場所にあります。さらにはデータレイクそのものにも様々な製品やサービスがあります。必要に応じて自在に利用できるべきです。

データレイクはビッグデータのブームから生まれたほどです。大量のデータでも高速に連携し処理できる必要があります。簡易な連携便利ツールでは実用的な性能が出なくて困ることもあります。

データ加工の能力が高いこと

データレイクのデータは事前に整えられていないことが多くなります。利用に応じて、必要なデータ加工ができる手段が望まれます。単にデータを右から左に転送できる機能しかない場合、必要なことができない可能性があります。

ノーコード・ローコード（業務の現場が自分で活用できる）

データ連携やデータの加工を何かあるごとに手作業で行っていては、手間と時間がかかりすぎますし、その都度、要望をドキュメントにまとめてシステム開発を依頼していても時間がかかりすぎます。データ活用は取り組んでみないと解らないことが多い傾向もあり、事前の要件分析で連携システムに必要なことを分析することも現実的ではありません。
そうであるなら、データ活用の現場主導で、データ活用のやり方を迅速に変更・実現できる必要があります。

GUIのみでデータ連携を自在に開発できるノーコードやローコードのツールがあれば、現場主導でこのようなニーズを自ら迅速に解決し、データ活用を効率的に進めることができます。

TOPへ

• DWH
  • -分析するためのデータを溜めておくためのデータベースです。分析に特化した性能になっており、大量のデータの保持や、分析処理の実行に向いた性能を備えていることが多い。
• ETL
  • -昨今盛んに取り組まれているデータ活用の取り組みでは、データの分析作業そのものではなく、オンプレミスからクラウドまで、あちこちに散在するデータを集めてくる作業や前処理が実作業の大半を占めます。そのような処理を効率的に実現する手段です。
• オブジェクトストレージ
• iPaaS
  • -様々なクラウドを外部のシステムやデータと、GUI上での操作だけで「つなぐ」クラウドサービスのことをiPaaSと呼びます。
• ノーコード/ローコード

関連製品

データレイクを導入すると、多種多様なデータがどこに、どんな形で格納されているのかわからずデータ活用が進まなくなることがあります。そこで、どのようなデータがどこにあるかを「見える」ようにするのがデータカタログ。ご興味ありましたら以下もご覧ください。

当社で開発販売しているデータ連携ツール「DataSpider」は、ETLとしての機能も備えており、DWHの利活用をささえる手段として多数の利用実績もあるデータ連携ツールです。

通常のプログラミングのようにコードを書くこと無くGUIだけ（ノーコード）で開発でき、「高い開発生産性」「業務の基盤（プロフェッショナルユース）を担えるだけの本格的な性能」「業務の現場が自分で使える使いやすさ（プログラマではなくても十分に使える）」を備えています。
データ活用のみならず、クラウド活用などの様々なIT利活用の成功を妨げている「バラバラになったシステムやデータをつなぐ」問題をスムーズに解決することができます。

無料体験版や、無償で実際使ってみることができるオンラインセミナーも開催しておりますので、ぜひ一度お試しいただけますと幸いです。