データハブ vs データレイク vs データの仮想化

概要

大規模な組織には大量のデータが保有されており、そのほとんどが多数の様々なシステムに分散されています。これは意図的にデータを分散させたわけではなく、現場の現実的な判断が積み重なり、結果として分散しているのです。データサイロは技術的負債であり、SaaS（Software as a Service）アプリケーションやその他のクラウドサービスが導入されるにつれて増加しています。これにより、ビジネスとITの間で摩擦が高まっています。このようなデータサイロの解消は非常に困難であり、また従来のデータウェアハウスのアプローチでは問題があることは明らかです。そのため、IT部門は（ビジネス部門から迫られる形で）この問題を解決できる現代的なアプローチを探してきました。

ここでは、データ統合の現代的なアプローチである、データレイク、データの仮想化（フェデレーション）、データハブの3つを比較します。これら3つのアプローチのいずれの場合でも、既存のアプリケーションを妨げることなく、多様なソースのデータをシンプルなセルフサービスで利用できます。しかし、これらの現代的なアプローチのそれぞれにはトレードオフがあり、また、相互に排他的なものでもありません（データハブに基づくアーキテクチャと一緒に、データレイクも使用し続ける組織も多くあります）。

比較表

データレイクとは

データレイクとは、あらゆる規模や構造のデータを保管できるセントラルレポジトリです。データレイクは、分散ファイルシステムHadoopの台頭とともに人気を博すようになりました。Hadoopでは、容易に生データをセントラルレポジトリに移動し、データを低コストで保管できます。データレイクでは、データのキュレーション（エンリッチ、マスター管理、ハーモナイズ）がなかったり、検索できないことがあります。データを分析および業務活用するには、Hadoopエコシステムの他のツールで複数ステップの処理を行う必要があります。しかし、データレイクには、データの読み込み時に事前の多くの作業が不要だというメリットがあります。

データレイクの利用目的としては、分析用サンドボックス、機械学習モデルのトレーニング、データ準備パイプラインへのフィード、あるいは単に低コストなデータストレージなどがあります。

数年前、Hadoopの分野においては、主にCloudera、Hortonworks、MapRの3社が競合していました。現在では、ClouderaとHortonworksの合併、そしてMapRの投げ売り的な事業売却により、Clouderaのみが残っています。

多くの組織にとって、Amazon S3などのオブジェクトストアが事実上のデータレイクとなり、オンプレミスのHadoop環境からクラウドへの移行を後押ししています。

Apacheエコシステムには、Hadoopコア以外にも多くの関連ツールがあります。例えば、イベントストリーミング用アーキテクチャでストリーミングデータの処理と分析を行う場合、SparkとKafkaの2つのツールがよく使用されます（それぞれDatabricksおよびConfluentとしてマーケティングされています）。

今回の比較では、これらのツールの詳細なレビューは行いません。一般的に言うと、これらのツールは、ほとんどのユースケースにおいてデータハブを補完するものです。これらのツールはストリーミングデータを管理しますが、データベースが必要なことは変わりません。例えば、Kafkaにはデータモデルやインデックスがなく、データへのクエリもできません。通常、イベントベースのアーキテクチャや分析プラットフォームは、データハブ上に構築した方が信頼性が高まり、よりオペレーショナル（業務活用可能）になります。

データの仮想化とは

データの仮想化では、既存のデータベースに格納されているデータの仮想ビューを作成します。データを物理的に移動せず、新たな仮想データレイヤーで複数ソースからのデータを統合ビューとして表現します。この手法はしばしば「データフェデレーション」（または「仮想データベース」）と呼ばれます。基となる複数のデータベースがフェデレーションの対象（「フェデレート」と呼ばれます）となります。

例えば、OracleとSAPのデータベースがいくつか稼働しており、ある部門がこれらのシステムのデータにアクセスしたい場合を考えてみましょう。この際ETLを使ってデータを物理的に移動し、さらに別のデータベース内に永続化（格納）する代わりに、特定のチームや用途用に仮想的に（かつ素早く）データを取得し、統合できます。

データの仮想化では、基となっているデータベースに対してクエリが実行されます。最新の仮想化技術では、クエリ実行の計画と最適化がますます洗練されてきています。インメモリのキャッシュデータや、統合された超並列処理（MPP）を利用し、クエリ結果をジョインおよびマッピングして、複合的なビューとして表示するものもあります。新しいデータの仮想化技術の多くでは、データの読み取りだけでなく書き込みもできます。新しいソリューションではデータガバナンスも進化しており、さまざまなロールやユースケースに応じたデータのマスキング、LDAP認証などの機能も搭載されています。

