データ統合の再考: データ仮想化によるアジャイルな BI システムの実現

データ統合の再考:
データ仮想化による
アジャイルな BI システムの実現
テクニカルホワイトペーパー
Rick F. van der Lans
ビジネスインテリジェンスアナリスト
R20/Consultancy
2014 年 3 月
後援:
Copyright © 2014 R20/Consultancy.All rights reserved.Red Hat, Inc.、Red Hat、Red
Hat Enterprise
Linux、Shadowman ロゴ、および JBoss は、米国およびその他の国における Red Hat, Inc.
の登録商標です。Linux® は、米国およびその他の国における Linus Torvalds 氏の登録商標
です。このドキュメントで参照されている会社の商標は、各社の独占的な所有物です。
目次
1
要旨
1
2
BI システムの新たな課題
2
3
現在の BI システムと新たな課題
4
4
データ仮想化によるオンデマンドの統合
6
5
データ仮想化サーバーの詳細
8
6
データ仮想化の BI 関連の応用分野
13
7
データ仮想化と新たな BI の課題
15
8
データ仮想化により統合仕様の共有を簡素化
15
9
Red Hat JBoss Data Virtualization サーバーの概要
17
ライターの Rick F. van der Lans について
21
Red Hat, Inc. について
21
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
1
1 要旨
ビジネスインテリジェンス (BI) の新時代。それは唐突ではないものの、確かに到来しました。BI
システムが 1 日前のデータを提供していた日々、社内データだけで組織の BI ニーズをすべて満
たせていた日々、そして新しいレポートの作成に数週間から数か月を要していた日々は既に過去
のものです。
今日の組織は、かつてないほど BI システムへの依存を高めてい BI は、組織が差別化を図り、競
ます。現在の目まぐるしく変化するビジネス環境においては、組争力を維持するための重要な
ツールになりました。
織の意思決定プロセスのために、適切な形態の適切なデータに、
適切なタイミングでアクセスできることが必要です。BI は、組織
が差別化を図り、競争力を維持するための重要なツールになりました。
この新時代において、BI システムは新しい技術的進歩および新しいビジネス要件という課題に直
面しており、変化を迫られています。BI システムが直面している主な課題の一部を次に示します。
•
生産性の向上:ビジネスのスピードは増す一方であり、それに応じて BI 開発者の生産性
の向上も求められています。BI 開発者は、このビジネスのスピードに追随する必要があり
ます。レポートの作成に数週間をかけるようなことは、もはやできません。
•
セルフサービス BI:ユーザーが各自のレポートを作成して管理できるように、BI システ
ムはセルフサービスの BI ツールをサポートする必要があります。
•
運用インテリジェンス:ユーザーが分析したいのは、1 日前のデータではなく運用データ
です。この分析形態は、運用インテリジェンスまたはリアルタイム分析と呼ばれます。
•
ビッグデータ、Hadoop、および NoSQL:BI 業界にもたユーザーがスモールデータと
らされた最大級の変化の火付け役となったのがビッグデ同じくらい簡単に、ビッグデー
タをレポート作成および分析
ータであることに疑問の余地はありません。BI システム
に使用できるようにします。
は、ビッグデータとそれに付随する Hadoop および NoSQ
L のデータストレージテクノロジーに対応する必要があ
ります。ユーザーが従来のシステムに格納されたデータと同じくらい簡単に、ビッグデー
タをレポート作成および分析に使用できるようにすることが課題です。
•
クラウドのシステム:組織は、BI システムのコンポーネントを、よく話題に上るクラウド
に移行させています。BI システムは、クラウドテクノロジーとクラウドソリューションに
透明性の高い方法で対応できなくてはなりません。
•
クラウドのデータ: 社外データを使用して社内データの質を高めることで、分析機能を拡
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
2
張できます。インターネット上では、ソーシャルメディアデータや数々のオープンデータ
ソースなど、貴重な社外データを含む無数のソースにアクセスできます。BI システムの課
題は、クラウドのこうした貴重なデータをすべて社内データと統合することです。
現在の多くの BI システムでは、これらの課題すべてに対応することは困難でしょう。その理由は
主に、システムの内部アーキテクチャーが、ステージングエリア、データウェアハウス、およびデー
タマートから成るデータベースチェーンで構成されているためです。データはデータベース間で
コピーすることでユーザーに提供され、各コピープロセスを経るごとに、データの形はユーザーが
求めるものに近づいていきます。このデータサプライチェーンは長年、多くの組織でうまく機能し
てきましたが、最近では障害になってきています。
「構築したものを使用し続ける」という精神に基
づき設計されたにも関わらず、組織は、
「変化に対応可能な設計」で構築されたソリューションを求
めているからです。
このホワイトペーパーでは、データ仮想化と呼ばれる、オンデマデータ仮想化を導入すると、BI
ンドのデータ統合テクノロジーの効率的形態について説明しまシステムのアーキテクチャー
す。データ仮想化を導入すると、BI システムのアーキテクチャーがよりシンプルでアジャイル
なものになります。
がよりシンプルでアジャイルなものになり、新たな課題にはるか
に容易に対応できるようになります。論理テーブル、データソー
スのインポート、データのセキュリティ、キャッシュ、クエリ最適化など、データ仮想化の重要な概
念もすべて説明しています。仮想データマート、ビッグデータ分析、拡張データウェアハウス、コー
ルドデータのオフロードといった、BI 向けのデータ仮想化の応用分野については、例を挙げてい
ます。
ホワイトペーパーの末尾には、初のオープンソースのデータ仮想化サーバーである、Red Hat JBos
s Data Virtualization の概要を記載しています。
2 BI システムの新たな課題
BI システムは、新しい技術的進歩と新しいビジネス要件に直面しています。その結果、変化を迫ら
れています。このセクションでは、BI システムが現在直面している主な課題の一部を挙げます。
生産性の向上 – 組織の競争力と高いコスト効果の維持を IT 部門が支援するには、増し続ける
ビジネスのスピードに BI システムの進化が追随する必要があります。このことは、Aberdeen Gro
1
up が実施した調査で明確に示されています。具体的には、43% の企業が、意思決定をタイムリー
に行うことが困難になっていると感じています。マネージャー職の従業員は、特定のビジネスイベ
1
Aberdeen Group、
『Agile BI:Three Steps to Analytic Heaven (アジャイルな BI: 効果的な分析を行うための 3 つ
のステップ)』、2011 年 4 月、https://www.tableausoftware.com/sites/default/files/whitepapers/agile_bi.pdf を
参照
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
ントが発生した後に意思決定にかけられる時間がますます減ってきていると感じています。つま
り、既存のレポートの修正と新しいレポートの作成の迅速化が必須だということです。
しかし、ツールの品質、開発者自身の問題、変わり続けるユーザーニーズ、ほとんどの BI システム
に見られる柔軟性の低いアーキテクチャーなど、さまざまな要因に阻まれ、多くの IT 部門は BI
の生産性の課題に効果的に対応できていないのが実情です。そのため、BI の未処理作業は増加の
一途をたどっています。
セルフサービス BI – 多くの IT 部門では、BI レポートの作成に反復的アプローチを採用して
います。このアプローチは通常、ユーザーがレポートを要求することから始まります。次に、IT 部
門の担当者が手始めにユーザーのニーズを分析します。これには、インタビューや、データ構造、各
種レポート、およびドキュメントの調査が含まれます。また、ほとんどの場合、ユーザーの要求内容
とすべての用語の意味を理解することを主な目的とした、IT スペシャリストによる詳細な分析プ
ロセスも含まれます。この「理解する」プロセスには非常に時間がかかることがあります。やがて I
T スペシャリストが第 1 版のレポートを作成し、そのレポートをユーザーが見て内容を確認しま
す。内容がユーザーの希望に沿っていなかった場合、スペシャリストは第 2 版に着手し、そのレポ
ートをユーザーに見せます。ユーザーがどの程度自分のニーズを明確にできるか、そしてアナリス
トがどの程度ユーザーとそのニーズを理解できるかによって、このプロセスは何度か反復される
ことがあります。こうした作業をすべて経て、ようやく実装に至ります。
この反復プロセスに時間がかかる場合があるのは明らかです。当然のように、多くのユーザーは代
替ソリューションを探し始め、セルフサービス BI ツールを見つけました。こうしたツールは直感
的なインターフェースを備えており、ユーザーが独自のレポートを作成できるように設計されて
います。ユーザーは既に自分のニーズを理解し、何が必要なのかわかっています。つまり、上述のス
テップの多くを省略できるため、生産性が大幅に向上するのです。
しかし、セルフサービスの作成は混乱を招くこともあります。ユーザーはプロの作成者ではありま
せん。再利用可能なソリューションや正式なテスト手法の作成について訓練を受けたわけでもな
く、共有メタデータや統合仕様の作成を目指しているわけでもありません。レポートをできるだけ
迅速に作成することのみを目指しています。BI システムの課題は、同じ作業を何度も繰り返すこ
となく、レポートで正確かつ一貫性のある結果を得るために、このセルフサービスの作成をいかに
管理するかということです。
1 日前のデータに価値を認め
ないユーザーは増加していま
週間前のデータに関するレポートで満足していた時期もありま
す。ユーザーは運用インテリジ
した。しかし今日のユーザーは、これほどまでのデータレイテン
ェンスを必要としています。
シをもはや許容せず、1 分、場合によっては数秒以内のデータレ
イテンシを求めています。特に、運用管理部門や社外の関係者な
どのユーザーグループは最新の状況に関するインサイトを得たいため、これらのユーザーグルー
運用インテリジェンス – データウェアハウスのユーザーが、1
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
4
プにとって 1 日前のデータに価値はありません。ユーザーが非常に低いデータレイテンシを求め
るこの BI の形態は、運用インテリジェンスと呼ばれます (リアルタイム分析と呼ばれることも
あります)。
本番システムに新しいデータを入力し、データマート上でレポートを作成する場合、主な技術的課
題は、本番システムからステージングエリアおよびデータウェアハウスを経由してデータマート
にデータを高速コピーすることです。チェーンが長いほどデータレイテンシが増大するというの
は、誰の目にも明らかです。そして、多くの BI システムでは、このチェーンが長いという事実があ
ります。
ビッグデータ、Hadoop、および NoSQL – BI 業界の一大トレンドとしてビッグデータを挙げる
2
ことに異論はないでしょう。Gartner は、2016 年を通してビッグデータ関連の支出が 2320 億ド
3
ルに上ると予測しており、Wikibon は、2017 年のビッグデータ関連の収益が 501 億ドルまで伸
びると断言しています。多くの組織がビッグデータを導入しています。自社にとってのビッグデー
タの可能性を検討している組織もありますが、多くはビッグデータシステムの開発段階にありま
す。中にはこうしたシステムに既に依存している組織もあります。これらの組織はすべて、分析能
力の質を高めることを目標にしています。
ビッグデータが構造化データ、非構造化データ、多構造化データ、BI システムによってユーザー
半構造化データのいずれであっても、膨大な量のデータというが「スモール」データと同じくら
点は変わりません。このような大規模データベースを処理するい簡単に、ビッグデータのレポ
ート作成と分析を実行できるよ
にあたって、多くの組織は馴染み深い SQL システムではなく、H うにする必要があります。
adoop システムまたは MongoDB や Cassandra などの NoSQL
システムを導入する決断を下しました。Hadoop システムと NoS
QL システムはビッグデータのワークロード用に設計された強力でスケーラブルなシステムです
が、SQL システムとは違いがあります。まず、これらのシステムは、一般的な SQL データベース言
語や、テーブル、列、レコードといった馴染み深いリレーショナルモデルの概念を必ずしもサポー
トしていません。また、これらのシステムの多くは、独自の API、データベース言語、および一連の
データベース概念をサポートしています。そのため、1 つの製品で通用する専門知識でも、別の製
品では容易に再利用できないことがあります。
BI の課題は、Hadoop システムおよび NoSQL システムに格納されたすべてのビッグデータをデー
2
Gartner、2012 年 10 月、http://techcrunch.com/2012/10/17/big-data-to-drive-232-billion-in-it-spending-thr
ough-2016/ を参照
3
Wikibon、「Big Data Vendor Revenue and Market Forecast 2013-2017 (ベンダーのビッグデータ関連の収益および
市場予測 2013 ～ 2017)」、2014 年 2 月 12 日、http://wikibon.org/wiki/v/Big_Data_Vendor_Revenue_and_Market_F
orecast_2013-2017 を参照
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
タウェアハウス環境と統合して、ユーザーが「スモール」データと同じくらい簡単に、ビッグデータ
をレポート作成と分析に使用できるようにすることです。
クラウドのシステム – 本番システム、ステージングエリア、データウェアハウス、データマート
といった BI システムのあらゆるソフトウェアコンポーネントは、従来オンプレミスで実行され
ていました。しかし現在では、コンポーネントがクラウドに配置されることもあります。
コンポーネントをクラウドに移動すると、パフォーマンス、技術的インターフェース、セキュリテ
ィの側面などに影響が及ぶことがあります。場合によっては、このような変更を行うために再開発
が必要になります。ここでの課題は、クラウドソリューションを透明性の高い方法で導入するとい
うことです。たとえば、データマートをクラウドに移動した場合でも、クラウドベースの ERP シス
テムを導入した場合でも、すべてをできるだけ透明性の高い状態にする必要があります。
クラウドのデータ – データウェアハウスのデータソースは従社内データと社外データを統
来、社内の本番システムに限られていました。社内データのレポ合することで、分析能力とレポ
ート作成能力の質を高めるこ
ート作成と分析により有益なビジネスインサイトを得られるこ
とができます。
ともありますが、クラウドに含まれる膨大な量の貴重な社外デー
タを活用すれば、分析能力の質を高めて、さらなる予想外のイン
サイトを得ることができます。たとえば、社内の顧客データとソーシャルメディアデータを統合す
ることで、製品および会社に対する顧客の考えについて、より詳細で完全な像が見えてきます。
今日では、クラウドから数多くの社外データを入手できますが、その中で最もよく知られているの
はソーシャルメディアデータです。しかし、それだけというわけではありません。無数のオープン
データソースが公開されており、その情報を入手できます。気象データ、デモグラフィックデータ、
エネルギー消費データ、病院のパフォーマンスデータ、公共交通機関データなど、オープンデータ
ソースの例は枚挙にいとまがありません。これらのオープンデータソースはほぼすべて、何らかの
API を通じてクラウドから入手可能です。
BI システムの課題は、クラウドベースのこうした貴重なデータをすべて社内データと統合するこ
とです。このデータをすべてコピーするとコストがかかりすぎる可能性があるため、よりスマート
なソリューションを考案する必要があります。
3 現在の BI システムと新たな課題
前のセクションで説明した課題は、既存の BI システムではア
データサプライチェーンは、
ーキテクチャーの問題により実装が困難となる可能性があり「変化に対応可能な設計」で構
ます。このセクションでは、従来の BI アーキテクチャーにつ築する必要があります。
いて説明し、前のセクションで説明した課題に容易に対応でき
ない理由を概説します
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
6
従来の BI システム – ほとんどの BI システムのアーキテデータベースのチェーンと ET
クチャーは、長いデータベースのチェーンのような構造を持ち
ます (図 1 を参照)。このようなシステムでは、データはまず、
本番アプリケーションを使用して入力され、本番データベース
に格納されます。次に、ステージングエリアおよび運用データス
トア経由で中央データウェアハウスにコピーされます。そして、
すべてのレポート作成と分析の大部分が実行されるデータマー
トにコピーされます。
ほとんどの BI システムのア
ーキテクチャーは、長いデータ
ベースのチェーンのような構
造を持ちます。
分析とレポート作成
本番アプリケーション
ETL
L ジョブは、組み立てラインと
非常によく似ています。
ETL
本番データベース
ステージングエリア
ETL
運用データストア
図 1. ほとんどの BI シ
ステムはデータベースの
チェーンで構成されてい
ます。新しいデータは本番
システムに入力され、ここ
からデータベース間でコ
ピーされます。
ETL
データウェアハウス
データマート
ETL ジョブは、データベース間でデータをコピーするのによく使用されます。また、データを変換、
統合、およびクレンジングする役割を担っています。ETL ジョブは、定期的に実行されるようスケ
ジュールされます。つまり、データの統合と変換はバッチプロセスとして実行されることになりま
す。
データベースのチェーンとデータベース同士をつなぐ ETL ジョブは、(本番データベースの) 生
データをレポート作成用のデータに変換する「工場」となります。これは、原料を段階的に加工して
いき最終製品を作り上げる実際の組み立てラインと非常によく似ています。このチェーンがデー
タサプライチェーンです。
従来の BI システムと新たな課題 – バッチ指向のコピー方式を採用したこのデータサプライ
チェーンは長年、数多くの組織でうまく機能してきましたが、最近では障害になってきています。
このモデルは、
「構築したものを使用し続ける」という精神に基づき設計されました。そのため、レ
ポートに一見単純な変更を加えるだけでも、データベースと ETL ジョブに変更が発生し、作成に
多大な時間がかかってしまうのです。問題が発生する可能性のあるステップは数多くあります。チ
ェーンの規模は際限なく拡大するものなので、チェーンは限界まで引き伸ばされ、不安定になって
います。今日の組織が求めているのは、
「変化に対応可能な設計」で構築されたソリューションです。
しかし、最も懸念されるのは、こうしたシステムでは次に挙げる新たな課題に対応するのが困難だ
という点です。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
•
生産性の向上:ETL の重要な特徴は、統合結果がデータベースに格納されなければその結
果を使用できないということです。このようなデータベースには、インストール、設計、管
理、最新状態の維持といった作業が伴います。これらの作業にはすべて、人手が必要です。
•
セルフサービス BI: セルフサービス BI であるかどうセルフサービス BI のユーザ
かに関わらず、レポートで正確かつ一貫性のある結果がーが入力した仕様を共有可能
得られ、高い生産性が実現されなくてはなりません。そうにする必要があります。
でなければ、何も得ることができません。そしてそのため
には、セルフサービス BI のユーザーが入力した仕様を共有可能にする必要があります。
同じ作業を繰り返す必要性は最小限に抑えなくてはなりません。しかし現在の BI システ
ムは、ユーザーによる仕様の共有を容易にする「モジュール」を備えていません。
•
運用インテリジェンス:前のセクションで説明したように、本番システムに入力された新
しいデータは、数回コピーされてからレポート作成に利用できるようになります。これは、
レイテンシゼロのデータの分析に関心があるユーザーにとって、理想とはほど遠い状況で
す。何らかの方法でチェーンを短くする必要があります。データベースと ETL ジョブの数
を少なくするべきです。
•
ビッグデータ、Hadoop、および NoSQL:ビッグデータは、コピーするにはサイズが大きす
ぎることがあります。コピープロセスに時間がかかりすぎることや、複製したビッグデー
タの格納にコストがかかりすぎることもあります。データ変換、データ統合、およびデータ
クレンジングに関しては、ビッグデータを別の方法で処理する必要があります。チェーン
内をプッシュさせることは避けるべきです。
•
クラウドのシステム:システムをクラウドに移動したとき、場合によっては、データの抽
出方法を変更する必要があります。たとえば、データのコピーにかかる時間は、クラウドで
実行したときの方が長くなることがあります。インターネット経由でデータを転送する際
に、以前は不要だったデータ暗号化が必要になることもあります。BI システムのアーキテ
クチャーは、クラウドの内外にコンポーネントを移動、またはクラウド内でコンポーネン
トを移動する際に透明性を確保できるよう十分な柔軟性を持たせなければなりません。
•
クラウドのデータ:原則として、クラウドの社外データは社内データと同じように処理す
ることが可能で、データベースのチェーンを経由して抽出、統合、変換を行った後にコピー
できます。しかし、こうした社外データソースを直接使用してレポートを作成できた方が
便利なこともあります。このようなソリューションを既存のアーキテクチャーに当てはめ
るのは困難でしょう。たとえば、レポートにデータマートおよび社外データソースからの
データが必要な場合、そのデータをどこでどのように統合、変換、およびクレンジングすれ
ばよいのか、といった問題があります。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
8
まとめ – データベースのチェーンと ETL ジョブで構成された従来の BI アーキテクチャーは
長年の間うまく機能してきました。しかし、このアーキテクチャーを維持することで BI システム
が新たな課題にどう対応できるのかは、明確ではありません。
4 データ仮想化によるオンデマンドの統合
このセクションでは、データ仮想化と呼ばれるデータ統合の新しいテクノロジーと、それがオンデ
マンドのデータ統合の効率的形態をもたらす方法について説明します。以下の各セクションでは、
こうした製品の仕組み、その応用分野、およびセクション 2 で挙げた要件を満たす方法を説明し
ます。
データ仮想化とは – データ仮想化とは、あらゆる種類のデータソースからのデータを統合、変
換、および操作して、あらゆる種類のアプリケーションに対してそのすべてのデータを 1 つの統
合されたビューとして提示するテクノロジーです。データ仮想化は、抽象化レイヤーとカプセル化
レイヤーを提供します。これにより、アプリケーションに対して、データの格納方法と格納場所に
関する技術的な側面の大部分が隠されます (図 2 を参照)。このレイヤーのおかげで、すべてのデ
ータの物理的な格納場所、データの統合方法、データベースサーバーの実行場所、データの挿入と
更新の方法、必要な API、使用するデータベース言語などについて、アプリケーションが把握する
必要はありません。データ仮想化を導入すると、各アプリケーションにとっては 1 つの大きなデ
ータベースにアクセスしたような状況になります。
4
補足情報として、データ仮想化の定義を次に示します。
データ仮想化とは、一連の異種データストアに格納されたデータへのクエリおよび操作に
対して、データ使用者に統合、抽象化、およびカプセル化されたビューを提供するテクノロ
ジーです。
4
Rick F. van der Lans、
『Data Virtualization for Business Intelligence Systems (ビジネスインテリジェンスシ
ステムのためのデータ仮想化)』、Morgan Kaufmann、2012 年
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
本番アプリケーション分析と
レポート作成
社内ポータル
モバイル
アプリケーション
Web
ト
サイ
ダッシュボード
データ仮想化サーバー
本番
データ
ベース
アプリケーション
データ
ウェア
ハウスと
データ
マート
非構造化
データ
ストリーミング
データベース
ESB
非公開
ビッグ
データ
データ
ストアソーシャル
メディアデータ
社外データ
図 2: データ仮想化サーバーにより、一連の異種データソースを 1 つの論理データベースであるか
のようにアプリケーションに見せることができます。
データ仮想化はオンデマンドの統合を提供 – アプリケーションが複数のソースからのデー
タを統合するようデータ仮想化サーバーにリクエストすると、統合がオンデマンドで実行されま
す。これは、アプリケーションがリクエストする前に統合を実行する ETL ベースの統合と大きく
異なります。典型的な ETL 環境では、取得したデータが 1 週間前に統合されていたということも
あります。統合がライブで実行されるデータ仮想化では、このようなことはありません。アプリケ
ーションがデータをリクエストしたときのみ、データ仮想化サーバーは必要なデータをソースデ
ータベースから取得して、統合、変換、およびクレンジングを実行します。
これを、サンドイッチを買う状況にたとえてみましょう。レストラ
ンで客がサンドイッチを注文すると、パン、ハム、チーズ、レタスな
どの材料がすべて、キッチンで即座に「統合」されます。これがデー
タ仮想化です。ETL は、いわば店で包装済みのサンドイッチを買う
のと同じです。すべての材料の「統合」は早朝、場合によっては前日
の晩に行われているかもしれません。データ仮想化の本質とは、オ
ンデマンドのデータ統合なのです。
データ仮想化による統合はレ
ストランでサンドイッチを注
文するのと似ています。すべ
ての材料が、キッチンで即座
に「統合」されます。
変換と翻訳 – データ仮想化テクノロジーでは、さまざまなデータソーステクノロジーにアクセ
スできるため、さまざまな API と言語がサポートされています。データ仮想化テクノロジーは、た
とえば、SQL、XQuery、XPath、REST、SOAP、JMS などで指定されたリクエストを処理できなくてはなり
ません。つまり、技術的に言うと、アプリケーションが SOAP/XML インターフェースを使用してデ
ータにアクセスすることを求め、データソースが JMS をサポートしている場合、データ仮想化サ
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
10
ーバーは SOAP/XML を JMS に翻訳、つまり変換する機能を備えている必要があるということです。
効率的なデータ統合 – ETL を使用して 2 つのデータを統合するには、多大な労力を要するこ
とがあります。統合ロジックを設計および実装し、統合プロセスの結果を格納するデータベースを
設定し、このデータベースをチューニングおよび最適化して運用期間全体にわたって管理し、統合
プロセスをスケジュールしてチェックする、といった具合にやるべきことは数多くあります。
データ仮想化を通じたオンデマンド統合の主な利点は、効率的効率的な統合の利点は、提供の
なデータ統合です。データ仮想化では、統合ロジックのみを設計早さと変更の容易さです。
および実装すれば十分です。これを済ませれば、アプリケーショ
ンは統合されたデータ結果にアクセスできます。統合結果を格納するための新しいデータベース
を作成して管理する必要はありません。この効率的な統合形態の利点は、迅速に提供できることと、
既存の統合ソリューションを容易に変更できることです。
読み取り専用に限定されない – ETL ジョブの結果を格納するために作成された、データマー
トなどの導出データベースのデータは、読み取り専用です。その内容を変更することは技術的には
可能ですが、アプリケーションはソース自体ではなく導出データを更新することになるので、この
変更は無意味です。
データ仮想化ではソースに直接アクセスするため、データ仮想化サーバーを使用してデータを変
更した場合、変更されるのはソースデータです。データ仮想化では、新しいデータを挿入すること
も、既存のデータを更新あるいは削除することも可能です。ただし、データ仮想化サーバーによる
データの変更をソース自体が許可しないこともあるので、注意してください。
論理データウェアハウス – データ仮想化サーバーを経由してデータにアクセスするユーザー
にとっては、複数のテーブルで構成された 1 つのデータベースにアクセスしているような状況に
なります。複数のデータソースにアクセスしているという事実は、一切ユーザーに意識されること
はありません。ユーザーにとっては、クエリ対象のデータベースがデータウェアハウスとなるので
す。しかし、そのデータウェアハウスはもはや 1 つの物理データベースではないのです。論理的概
念となったそれは、論理データウェアハウスと呼ばれます。
データ仮想化は ETL に取って代わるものではない – デーデータ仮想化と ETL は補完的
タ仮想化は ETL を脅かすものだ、と不当に評価されることがあな統合ソリューションです。
ります。しかし、データ仮想化は ETL に取って代わるものではあ
りません。ETL の行っていた作業の一部がオンデマンド統合に置き換わるのは確かですが、すべて
が置き換わるわけではありません。たとえば、多く (おそらくは大半) の組織では、履歴データの
追跡、潜在的なパフォーマンスや安定性の問題により本番システムにアクセスできない、といった
理由で、物理データウェアハウスは依然として必要になります。物理データウェアハウスが必要な
場合には、データを定期的にロードするために ETL が適切な統合テクノロジーとなることもある
のです。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
データ仮想化と ETL は補完的な統合ソリューションであり、どちらも一長一短があります。特定
の統合の問題について、最適なソリューションが何かを判断するのはアーキテクトの仕事です。
5 データ仮想化サーバーの詳細
ほとんどのデータ仮想化サーバーは、類似の概念をサポートしています。このセクションでは、こ
うした重要な概念について説明します。
データソースのインポート – データ仮想化サーバーを経由し物理テーブルはデータソース
てソースシステムのデータにアクセスできるようにするには、まのラッパーです。
ずその仕様をインポートする必要があります。これは、データ仮
想化サーバーにデータがロードされるということではありません。物理 SQL テーブルなどの完全
な記述がデータ仮想化サーバーのリポジトリに格納されるということです。この記述には、物理テ
ーブルの構造 (列)、各列のデータ型と長さ、テーブルの物理的な場所、セキュリティの詳細などが
含まれます。レコードの数やバイト単位のサイズなど、テーブルに関する数量的情報の一部を収集
することもあります。インポートの結果は物理テーブルと呼ばれます (図 3 を参照)。物理テーブ
ルは、データソースのラッパーと見なすことができます。
図 3: 物理テーブルは
データソースをラップす
るのに使用されます。
<XML>
物理テーブル
データソース
SQL データベースのテーブルに対する物理テーブルを作成するには、数回の単純なクリック操作
を行います。SQL 以外のソースにアクセスした場合は、もう少し手間がかかる場合があります。た
とえば、データを Excel スプレッドシートから取得した場合は列名を定義する、ソースが Web サ
ービスの場合は必須パラメーターを指定する、といったことが必要になる可能性があります。また、
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
12
ソースのデータが XML 形式や JSON 形式など、階層構造で提供されている場合は、データを「平坦
化」するためのロジックが必要になります。しかし、インポートプロセスは通常、比較的単純です。
論理テーブル – 物理テーブルを定義した直後から、アプリケーションで物理テーブルを使用で
きます。アプリケーションから見えるのは当然、ソースシステム内に格納された状態のオリジナル
データです。これには、誤ったデータやスペルミスのあるデータなどもすべて含まれます。また、デ
ータはまだ他のソースと統合されていません。この場合、アプリケーションが統合の役割を担うこ
とになります (図 3 を参照)。
論理テーブル (仮想テーブルまたは論理データオブジェクトと呼ばれることもあります) を定義
することで、変換と統合の仕様を定義できます (図 4 を参照)。通常は ETL ジョブ内で完結する
変換および統合のロジックが、論理テーブルの定義内で完結します。アプリケーションにとって、
論理テーブルは列とレコードを持つ通常のテーブルに見えます。異なるのは、コンテンツが仮想的
だということです。この点に関して、論理テーブルは SQL データベースのビューのようなもので
す。論理テーブルの仮想コンテンツは、物理データベース (データソース) がアクセスされたとき
に導出されます。
論理テーブルの定義は、構造とコンテンツで構成されます。コンテンツは SQL クエリを使用して
定義されます。構造とクエリの組み合わせにより、論理テーブルのマッピングが作成されます。
図 4: 論理テーブル
は、データの統合、変
換、およびクレンジン
グに使用されます。
論理テーブル
<XML>
物理テーブル
データソース
このマッピングは、物理テーブルからのデータを変換および統合する方法を定義します。開発者は
SQL をフル活用して仮想コンテンツを定義します。SQL クエリで指定可能な次のような各操作を
使用できます。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
•
•
•
•
•
•
•
•
•
•
•
•
ソーステーブルからのすべての行のサブセットを選択するようにフィルターを指定
複数の物理テーブルからのデータを結合 (統合)
物理テーブルの列を削除 (射影)
文字列操作関数の長いリストを適用することで、値を変換
物理テーブルの列を連結
ソーステーブルの列名とソーステーブル自体の名前を変更
新しい仮想列と導出可能列を追加
グループ化操作を指定して、データを集約
統計関数を適用
誤ったデータ値をクレンジング
行をソート
行にランク番号を割り当てる
論理テーブルのネスト – SQL データベースのビューはネスト (またはスタック) できますが、
論理テーブルでも同様のことが可能です。言い換えると、論理テーブルを他の論理テーブルの上位
に定義できるということです (図 5 を参照)。こうような方法で定義された論理テーブルは、ネス
トされた論理テーブルと呼ばれることがあります。論理テーブルはいくつでもネストできます。
仮想テーブルのネストが可能なことの最大の利点は、共通仕様論理テーブルをネストすること
を共有できることです。たとえば、図 5 では、ネストされた 2 で、共通仕様を共有できます。
つの仮想テーブル LT1 および LT2 は、3 つ目のテーブル LT3
の上位に定義されています。このレイヤー型アプローチの利点は、LT3 のマッピング内のすべての
仕様が、他の 2 つのテーブルと共有されることです。LT3 の共通仕様が変更されれば、その変更は
LT1 と LT2 にも自動的に適用されます。これは、クレンジング、変換、および統合の仕様に関連さ
せることもできます。つまり、2 つのデータソースの統合ソリューションを定義したら、他のすべ
ての論理テーブルおよびアプリケーションで再利用が可能というわけです。
LT1
LT2
ネストされた
論理テーブル
論理テーブル
LT3
<XML>
Copyright © 2014 R20/Consultancy, all rights reserved.
物理テーブル
図 5: 論理テーブルをネス
トすることで、共通仕様を
共有できます。
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
14
論理テーブルの公開 – 定義した論理テーブルは、公開する必要があります。公開とは、1 つまた
は複数の言語および API を通じてアプリケーションで論理テーブルを利用できるようにするこ
とです。たとえば、あるアプリケーションは JDBC API を通じ SQL 言語を使用して論理テーブル
にアクセスすることを求め、別のアプリケーションはこの同じ論理テーブルに、SOAP および HTTP
を使用し Web サービスとしてアクセスすることを求めている、というケースが考えられます。
ほとんどのデータ仮想化サーバーは、幅広いインターフェースと言語をサポートしています。その
中でも特に一般的なものを、いくつか次に挙げます。
•
•
•
•
•
•
•
SQL と ODBC
SQL と JDBC
SQL と ADO.NET
HTTP を利用した SOAP/XML
ReST (Representational State Transfer) と JSON (JavaScript Object Notation)
ReST と XML
ReST と HTML
1 つの論理テーブル上に複数の技術的インターフェースが定義されていると、マッピングの定義
が再利用される点に注意してください。そのため、マッピングが変更されると、アプリケーション
が使用する技術的インターフェースに関わらず、すべてのアプリケーションで違いが認識されま
す。
論理テーブルを通じたデータセキュリティ – 一部のソースシステムは、独自のデータセキュ
リティシステムを備えており、データの誤った使用または不正使用から保護するための独自の機
能をサポートしています。データ仮想化サーバーがこのようなソースにアクセスした場合、データ
仮想化サーバーはそのデータソースのユーザーとして扱われるため、独自のセキュリティルール
がそのまま適用されます。
しかし、すべてのデータソースがデータセキュリティレイヤーを備えているわけではありません。
その場合、データ仮想化サーバーにデータセキュリティを実装できます。各テーブルに対する権限
の付与は、SQL データベースのテーブルにアクセス権を付与するのとほぼ同じ方法で実行できま
す。選択、挿入、更新、削除といった権限を付与できます。データソースが独自のデータセキュリテ
ィメカニズムをサポートしている場合でも、データセキュリティを実装できる点に注意してくだ
さい。
データ仮想化サーバーの中には、アクセス権をテーブルレベル、個々の列レベル、レコードレベル、
および個々の値レベルで付与できるものもあります。最後に挙げたケースの意味は、2 人のユーザ
ーがある特定のレコードにアクセスできる状態で、一方にはすべての値を見せ、もう一方にはマス
クされた値を見せるというような制御が可能だということです。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
論理テーブルのキャッシュ – 前述のとおり、データ仮想化サ論理テーブルのキャッシュは
ーバーはオンデマンドのデータ統合をサポートしています。統合クエリのパフォーマンスを向
上させるのに使用されます。
をライブで実行するのは常に推奨されるわけではないため、キャ
ッシュがサポートされています。各論理テーブルに対してキャッ
シュを定義できます。要点は、仮想コンテンツが実体化されるということです。クエリを実行する
ことでコンテンツが決定され、その結果がキャッシュに格納されます。その後アプリケーションが
キャッシュされた論理テーブルにアクセスする際、データソースにはアクセスせず、キャッシュか
らデータを取得することで求める結果を決定します。
キャッシュは、次に示すさまざまな理由で使用されます。
•
•
•
•
•
クエリのパフォーマンス
ロードの最適化
一貫性のあるレポート作成
ソースの可用性
複雑な変換
キャッシュがメモリー、ファイル、データベースのいずれに格納されていても、データ仮想化サー
バー自体に管理されるという点は変わりません。キャッシュされた各論理テーブルに対して、更新
スケジュールを定義する必要があります。
クエリの最適化 – データソースにアクセスする際のパフォーマンスは重要です。そのため、デー
タ仮想化サーバーができるだけ効率的にソースにアクセスする方法を認識していることが重要で
す。データ仮想化サーバーはインテリジェントクエリオプティマイザーをサポートしている必要
があります。
最も重要なクエリ最適化機能の 1 つはプッシュダウンと呼ばれます。データ仮想化サーバーは、
プッシュダウンによって、クエリ処理のできるだけ多くをデータソース自体にプッシュしようと
します。そのため、クエリを受け取ると分析し、データソースにクエリ全体をプッシュできるか、あ
るいは一部をプッシュダウンできるかを判断します。前者の場合、ソースから返された結果はデー
タ仮想化サーバーによる追加処理を必要とせず、アプリケーションに直接プッシュできます。後者
の場合、ソースから受け取った結果をデータアプリケーションに返す前に、データ仮想化サーバー
が何らかの追加処理を実行する必要があります。
プッシュダウンは、データ仮想化サーバーに返される転送データの量、データベースサーバーの I
/O 処理量、およびデータ仮想化サーバー自体の処理量を最小限に抑えるために必要です。これら
はすべて、クエリのパフォーマンス向上の目的で行われます。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
16
6 データ仮想化の BI 関連の応用分野
現在、データ仮想化は BI システムにおいてさまざまな方法で使用されています。このセクション
では、特に一般的な応用分野の一部を説明します。
仮想データマート – データマートは、さまざまなニーズに応じて作成できます。たとえば、レポ
ート作成ツールとユーザーがデータを簡単に理解してクエリを実行できるような方法で、テーブ
ルと列を整理したい場合などです。そのため、データマートは特定のレポートおよびユーザーの組
み合わせに対して設計されます。従来の BI システムでは、データマートは物理データベースです。
物理データマートを作成することには欠点があります。第 1 に、データマートデータベースを設
計、作成、最適化、および管理する必要があることです。第 2 に、データマートをロードするために
ETL プロセスを設計、作成、最適化、管理、およびスケジュールする必要があることです。
データ仮想化を使用すれば、論理テーブルを使用してデータマー仮想データマートは BI シス
トをシミュレーションできます。異なるのは、ユーザーに見えるテムの俊敏性を高めます。
テーブルは論理テーブルであり、物理的に格納されたものではな
い点です。そのコンテンツは、論理テーブルにクエリが実行されたときにオンデマンドで導出され
ます。仮想データマートという名前の由来はここにあります。ユーザーには違いはわかりません。
仮想データマートの大きな利点は、俊敏性です。仮想データマートの方が作成と対応を短時間で済
ませることができるのです。
拡張データウェアハウス – 分析に必要なデータのすべてがデータウェアハウスから入手でき
るわけではありません。社外データソース、コールセンターのログファイル、ブログファイル、顧客
との通話の音声トランスクリプト、個人のスプレッドシートといった従来型ではないデータソー
スは、多くの場合含まれていません。これらを含めれば分析とレポート作成の能力を確実に高める
ことが可能なため、残念なことです。
これらのデータソースの一部でデータウェアハウスを強化するデータ仮想化により、拡張デー
には、労力と時間がかかることがあります。データソースによっタウェアハウスを簡単に作成
できます。
ては、データをデータベースのチェーンに組み込むのに数か月を
要する場合もあります。その間、ビジネスユーザーはその全デー
タの統合ビューを得る方法がなく、当然、高度な形態の分析を実行することもできません。
データ仮想化サーバーを使用すると、これらのソースとデータウェアハウスが全体として 1 つの
統合されたデータベースに見えます。この概念は、拡張データウェアハウスと呼ばれます。ある意
味、データ仮想化はこの目的のために設計されたとも言えます。この概念は、文献にある logical
data warehouse (論理データウェアハウス) および data delivery platform (データ供給プラ
ットフォーム)Error: Reference source not found という概念と類似しています。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
ビッグデータ分析 – ビッグデータを Hadoop システムと NoSQL システムに格納する組織が増
えています。残念ながら、ほとんどのレポート作成ツールと分析ツールは、SQL または類似のイン
ターフェースが必要なため、これらのデータベースサーバーにアクセスできません。この問題を解
決する方法は 2 つあります。1 つは、関連するビッグデータを SQL データベースにコピーするこ
とです。ただし、Hadoop ソリューションまたは NoSQL ソリューションを選択した場合、データ量
はおそらく膨大なものになります。このデータをすべてコピーした場合に時間がかかることや、2
回分のデータ格納にコストがかかることがあります。
もう 1 つの解決策は、Hadoop システムと NoSQL システムの上位でデータ仮想化サーバーを使用
し、物理テーブルとしてラップして、SQL インターフェースで公開することです。データ仮想化サ
ーバーの役割は、受け取った SQL ステートメントをビッグデータシステムの API または言語に
変換することです。NoSQL システムのインターフェースは独自仕様なので、データ仮想化サーバー
は個々の NoSQL システムに対する専用のラッパーテクノロジーをサポートする必要があります。
運用データウェアハウス – 運用データウェアハウスは通常、履歴データだけでなく運用データ
も保持するデータウェアハウスとされています。これにより、数秒前に入力されたデータのレポー
トを作成することが可能になります。
新しい本番データをデータウェアハウスに高速コピーすることで運用データウェアハウスを実装
するのは、技術的な困難を伴うことがあります。データ仮想化サーバーを導入することで、データ
をコピーすることなく運用データウェアハウスをシミュレーションできます。
データ仮想化サーバーは、本番データベースを含むあらゆるタイデータ仮想化により、運用デー
プのデータベースと接続できます。そのため、レポートが運用デタをコピーすることなく運用
データウェアハウスを実現で
ータにアクセスする必要がある場合は、本番データベースのテー
きます。
ブルをポイントする論理テーブルを定義できます。これにより、
アプリケーションは、(本番データベースの) 運用データと (デ
ータウェアハウスの) 履歴データを高度な方法で結合できます。その結果、運用データ自体を格納
するデータウェアハウスを実際に作成しなくても、運用データウェアハウスを作成することが可
能になります。
通常、本番システムへの干渉を最小限に抑えるために、ETL ジョブはいわゆるバッチ期間にスケジ
ュールされます。多くの本番システムは 24 時間年中無休で運用されるため、このバッチ期間は設
けられていません。クエリのワークロードは 1 日全体に分散しているため、データ仮想化サーバ
ーにより生成されるワークロードは、この 24 時間年中無休の制約に近い部分があります。また、
データ仮想化サーバーは、データソースにできるだけ効率的にアクセスするためのキャッシュや
プッシュダウンの最適化といった各種機能をサポートしています。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
18
コールドデータのオフロード – データウェアハウスに格納されたデータは、コールド、ウォー
ム、ホットのいずれかに分類できます。ホットデータは毎日のように使用され、コールドデータは
ときどき使用されます。コールドデータをデータウェアハウスに保持しておくと、大部分のクエリ
の処理速度が低下します。また、すべてのデータを高価なデータストレージシステムに格納するこ
とになるため、コストもかかります。データウェアハウスを SQL データベースで実装している場
合、コールドデータをそのデータベースの外部、たとえば Hadoop システムに格納すると便利かも
しれません。このソリューションを用いると、ストレージコストを削減できますが、それ以上に注
目すべきなのは、データウェアハウスのホットデータとウォームデータに対するクエリの処理速
度が向上すること (データ量の削減)、そして扱えるデータ量が増えることです。
しかし、最も重要なのは、データウェアハウスの SQL 部分からのデータを Hadoop システムに供
給する必要があるときに、データ仮想化サーバーが非常に有用だということです。データのコピー
は、SQL テーブル間でコンテンツを単純にコピーするだけでよいので、シンプルです。また、Hadoop
のビッグデータファイルにデータ仮想化サーバーを使用した場合でも、レポートは簡単にコール
ドデータにアクセスできます。
クラウドの透明性 – セクション 2 で説明したように、データウェアハウスアーキテクチャー
のコンポーネントはクラウドに移動されつつあります。このような移行は、データへのアクセス方
法に変化をもたらすことがあります。データ仮想化サーバーによって、この移行を隠すことができ
ます。すべてのデータが必ずデータ仮想化サーバー経由でアクセスされるようにすれば、データの
物理的な格納場所を隠すことが可能です。データベースがクラウドに移動しても、オンプレミスに
戻っても、あるいはクラウド間で移行した場合でも、データ仮想化サーバーが技術的な違いを隠す
ため、レポートとユーザーにとってこうした移行は簡単で透明性が確保されたものになります。こ
のように、データ仮想化サーバーでクラウドの透明性が実現します。
まとめ – データ仮想化テクノロジーは、さまざまな応用分野に使用できます。このセクションで
は数例のみ紹介しましたが、他にもデータサイエンティスト向けのサンドボックス化、データサー
ビス、統合ソリューションのプロトタイプ化といった例が挙げられます。
7 データ仮想化と新たな BI の課題
このセクションでは、データ仮想化を使用してセクション 2 に挙げた新たな BI の課題に対応す
る方法を概説します。
•
生産性の向上:データ仮想化はオンデマンドのデータ統合をサポートするため、データマ
ートなどの導出データベースを作成する必要性が低減されます。これにより、データベー
スのチェーンを明らかに短くすることができ、開発が迅速で保守が容易なシステムが実現
します。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
•
セルフサービス BI:仮想データマートを作成すれば、IT 部門は変更要求を容易に実装で
きます。論理テーブルの定義を変更するだけで済みます。物理データマートをアンロード
および再ロードする必要も、ETL ジョブを変更する必要もありません。これについては、セ
クション 8 で詳しく説明します。
•
運用インテリジェンス:前のセクションで説明したように、運用データウェアハウスはデ
ータ仮想化の応用分野です。(論理テーブルを通じて) ユーザーに運用データへのアクセ
ス権を付与できます。該当データをコピーする必要はありません。また、ユーザーは、運用
データを物理データウェアハウスに格納された履歴データと統合できます。
•
ビッグデータ、Hadoop、および NoSQL:ほとんどのデータ仮想化サーバーは、Hadoop シ
ステムと NoSQL システムへの直接アクセスをサポートしています。つまり、データの場所
は変えないまま、SQL を使用したレポート作成ツールおよび分析ツールによるデータ分析
が可能だということです。ビッグデータはチェーンを通じて取得されます。
•
クラウドのシステム:データ仮想化は、クラウドテクノロジーを隠すことができます。ま
た、システムが実行されている場所も隠せます。クラウド間でシステムを移行する場合で
も、移行の透明性は確保されます。データ仮想化は、クラウドを透明なものにします。
•
クラウドのデータ :社外データソースが明確に定義された API を持つ場合、データ仮想
化サーバーはそのデータソースにアクセスできます。データ仮想化サーバーを使用すると、
こうした社外データソースのレポートを直接作成でき、社外データは社内データと同じ方
法で統合、変換、およびクレンジングすることが可能です。
8 データ仮想化により統合仕様の共有を簡素化
仕様を共有しないことの危険性 – 組織のすべてのユーザー多くの BI システムでは、各
が同じレポート作成ツールを使用するということはめったにあ BI ツール間で仕様は共有され
ません。
りません。さまざまなツールを使用するのが一般的です。しかし、
ツールは統合、変換、またはクレンジングの仕様を共有しません
(図 6 を参照)。あるツール用に開発されたソリューションを別のツールで再利用することはでき
ないのです(数多くの BI システムが存在する状態では、ユーザーが同じツールを使用していても、
仕様はやはり共有されないことに注意してください)。そのため、ソリューションをさまざまなツ
ールに実装する必要が生じ、すべての統合、変換、およびクレンジングの仕様を複製することにな
ります。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
BI ツール
1
ソース
1
BI ツール
3
BI ツール
2
リポジトリ
ソース
2
リポジトリ
リポジトリ
ソース
3
20
ソース
4
ソース
5
図 6: BI ツールは統
合、変換、およびクレ
ンジングの仕様を共
有しません。それぞ
れ、独自の中央リポ
ジトリを持っていま
す。
ソース
6
たとえば、あるユーザーが、顧客の合計注文数、平均注文額、製品の返品数、注文してからの経過時
間などに基づいて「優良顧客」の概念を定義したとします。優良顧客とそうでない顧客を識別する
ためのフィルターや数式も入力します。しかし、類似の概念を必要としているものの、別のツール
を使用している別のユーザーは、定義済みのその概念を利用できません。自分のツールを使用して、
自ら概念を定義しなければならないのです。その結果、同じ作業が何度も繰り返されることになり
ます。
仕様を共有しなかった場合、BI システムの俊敏性レベル、BI 開発者の生産性、およびレポート結
果の正確さと一貫性が低下するのは明らかです。
セルフサービス BI ツールは中央リポジトリを持たないセルフサービス BI ツールでは、
– 多くのセルフサービス BI ツールの欠点は、仕様を格納しユユーザーが同じ作業を何度も繰
り返すことがよくあります。
ーザーとレポートで共有できる中央リポジトリが実質的に存
在しないことです。たとえば、2 人のユーザーが同じ 2 つのデ
ータソースを統合する場合、それぞれが自分のソリューションを定義する必要があります。つまり、
これらのユーザーは同じツールで作業しているにも関わらず、統合と変換の仕様は限定的にしか
共有されないのです。そのため、同じ作業が何度も繰り返されることになります。
また、データソースの統合は必ずしも簡単にはいきません。データソースの構造が非常に複雑な場
合、データの整理方法について深い知識が必要になります。そのロジックの一部は、データ構造や
データ自体の深部に隠されていることもあります。ここで問題になるのは、そのような状況で本当
に正しい形態の統合が実装されているのか、ということです。システムの統合は、ドラッグアンド
ドロップの操作のように簡単にいくとは限りません。統合の複雑さは決して軽視されるべきでは
ありません。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
データ仮想化による解決 – データ仮想化を導入すると、多くデータ仮想化により、仕様の共
の仕様を一元的に実装し、共有することが可能です。仕様は、さま有が可能になります。
ざまなベンダーのさまざまなツールでも共有できます (図 7 を
参照)。データ仮想化サーバーを使用すれば、優良顧客の定義は一度入力するだけで済み、その定義
をすべてのユーザーで共有できます。定義を使用中のすべての BI ツール間で共有することも可
能なのです。
この仕様の共有が BI システムの俊敏性レベルを向上させるのは明らかです。優良顧客の定義が
変わっても、1 か所で変更するだけで済みます。BI 開発者の生産性やレポート結果の正確さおよ
び一貫性を向上させることも可能です。また、一部のデータソースの統合が複雑な場合は、IT スペ
シャリストが (論理テーブルを使用して) すべての BI ユーザーに対して実装できます。このよ
うに、仕様の共有と再利用によって、同じ作業を何度も繰り返すことがなくなります。
BI ツール
1
BI
2
ツール
BI
3
図 7: データ仮想化
を導入すると、仕様
は中央リポジトリに
格納され、共有でき
ます。
ツール
リポジトリ
仕様を共有したデータ仮想化
ソース
1
ソース
2
ソース
3
ソース
4
ソース
5
ソース
6
セルフサービス BI ツールに関しては、ユーザーは低レベルの論理テーブルにアクセスすること
で、統合仕様を自分で定義することもできます。優良顧客などの概念を自分のツールで定義する代
わりに、データ仮想化サーバーにおいて自分で再利用可能な仕様を作成できます。自分のセルフサ
ービスツールで体験したのと同レベルの使いやすさと柔軟性を享受できるのです。データ仮想化
サーバーで仕様を変更するには、セルフサービス BI ツールで対応する仕様を変更すればよいの
で簡単です。
9 Red Hat JBoss Data Virtualization サーバーの概要
Red Hat JBoss Data Virtualization の歴史 – Red Hat のデータ仮想化製品 JBoss Data V
irtualization (JDV) は、新製品ではなく、成熟した製品です。当初はクローズドソース製品で、Me
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
22
taMatrix と呼ばれていました。ベンダーは 1998 年創立の Quadrian で、後に社名は MetaMatrix
に変更されました。同社初のデータ仮想化製品がリリースされたのが 1999 年。まだこの製品が市
場で大きな注目を浴びておらず、データ仮想化が普及していなかった 2007 年 6 月に、Red Hat
は同社を買収しました。Red Hat は数年をかけて、このクローズドソース製品をオープンソース製
品に転換しました。
当初、Red Hat の製品は JBoss Enterprise Data Services Platform という名前でリリースされ
ました。この名前は 2013 年末に変更されています。現在、この製品には 2 つのバージョンがあり
5
ます。コミュニティエディションの Teiid と、エンタープライズエディションの JBoss Data Vi
rtualization です。Red Hat の製品が現在リリースされている唯一のオープンソースデータ仮想
化サーバーであるという点は、注目に値します。このセクションでは、JDV にのみ焦点を当てます。
共同作業による迅速な開発 – 各データ仮想化製品にはオンデマンドのデータ表示機能が装備
されています。論理テーブルを作成したら、ユーザーは直ちにその (仮想) コンテンツを調査でき
ます。JDV は、ダッシュボード化を通じたオンデマンドのデータ視覚化もサポートしています。こ
の機能を使用すれば、論理テーブルを作成した直後に、論理テーブルの仮想コンテンツを棒グラフ、
円グラフなどで視覚化できます (図 8 を参照)。
図 8: JBoss Data Virtualization でのダッシュボードを通じたデータ視覚化
5
Teiid はトカゲの一種です。この名前に含まれる頭字語 EII は、Enterprise Information Integration
(企業情報統合) を意味します。EII という語は、データ仮想化という語の先駆的概念と捉えることもできま
す。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
このオンデマンドのデータ視覚化機能により、共同開発が可能になります。アナリストとビジネス
ユーザーは協力して、論理テーブルの定義に関する作業に取り組めます。(一部のユーザーには技
術的に高度すぎる可能性がある) 定義とモデルに関する作業をアナリストが行うと、ユーザーは
直感的に視覚化された自分のデータを見ることができます。誤った実装方法では開発に時間がか
かりますが、このような共同開発を行えば、開発時間を短縮してコストを削減できます。そして迅
速な開発が実現します。
設計環境 – グラフィカルで使いやすい設計環境を使用して論理テーブルを定義できます。図 9
は、5 つの論理テーブルとそれらの関係を示したスクリーンショットです。よく知られた JBoss D
eveloper Studio はアドオンであり、設計環境および開発環境として使用できます。
系統分析と影響分析 – JDV は、データソース、論理テーブル、物理テーブルなどの概念のすべて
の定義を 1 つの中央リポジトリに格納します。そのため、これらのオブジェクト間のすべての依
存関係を簡単に表示できます。この機能を使用すると、たとえば、ソーステーブルまたは論理テー
ブルの構造が変更されたときの影響 (他に変更の必要がある論理テーブルはどれか) を判断する
のに役立ちます。言い換えると、JDV では系統分析と影響分析が可能なのです。
データソースへのアクセス – JDV は、数多くのソースシステムにアクセスできます。具体例を
挙げると、最もよく知られた SQL データベースサーバー (Oracle、DB2、SQL Server、MySQL、および
PostgreSQL)、エンタープライズデータウェアハウスプラットフォーム (Teradata、Netezza、およ
び EMC/Greenplum)、オフィスツール (Excel、Access、および Google スプレッドシート)、アプリ
ケーション (SAP および Salesforces.com)、フラットファイル、XML ファイル、SOAP および REST
Web サービス、OData サービスなどに対応しています。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
24
図 9: JBoss Data Virtualization でのテーブル間の関係表示
Hadoop と NoSQL のビッグデータへのアクセス – Hadoop システムまたは NoSQL システム
に格納されたビッグデータにアクセスするために、JDV は HDFS および MongoDB 用のインターフ
ェースを備えています。Hadoop に関しては、JDV の実装は Hive 経由で機能します。つまり、JDV
がアプリケーションから受け取った SQL クエリを Hive に送信し、Hive がそのクエリを MapRed
uce コードに変換し、そのコードが HDFS ファイルで並行して実行されます。MongoDB の場合は、
階層データがリレーショナルテーブルに平坦化されます。
ユーザー定義関数 – SQL では複雑すぎるロジックの場合、開発者は独自の関数を作成できます。
たとえば、複雑な統計関数や、複雑な値を一連の単純な値に変換する関数などです。これらのユー
ザー定義関数は、Java で作成し、SQL ステートメントから呼び出すことができます。ユーザー定義
関数の呼び出しは、組み込まれた SQL 関数の呼び出しと似ています。
論理テーブルを作成するための 2 つの言語 – 論理テーブルは、SQL クエリまたはストアド
プロシージャを使用して定義できます。豊富な SQL 方言をサポートしており、必要な変換、集約、
および統合のほとんどを指定できます。ストアドプロシージャは、たとえば、非リレーショナルデ
ータをよりリレーショナルな構造に変えるための複雑な変換を必要とする SQL 以外のソースシ
ステムにアクセスした場合に必要になることがあります。
クエリオプティマイザー – クエリのパフォーマンスを向上させるために、JDV のクエリオプテ
ィマイザーは、クエリ処理の大部分または全部をデータソースにプッシュダウンするための各種
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
手法をサポートしています。マージ結合や分散結合といった、複数の結合処理戦略に対応していま
す。オプティマイザーにより選択された処理戦略 (またはクエリ計画) は、開発者が検討を加える
ことができます。オプティマイザーはブラックボックスではありません。オプティマイザーのこの
オープン性は、クエリのチューニングおよび最適化に非常に役立ちます。
キャッシュ – JDV は、2 つの形態のキャッシュをサポートしています。内部実体化キャッシュと
外部実体化キャッシュです。内部実体化キャッシュでは、キャッシュはメモリーに保持されます。
内部実体化キャッシュを使用すると、データに高速アクセスできるという利点があります。しかし、
メモリーが限られており、すべてのデータをキャッシュできないという欠点もあります。外部実体
化キャッシュでは、データは SQL データベースに格納されます。この場合、キャッシュされたデー
タのサイズに制限はありません。しかし、メモリーを使用した場合と比べると処理速度がある程度
低下します。
論理テーブルの公開 – JDV は数多くの API (JDBC、ODBC、SOAP、RESR、OData など) をサポート
しており、これらの API を通じて論理テーブルにアクセスできます。
データセキュリティ – JDV は、セクション 5 で示した 4 種類の形態のデータアクセスセキュ
リティをサポートしています。選択、挿入、更新、削除などの権限は、テーブルレベル、個々の列レベ
ル、レコードレベル、および個々の値レベルで付与できます。これにより、JDV をデータセキュリテ
ィファイアウォールとして活用できます。また、特定の API を使用して論理テーブルが公開され
た場合、セキュリティ要素も定義できます。たとえば、開発者は、WS-Security で拡張された SOAP
を使用して論理テーブルを公開できます。
埋め込み可能 – JDV の機能はすべて、オープン API を通じて呼び出せます。アプリケーション
が JDV の機能を呼び出せるということです。JDV が埋め込み可能なデータ仮想化サーバーである
理由はここにあります。ベンダーと組織はこの API を使用して、埋め込み可能なソリューション
を開発できます。
まとめ – 成熟したデータ仮想化サーバーである JBoss Data Virtualization を使用すると、組
織はアジャイルなアーキテクチャーを備えた BI システムを開発できます。オンデマンドのデー
タ統合機能により、次に示す数多くの応用分野に対応できます。
•
•
•
•
•
•
仮想データマート
拡張データウェアハウス
ビッグデータ分析
運用データウェアハウス
コールドデータのオフロード
クラウドの透明性
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
26
JDV により、BI システムが直面している新たな課題に対応する俊敏性の高い BI システムを開発
できます。
Copyright © 2014 R20/Consultancy, all rights reserved.
データ統合の再考:データ仮想化によるアジャイルな BI システムの実現
ライターの Rick F. van der Lans について
Rick F. van der Lans は、データウェアハウス化、ビジネスインテリジェンス、データベーステク
ノロジー、およびデータ仮想化を専門とし、独立系のアナリスト、コンサルタント、ライター、およ
び講師の肩書きを持ちます。現在、1987 年に自ら設立したコンサルタント会社 R20/Consultancy
(www.r20.nl) に勤務しています。
Rick は、年次開催の European Enterprise Data and Business Intelligence Conference (ロン
6
ドンで開催) の議長も務めています。また、著名な B-eye-Network.com や他の Web サイトに寄
7
稿しています。2009 年には、BeyeNetwork.com で公開された複数の記事で、データ仮想化に基づ
いた Data Delivery Platform (データ供給プラットフォーム) と呼ばれるビジネスインテリジ
ェンスのアーキテクチャーを紹介しました。
8
著書も複数あり、最新の著書『Data Virtualization for Business Intelligence Systems (ビジ
ネスインテリジェンスのためのデータ仮想化)』は 2012 年に出版されました。1987 年に出版され
9
人気を博した『Introduction to SQL (SQL 入門) 』は、市販されている英語の書籍で初めて SQL
のみを扱った内容でした。この書籍は 25 年以上経てなお販売されており、中国語、ドイツ語、イタ
リア語、オランダ語などの複数の言語に翻訳されています。
詳細については、www.r20.nl をご覧いただくか、[email protected] まで E メールでお問い合わせくだ
さい。LinkedIn や Twitter (@Rick_vanderlans) で連絡を取ることもできます。
Red Hat, Inc. について
Red Hat は、オープンソースソリューションの世界有数のプロバイダーです。コミュニティに支え
られたアプローチを活かして、信頼性が高くパフォーマンスに優れたクラウド、仮想化、ストレー
ジ、Linux、およびミドルウェアのテクノロジーを提供しています。また、受賞歴のあるサポート、ト
レーニング、コンサルティングサービスも提供しています。Red Hat は、S&P 社の株価指標に採用
されている企業で、世界中に 70 以上の拠点を展開し、お客様のビジネスを支援しています。
6
http://www.b-eye-network.com/channels/5087/articles/ を参照
7
http://www.b-eye-network.com/channels/5087/view/12495 を参照
8
R.F. van der Lans、『Data Virtualization for Business Intelligence Systems (ビジネスインテリジェンスシス
テムのためのデータ仮想化)』、Morgan Kaufmann Publishers、2012 年
9
R.F. van der Lans、
『Introduction to SQL; Mastering the Relational Database Language (SQL 入門、リレーショ
ナルデータベース言語をマスターする)』、第 4 版、Addison-Wesley、2007 年
Copyright © 2014 R20/Consultancy, all rights reserved.

Download Report