datalake-top

Column

 

この記事では、データレイクの定義・役割から、導入するメリット、データウェアハウス・データマートといった概念との違い・使い分け、導入事例、注意点を解説します。

 

 

マクロセンドは、データ自動収集システム、データレイク・DWH基盤構築、セルフデータプレパレーションツールの提供等、企業の状況・要望に合わせたデータ活用・DXを支援するサービスを行っております。興味のある方は、以下のサービス記事もご確認ください。

 

 

 

 

データレイクとは

まず、データレイクの定義や特徴を解説した上で、主要なデータレイク製品やサービスを紹介します。

データレイクの定義

データレイクは、あらゆるソースからなるビッグデータを、ひとまとめに格納することのできる、容量無制限で一元的なリポジトリ(データ保管場所)のことを指します。

 

Hadoopをはじめとする、オープンソースBIツールを提供するPentahoのCTO・James Dixonが2010年に初めて提唱した概念で、「データを蓄積する湖」の意からデータレイクと呼ばれます。

 

オンプレミスな従来のデータウェアハウスとは異なるものであり、増え続ける企業のデータ量に対応するために考案されたアーキテクチャです。データレイクは、音声・画像といった非構造化データを含めて一元的に保管できることから、機械学習や分析をする際の基盤として活躍します。

 

データレイクの定義や存在意義について、クラウドコンピューティングサービス大手のAmazon Web Serviceでは、次のように解説しています。

 

データレイクは、規模にかかわらず、すべての構造化データと非構造化データを保存できる一元化されたリポジトリです。

 

データをそのままの形で保存できるため、データを構造化しておく必要がありません。

 

また、ダッシュボードや可視化、ビッグデータ処理、リアルタイム分析、機械学習など、さまざまなタイプの分析を実行し、的確な意思決定に役立てることができます。

 

AWSでのデータレイクと分析・データレイクとは|AWS公式

 

データレイクの役割

データレイクの役割は、従来のデータウェアハウスでは対応しきれないデータの保存です。つまり、データウェアハウスを拡張するというのが、データレイクの本質的な役割と言えるでしょう。

 

年々増え続けるデータ量に対し、従来のオンプレミスなデータウェアハウスではすべてのデータを格納することが難しい状況の中、「今は必要ないが将来的に必要になるかもしれないデータ」を保管するために、データレイクは不可欠なリポジトリなのです。

 

増え続けるデータ量の推移について、2014年に発表された米国ストレージベンダー・EMCと調査会社・IDCの調査結果によれば、2013年時点で4.4ZBだったデータ総量は、2020年に10倍の44ZBに拡大するとしています。

 

そのほかにも、DELLテクノロジーズの調査によれば、企業の管理するデータ量は、2016年に比べて2018年時点で平均831%増加していると発表しており、世界15カ国の従業員数250人超の企業と公的機関の意思決定者1,000人を対象として行ったアンケートの回答では、回答者のうち81%が「現在のデータ保護ソリューションでは、今後のビジネスニーズに対応することはできない」と答えたとのことです。

 

さらに、Aberdeen社の調査によれば、データレイクを実装した企業は同業他社と比べて収益成長率が9%上回るという結果が出ています。

 

以上の結果からも、無制限にデータを取り込めるリポジトリの設置は急務であり、データレイクは今後のデータ活用の分析基盤として必要不可欠な存在と言えるでしょう。

 

参考:

ビジネスの現場で増え続けるデータに企業はどう立ち向かうべきか|できるネット

Previous DELL、企業が管理するデータ量の平均が2016年から831%増と発表|IoTNEWS

Aberdeen – Angling for Insight in Today’s Data Lake(PDF)

 

主なデータレイク製品・サービス

データレイクを構築できるサービスには、次のようなものがあります。

 

・Amazon S3(AWS)

・Cloud Storage(Google Cloud Platform)

・Azure(Microsoft)

・IBM Cloud Pak for Data(IBM Cloud)

・Oracle Cloud Infrastructure Object Storage(Oracle Cloud)

・Snowflake

 

また、データレイクにはあらゆるソースからのデータがひとまとめに格納されるため、目次として機能するメタデータを付与しておかなければ、せっかくのデータも活用できないものになってしまいます。

 

このことに対して、90年代にデータウェアハウスを提唱したBill Inmonは、Data Lake Architecture: Designing the Data Lake and avoiding the Garbage Dump(2016年)の中で、次のように語っています。

 

データを放り込むだけだとゴミ溜めになってしまうが、メタデータなどの情報をセットで登録すると金山になる。Data Lake Architecture: Designing the Data Lake and avoiding the Garbage Dump

 

データレイクに格納するデータは、メタデータを付与すればデータカタログで管理できるようになります。データカタログ機能を持つサービスやベンダーには、次のようなものがあります。

 

