データマネジメント/アナリティクス業界では、すべての企業が理解しておくべき多くの用語が飛び交っています。これらの用語の多くは、簡単に混同してしまいます。今回のテーマであるデータウェアハウスとデータレイクのケースがそれに当たります。2つの最も重要な違いは何か、そしてビジネスにおいてどういった形で最も効果的に使用することができるでしょうか？

Table of Contents

1. データウェアハウスとデータレイク

2. 人気のデータレイク

3. 人気のデータウェアハウス

データウェアハウスとデータレイク

データウェアハウスは、企業が構造化され統合済みのデータを保存するリポジトリです。ここで保存されたデータは、重要なビジネス上の意思決定をサポートするためのBI（ビジネスインテリジェンス）に使用されます。データレイクもデータリポジトリですが、データレイクは構造化されたデータと非構造化されたデータの両方の形で様々なソースからのデータを保存するのに使用されます。

多くの人は、データレイクとデータウェアハウスは同じものだと誤解しています。確かに２つには以下のようにいくつかの共通点があります。

  • データを保存するためのリポジトリ
  • クラウド型またはオンプレミス型
  • 驚異的なデータ処理能力

しかし、それ以外の多くの部分には大きな違いがあります。

注）Data Lake(左) vs.Data Warehouse(右)

  1. スキーマ・オン・リード vs. スキーマ・オン・ライト

  2. すべてのデータタイプ vs. 構造化データ

  3. 分離されたストレージとコンピューティング vs. 密接に組み合わされたストレージとコンピューティング

  4. 汎用的なデータ vs. すぐに活用できるデータ

  5. データ保持時間が長い vs. 短い

  6. ELT vs. ETL

  7. 変更やスケールの変更が容易 vs. 困難

1. スキーマ・オン・リード vs. スキーマ・オン・ライト

スキーマは定義の１つで、特定のデータベースのDBMS（データベース管理システム）に限定された正式な言語を作成するものです。スキーマは、記述、テーブル、IDなどウェブ上やデータベース内でほとんどのユーザーが簡単に理解して検索できる共通言語の使用を保証することで、データにある程度のレベルの体系と構造をもたらします。

データレイクは、データがすぐに必要な場合、スキーマを適用する作業を省略します。言い換えると、ユーザーがデータを参照しているときに、スキーマを適用することができるということです。専門家はこのプロセスをスキーマ・オン・リード（Schema on Read）と呼んでいます。このプロセスは、複数の新しいデータソースを定期的に追加する必要があるビジネスにとって非常に有用です。非常に時間のかかるそれぞれのスキーマを前もって定義しなければならないのではなく、ユーザーはデータが必要とされるときにスキーマを定義することができます。

これは、ほとんどのデータウェアハウスとは対照的だといえます。データウェアハウスの場合、スキーマ・オン・ライト（Schema on Write）を適用しますが、これはデータを参照するプロセスのはじめに時間と労力を必要とします。ユーザーは、データをウェアハウスにロードする直前にスキーマを定義します。スキーマ・オン・ライトは、スキーマに準拠しないデータの使用を防ぐことができ、ビジネスにおいて大量の反復データを処理しなければならない場合に最適です。

ここでの違いは、次で紹介する違いにも直結します。

2. 全てのデータタイプ vs. 構造化データ

データレイクは、様々なソースから構造化された形式だけでなく、非構造化された形式のデータを受け取ることから、人々はデータレイクと呼んでいます。パッケージが整理整頓されている事が多いウェアハウス（倉庫）とは異なり、データレイクは湖に似ており、様々なソースから水が流れ込み、それゆえに様々なレベルのデータ構成やデータのクリーンさを保持しています。

ユーザーはスキーマ・オン・リードベースでデータにアクセスするので、データレイクに入ったときには非構造化されています。データには多くのテキストが含まれているかもしれませんが、価値のある情報はほとんど、または全く含まれていないかもしれません。このため、多くのユーザーは構造化される前のデータを理解するのに苦労することになります。これはデータレイクが一般的にデータサイエンティストか同等のデータに対する理解を持つ人によってだけ活用する事が可能だと考えられる理由です。

