すでにSparkを使っていて、さらにオペレーショナルデータハブを構築したいとします。これにはトランザクショナルなデータベースが必要です。ここでMarkLogicの出番となります。

Apache Sparkは、今日最も人気のあるオープンソースのクラスタコンピューティングフレームワークです。 これは導入が容易で、大量データの分析を極めてパワフルかつ高速なインメモリデータ処理で行えるアーキテクチャです。

Sparkのコアアーキテクチャでは、データ処理のコンセプトやメカニズムがうまく抽象化されていて、洗練された分析技術を開発において数多く利用できます。具体的には、リレーショナルデータベース（Oracleなど）、分散ファイルシステム（Hadoop HDFSなど）、エンタープライズNoSQLデータベース（MarkLogicなど）に格納された多様なデータセットに対してSQL、機械学習、ストリーミング分析ができます。

「Sparkだけでオペレーショナルデータハブを実現できますか。それとも他に何か必要ですか」とよく聞かれますが、簡単に言うと、Sparkだけでは実現できません。オペレーショナルデータハブを構築する場合、「Sparkだけ」あるいは「SparkとHadoopの組み合わせ」では不十分です。というのも、トランザクションやセキュリティを実現し、柔軟にスキーマを扱え、多様なデータを一元的に表現できるデータベースが必要だからです。これに加えて、データの出自、プライバシー、保管規則など、業界固有の規制を順守する必要もあります。

とはいえ、これまでのSparkへの投資が無駄になるわけではありません。Sparkはビッグデータ処理フレームワークとして機能するので、必要なのはSparkを補完し日々の業務にインサイトを与えられるNoSQLのデータ統合プラットフォームということになります。

Sparkに対する別のアプローチ

話を始めるに当たって、私がこれまで経験した2つの観点について確認しておきます。これらは、分散クラスタコンピューティングアーキテクチャのオープンソースおよび商用技術に関する異なる考え方を反映したものです。

これまでHadoopやHiveといったオープンソース技術の経験がある人は、「Sparkで、Hadoop内のMapReduceフレームワークを単純に置き換えられるのでは？」と考えたことがあるのではないでしょうか。また「Hadoopがあれば、MarkLogicのような他のデータベースがなくてもSparkを使えるのでは？」と思ったこともあるでしょう。

片やMarkLogicを使っている人からすると、「すでにMarkLogicでJSONやXMLのようなリッチなフォーマットでデータを処理・格納していてやりたいことはすべてリアルタイムでできているのに、なぜ今更Apache Sparkのような他のクラスタコンピューティングフレームワークが必要なのか？」と思うでしょう。

表面上、それぞれの主張は妥当なものに思われます。ビッグデータという言葉が使われ始めてしばらく経った現在、MarkLogicのようなデータベースは単にパーシステンス（永続）層であるだけでなく、エンタープライズアプリケーション用のスケーラブルなデータ処理プラットフォームでもあります。これによりデータの格納場所のすぐ近くでデータをリアルタイム/ほぼリアルタイムで処理できます。別途データ処理フレームワークは不要です。この結果、問いに対する回答を得るまでの時間が短縮されます。

「データベース」と「データ処理フレームワーク」の境界はだいぶ曖昧になってきましたが、MarkLogicのようなモダンなデータベースに関しては、データ処理フレームワーク要件の幅広いスペクトラムを確認し、これらの要件にどんなアーキテクチャが最適なのかを判断することが大切です。

このスペクトラムの一端には、高度にオペレーショナルなアプリケーションがあります。数十万人のユーザーが同時接続するようなものです。これらのユーザーは、業務に応じて極めて特化したクエリを利用しています。

例えば、金融サービスではMarkLogicはオペレーショナルトレードストアとして使用されることがよくあります。トレードストアでは、特定のスワップ取引の情報や付随する取引前のコミュニケーションを確認し、取引発生地点において規制要件を満たしていたかどうかを証明する必要があります。金融サービス機関のアナリストや規制当局は特定の金融商品のパフォーマンス、関連ニュース、分析、レビューを調べます。

この場合、構造化および非構造化情報の両方に対してクエリが実行されます。こういったクエリの性格はさまざまですが、通常は極めて選択的なクエリです。つまり、ユーザーは自分が何を探しているのかをかなり細かく知っていて、結果が数ミリ秒で返ってくることを期待しています。

金融商品のパフォーマンスは秒単位で変化し、ユーザーも分単位/秒単位の情報を求めています。これこそがMarkLogicが得意とするもので、ビルトインの検索機能によって、変化し続けるデータに対して極めて高速なクエリができます。業務アプリケーションでは、データアクセスの際にユーザーは読み取り/書き込み操作を行います。つまり、同時に行われるインサート/更新によってデータが消失しないためには、ACID準拠のデータベースが必要です。またデータベースには、情報漏洩を回避するためのセキュリティ機能も必要です。

このスペクトラムの対極には、極めて分析的なアプリケーションがあり、ここでも構造化および非構造化のデータを大量に扱う必要があります。企業内おいては、価値の高いビジネス分析を行うユーザーはそう多くないでしょう。通常は多くても1000人以下です（ビジネスアナリスト、データサイエンティスト、データエンジニアなど）。