・Alteryx

・Talend

・Informatica

・erwin

データレイクを導入するメリット

データレイクを導入することで得られるメリットは、主に次の通りです。

 

・あらゆるデータを一元管理できる

・データの成形処理が不要になる

・生のデータ(rawデータ)を残せる

・組織間でのデータ連携が容易になる

・リアルタイムなデータ取得による業務効率向上

 

ひとつずつ見ていきましょう。

あらゆるデータを一元管理できる

クラウドで構築するデータレイクは、オンプレミスなデータウェアハウスと比べ、低コストで大容量のストレージを使用できます。

 

また、構造化・半構造化・非構造化といったあらゆるデータを、事前の定義なく格納することができるため、あらゆるIoTデバイスで発生したデータを一元管理することが可能です。

 

サイロ化の心配がなく、分割やスケールアップに悩む必要もなく、クラウドなのでサーバやインフラの管理も必要ありません

 

従来のデータウェアハウスも、すべてのデータを保存することをコンセプトとしていましたが、実際には容量の問題などから優先度の低いデータを削除するケースも少なくありませんでした。データレイクでは、これらの課題が解決されています。

データの成形処理が不要になる

データレイクは、構造化・半構造化・非構造化といったデータの構造を問わずあらゆるデータを格納できます。

 

そのため、データウェアハウスやデータベースにデータを格納する際に発生していたデータの成形処理が不要になります。

生のデータ(rawデータ)を残せる

データウェアハウスでは、成形を施したデータを格納するのに対し、データレイクでは生のデータをそのまま格納できます。

 

rawデータが残ることにより、同じデータに対して別の分析を別のタイミングで行うことが可能です。

組織間でのデータ連携が容易になる

rawデータが蓄積されるため、rawデータをもとに部署ごとに必要なデータ分析を実施することができます。

 

rawデータが確実に保存されるアーキテクチャを構築することにより、同じタイミングで部署ごとに異なる視点から分析をかけるといったアプローチも可能になるのです。

リアルタイムなデータ取得による業務効率向上

IoTによりさまざまなエッジデバイスが活躍する中、データウェアハウスだけでは半構造化・非構造化データを含めたすべての情報をリアルタイムに格納することは難しいのがこれまでの状況でした。

 

それに対し、あらゆるデータを一元管理できるデータレイクなら、データをリアルタイムに取得することで、的確で迅速な意思決定をサポートします。

データレイク・データウェアハウス・データマートの違い

データレイク・データウェアハウス・データマートの違いは次の通りです。

 

データレイク

・実装前にスキーマを定義

・設計する必要がない(スキーマオンリード)

・構造化、非構造化問わずあらゆるデータを格納できる

・rawデータが無作為に格納されるため、データ品質はデータマネジメントやデータガバナンスに依存する

・将来的な分析に役立つ(機械学習、予測分析、プロファイリングなど)

 

データウェアハウス

・実装前にスキーマを定義・設計する必要がある(スキーマオンライト)

・主に構造化データを格納する(事前定義すれば半構造データも可)

・データはきれいに整理され、エンドユーザーにも扱いやすい

・過去の分析に役立つ(バッチレポート、BI、データの可視化など)

 

データマート

・データウェアハウスを特定の目的に応じて利用しやすい形に切り出したデータベース

 

データウェアハウスやデータマートが使用目的に先立って設計されるのに対して、データレイクは特定の使用目的を持たない点が大きな違いと言えるでしょう。

 

参考:

【初級】AWSで構築するデータレイク 基盤概要とアーキテクチャ例のご紹介|aws SUMMIT Tokyo2019

データレイクの導入・構築事例

ここからは、データレイクの実際の導入・構築事例を紹介します。

Amazon:PBクラスのDWHをAWSのデータレイク環境へ移行

aws-logo

まずは、データレイク環境構築の際に使われることの多い、Amazon Web Serviceの自社事例から紹介します。

 

Amazonは、Oracleを使ったPB(ペタバイト)クラスのデータウェアハウスを、自社サービスであるAWSを使用したデータレイク環境へと移行しました。

 

Amazonのデータウェアハウスには、次の課題がありました。

 

・毎年サーバとストレージを倍に増強

・パッチ適用などのメンテナンス工数は月数百時間

・ライセンス費用と、ピーク時に合わせたハードウェアサイジングによりコストがかさんでいた

 

これらの課題を解決するため、Andesというデータレイクプロジェクトを開始した結果、次の効果を実現しました。

 

・Amazonの成長に合わせて拡張可能なエコシステムの実現

・オープンなシステムアーキテクチャで、多様なデータ分析の選択肢を提供

・AWSを利用してフィードバック、サービス改善に貢献

 

