データレイク、データハブ、フェデレーション: どれが最良か?

世の中に変化はつきものですが、ずっと変わらないこともあります。業務、業界を問わず、データの「サイロ」(分断)は依然として存在していると言ってよいでしょう。そしてこれらのデータサイロにより、企業や官公庁などの世の中の変化に対する対応が遅くなっています。

データサイロがこの問題の根本的原因である場合があります。例えば、データが2つ(あるいは10個)のシステムに分断されているために、一見簡単に見える質問に答えられない場合があります。また、データがバラバラになっていて互換性がないために、イノベーションが阻害されている場合もあります。この際、責任を負うべきはデータサイロなのですが、代わりに開発チームや管理職が非難されることになってしまいます。

残念ながら、サイロのデータを統合することは極めて困難です。分散データの統合に対する究極の解決策は存在しません。しかし問題改善へのブレークスルーとなる新技術がいくつかあります。

このブログでは、新しい3つのアプローチ、すなわち仮想データベース(別名:データベース「フェデレーション」)、データレイク、データハブについてご紹介し、その違いと長所・短所を説明します。

MarkLogicはこれら3つの手法を、程度の差はありますがすべてをサポートしています。しかし、データハブが一番望ましいと考えています。以下で、データハブがベストな理由、またMarkLogicがこれをどのようにサポートしているのかを説明します。データハブ構築の予定がなくても、またMarkLogicを使ってない人にとっても、このブログは役に立つことをお約束します。


従来の方法:包括的エンタープライズモデリング

従来の方法:包括的エンタープライズモデリング

最初に従来のアプローチについて簡単に触れておきます。以前は(あるいは現在でもたまに)、組織内のすべてのサイロに含まれるすべてのフィールドと値を含む包括的なデータモデルを新規構築していました。その後、新しいデータウェアハウス内にあるこの新しいモデルに対して、すべてのサイロをETLでマッピングしていました。

ITBusinessEdgeが行った企業調査によると、このアプローチでは失敗することが明白です。調査結果によれば、予算超過やプロジェクトの失敗が必ず発生しています。

ここではこれには触れずに、仮想データベース、データレイク、データハブについて説明します。これらは、この問題への新しい解決策となります。


定義:仮想データベース、データレイク、データハブ

まず最初に、これらの用語を定義しておきましょう。

仮想データベース

「仮想データベース」は、クエリを受け付け、大きなデータベースのように振る舞うシステムです。この中にはサイロ化され分散しているデータセットが数多く含まれています。実際に、これはバックエンドのシステム(ライブ/実稼働/ウェアハウス)に対してリアルタイムでクエリを投げます。その際に、データを一般的な形式に変換します。

これは「フェデレーションデータベース」とも呼ばれます。また統合されている個々のサブシステムのことを、「フェデレート」と呼びます

データレイク

「データレイク」はHadoopのコミュニティーが広めた用語で、定義は複数あります。広義では、分断されたサイロからのデータを1つのシステム(Hadoop/HDFS)に入れた場合、このシステムがデータレイクとなります。ここでデータは必ずしも、ハーモナイズやインデックス付けがされておらず、また検索可能になったり使い易くなっている訳ではありません。しかし、少なくともレコードへアクセスしたい場合に、ライブの実稼働システムに接続する必要はありません。

データハブ

「データハブ」はハブ&スポークのアプローチでデータを統合するものです。ここでデータは新しいシステムに物理的に移動され、インデックスが付け直されます。データハブでは(データレイクとは違って)、発見、インデックス付け、分析をサポートしています。


移動、ハーモナイゼーション、インデックス付け

ここではこれらの3つの違いを紹介します。いつ、どこで使われるのか、また「移動」「ハーモナイゼーション」「データのインデックス付け」の有無に関して比較します。詳細な定義については以下にあります。