分析ユースケースの好例として、ログ処理や機械生成データの分析があります。データの量は膨大ですが、ユーザーは個々のログイベントに対してクエリするわけではありません。このようなログ分析の目的は、ユーザーの行動パターンやシステムの挙動パターンの知見を得るためです。こういった行動パターンを理解するためには、利用可能なログイベントをすべて処理し、高度な分析アルゴリズムや機械学習アルゴリズムで、ユーザー行動やシステム挙動における特異パターンを特定する必要があります。こういった分析から得られたインサイトは、ユーザー数拡大、顧客離脱の抑制、業務効率の改善などに活用できます。

データアクセスとしては、分析アプリケーションは「リードオンリー」の場合が多いです。この場合、大量のイミュータブル（変更不可）なデータセットに対して膨大な並行処理を行う、データ処理プラットフォームが必要です。Apache Sparkはこういった要件を得意としています。

ここまでのところで、オペレーショナル（業務）アプリケーションと分析アプリケーションの明確な違いを説明し、こういったアプリケーションにMarkLogicとApache Sparkが適していることを説明しました。さてここで問題となるのは「どちらのテクノロジーをどのユースケースに利用したら良いのか」ということです。確かに一部重なる部分もあり、それらの使い分けはいつも明確なわけではありません。

実際にアプリケーションを構築する段になると、要件がこのスペクトラムのあちこちに点在することもよくあるでしょう。同一のアプリケーションにおいて、オペレーショナルと分析の両方の要件を扱わなければならないこともあります。このようなビジネス要件においては、一緒に使えるオペレーショナル用および分析用のデータ処理プラットフォームが必要です。

以下のセクションでは、この問題を解決するためのアーキテクチャについて説明します。これはMarkLogicおよびApache Sparkを一緒に活用し、極めて多様なユースケースを扱うものです。

MarkLogicオペレーショナルデータハブ

「オペレーショナルデータハブ」は最近登場したエンタープライズデータ統合プラットフォームで、大規模な成功事例もみられます。オペレーショナルデータハブの主な目的は、エンタープライズデータのサイロを統合し、統合済み業務データを管理するための信頼性が高く安全な一元化されたデータプラットフォームを提供することです。オペレーショナルデータハブは、オペレーショナル（業務）の世界と分析の世界を1つに収束させます。この際、実際に活用可能な知見を業務データにもたらし、戦略的意思決定のみならず、日々の業務においてもデータドリブンな企業を実現します。

CDO（チーフデータオフィサー）やCIOにとっては、オペレーショナルデータハブは、組織内のガバナンスを実現するための主要なアセットです。アーキテクチャ的には、データハブはノンディスラプティブです（他のシステムを止めません）。 これにより、業務をさらにスムーズかつ効率的にできます。また使用中のデータ関連アーキテクチャのコンポーネントを捨てる必要もありません。さらにデータを下流でさまざまに業務処理したあと、オペレーショナルデータハブからデータウェアハウスに移動して、BIアプリケーションで利用することもできます。

MarkLogicとSparkによるオペレーショナルデータハブ

MarkLogicは、オペレーショナルデータハブとして極めて上手く機能しますが、Sparkを一緒に使うと、このオペレーショナルデータハブはさらに強力になります。

MarkLogicとSparkによるオペレーショナルデータハブの理解を深めてもらうために、さまざまなユースケースを説明し、またMarkLogicとSparkによるそれらへの対処のベストプラクティスをご紹介します。

