データハブ、データレイク、データ仮想化の比較
概要
大規模な組織には大量のデータが保有されており、そのほとんどが多数の様々なシステムに分散されています。これは意図的にデータを分散させたわけではなく、現場の現実的な判断が積み重なり、結果として分散しているのです。データサイロは技術的負債であり、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)、Mitchell 1 の導入事例をご参照ください。
