HOAP？ HTAP？ トランスリティカル？バズワードが示唆するメリットとは

私は一元化データの管理戦略やプラットフォームのメリットについて、しょっちゅう話しています。これは今年のMarkLogic Worldの基調講演の主要テーマでしたが、よく考えてみると、これは何年にもわたって主要テーマであり続けています。「一元化データの管理戦略」にはさまざまな要素がありますが、極めて単純に言えば、「1つのプラットフォームでいろいろなことができる」ということです。

今日、データ管理に関してあらゆる種類の専用ソリューションが揃っています。しかし専用ソリューションを複数使用したり、同一のソリューションで複数のインスタンスを使用している場合、結果的にはデータサイロを増やしてしまうことになります。

専門家は「ハイブリッドアプローチ」を推奨

一元化をさらに進めるための適切なステップである「オペレーショナル（業務）用と分析用の両方に同一のプラットフォームを使用する」というトレンドが、ようやく注目を集め始めています。各アナリスト企業はこれを、「HOAP」（hybrid operational analytical processing）、「HTAP」（hybrid transactional analytical processing）、「トランスリティカル」など、いろいろな名前で呼んでいます。

451 Research（彼らは「HOAP」という呼び方をしています）によると、ハイブリッドなワークロードに関心を寄せる企業が増えており、ハイブリット処理のニーズに応える製品の開発も増加しているとのことです。451 Researchは、このメリットを以下のように説明しています。「例えば、トランザクショナルシステムと分析システムを統合することで、ITの複雑さが緩和されます。またHOAPはカスタマーエンゲージメントを促進し、顧客からの問い合わせ時にお薦めを提示することで売り上げを増やせる可能性があります」。

またガートナーはこれまで2つあったマジッククアドラント（「ODBMS：Operational Database Management Systems」と「DMSA：Data Management Solutions for Analytics」）を今後は1つにまとめるとしています。これは「オペレーショナル」と「アナリティカル（分析）」のいずれかにきれいに分類できないユースケースが増えてきているためです。

誰もが「データは戦略的アセットだ」と言います。これはどういう意味なのでしょうか。簡単に言うと、手持ちのデータをキュレーションおよびスチュワーディングして現在および将来の複数のユースケースで利用できるようにするというものです。これによりデータ統合の作業は、組織全体で活用可能な「持続性のあるデータアセット」を構築することで、目の前のビジネス課題の解決にさらにフォーカスするものとなります。これは現在の問題用に別の専用ソリューションを追加するものではありません。これがうまくいけば、新しいユースケースのたびに必要な作業が減り、データのガバナンスが極めて楽になります。

それでは、これをどのように行えばよいのでしょうか。

モデルのジレンマ

結局のところ、データ統合プロジェクトとは、サイロに分断された数多くのデータソースからのデータを業務や分析で利用できるようにするものです。これらの入力データは、ソースシステムのモデルに基づいています。例えば、ERPシステムからのデータは、このシステム固有の方法でモデリングされており、このシステムの目的に合わせて最適化されています。この場合、今後の再利用が楽になるように、データのモデリング、格納、管理を変えるようにERPシステム側にお願いすることはできません。このデータはそのまま受け入れるしかないのです。ソースシステムに由来するモデルは、「ソースモデル」と呼ばれます。

同様に、データはある特定のやり方で使用しなくてはなりません。例えば、データをデータウェアハウスに入れる場合、データが従うべき形式やスキーマがあります。また顧客のプロファイルデータをwebページに送る場合、webアプリケーション側はこのデータをJSONオブジェクトとして扱わなければならないでしょう。データをBIツールで分析する場合、データを行と列からなる表に入れなくてはなりません。このようにユースケース（利用方法）に準拠するモデルは、「コンサンプション（消費）モデル」と呼ばれます。

さまざまなソースモデルをさまざまなコンサンプションモデルに変換するのは極めて困難です。目的に合うようにデータを整えるにはかなりの作業が必要です。また何かが変わるたびに、あるいは新しいユースケース用に新しいコンサンプションモデルを追加するたびに、システム全体で大量の作業をやり直す必要があります。また、どのようにデータが複数のソースから得られ、さまざまな変換を経て複数の利用システムに送られたのかをトラッキングするのも困難です。

第三のモデルへの道：エンティティモデル

MarkLogicデータハブでは、「エンティティモデル」という第三のモデルを使ってソースモデルをコンサンプションモデルから抽象化することで、この問題を解決します。

エンティティモデルは、特定のユースケースに特化しないニュートラルなモデルと考えることができます。これはビジネスにおいてデータをどのように考えているのかを表現したものです。この第三のモデルは、変化の発生時に上流および下流のシステムを防護する役割を果たします。つまり新しいソースモデルが登場した場合、あるいはソースモデルに変更が加えられた場合、自分のエンティティモデルに新しいソースモデルをプラグインできます。この際、このハブに依存する下流システムを変更する必要はありません。またこの一か所において、データにメタデータをアタッチすることでデータのガバナンスを実現できます。例えば、組織にとって価値が高いデータを生み出すものは何か、あるいはこのデータに関するポリシーは何かを定義することは、実際のビジネスコンセプトを表現したモデルがあった方が圧倒的に楽になります（特定のソースあるいはコンサンプションに準拠した形式のモデルではなく）。

またMarkLogicには柔軟なスキーマやインデックスがあるため、あらゆるユースケースに妥当する完璧なエンティティモデルを何年もかけて生み出す必要はありません。まずは一番重要なビジネス課題を解決するシンプルなモデルを作り、このモデルを成長させたりリファクタリングしていくことができます。これを、モデル内の変更が上流および下流のシステムに与える影響を抽象化しながら行います。モデルが成長・変化するにつれて、データをエンリッチ・強化できます。これにより、現在および将来のユースケースにおける価値が高まります。これこそが「持続性のあるデータアセット」なのです。

一元化データ管理戦略

エンティティモデルは、私がこのブログの冒頭で簡単に述べたこと、つまり「1つのプラットフォームでいろいろなことができる」を実現します。これは単なる業務用/分析用といったユースケースを超えるものです。

451 Researchのこの件に関する見解については、451 Perspective: A HOAP-ful future for hybrid operational and analytical processingをご覧ください。

MarkLogicデータハブサービスの詳細については、リンクをクリックしてください。