1. 外部ソースデータをMarkLogicに読み込み、Apache Sparkですぐに変換する。これはデータ移動およびデータ変換のシナリオです。MarkLogicはドキュメントデータベースでもあるので、複雑なデータ構造に対する複雑なクエリを実行できます。通常ビジネスエンティティは、MarkLogic内のドキュメントとして表現されます。例えば、顧客/患者/注文/保険請求などをドキュメントとして表現できます。ほとんどの企業ではこういった情報をリレーショナルデータベースに格納しているため、顧客情報が20から30もの異なるソーステーブルに、またトランザクション情報（注文など）が50から100ものソーステーブルに分散していることもよくあります。ここで、すぐに大量のデータの移動や変換を一括で行いたい場合（複数のソーステーブルからのデータを読み取り、顧客ドキュメントや注文ドキュメントとしてMarkLogic内にロードするなど）、このデータ移動ジョブを整理するためのバッチデータ処理フレームワークが必要です。このような作業はSparkが得意です。Sparkを使って、ソーステーブルに対して適切なジョインやフィルタリングができます。Sparkは一括（バッチ）のデータ移動だけでなく、ソースシステム内の変更済みデータのストリーミングもできます。表形式のデータをリッチな階層型データ構造（MarkLogic内でJSONあるいはXMLドキュメントとして表現されるもの）に変換する作業は、Spark層あるいはMarkLogic（サーバーサイドJavaScriptを使用）で行えます。
2. さまざまな形態のデータをMarkLogicで集計する。MarkLogicはデータをドキュメントとして格納しますが、データの集計やハーモナイズもできます。この場合、多様なソースシステムからのデータを扱う際の事前のデータモデリングは不要で、データをソース固有の形式のままロードできます。このため、形態が異なるSalesforceシステムやERPシステムからのデータを簡単に読み込むことができ、クエリもできます。いったんMarkLogic内にデータが読み込まれると、データ構造全体あるいはその一部を標準化してデータをハーモナイズすることで、エンタープライズデータを一元的に把握できます。MarkLogicの柔軟なデータモデルと「何にでも対応できる」ユニバーサルインデックスにより、データハーモナイズプロジェクトのROIを短期間で実現できます。また完全にアジャイルなやり方でプロジェクトを実行できます。リレーショナルでよくある、事前のデータモデリングに時間がかかりすぎてプロジェクトの予算を食いつぶしてしまったり、ビジネスユーザーが使える前にプロジェクト自体が中止になってしまうことはありません。
3. MarkLogicで、変化するデータに対する大量の同時トランザクションと安全なクエリ実行を実現。データハブに基づく業務アプリケーションでは、リッチなクエリ機能とデータハブに書き戻せる機能（ライトバック）が必要です。MarkLogicはセキュリティとACID準拠に注力し、このニーズを満たしています。またMarkLogicのアーキテクチャは極めて拡張性に優れています。これは大量のデータに対応するだけでなく、大量の同時ユーザーリクエストに対応することもできます。MarkLogicは規制要件が厳しい金融機関、ヘルスケア、政府機関などで基幹業務で使用されています。これはこれらの業界におけるセキュリティ基準を満たしているからです。
4. MarkLogicは業務用BIおよびレポーティングをリアルタイム/ほぼリアルタイムで実現。これは日々の業務における極めて粒度の細かいクエリにリアルタイム/ほぼリアルタイムで対応したい状況のことです。これにより任意の時点におけるビジネスの様子を把握できます。つまり、夜間ETL処理した後、BIダッシュボードやレポートにデータを渡すといった時間がかかるやり方は不要です。MarkLogicにビルトインされた検索エンジンでは、ユニバーサルインデックスおよびその他のリッチなインデックスにより、業務用BIの要件を満たすことができます。
5. Apache Sparkによるデータウェアハウスと高度なマルチステップ分析。エンタープライズデータはある特定のライフサイクルを繰り返します。例えば1週間あるいは1か月を過ぎた注文といった特定のステータスに至ったトランザクションは、ビジネスルールに基づいてエンタープライズデータウェアハウスシステムに入れることができます。こういった場合、データハブ内の業務データを集約し、他のデータソースなどと一緒にエンタープライズデータウェアハウスに入力します。このようなデータパイプラインはApache Sparkで構築できます。この場合、SparkのデータパイプラインはMarkLogicからデータを読み込み、適切なスキーマ（通常はスタースキーマ）に合わせてデータを変換します。その後、このデータをデータウェアハウスに読み込みます。
6. Apache SparkとMarkLogicで、分析から得られたインサイトを業務アプリケーションにフィードバックする。これは分析プロセスの一環としてBIダッシュボードにデータを提供するレベルを超えて、分析結果を業務プロセスに戻していくというシナリオです。例えば、過去のトランザクションデータを使って機械学習モデルを訓練し、この機械学習モデルをリスク査定や不正検知に使って新しいトランザクションを分類するなどです。このような場合、Apache Sparkの機械学習およびストリーム分析機能をMarkLogicと一緒に使うことで、インテリジェントな業務アプリケーションを構築できます。

SparkとMarkLogicを使った次のステップ

もうこれで準備OKでしょう。このへんでまとめに移ります。今回は、MarkLogicとApache Sparkで対処できる技術的な問題を取り上げました。MarkLogicは、安全性を求められる大量の同時トランザクションや、変化するデータに対するリッチなクエリが求められる業務アプリケーションを構築できる素晴らしいソリューションです。片やApache Sparkは、膨大なイミュータブルデータに対して大量の並行処理を行う、洗練された分析機能を提供します。現実のユースケースは、本質的にハイブリッド（オペレーショナル＋分析）なことが多く、MarkLogicとSparkを一緒に使うことから大きな恩恵が得られます。

あなたがエンタープライズアーキテクトやオペレーショナルデータハブの構築および利用法のプランニング担当者であれば、MarkLogicで構築されたオペレーショナルデータハブの詳細についてご確認ください。

あなたが開発者で、さらに詳しく知りたい場合は、MarkLogic Worldにおける私の発表ビデオ「Putting Spark to Work With MarkLogic（SparkをMarkLogicと一緒に活用する）」をご覧ください。今回のブログよりも詳しく説明しています。また開発者向けのブログ「How to use MarkLogic in Apache Spark applications」も読んでみてください。

さっそく何かやってみたい・構築してみたいという方は、GitHubプロジェクト「MarkLogic Spark Examples」および「MarkLogic Data hub on GitHub」をご覧ください。

The post SparkとMarkLogic appeared first on MarkLogic.