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

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

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

様々なプロダクトが（特に広義には）データレイクに関係しますが、『Hadoop』を利用して構築されることがあり、最近では『Amazon S3』などのオブジェクトストレージがデータレイク構築の手段として利用されることがあります。

2010年前後に「ビッグデータ」という言葉が世間でよく聞かれた時期がありましたが、その時期に昔ながらのデータ基盤では受け入れきれないようなデータも受け入れて活用する取り組みが進められました。

また、蓄えずに捨ててしまった過去のデータを未来から遡って取得できないので、未来のためにも今のデータは今のうちに貯めておくしかない、当時そういうことも言われるようになり、その手段としてもデータレイクが導入されるようになりました。

データを溜めておく基盤としては「DWH」も広く知られています。データレイクとの大きな違いは、事前に整えたデータ以外を受け付けるかどうかです。

通常「データベース」と呼ばれるものにデータを格納する場合には、事前にデータの形式を定義してその形式でデータを格納する必要があります。例えば、社員一覧なら「氏名」「社員番号」「所属部署」などのデータ形式を事前に定義し、その形式にあわせて整えられたデータを用意して格納します。そうでない場合にはエラーになってしまいます。

結果的にデータがきちんと整えられ、蓄えられたデータは利活用しやすくもなりますが、様々なデータが日々どんどん生まれる時代になると、事前にデータを整える前提はデメリットも目立ってきます。データがあって活用したいと思った、しかしその前にデータスキーマを定義してデータを前加工しないと、そもそもデータ基盤に投入することすらできないのでは不便でもあります。

例えば、自社で社内のデータを集めたデータ基盤を作ろうとしていたとします。「データは必ず指定の形式に整えてからDWHに入れてください」と言ったなら、そんなことは面倒だ、と協力してくれる人は一気に減ることもあるでしょう。その結果データが溜められずに捨てられるとか、事前加工で時間がかかりすぎてデータの鮮度が落ちては台無しです。 データを整えること自体は目的ではありません。「データ活用」が目的なのであれば、目的が今一つ果たされていないとも言えます。

そこで、流れ込んでくる多種多様で大量のデータを湖に水を溜めるように「そのまま貯めることができる手段」として提案されるようになったのがデータレイクです。

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

自由にデータを受け入れた結果、データが乱雑に格納され、どこに何があるのか解らなくなった状況のことを「湖ではなく沼」と、問題ではないかと指摘しています。
事前にデータを整える必要があるDWHではそうなりにくいことから「だからデータレイクはダメ」と使われることもありますし、データレイクは便利だが注意して使わないといけない教訓としても使われます。

「データの沼」にしないためにはデータをきちんと管理して格納するよう注意する必要があります。さらには、どういうデータが入っているのかが見えるようにする（データカタログ）、どういう経緯でいつデータが来たのか（データリネージュ）などを解るようにしておくことも望まれます。

それ以外にも欠点があり、データレイクには、データ分析をする際に必ず必要になるデータの検索や集計の能力が劣ることが多く（SQLがフル機能で使えないシステムが多いなど、自在な検索が出来ない・速度が遅いなど、検索性能が悪いことがある）、自在な分析が難しいことも欠点です。

ではデータレイクやDWHはどちらをどのように使えばよいのでしょうか。

DWH側の各社ではデータレイク的な機能強化に取り組んでおり、今はDWHだけで十分でデータレイクはもう不要だと言っていることがあります。一方でデータレイク側も検索能力などデータの処理能力を強化するなどして、DWHは無くても大丈夫でデータレイクだけで大丈夫だと言っていることもあります。
各社は自分の製品を使いましょう、それだけで大丈夫だと言っていたりします。

組み合わせて使うべきだとする意見もあります。データをまずデータレイクで受け付け、データを整えてDWHに格納して分析する形でうまく分業させましょう、と。
さらにはデータレイクについて、生データをそのまま保全しておく場所と、沼にならないよう整えたデータを入れたデータレイクに分けるべきとする意見などもあります。 さらにはデータレイクやDWH以外のデータ利活用の手段と組み合わせるべきという意見など、様々な提案があります。

今後、技術的状況が変われば、このような「あるべき姿が何か」も変わってゆくでしょう。そもそも一昔前にはデータレイクは無かったのですから。

さらには皆さんそれぞれ状況に応じてデータ利活用のニーズは異なります、取り扱っているデータや
ITシステムの実態によっても何が望ましいかは違うはずです。我々には多様な選択肢があり、自分たちに適したものを選ぶ必要があります。

状況が変わりうるなら、「正解」を探すことは難しくなります。
それなら「現在の正解」を探すよりも、DWHやデータレイクを、必要に応じて様々に組み合わせて利用できるようにし、今後の技術的状況の変化やニーズの変化に継続的に対応で切るようにした方が、長期的に安心して利用できるはずです。つまり、データレイクやDWHを必要に応じて自在にデータ連携できる状況を整備しておく方法です。

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

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

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

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

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

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

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

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

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

• DWH
• ETL
• オブジェクトストレージ
• iPaaS
• ノーコード/ローコード

関連製品

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

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

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

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