データハブとデータウェアハウスの比較
概要
さまざまなデータ格納手法が登場し、状況は複雑になってきています。このため、どの方法が適切なのかという疑問も湧いてきます。特定の手法が優れている、あるいは劣っているという単純な議論はできません。さまざまなシステム、データベースの種類、ストレージの形式を比較する際には、特に組織固有のデータ要件のコンテキストを考慮することが大切です。ここではまず最初に、MarkLogic データハブとデータウェアハウスの比較表を示し、次にデータハブ一般とデータウェアハウスの違いについて説明します。
比較表
| MarkLogic データハブ | データウェアハウス | |
|---|---|---|
| ユースケース |
|
|
| データモデル |
|
|
| 検索＆クエリ |
|
|
| データの読み込み |
|
|
| データの質 |
|
|
| データのキュレーション |
|
|
| セキュリティ |
|
|
| スケーラビリティ |
|
|
| デプロイメント |
|
|
| 成熟度 |
|
|
データウェアハウスとは
データウェアハウスは、データの分析を行う「ビジネスの観察」用のデータストアです。多くの場合、データは上流の「ビジネスの遂行」用のトランザクショナルシステムから送られてきます。ここでの目的は、アナリストがデータを集約し、さまざまな観点から把握できるようにすることです。
データウェアハウスではリレーショナルモデルが使用され、データははっきりと構造化された行と列の形で管理されます。データ構造 (スキーマ) は事前に定義され (「スキーマオンライト」)、SQL を使用した分析クエリを高速に実行できるよう最適化されています。通常、分析クエリには、データの結合 (ジョイン)、集計、フィルタリングが含まれます。
データウェアハウスは数十年前から存在していましたが、最近のデータウェアハウスはクラウド用に設計されています。最近人気のある Snowflake や Redshift などは、従来のデータウェアハウス (Netezza や Teradata など) の生まれ変わりと呼ぶことができます。Snowflake は、自らを「栄光ある SQL」と呼んでいます。これらのクラウドネイティブなデータウェアハウスは、クラウドの拡張性と経済性を備え、フルマネージド型のサービスとして提供されています。また、JSON をある程度サポートするようになっています。ただし、核となるユースケースは、依然として「リレーショナルデータに対するエンタープライズ BI および分析」のままです。
データウェアハウスの典型的な使用例を考えてみましょう。大手銀行が、トランザクションを扱うために、リアルタイムトレーディングシステムを稼働させています。これらのトランザクションは銀行内の複数の OLTP システムで発生します。これらは、ETL (データの抽出/変換/読み込み) ツールを使用して、中心となる OLAP (オンライン分析処理) 用データウェアハウスに集約されます。
データウェアハウスでは、追加のバックエンド処理 (トレードの照合など)、分析 (リスクエクスポージャの集計など)、レポーティング (規制当局への対応など) が行われます。
データハブとは
データハブは、「ハブ＆スポーク」アーキテクチャにおける安定した統合ハブとして機能するデータストアで、最も重要なデータアセットを一元的に表現できます。ここでは、マルチ構造のさまざまな種類のデータを格納するのにマルチモデルデータベースを使用しています。また、これらのデータのキュレーション (エンリッチ、マスター管理、ハーモナイズ) 用のツールも備えています。また、データハブはオペレーショナルかつトランザクショナルです。つまり、トランザクショナルアプリケーションの基盤とすることや、高度な分析に使用することもできるほか、単純に他の下流のシステムにデータをフィードすることもできます。
データハブは SoR (system of record) としての機能を持つほか、ほとんどのアーキテクチャで共有統合ポイントと呼ばれ、組織の 360° ビュー (全体像) の作成に使用されます。一般的に言って、データハブはドロップインアップグレードではなく、またデータウェアハウスを置き換えるものでもありません。データハブとデータウェアハウスは容易に共存させることができ、MarkLogic のお客様は、しばしばこの2つを併用しています。
データハブの主な利点
データハブは、データウェアハウスよりもアジャイル性が高いです。またデータキュレーションツールが組み込まれているほか、分析だけでなく、オペレーショナル (業務) にも利用できます。
データハブは、アジャイルな DataOps を実現します。これにより、アジャイル開発の原則をデータレイヤーでのデータの管理に適用できます。これが可能なのは、ウォーターフォールのように厳密なスキーマを事前定義する必要がないためです。データハブでは、生データをそのまま読み込むことができます。読み込んだ生データは、下流の用途に合わせてキュレーションできます。このプロセスは「ELT」 (抽出/読み込み/変換) と呼ばれることが多いです。というのもまずデータを読み込み、その後ビジネスのニーズに合わせて反復的に変換するからです。スキーマは、キュレーション済みのデータに対して定義することも、クエリ実行時に定義することもできます (「スキーマオンリード」)。
またデータハブは、状況が曖昧な場合にも威力を発揮します。例えば、構造が未知の複雑なデータソースからデータをストリーミングで取り込む (または一括で読み込む) 必要があり、その後のデータの活用法が不明な場合でも、データハブを使用できます。
データハブが曖昧なものの扱いに長けているのは、すべてのデータに対してインデックス付けし、データを読み込んだ直後から検索タイプのクエリを実行できるためです。またデータハブには、こういった曖昧さを後で解決するためのツールも備わっています。例えば、下流での利用法に関して、ソースデータをどのようにハーモナイズおよびキュレーションすべきかがはっきりとした時点で対応できます。
データハブは統合に適しているのか
ここでは、統合に関する課題のうち、データハブが解決できる例をいくつか示します。
- 名前の付け方の違い。同じ値を含む2つの列に違う名前が付けられている (例：「FirstName」vs「FName」)
- 構造の違い。フィールドの個数や組み合わせが異なる (例：あるシステムでは在庫の箱数「boxes_available」フィールドと箱内の個数「count_per_box」フィールドを使って総個数を計算している。しかし別のシステムでは「total_items」に総個数が記載されており、箱数は関係ない)。
- セマンティック (意味論的) な違い。名前の付け方の違いと似ているが、この場合は名前が若干異なるだけでなく、値自体も少し異なる (例：患者のステータスとして、あるシステムでは3種類あるのに、もう1つのシステムでは5種類ある)。これらのステータスは重複していることも多く、相互に関係付けるのは困難 ({Scheduled, Needs_Followup, Inactive} vs {Intake, Scheduled, Telemedicine-only, Discharged})。
データハブはオペレーショナル (業務活用可能) です。ビジネスのリアルタイムのビューが最新のものに更新され、必要に応じて上流のシステムにデータを書き戻すこともできます。データハブは、トランザクション対応によりリアルタイムでの更新ができ、データのガバナンスと正確性を損なうことなく統合済みデータを直接更新できる、信頼性の高いデータストアを提供します。
データハブに最適なユースケース
次のような場合は、アーキテクチャとしてデータハブを選択することをお勧めします。
- データソース自体またその利用法が複雑で変化する場合。データハブは、マルチ構造の変化するデータの統合が得意です。そのため、入ってくるデータソースの内容がはっきりとわからない場合、データがいつ来るかわからない場合、数多くの複雑なスキーマを統合する場合、上流のデータソースが頻繁に変化する、または品質が不明な場合、統合データの用途が定まっていない場合は、データハブが適しています。
- ビジネスで素早くデータを利用する必要がある場合。データハブはアジリティの面で大きなメリットがあります。そのため、大量の事前データモデリングの時間がない場合、業務部門がすぐにデータを欲しがっている場合、データハブが適しています。また、ビジネスニーズが頻繁に変化し、アジャイルな DataOps が必要な場合にも適しています。
- 複雑な (想定されていなかった) クエリを使用する場合。データハブでのデータのクエリは、Google 検索に似ています。そのため、従来のデータウェアハウスでは不可能だった複雑な問いを行うのに理想的です。行と列の考え方に縛られたり、複雑なジョインに悩まされることなく、多次元のエンティティや関係性 (値、メタデータ、語、語句、構造など) に対してクエリを実行できます。
- リアルタイムのオペレーショナルなビューが必要な場合。データハブは、オペレーショナルかつトランザクショナルです。分析チームが過去のスナップショットではなくリアルタイムビューを求めている場合は、データハブが適しています。また、アナリストがナレッジ管理のシステムの一環としてシステムにデータを書き戻し、フィードバックループを実現する必要がある場合にも適しています。
- 安定したプラットフォームや信頼できる統合ポイントが必要な場合。データハブは、データベースに基づいています。つまり、データハブは、データの永続化、高可用性と災害復旧、トランザクションの整合性、エンタープライズ仕様のセキュリティ、その他安定したプラットフォームに必要なあらゆる機能を備えています。アーキテクチャが全体としてシンプルなため、新たなサイロが生じることはありません。
MarkLogic のユーザーは通常、全体像の把握、検索と発見、運用分析などにMarkLogic データハブサービスを使用しています。
データウェアハウスが適しているケース
データウェアハウスには大企業での実績があり、ほとんどすべての組織において、1つあるいは複数のデータウェアハウスがあります。また、多くの場合、データウェアハウスから派生したデータマートも多数存在します。データがしっかり構造化され、きちんと定義されており、データウェアハウスの目的も定まっている場合には、データウェアハウスが便利です。
行と列に対して高速に SQL クエリを実行するだけなら、データウェアハウスが威力を発揮します。データウェアハウスは、構造化されたデータを読み込み、SQL を使用してクエリを実行する作業に最適化されており、過去30年以上にわたって企業で主流の技術として使用されてきたため、データウェアハウスや SQL に関するスキルを持った人材も豊富です。
データウェアハウスに満足しており、データ統合に関する課題もないのであれば、何も変える必要はありません。
一緒に使う方法
データハブとデータウェアハウスは容易に共存できます。MarkLogic のお客様は、しばしばこの2つを併用しています。
ほとんどの組織には、すでにデータウェアハウスがあります。ここで、これらのデータウェアハウスからのデータを統合する必要が発生したけれど、すべてのデータを統合する共通スキーマを構築するための ETL やデータモデリングに多くの時間とコストをかけられないとします。
この問題を解決するものとして、これらの分断されたデータウェアハウスのデータ (およびその他のあらゆるデータサイロ) を統合できるデータハブがあります。導入したデータハブを利用し、アプリケーションの基盤としたり、キュレーションしたデータを別の下流のデータウェアハウスに渡したり、低コストなストレージとして最適化されているファイルシステムにデータをオフロードできます。
このように、データウェアハウスは依然としてアーキテクチャの重要な要素ですが、データハブを導入することにより、データ統合プロセス全体をよりアジャイルで信頼性のあるものにできます。
導入事例
データウェアハウスを MarkLogic データハブで補完または置き換えることを選択した多くのお客様がいます。エアバス、ノーザン・トラスト、 ハノーバー再保険、 シェブロンなどの事例があります。