データの仮想化の主なメリットの1つに、短時間での価値創出があります。データを物理的に移動しないため、データへのクエリ前にやらなくてはならない作業やコストが少なく、既存のインフラへの影響も抑えることができます。

データの仮想化のもう1つの大きなメリットとして、非構造化データソースと構造化データソースの両方に対してアドホックなSQLクエリを実行できる点があります。データの仮想化ではこれが主なユースケースです。

これらのメリットを踏まえたうえでのデータの仮想化の欠点

• 仮想データベースではデータがインデックス付けされず、インデックス格納用の独立したデータストレージもありません。ここでは、基となるソースシステムで付けられたインデックスに依存しますが、これらのインデックスは適切でないことがしばしばあります。
• 仮想データベースでは、すべてのリクエストを、個々のソースシステム用の別のリクエストにマッピングしてから、すべてのソースシステムに対して実行します。そのため、ネットワーク全体でパフォーマンスの問題が発生する可能性があり、システムは常にネットワーク容量の問題に悩まされることになります。
• 仮想データベースには、データをキュレーションし、データ品質を向上させ、データのリネージや履歴をトラッキングできる場所がありません。データが返されるとき、または処理されるときにデータに対して最小限のハーモナイズが行われるだけです。永続化されたカノニカルな（規準となる）データは存在しないため、下流のユーザーと安全に共有できる「single source of truth」（信頼できる唯一の情報源）は得られません。
• 一般に、仮想データベースではセキュリティ制御に制約があります（少なくとも実装が複雑です）。例えば、仮想データベースでは、レコード単位ではなくテーブル単位でのみデータを保護できます。
• 仮想データベースの容量は、常に基となるソースシステムのデータ量に制限されます。

スタンドアロンのデータの仮想化ソリューションを提供している会社としては、SAS、Tibco、Denodo、Cambridge Semanticsがあります。Oracle、Microsoft、SAP、Informaticaなどその他のベンダーは、主力製品の一機能としてデータの仮想化を組み込んでいます。

データハブとは

データハブは、「ハブ＆スポーク」アーキテクチャにおける統合ポイントとなるデータストアです。マルチ構造データを物理的に移動して統合し、基となるデータベースに格納します。

データハブの主なメリット

• データハブには、基礎となるマルチモデルデータベースがあります（データレイクや仮想データベースにはこのようなデータベースはありません）。これにより信頼性実現のためのシステム（「system of truth」）が実現されます。ここには、データの機密性（アクセス制御）、データの可用性（高可用性と災害復旧）、データの整合性（分散トランザクション）を含む、必要なあらゆるエンタープライズ機能が備わっています。
• データハブにはデータをキュレーション（エンリッチ、マスター管理、ハーモナイズ）するツールが用意されています。また、段階的にハーモナイズでき、結果をデータベースに永続的に保存できます。
• データハブは、オペレーショナル/トランザクショナルなアプリケーションをサポートします。データレイクはこのような用途で使用できません。また、仮想データベースではトランザクションをサポートできますが、基となるデータベースシステムのパフォーマンスによりトランザクションの処理速度が制約を受けます。

データハブにはこのようなメリットがあり、ガバナンスが効いたトランザクショナルなデータレイヤーを提供することで、データレイクやデータの仮想化を強力に補完します。これについては後で詳しく説明します。

データハブに最適なユースケース

次のような場合は、アーキテクチャとしてデータハブを選択することをお勧めします。

• マルチモデルデータを統合したい場合。データハブは、構造が複数存在する、変化するデータの統合に適しています。これはデータの由来をトラッキングし、単一の管理しやすいセキュリティデータモデルを適用するのに最適です。また、データのエンリッチ、ハーモナイズ、マスター管理（重複排除を含む）を行うキュレーション機能がビルトインで備わっています。
• 業務部門がデータサービスをすぐに使いたい場合。データハブは、データの取り込み、および価値創出の両面でアジャイルです。データハブは単なる分析用サンドボックスではありません。適切にキュレーションされたデータが大量に含まれたデータハブがあれば、データサービスを数週間で提供し、ビジネスバリューを創出できます。
• リアルタイムのオペレーショナルな（業務用）ビューが必要な場合。データハブは、オペレーショナルかつトランザクショナルです。リアルタイムのビューを提供することで、信頼できる唯一の情報源となります。分析チームが、過去のスナップショットではなくリアルタイムのオペレーショナルな分析を必要とする場合、データハブが適しています。
• 安定したプラットフォームや信頼できる統合ポイントが必要な場合。データハブは、データベースを基盤としています。他のシステムとは独立して動作するため、他のシステムのネットワークやインフラの制約を受けません。さらに、データハブは、データの永続化、高可用性と災害復旧、トランザクションの整合性、エンタープライズ仕様のセキュリティ、その他安定したプラットフォームに必要なすべての機能を備えています。

