データウェアハウス、データマート、データレイク、そしてデータハブへ

いったん作成されたデータは、さまざまな方法で何度も利用できるのが理想でしょう。またデータの価値は、集約したり関連付けることでさらに高まります。これを実現する最善の方法は、時間とともに進化してきています。

「適切な情報を/適切なタイミングで/適切な人に」というのはシンプルに聞こえますが、これを実現するプラットフォームを作るにはかなりのお金と時間がかかります。経営的には「データアクセスの改善に投資したら、それなりの見返りがある」ことが求められるのは当然でしょう。どの組織でも、すぐに解決しなければならない事案が1、2個あるのが普通ですが、実際にはその背後にもっと多くの事案が隠されていることでしょう。

初期のデータ集約

まず最初は「データウェアハウス」でした。これは、かなり昔からあります。

典型的な使用例は「財務/製造/セールスなどの表形式データを読み込み、レポーティングツールを使って部門横断的に把握する」というものです。

当初、これは簡単にはできませんでした。今では一般的になった問題（データの整合性、パフォーマンス、セキュリティなど）への対応が大変だったことを、私もよく覚えています。

しかしこれらのシステムが、シンプルなレポート作成からリアルタイム分析（OLAP）や自動意思決定に発展したことで、状況は改善されました。この時「オペレーショナルデータウェアハウス」という言葉が登場しました。これにより、例えばネットショップで特定商品の需要が急増した場合、その出荷判断を自動化できるようになりました。あるいは自動的に価格を変更することもできます。

データウェアハウスは今でも便利ですが、これはそもそもシンプルな形式のデータ用だということを忘れない方が良いでしょう。つまり、他の主要システムからの大量のリレーショナルデータを対象にすることが一般的なのです。

その後、興味深いバリエーションとして「データマート」が登場しました。これは主要なデータウェアハウスでは対応できない特定業務用です。

データマートの利用者は、自分固有のニーズのために独自のやり方で作業したかったのです（共有されている標準ソリューションではうまくいかないため）。

業界によってはデータマートの人気が出すぎて、大量発生したことが問題となりました。ここにおいて、費用はさておき、複数の業務部門間で「真実」を共有することが重大な課題となってきました。というのも人々は皆個別に「自分たちの」データを使っているからです。

この結果、データの「全社的標準 vs 業務部門の要件」という興味深い問題が発生し、これについては未だに議論が続いています。

そしてデータがサイエンスとなった

その後、データサイエンスの大流行により、流れが変わりました。新しく登場したデータサイエンティストたちは、驚くほどインパクトのある知見をもたらし、経営陣から大きく注目されました。

これらのデータサイエンティストは、乱雑で分断された（しかしシンプルな）データソース（通常はwebからの）を扱う方法、またこれらのデータを関連付けることでユニークな知見を得る方法を発見したのです。

彼らは新しい方法でデータを扱うため、新しいプラットフォームが必要となりました。

ここでデータレイクが登場しました。これは高度な分析と機械学習に取り組む専門家チーム用に設計されました。これは巨大なファイルシステムに基づき、ほぼすべてがオープンソースのツールが組み合わされています。私のようなデータオタクにとっては、これはかなり素敵です。

しかしこの場合でも、ほとんどのデータレイクはシンプルデータ用なのです。

データハブの登場

ここまで説明したものはすべて、シンプルデータを集約するものです。それではもっと複雑なデータ（＝コンプレックスデータ）についてはどうなるのでしょうか。

データが複雑になるのは「データ自体が本質的に複雑である」（たとえば、ドキュメントや帳票など）あるいは「標準に準拠しないさまざまなシンプルデータが大量にある」ためです。こういった状況はどちらも、さまざまな業界で当たり前のように存在します。

複雑になるもう1つの原因として、データの件数を大量増殖させないように、業務部門のニーズと全社的な要件のバランスを取りながら、両方の情報を反映させていることもあります。

この場合、エンタープライズデータの「ゴールドスタンダード」を共有し、各業務部門はデータのコピーを新たに作成することなく、必要に応じて異なる形式で利用できる（異なる「レンズ」で見る）のが理想です。

データハブを現実世界で例えるならば、巨大な物流センターのようなものです。ここでは、生産者から届いた大量の商品を、購入依頼に応じてパッケージを変えたり、製品を組み合わせ直したりします。

これが複雑になるのは自然なことです。というのも届けられる物品の多様なパッケージはこちら側の都合とは全く関係なく、変更の依頼もできないためです。ここでは、とにかくこれらを入荷し格納し処理する必要があります（幸いなことにバーコードを利用できますが）。Amazonでは、パッケージの変更や出荷はオンデマンドで行われており、自動化が極めて進んでいます。

機密データを含む可能性が高いエンタープライズデータに対して同様のことを行う場合、これに出自/コンプライアンス/セキュリティといった問題が加わります。

これが重要な理由

大企業は、データウェアハウスやデータマートの長所および短所をよく理解しています。データウェアハウスとデータマートは、両方とも長いこと存在しているからです。また、分析チーム専用の環境として何らかのデータレイクができている可能性もあります。こういったことには、特に問題はありません。これらはすべて、シンプルデータではうまくいくのです。

一方、「コンプレックス（複雑な）データ」を扱わなければならない業務部門では対応が遅れていることが多いです（コンプレックスデータの例としては、「データ自体が複雑なもの（ドキュメントなど）」や「標準にきちんと準拠していない複数のソースからのデータ」などがあります）。また、全社的標準の作成時には想定されなかった形式で、情報を表示する必要が出てくることはよくあります。

こういった場合「データハブ」プラットフォームが適しています。これはリアルタイムの物流センターと呼べるもので、ビジネスユーザーのニーズに応じてあらゆる形式のデータソースを受け入れ、データ間の重要な関連付けを行い、オンデマンドで提供します。

従来のデータウェアハウスと同様、データハブプラットフォームは一般業務でも利用できます。つまり、拡張性があり意思決定を自動化するアプリケーションを構築できるのです。また一元的なデータAPIがあるので、開発期間が短縮されます。

これを実現するには

「馴染みのあるデータウェアハウス、データマート、さらにはデータレイクでさえ、すべてのニーズを満たすことはできない」ということを人々が理解するに至る経緯を、私は興味深く見てきました。

これらのプラットフォームはすべて、シンプルデータ（表、きちんと構造化されたオブジェクトなど）用に設計されています。このためこれらをコンプレックスデータに使用した場合、コンプレックスデータはシンプルデータとは別物であることに気付くでしょう。つまり、データの読み込み/処理/整理/アクセスの方法が違うのです。

「コンプレックスデータは別物だ」と気付いたならば、そのための解決策を見つけるべきです。そして、ここがMarkLogicの出番なのです。