世の中に変化はつきものですが、ずっと変わらないこともあります。業務、業界を問わず、データの「サイロ」（分断）は依然として存在していると言ってよいでしょう。そしてこれらのデータサイロにより、企業や官公庁などの世の中の変化に対する対応が遅くなっています。
データサイロがこの問題の根本的原因である場合があります。例えば、データが2つ（あるいは10個）のシステムに分断されているために、一見簡単に見える質問に答えられない場合があります。また、データがバラバラになっていて互換性がないために、イノベーションが阻害されている場合もあります。この際、責任を負うべきはデータサイロなのですが、代わりに開発チームや管理職が非難されることになってしまいます。
残念ながら、サイロのデータを統合することは極めて困難です。分散データの統合に対する究極の解決策は存在しません。しかし問題改善へのブレークスルーとなる新技術がいくつかあります。
このブログでは、新しい3つのアプローチ、すなわち仮想データベース（別名：データベース「フェデレーション」）、データレイク、データハブについてご紹介し、その違いと長所・短所を説明します。
MarkLogicはこれら3つの手法を、程度の差はありますがすべてをサポートしています。しかし、データハブが一番望ましいと考えています。以下で、データハブがベストな理由、またMarkLogicがこれをどのようにサポートしているのかを説明します。データハブ構築の予定がなくても、またMarkLogicを使ってない人にとっても、このブログは役に立つことをお約束します。
従来の方法：包括的エンタープライズモデリング
最初に従来のアプローチについて簡単に触れておきます。以前は（あるいは現在でもたまに）、組織内のすべてのサイロに含まれるすべてのフィールドと値を含む包括的なデータモデルを新規構築していました。その後、新しいデータウェアハウス内にあるこの新しいモデルに対して、すべてのサイロをETLでマッピングしていました。
ITBusinessEdgeが行った企業調査によると、このアプローチでは失敗することが明白です。調査結果によれば、予算超過やプロジェクトの失敗が必ず発生しています。
ここではこれには触れずに、仮想データベース、データレイク、データハブについて説明します。これらは、この問題への新しい解決策となります。
定義：仮想データベース、データレイク、データハブ
まず最初に、これらの用語を定義しておきましょう。
仮想データベース
「仮想データベース」は、クエリを受け付け、大きなデータベースのように振る舞うシステムです。この中にはサイロ化され分散しているデータセットが数多く含まれています。実際に、これはバックエンドのシステム（ライブ/実稼働/ウェアハウス）に対してリアルタイムでクエリを投げます。その際に、データを一般的な形式に変換します。
これは「フェデレーションデータベース」とも呼ばれます。また統合されている個々のサブシステムのことを、「フェデレート」と呼びます
データレイク
「データレイク」はHadoopのコミュニティーが広めた用語で、定義は複数あります。広義では、分断されたサイロからのデータを1つのシステム（Hadoop/HDFS）に入れた場合、このシステムがデータレイクとなります。ここでデータは必ずしも、ハーモナイズやインデックス付けがされておらず、また検索可能になったり使い易くなっている訳ではありません。しかし、少なくともレコードへアクセスしたい場合に、ライブの実稼働システムに接続する必要はありません。
データハブ
「データハブ」はハブ＆スポークのアプローチでデータを統合するものです。ここでデータは新しいシステムに物理的に移動され、インデックスが付け直されます。データハブでは（データレイクとは違って）、発見、インデックス付け、分析をサポートしています。
移動、ハーモナイゼーション、インデックス付け
ここではこれらの3つの違いを紹介します。いつ、どこで使われるのか、また「移動」「ハーモナイゼーション」「データのインデックス付け」の有無に関して比較します。詳細な定義については以下にあります。
「移動」「ハーモナイゼーション」「インデックス付け」といった用語は、ここでは特別な意味を持ったものとして扱います。この3つが、データレイク、データハブ、フェデレーションを区別する上での重要な概念となります。
データの移動
データハブとデータレイクではどちらも、データは「移動」されます。サイロからのデータは、新しいディスク群にコピーされ、新しいサーバーやソフトウェアによって処理されます。今やディスクはとても安くなっています。このため、別のデータストアを持つこと（つまりルックアップのたびに毎回実稼働サーバーを見に行かなくてもよいこと）の業務上の（そして組織にとっての）メリットは極めて大きいです。
一方、仮想（フェデレーション）データベースでは、個々のクエリを各ソースシステムに対応させます。このため、データは移動されず、サイロ内に残っています。
データのハーモナイズ
ハブとフェデレーションでは両方とも、データのハーモナイズを行います（フェデレーションの場合は、データが返されて処理されたときしか行いませんが）。さまざまなサイロ内にあるデータは、その形式、フィールド名、スキーマが異なっています。しかし最終的な提供段階においては、レコードはグループとしてまとめて処理できるように最低限似たものになっている必要があります。ハーモナイゼーションは以下の3つのカテゴリで行われます。
- 名前の付け方の違い：一番単純に扱えるものとして、名前の付け方（命名法）の違いがあります。例えば、値も意味も全く同じものが、別のサイロでは名前が違う場合です。例：「PERSON.firstName」と「IDENTITY.GIVEN_NAME」が、別個の2つのリレーショナルデータベースのテーブル内にあります。しかしこれらのデータの内容は同じです。
- 構造の違い：名前の付け方よりも若干複雑なものとして、構造の違いがあります。例えば、サイロ間でフィールドの個数や組み合わせが異なる場合です。例：「boxes_available」は、あるシステムでは在庫の箱数を表し、これと「count_per_box」フィールドを使うことでアイテムの総数を計算できます。しかし他のシステムでは「total_items」だけでアイテムの総数が示されています（箱数から算出する必要はありません）。別の例：「在庫」とは、あるシステムでは発注分に割り当てられていないものを表し、他のシステムでは（発注に関わらず）物理的に在庫として存在している全てを表しています。
- セマンティック（意味論的な）の違い：これが一番厄介です。患者のステータスとして、あるシステムでは3種類あるのに、もう1つのシステムでは5種類ある場合が考えられます。これらのステータスは、オーバーラップしている（被っている）ことが多く、相互の関係付けが困難です（{Scheduled, Needs_Followup, Inactive}対{Intake, Scheduled, Telemedicine-only, Discharged}など）。
アジャイル性のための段階的ハーモナイゼーション
「ハーモナイゼーション」は、すべてのアプローチにおいて行われます。結局のところ、きちんと構造化されたAPIやデータエクスポート（あるいはレポート）は、定義された形式で一貫性のあるデータを返さなくてはなりません。しかしながら、ハーモナイゼーションはアジャイルかつ段階的に行えます（行うべきです）。
通常は、重要要件は初期の段階で特定され、それに関連するデータ要素も「重要なデータ要素」として定義されて、最初にハーモナイズされます。時間の経過につれ要件が追加されると、ハーモナイゼーションの対象となるデータがどんどん増えます。重要データのハーモナイゼーションを、「部分的」ハーモナイゼーションと呼びます。一方、時間の経過につれてハーモナイズされるサブセットが増えていくプロセスを、「段階的」ハーモナイゼーションと呼びます。
MarkLogicはこれがとても得意です。というのも、MarkLogicサーバーでは、ソースシステムからのデータの構造を「ハーモナイズ」されたバージョンと元のバージョンの両方でインデックス付けするからです。このため、ある検索や処理はデータレイク方式で行われ、一方、重要データはハーモナイズされた形式でインデックス付けならびにアクセスされます。
インデックス付け
これらのアプローチを定義し区別する特徴の最後として、データへのインデックス付けの方法とタイミングがあります。インデックスがあると、インデックスが付けられた任意のフィールドに基づいて高速なルックアップと分析ができます。インデックスはディスクに書き込まれ、データフィールド自体に対して作成されます。このためデータの移動方法ならびにハーモナイズ方法によって、インデックス付けの方法が変わってきます。
- フェデレーション（仮想）データベースでは、インデックス付けは全く行われません。またインデックスを格納するための、独立したデータストレージもありません。また、十分なインデックス付けを行うには、さまざまなサイロとソースシステムに依存する必要があります（このやり方は正しくなく、その前提も間違っていますが）。このアプローチでは、全てのリクエストを、個々のソースシステム用の別個のリクエストにマッピングし、すべてのソースシステムに対して実行します。
- データレイクでは、インデックス付けはほとんど行われません。まれにインデックス付けを行うのは、追加コンポーネントを統合する場合です（大量のコンポーネントを統合すると、「フランケンシュタイン（継ぎはぎ）スタック」ができてしまいます）。ここでは、各部分（より小さなデータマート、SOLRテキストインデックス、インデックス付きHBaseテーブルなど）に個別にインデックスを付けます。こういったフランケンシュタインシステムに関する私の個人的な体験についてお読みください。
- データハブでは、すべてのデータを一か所に移動します。また一部あるいは全体をハーモナイズし、その後、「ハーモナイズされた形式のデータにインデックスを付ける」というのが理想的です。というのも最も役立つインデックスというのは、ハーモナイズされたデータに付けられたものだからです。
苦しみの世界
当然のことながら、データの名前の付け方に一貫性がなく、根本的な構造が異なっており、セマンティックが異なっており、インデックスが付けられていないという場合、データの集計、発見、分類、分析は極めて困難です。あなた自身や開発者たちがこれらの違いを何とか吸収できるかもしれません。しかしこれは注意深くやらないと、却って状況を悪化させることになりかねません。管理されていないコードが、何十というレポート、バッチ処理、ETLジョブなどに溢れかえることになってしまいます。
違いのまとめ
という訳で、アプローチが3つ、そしてそれらの違いを示す基準が3つあります。次に、これら3つのアプローチと、各基準におけるそれぞれの内容を表にしてみます。