データウェアハウスは構造化されたデータのみを扱い、直接的に質問に答えないデータは除外されています。つまり、CEO、マーケティングチーム、ビジネスインテリジェンスの専門家、またはデータアナリストは常に、整理されたクリーンなデータを参照し、活用することができます。

3. 分離されたストレージとコンピューティング vs. 密接に組み合わされたストレージとコンピューティング

データレイクは、分離されたストレージとコンピューティングが特徴としてよく取り上げられます。クラウドをベースにしたデータウェアハウスにも、この重要な特性が含まれています。ストレージとコンピューティングが分離されているため、両者は互いに独立してスケールすることができます。データレイクでは、処理されることのない膨大な量のデータが保存される可能性があるので、これは重要です。そのため、コンピューティングを増やすことは、多くの場合、不必要かつコストがかかります。アジリティを強みとする企業や、年間の利益が小さい中小企業は、このオプションを好むかもしれません。

オンプレミスデータウェアハウスの場合、密接に結合されたストレージおよびコンピューティングを使用します。一方がスケールアップすると、もう一方もスケールアップしなければなりません。ストレージだけを増やすことは、一般的にストレージとコンピュートの両方を同時にスケーリングするよりもはるかに安価なため、これはコスト増加要因になります。しかし、同時により高速な機能性を意味するので、多くの場合、特にトランザクション・システムでは不可欠です。

4. 汎用的 vs. すぐに活用できるデータ

データレイクにはあらゆる種類の非構造化データが含まれているため、提供される結果は汎用的なものであり、ビジネスプロセスにすぐに適用できるものではないものがほとんどです。その結果、データサイエンティストやデータ専門家は、価値のある情報を見つけるためにデータレイクの中を整理するのに多くの時間をかける必要があります。この汎用的なデータは、実験の解析に使用することができ、予測分析に役立ちます。

データウェアハウスから得られた結果は、すぐに利用でき、理解しやすいものです。レポートダッシュボードや、整理・ソートされたデータを表示するその他の手段を通じて、ユーザーは簡単に結果を分析し、重要なビジネス上の意思決定に迅速に活用することができます。

5. データ保持時間が長い vs. 短い

ユーザーはデータをデータレイクに長期間保存することができ、企業はデータを何度も参照することができます。一部のデータはアーカイブされますが、一般的にはデータウェアハウスのように削除することはありません。特定のタイプのデータを保持するための法的要件に応じて、短期間から10年まで保持されることがあります。これは、様々な目的のために、あるいは長期間にわたって同じデータを参照する必要がある研究ベースの産業や科学的な産業において、特に重要になるかもしれません。

企業は通常、データを非常に限られた期間だけデータウェアハウスに保存し、その時点でユーザーはデータレイクなどの別のリポジトリにデータを転送するか、破棄することができます。これは、消費者サービスや、いわば「今」を生きる他の産業にとっては良いことです。

6. ELT vs. ETL

データレイクがELT, (extract, load, transfer)を使用するのに対し、データウェアハウスはETL (extract, transfer, load)を使用します。ELTとETLはどちらも重要なデータ処理ですが、処理の順番によっていくつかのことが変わります。

ETLは、データをソースからステージングへ、そしてデスティネーションに運びます。データはバッチで処理されます。

ELTは、ソースからデスティネーションへと直行し、多くの場合、連続的、ほぼリアルタイム、またはリアルタイムストリームで行われます。デスティネーション（送信先）は、ユーザーが変換を適用する場所でもあります。

変換には、必要に応じて特定のセキュリティ対策と暗号化の適用を含むため、ETLはより安全なデータ管理方法だといえます。つまり一般的にデータレイクよりもデータウェアハウスの方がデータが安全であることを意味しており、ヘルスケアのような機密性の高い業界では必要不可欠かもしれません。しかし、ELTは、最高のアジリティをサポートするほぼリアルタイムでのビジネスプロセスの参照を提供する事が可能です。

7. 変更やスケールの変更が容易 vs. 困難

データレイクは構造化されていないため、データウェアハウスよりも機敏で柔軟性に富んでいます。開発者やデータサイエンティストは、より簡単にデータレイクを変更したり、再構成したりすることができます。データソースやデータ量が常に変化している場合には、必要不可欠な場合があります。