「移動」「ハーモナイゼーション」「インデックス付け」といった用語は、ここでは特別な意味を持ったものとして扱います。この3つが、データレイク、データハブ、フェデレーションを区別する上での重要な概念となります。

データの移動

データハブとデータレイクではどちらも、データは「移動」されます。サイロからのデータは、新しいディスク群にコピーされ、新しいサーバーやソフトウェアによって処理されます。今やディスクはとても安くなっています。このため、別のデータストアを持つこと(つまりルックアップのたびに毎回実稼働サーバーを見に行かなくてもよいこと)の業務上の(そして組織にとっての)メリットは極めて大きいです。

一方、仮想(フェデレーション)データベースでは、個々のクエリを各ソースシステムに対応させます。このため、データは移動されず、サイロ内に残っています。

データのハーモナイズ

ハブとフェデレーションでは両方とも、データのハーモナイズを行います(フェデレーションの場合は、データが返されて処理されたときしか行いませんが)。さまざまなサイロ内にあるデータは、その形式、フィールド名、スキーマが異なっています。しかし最終的な提供段階においては、レコードはグループとしてまとめて処理できるように最低限似たものになっている必要があります。ハーモナイゼーションは以下の3つのカテゴリで行われます。

  1. 名前の付け方の違い:一番単純に扱えるものとして、名前の付け方(命名法)の違いがあります。例えば、値も意味も全く同じものが、別のサイロでは名前が違う場合です。例:「PERSON.firstName」と「IDENTITY.GIVEN_NAME」が、別個の2つのリレーショナルデータベースのテーブル内にあります。しかしこれらのデータの内容は同じです。
  2. 構造の違い:名前の付け方よりも若干複雑なものとして、構造の違いがあります。例えば、サイロ間でフィールドの個数や組み合わせが異なる場合です。例:「boxes_available」は、あるシステムでは在庫の箱数を表し、これと「count_per_box」フィールドを使うことでアイテムの総数を計算できます。しかし他のシステムでは「total_items」だけでアイテムの総数が示されています(箱数から算出する必要はありません)。別の例:「在庫」とは、あるシステムでは発注分に割り当てられていないものを表し、他のシステムでは(発注に関わらず)物理的に在庫として存在している全てを表しています。
  3. セマンティック(意味論的な)の違い:これが一番厄介です。患者のステータスとして、あるシステムでは3種類あるのに、もう1つのシステムでは5種類ある場合が考えられます。これらのステータスは、オーバーラップしている(被っている)ことが多く、相互の関係付けが困難です({Scheduled, Needs_Followup, Inactive}対{Intake, Scheduled, Telemedicine-only, Discharged}など)。

アジャイル性のための段階的ハーモナイゼーション

「ハーモナイゼーション」は、すべてのアプローチにおいて行われます。結局のところ、きちんと構造化されたAPIやデータエクスポート(あるいはレポート)は、定義された形式で一貫性のあるデータを返さなくてはなりません。しかしながら、ハーモナイゼーションはアジャイルかつ段階的に行えます(行うべきです)。

通常は、重要要件は初期の段階で特定され、それに関連するデータ要素も「重要なデータ要素」として定義されて、最初にハーモナイズされます。時間の経過につれ要件が追加されると、ハーモナイゼーションの対象となるデータがどんどん増えます。重要データのハーモナイゼーションを、「部分的」ハーモナイゼーションと呼びます。一方、時間の経過につれてハーモナイズされるサブセットが増えていくプロセスを、「段階的」ハーモナイゼーションと呼びます。

MarkLogicはこれがとても得意です。というのも、MarkLogicサーバーでは、ソースシステムからのデータの構造を「ハーモナイズ」されたバージョンと元のバージョンの両方でインデックス付けするからです。このため、ある検索や処理はデータレイク方式で行われ、一方、重要データはハーモナイズされた形式でインデックス付けならびにアクセスされます。

インデックス付け