MarkLogicのお客様は、ビジネスの全体像の把握、オペレーショナル分析、コンテンツの収益化、研究開発、製造業におけるIoT、規制順守、ERP統合、メインフレーム移行などの用途でMarkLogicデータハブプラットフォームを活用しています。

データレイクが適している場合

データレイクはストリーミングデータに最適です。大量データ（構造化および非構造化データ）を低コストで格納したい場合のレポジトリに適しています。ほとんどのデータレイクはHDFSを基盤としており、広範なHadoopエコシステムに簡単に接続できます。そのため、オープンソースのツールと低コストな分析用サンドボックスを必要とする大規模な開発チームに適しています。多くの組織では、データサイエンティストの作業用にデータレイクを活用しています。ここにトレーニングデータを格納し、JupyterやSparkなどのツールにフィードすることで、機械学習プロジェクトを推進しています。

データの仮想化が最適な場合

データの仮想化は、分析に最適です（データ統合において必要となデータハブほどの堅牢性を必要としない場合）。迅速に導入でき、データを物理的に移動しないため、プロジェクト開始時におけるインフラのプロビジョニング作業がほとんどいりません。データの仮想化の一般的な利用例としては他に、データチームが、非リレーショナルなデータソースに対してアドホックなSQLクエリを実行するというものがあります。

データハブ、データレイク、データの仮想化を一緒に使う方法

「データハブ」と「データの仮想化」は、データ統合に対する2つの異なるアプローチであり、同一ユースケースにおいて競合することもあります。一般的に、データハブをすでに使用している場合、データの仮想化を導入する必要はありません。データハブでは、データの仮想化のメリットほぼすべてが得られます。例えば、MarkLogicのお客様の多くは、MarkLogicデータハブでメタデータ（またはコンテンツ）のレポジトリを構築することで、重要なデータアセットを仮想化しています。

そのため、他のデータソースと同様に、MarkLogicデータハブをフェデレーション対象のデータソースとして扱うこともできます。例えば、複数のデータソースを統合したMarkLogicデータハブをフェデレーション対象のデータソースとして扱い、Sparkなどのツールでアクセスして、機械学習モデルのトレーニングやスコアリングに使用できます。

「データレイク」は、「データハブ」をうまく補完します。MarkLogic Connector for Hadoopを使用してHadoopからMarkLogicデータハブへ、またはMarkLogicデータハブからHadoopへデータを移行しているお客様が数多くいます。データレイク上にデータハブを置くことで、高品質、キュレーション済み、安全、重複排除済み、インデックス済み、かつクエリ可能なデータにアクセスできます。さらに、MarkLogicデータハブには、巨大なデータを管理するための自動的なデータ階層化機能があります。これによりデータレイク内に安全にデータを格納しこれにアクセスできます。

最も一般的なのは、既存のデータレイクからデータを移行するというもの、また使用頻度の低いデータを低コストなストレージであるHadoopにオフロードするというもの、機械学習プロジェクトに利用するというものです。

詳細はこちら

アーキテクチャのプランニングにおける今後のステップとして、以下のオプションを考えてみてください。

• 次の大規模なデータ統合プロジェクトでは、データレイクやデータの仮想化ではなく（あるいは、数多くのコンポーネントをつなぎ合わせてカスタムメイドの「データハブ」を構築するのではなく）、MarkLogicデータハブサービスを使用して新たにデータハブを構築する。
• データレイク上にデータハブを構築する。MarkLogicデータハブサービスをデータのキュレーションとガバナンスのための統合ポイントとして使用し、データレイクをバッチ処理とデータサイエンスに使用する。
• 可能な限り多くのデータを1つあるいは複数のデータハブに統合し、データの仮想化を通じて公開する。

多くのお客様が、データレイクまたはデータの仮想化を補うものとして、またはそれらを置き換えるものとしてMarkLogicデータハブを使用しています。ノーザン・トラスト、米空軍研究所（AFRL）、シェブロンの顧客事例をご覧ください。