データウェアハウスはデータのための高度に構造化されたリポジトリであり、それらを変更することは容易ではありません。大幅な再構成には多くの時間と労力が必要になるかもしれません。それは、データウェアハウスが反復的なプロセスを実行するために理想的であることも意味しています。

多くの有名なデータソフトウェアプロバイダは、データレイクとデータウェアハウスのための優れた最先端の技術を提供しています。

人気のデータレイク

Athena

Amazon Athenaは、理想的なデータレイク・ソリューションとしてAmazon S3と連携しています。Athenaは、サーバーレスでデータレイクからクエリを実行し、データを分析する機能を提供します。ユーザーはETLを使用せずに、標準SQLを使用してすぐにクエリを開始することができます。

Presto上に構築されたAthenaは、大規模なデータセットを扱う場合でも性能が良く、適度に高速です。Athenaは機械学習アルゴリズムを使用して、通常は広範囲に及ぶタスクを簡素化し、データドリブンな企業にとって最適なオプションです。

Microsoft Azure Data Lake

マイクロソフトは、Azure Blob Storage上に構築されたデータレイクソリューションを開発しました。このクラウド・データレイクは、拡張性が高く、大規模なストレージ機能を備えています。Azureには高度なセキュリティ対策が含まれており、そのうちの1つは可能性のある脆弱性をトラッキングしています。さらに、Visual StudioやEclipseとのディープな統合を通じて、開発者をサポートしています。これにより、開発者はAzureで作業しながら慣れ親しんだツールを使用することができます。

Azureはセキュリティ重視で構築されているので、ヘルスケア分野や機密データを扱う他の同様のインダストリーに最適です。

人気のデータウェアハウス

Redshift

Amazon Redshiftは、包括的なデータウェアハウスソリューションです。LyftやYelp、製薬大手のファイザーなど、1万人以上の様々な顧客が利用しています。

Amazonによると、Redshiftは他のクラウド型データウェアハウスよりも運用コストが低いと主張しており、市場で最も人気のあるデータウェアハウスソリューションの1つとなっています。このソフトウェアには、ライブデータをクエリするための新しいFederated Query機能が含まれています。

Amazon Redshiftは、ユーザーが差分更新を維持できるマテリアライズド・ビューを提供しています。高度な機械学習アルゴリズムと、ほぼ無制限のクエリを同時に実行する機能を備えています。自動バックアップを実行し、空間データをネイティブで処理する機能を提供することで、Redshiftは競合ソリューションのほとんどを凌駕し、企業に安全なデータウェアハウスを提供しています。

PostgreSQL

PostgreSQLは、多くの業界では単にPostgresとして知られています。Postgresはオープンソースのソリューションとして提供されているリレーショナルデータベース管理システム（RDBMS）です。また、低コストのデータウェアハウスソリューションとしても使う事ができます。クリエイターは、開発者がアプリケーションを構築するのを支援し、企業がデータを保護する事を支援することにフォーカスしています。

Postgresは、開発者がデータベースを再コンパイルすることなく、様々なコーディング言語でコードを書くことを可能にするユニークな機能を持っています。このソフトウェアは、強力なアクセス制御システムと他の様々なセキュリティ対策を備えています。多くのオープンソースのソリューションとは違って、開発者は豊富なドキュメントを提供しています。

様々なデータレイクやデータウェアハウスでETLやELTを実行するために、多くの企業は時代遅れのソフトウェアや非常に複雑なソフトウェアを使用しているかもしれません。ETLの実装に従業員は何時間もかける可能性があり、企業は選択したデータレイクやデータウェアハウスと統合できる合理的でシンプルなソリューションを必要としています。

これらの懸念は、企業がクラウドベースの、Low codeのETLソリューションを提供するXplentyに向ける原因となった理由の１つでしかありません。Xplentyを使えば、様々なデータレイクとデータウェアハウスと統合して、ビジネスに必要なニア・リアルタイムの分析を実現することができます。

ライブチャットサポートと優れたドキュメントにより、Xplentyは、企業が安全かつ迅速にETLを実行することを可能にします。Xplentyのプラットフォームを体験するためにぜひデモを予約してください。