これらのアプローチを定義し区別する特徴の最後として、データへのインデックス付けの方法とタイミングがあります。インデックスがあると、インデックスが付けられた任意のフィールドに基づいて高速なルックアップと分析ができます。インデックスはディスクに書き込まれ、データフィールド自体に対して作成されます。このためデータの移動方法ならびにハーモナイズ方法によって、インデックス付けの方法が変わってきます。

  • フェデレーション(仮想)データベースでは、インデックス付けは全く行われません。またインデックスを格納するための、独立したデータストレージもありません。また、十分なインデックス付けを行うには、さまざまなサイロとソースシステムに依存する必要があります(このやり方は正しくなく、その前提も間違っていますが)。このアプローチでは、全てのリクエストを、個々のソースシステム用の別個のリクエストにマッピングし、すべてのソースシステムに対して実行します。
  • データレイクでは、インデックス付けはほとんど行われません。まれにインデックス付けを行うのは、追加コンポーネントを統合する場合です(大量のコンポーネントを統合すると、「フランケンシュタイン(継ぎはぎ)スタック」ができてしまいます)。ここでは、各部分(より小さなデータマート、SOLRテキストインデックス、インデックス付きHBaseテーブルなど)に個別にインデックスを付けます。こういったフランケンシュタインシステムに関する私の個人的な体験についてお読みください。
  • データハブでは、すべてのデータを一か所に移動します。また一部あるいは全体をハーモナイズし、その後、「ハーモナイズされた形式のデータにインデックスを付ける」というのが理想的です。というのも最も役立つインデックスというのは、ハーモナイズされたデータに付けられたものだからです。

苦しみの世界

当然のことながら、データの名前の付け方に一貫性がなく、根本的な構造が異なっており、セマンティックが異なっており、インデックスが付けられていないという場合、データの集計、発見、分類、分析は極めて困難です。あなた自身や開発者たちがこれらの違いを何とか吸収できるかもしれません。しかしこれは注意深くやらないと、却って状況を悪化させることになりかねません。管理されていないコードが、何十というレポート、バッチ処理、ETLジョブなどに溢れかえることになってしまいます。


違いのまとめ

という訳で、アプローチが3つ、そしてそれらの違いを示す基準が3つあります。次に、これら3つのアプローチと、各基準におけるそれぞれの内容を表にしてみます。

アプローチ データは移動されるか? データはハーモナイズされるか? データにインデックスが付けられるか?
フェデレーション いいえ。データはサイロに残されたまま すべてクエリ時に行われる インデックスは付けない。クエリをソースシステムに分担してもらう
データレイク はい。データは一か所に移動される。しかしソース形式のまま 若干。しかし管理可能ではない。データレイクでは、対象フィールドの合計や相関を行うためには、分析ならびにレポーティング用のコードをビジネスロジック内で暗黙的にハーモナイズする必要がある。

このやり方では、さまざまなデータ形式の扱いは個々のアルゴリズムやETLプロセスに委ねられる

ほとんどされない。互換性のない形式のデータが大量にある場合、データにインデックスを付けることは困難
データハブ はい。データは一か所に移動される はい。移動の際に、データは(少なくとも一部は)ハーモナイズされる はい。効率的なアクセスと分析ができるように、ハーモナイズされたデータに対してインデックスを付ける

各アプローチが意味するところ

これで各アプローチの違いはだいぶ分かってきたと思います。しかし「悪魔は細部に宿る」と言います。

という訳で、こういった違いにどのような意味があるのか、さらに追求していきます。現実の世界ではこれがどう行われるのかについて、そしてその中でもデータハブがベストな解決策であることを示します。

仮想データベース(フェデレーション)とは何なのか

仮想(フェデレーション)データベースは、クエリの際にソースシステムに依存します。このため、ソースシステムの機能に制約を受けます。