参考:

【初級】AWSで構築するデータレイク基盤概要とアーキテクチャ例のご紹介 | AWS Summit Tokyo 2019|YouTube

データレイク構築における成功の秘訣 ~マインドと進め方、設計ベストプラクティス~ | AWS Summit Tokyo 2019|YouTube

Finra:750億イベント/日の処理基盤を構築


finra-logo

米国の金融業規制機構・FINRAのシステムは、日に最大750億のイベントが発生し、ストレージ容量は5PBを超えるものとなっていました。

 

この状況に対し、Amazon S3をデータ共有サービスとして定義し、EMRやRedshiftからアクセスを可能にすることでデータレイク環境を構築しています。

 

参考:

事例で見るデータレイク on AWS|「AWSではじめるデータレイク」出版記念 データレイクはじめの一歩

(BDT305) Amazon EMR Deep Dive and Best Practices – Amazon Web Services

リコー:共通データ基盤の構築とデータ活用の促進


ricoh-logo

事務機器、光学機器などを製造するメーカーであるリコーでは、2015年頃からAWSの活用を本格化しました。

 

データ活用の需要が各事業部で個別に拡大する中、社内およびグループ間をまたいだデータ活用ができないこと、またそもそも何のデータが存在しているか把握できないことが課題となっていました。

 

そこでリコーでは、データ共有サービスとしてAmazon S3を使用し、事業ごとにバケットを提供する形でデータレイク環境を構築しました。

 

1つのアカウントで運用し、アクセス制御は事業ごとにIAMを提供することで実現しています。事業間のデータ連携も可能になりました。蓄積したデータの集計にはAthenaを使用し、テーブルはGlueで作成しています。

 

参考:

事例で見るデータレイク on AWS|「AWSではじめるデータレイク」出版記念 データレイクはじめの一歩

データ蓄積(データレイク)|来たるべきAI時代のための「イケてる」データ基盤の作り方

Nasdaq:Redshift/EMRを使い分け


nasdaq-logo

世界初の電子株式取引所であるNasdaqでは、データウェアハウスサービスであるRedshiftと、ビッグデータプラットフォームであるEMRを使い分けています。

 

このアプローチにより、300TBの直近データと、全期間データに対し、共通のSQLでアクセスできる環境を構築しています。

 

参考:

事例で見るデータレイク on AWS|「AWSではじめるデータレイク」出版記念 データレイクはじめの一歩

(BDT314) A Big Data & Analytics App on Amazon EMR & Amazon Redshift

ヒルトン:データレイクを核にEIM基盤


hilton-logo

世界最大のホテルチェーンであるヒルトンでは、3ゾーン構成のデータレイクを核として、EIM(エンタープライズ情報管理)基盤を実現しました。

 

参考:

事例で見るデータレイク on AWS|「AWSではじめるデータレイク」出版記念 データレイクはじめの一歩

Ask an Amazon Redshift Customer Anything (ANT389) – AWS re:Invent 2018

Intuit:オンプレミスからの移行


intuit-logo

米国のIntuitは、クラウド会計ソフト QuickBooksをコアブランドとして擁する世界最大手の会計・税務ソフトクラウドサービス企業です。

 

Intuitでは、もともとHadoop処理系が中心の大規模データレイクを、オンプレミスで構築していました。

 

しかし、スケールアップするにつれてSLAの担保が困難になり、サポートやアップデートの負荷が増大し続けたことから、AWSへの移行を決断。

 

AWSに移行したことで、オンプレミスだったときに比べ、運用管理負担の低減やより進んだ自動化を実現しました。

 

参考:

事例で見るデータレイク on AWS|「AWSではじめるデータレイク」出版記念 データレイクはじめの一歩

データレイク活用のポイント・導入の注意点

データレイクは、企業のデータ分析を促進するリポジトリとして機能しますが、導入にあたって注意すべき課題もあります。

 

それは、データレイクをデータスワンプ(データの沼)にしてはいけないという点です。

 

データスワンプは、データレイクの対義語として定義される概念で、データレイクが分析基盤として活躍するのに対し、データスワンプは「現場で使えないデータが蓄積した状況」を表しています。

 

データレイクがデータスワンプになる主な原因は、生のデータ(rawデータ)の内容を確認しないまま保存してしまうことです。

 

データレイクをデータスワンプにすることなく、分析基盤として力を発揮させるためには、データマネジメントやデータガバナンスを考えて実装・格納する必要があります。

 

あらゆるデータを保管できるからといって、何の対策も講じずに生のデータを放り込んでしまうと、そのデータは分析に活用できないものになってしまうのです。

 

企業によっては、データスワンプにしないためにデータスチュワードという役割を設ける場合もあります。

 

 

 

2021年4月9日