必要最低限のクエリ:ソースシステムやサイロのうち1つでも、クエリをサポートしていないものがあった場合(このクエリが、特定フィールドに基づく検索やソート、位置(緯度経度)情報、テキスト検索、カスタムの重要度スコアを行うものだった場合)、このシステム全体がこのクエリをサポートできないことになります。つまり、後から何らかのシステムを新しく追加した場合、フェデレーション全体の機能が改善されるどころか損なわれる可能性があります。

クエリの再マッピング:仮想(フェデレーション)データベースの特徴的な欠点としては、システムに対するクエリは、フェデレーションを構成している個々のサイロやサブシステム用に大量のクエリ/リクエストに変換しなくてはならない、ということがあります。これには追加開発が必要で、フェデレーションシステムとサイロの関係が固定的になります。

リアルタイムデータ:これはフェデレーションのメリットの1つです。変更検知機能は不要で、実装する必要もありません。使用中のさまざまなソースやサイロに、毎時/毎日など定期的な変更検知の機能が備わっていない場合、組織ではこの問題を解決する必要があります。しかしフェデレーションのシステムがクエリを実行するのは、常にライブデータに対してのみです。つまり、ソースシステム変更の検知機能がなくても、常にリアルタイムになっています。

オペレーションの分離:フェデレーションシステムは、その構成要素(「フェデレート」)が1つでも落ちたら全体が落ちます。あるいは、パフォーマンスが落ちた状態で部分クエリをサポートするには、複雑なクエリあるいはユーザーの介入が必要です。往々にして、ライブのソースシステムには、最小限のリアルタイムのクエリですら、ましてや重要なバッチ処理の機能などはありません。このためフェデレートされている仮想データベースが落ちたり、重要な上流のシステムに対する影響が発生する可能性があります。

この図は、フェデレーションにおける、ハーモナイゼーションの「ジャストインタイム」形式を示しています。

仮想(フェデレーション)

仮想(フェデレーション)データベースは、すべてのハーモナイゼーションをリアルタイムで行います。このため「業務/ビジネスを行う」ためのリアルタイムのwebサービスをサポートできます。しかし、通常、バッチ処理や分析をサポートできるように拡張することはできません。フェデレーションデータベースでは、業務の一部を実行できます。しかし、各システムに対する負荷がどの程度になるのか注意を払う必要があります。

仮想(フェデレーション)データベースに関する私見のまとめ:

10個の異なるシステムに対して慌ただしくクエリを実行しているシステムを自動化したところで、10個のシステムに対して慌ただしくクエリを実行していることには変わりはありません。いずれにせよ、あまり意味がありません。


データレイクとは何なのか

オペレーションの分離:データレイクは、フェデレーションシステムよりはましです。というのもデータを別のインフラに移動しているため、業務が分離されるからです。これが、この方法の最大のメリットです。

クエリ:データレイクでは、データへのインデックス付けやデータのハーモナイズを行いません。また、ソースシステムのインデックスも利用できません。つまり、クエリ機能に関して言えば、データレイクの方が仮想(フェデレーション)データベースよりも劣っています。

バッチ処理:データレイクは(および一般的に言ってHadoopシステムも)、ある程度バッチ処理が得意です(予測分析を含む)。どんな状況でも常にすべてのレコードを読み込んで処理したい場合、洗練されたクエリは必要なく、インデックスがなくても何とかやっていけます。

単純さと管理のし易さ:データレイクでは、データの形式はさまざまなので、バッチ処理、ETL、分析のそれぞれにおいて複雑なロジックが必要です。このコードはすぐに管理不能になり、一貫性が取れず、古くなるので、重荷となります。

仮想(フェデレーション)

データレイクでは、分析や出力の際、あるいは分断されたさまざなまデータ形式をETLでバッチ読み込みして新しい形式に変換する際などに、データを無理やり処理するためのバッチ分析が必要とされます。このため通常は、リアルタイムの処理用ではなく、データ分析やインサイト用になります。データレイクは、分析/バッチ用という性格上、「ビジネスを確認する」ことはできますが、「ビジネスを遂行する」ことはできません。

データレイクでは、実際のところETLによってデータのハーモナイズを行っているので、データハブに近づいてはいます。しかし企業でのビジネス遂行に必要なトランザクションやリアルタイム機能はありません。

データレイクに関する私見のまとめ:

子供が部屋を散らかしたあと、床の上に落ちていたものを拾ってクローゼットに投げ込んだとします。クローゼットの扉を閉めてしまえば、部屋は片付いたといえるでしょうか?それとも単に一か所に集められただけで、まだ散らかっているのでしょうか?

データハブとな何なのか

クエリ:データハブでは自分のインデックスを管理します。またこれらのインデックスをハーモナイズされたデータ上に作成します。前述のように、ハーモナイゼーションは段階的でアジャイルなプロセスです。このためハーモナイズされたデータの幅が広がるにつれて、インデックスのパワーも増していきます。

一方、他のシステムでは基本的に「必要最低限」のインデックスやクエリに留まらざるを得ません。フェデレーションにおいてもクエリはサポートされますが、クエリが利用できるのは、フェデレーション内で最も能力が低いシステムでもサポートされている場合だけです。データレイクは、分析やレポーティング処理もサポートしますが、これが利用できるのは、データレイク内の最も「汚く」、最低限の互換性しかないデータソースをコードが扱える場合だけです。

つまり、クエリは最も能力が低いシステムや、ハーモナイズやインデックスがないデータソースに制約を受けるということです。しかしデータハブを使えば、クエリは一番強力なソースシステムをも超えられます。これはハーモナイズされたデータにインデックスを付けているからです。

MarkLogicは、フィールド、XML構造、JSON構造、テキスト、RDFセマンティックデータ、位置データにインデックスを付けます(すべて標準機能です)。またバイナリデータも格納できます。この際、Word文書、PDF、JPEGなどのバイナリ形式からテキストやメタデータを抽出して、バイナリデータと一緒に格納します。この理由により、通常MarkLogicではデータハブをお勧めしています。

オペレーションの分離:データレイクの場合と同様に、データハブでもデータを別のディスクやインフラに移動させます。つまり、読み込みや管理は、ソースシステムから分離されています。

バッチ処理:データレイクの場合と同様に、必要に応じてデータハブ内でクエリや処理が行えます。データレイクと違うのは、データハブではクエリの際にインデックスを利用して、特定用途における処理対象のデータ量を制限できることです。また高速なルックアップや、バッチジョブの際に「サブバッチ」を使用することなく、関連性の高いレコードを発見するためのデータ結合ができます。

単純さと管理のし易さ:データハブでは、少なくとも部分ハーモナイゼーションは行われるため、すべてのデータを共通コードで処理できます。前述の在庫の例で言うと、ハーモナイズされたデータセットでは、ハーモナイズされたフィールドとして「unitsOnHand」を持つことができます。これはこのデータが互換性のない任意のソースシステムから来ていても問題ありません(「total_items」対「boxes_available」)。ハーモナイズされたフィールドにはインデックスが付けられ、統一されます。これにより在庫情報へのアクセスが大幅にシンプルになります。

発見と探索:データハブでは、アドホックな(事前に予想できなかった)分析を簡単に行うことができます。データを一か所に移動し、重要なデータ要素をハーモナイズするという難しい作業は、移動とインデックス付けの際に終わっています。このため、必要な際に、クエリ、やり取り、フィルタリング、ドリルダウンを簡単に行うことができます。

クエリの再マッピング:データハブでは各ソースシステムへのクエリのマッピングを行いません。ここでは最初にデータをハーモナイズし、統一されたデータセットに対してインデックスを付けています。ここで注意したいのは、ハーモナイゼーションは「開発のサンクコスト」であるということです。これは、各ソースから形式が異なるデータを返すシステムを実現することがなかなか困難だからです。いずれのアプローチにおいても、遅かれ早かれハーモナイズを行う必要があります(各レポートに含まれるカスタムコードを使うなどして)。データハブでは、ハーモナイゼーションの後にインデックス付けと格納を行うことで、シンプルで統一的なクエリを利用できます。

従来の方法:包括的エンタープライズモデリング

データハブでは、データにインデックスをつけ、クエリの対象として利用できるようにしますが、その際に一般的な共通形式にします。このため、webサービス、リアルタイムアプリケーション、バッチ、分析などで利用できます。とりわけリアルタイムサービスを利用できるため、データハブで「ビジネスを遂行する」ことができます。

データハブに関する私見のまとめ:

データハブを構築すべきです。これは最も強力であるだけでなく、開発と保守が最も簡単だからです。


MarkLogicを選ぶ理由

これまでの情報が、みなさんが使用中のアプローチや最終的なアーキテクチャに関わらず、役に立つものであれば幸いです。ここまでデータハブのアプローチが他よりも優れていることを説明してきました。ではなぜデータハブの構築にMarkLogicを使ったほうが良いのでしょうか?

MarkLogicサーバーは、データレイクもフェデレーションもサポートしています。しかし私たちはデータハブが一番優れているという前提に立ち、業務をスムーズに行うための機能を10年以上にわたって開発してきました。

例えば以下のような機能があります。

ユニバーサルインデックス:MarkLogicはあらゆるデータを「アズイズ(そのまま)」で読み込んで、格納し、インデックスを付けます。一般的なレコード形式(XML、JSON、RDF)に含まれる構造を活用し、この構造に対し自動的にインデックスを付けます(コーディングは不要です)。

巨大な規模:MarkLogicは、もともと明快なクラスタ構成として使われることを想定して作られています。またリバースインデックスを使用します。これにより、MarkLogicは検索エンジンのように水平拡張します(他の多くのデータベースのように垂直拡張ではありません)。

MarkLogicのTCO(総所有コスト):大量のデータが統合され利用可能になると、MarkLogicは、あまり重要ではないデータを廉価なストレージ(HDFSやS3)に自動的に移動します。これにより計算処理のパフォーマンスとコストのバランスを取ります。

世界レベルのセキュリティ:どのようなビジネスにおいてもサイロの根絶は重要な問題です。またデータへのアクセスを楽にすることも大切です。しかしデータへのアクセスを楽にするとデータが簡単に盗まれることにもなりかねません。MarkLogicには、業界最高のロールベースのセキュリティとコンパートメントセキュリティが備わっており、これによりデータをレコード単位で守ります。MarkLogic9からは、フィールド単位で自動リダクション(「墨塗り」)ができます。

柔軟で業界標準準拠のサービス:MarkLogicには、検索用REST APIがあり、これを使って統合データの表示やカスタマイズができます。また提供時に、データを自由に変換できます。このため、あらゆるクライアントやAPIが必要とする形式で統合データを提供できます。通常これは、さまざまなJSON、XML、RDF、CSV形式となります。

テキスト検索:MarkLogicは、それぞれのデータベース設定ごとに、すべての語に対してインデックスを付けます。ステミング(語幹処理)、フレーズ検索、tf/idf関連度、and/or/not/近接クエリ、複合語の分割、多言語対応など、フル機能の検索製品に求められる機能はすべて含まれています。

位置クエリ:データを統合すればするほど、データへの多様なアクセス方法が必要となってきます。MarkLogicには、さまざまな標準機能が備わっています。例えば緯度経度に基づく位置クエリにおいて、地点、多角形、距離、多角形内の「くり抜き」などを利用できます。

これだけでも大量の機能があることがわかるでしょう。話がうますぎるように思う人もいるかもしれません。

でも前述したように、私たちはこれを10年以上やってきているのです。

もっと知りたい方は以下をどうぞ。

オペレーショナルデータハブ: 平均15分ほどの短いビデオのシリーズです(英語)。データハブの作成方法を順を追って説明しています。