プロジェクト REAL : 技術概要

トピック

	はじめに
	SQL Server 2005 の BI 機能
	プロジェクト REAL のデータ
	実装する論理コンポーネント
	Analysis Services を使用した OLAP キューブ
	実装する物理コンポーネント
	プロジェクト REAL の成果
	まとめ

はじめに

プロジェクト REAL は、Microsoft® SQL Server™ 2005 に基づいてビジネス インテリジェンス (BI) アプリケーションを開発する場合のベスト プラクティスを調査するプロジェクトです。プロジェクト REAL では、この目標を達成するために、実際の顧客シナリオに基づいた実装例を構築します。社内に顧客データを用意し、そのデータを使用して、顧客が展開するときに直面するものと同じ問題に対処します。たとえば、以下のような問題があります。

実際の展開シナリオを扱っているため、SQL Server BI ツールを使用して BI システムを実装する方法を完全に理解するようになります。プロジェクト REAL では、大規模データ セットでも解析可能なことを望んでいる企業が、実際の展開時に直面するあらゆる問題に対処できることを目標としています。

このホワイト ペーパーでは、プロジェクト REAL で使用されるデータ、設計、システム、および手法の概要を説明します。プロジェクト REAL の作業で明らかになった教訓とベスト プラクティスについて、より詳細に説明したホワイト ペーパーが、プロジェクト REAL の Web サイトで入手できます。これらの資料は、ほとんどの領域をカバーしています。SQL Server 2005 に基づいてビジネス インテリジェンス システムを計画または実装する際に、この実装例が役に立つことを願っています。

プロジェクト REAL をとおして、多数のドキュメント、ツール、およびサンプルが作成される予定です。最新情報を入手するには、以下のサイトを参照してください。

http://www.microsoft.com/sql/bi/ProjectREAL (英語情報)

共同の取り組み

プロジェクト REAL は、Microsoft と、各専門分野での実績を持つ複数のパートナー企業との共同の取り組みです。各パートナーから本プロジェクトに対してリソースが提供されました。また、各パートナーは、マーケティング情報を配信することではなく、一般的なベスト プラクティスを開発することを中心に技術研究を進めることに合意しています。各パートナーと専門分野は、以下のとおりです。

Apollo Data Technologies   データの更新時に常に最新の状態になるように、データ マイニング モデルを実装し、データを統合しました。

Barnes & Noble   プロジェクト REAL のビジネス シナリオとソース データ セットを提供しました。Barnes & Noble は、プロジェクトの目標が、自社で展開するシステムを作成することではなく、ベスト プラクティスと指示を広範囲の読者向けに作成することをであると理解したうえで協力しています。

EMC   プロジェクトに大量のストレージ リソースを提供し、システムのデータ完全性維持機能を実装して、プロジェクトのバックアップ システムを提供しました。

Emulex   サーバーをストレージ サブシステムに接続するホスト バス アダプタ (HBA) を提供しました。

Intellinet   Barnes & Noble で ETL システム全体の設計と実装を行い、プロジェクト REAL のモデルの実装要件に合わせてシステムを変更しました。

Panorama   システムの多様なクライアント アクセス方針を構築し、イントラネット、広域ネットワーク (WAN)、およびインターネットの各ユーザーの接続要件とセキュリティ要件をモデリングしました。また、見本となるプロジェクト REAL のフロントエンド システムも開発しました。

Proclarity   Analysis Services 2000 で実装されたものを Analysis Services 2005 へ移行する場合のガイドラインの構築とドキュメント化を行いました。また、見本となるプロジェクト REAL のクライアント フロントエンド システムも開発しました。

Scalability Experts   リレーショナル テーブルと Analysis Services キューブのパーティション分割など、データのライフサイクル管理機能の開発と実装を行いました。また、ETL プロセスにパーティション管理を実装しました。

Unisys   自社製品の Business Intelligence Center of Excellence から得られた専門技術を提供しました。また、32 ビット サーバー、64 ビット サーバーなど大量のハードウェア リソースも提供しました。さらに、日々の運用で使用する監視システムの設計と実装も行いました。

第 1 フェーズと第 2 フェーズ

プロジェクト REAL では、Microsoft のビジネス インテリジェンス製品の顧客から受け取ったデータを使用しています。プロジェクトの第 1 フェーズは、大規模な電子機器の販売業者をモデルに構築しました。この業者では、SQL Server 2000 のデータ ウェアハウス機能を使用して売上データと在庫データを管理しています。第 1 フェーズの実装では、現在 SQL Server 2000 を使用しているユーザーが SQL Server 2005 へ移行するときの懸案事項に焦点を当てました。結果として、既存機能の大部分は移行し、必要な場合は新しい機能をいくつか使用することになりました。第 1 フェーズに関するホワイト ペーパーは、以下の Microsoft Web サイトに公開されています。また、今後も公開されます。

プロジェクト REAL の第 2 フェーズは、Barnes & Noble で売上および在庫のデータ ウェアハウスに使用されているビジネスのシナリオ、スキーマ、およびデータに基づいています。第 1 フェーズは主に移行プロセスを検討していましたが、第 2 フェーズでは、SQL Server 2005 のベスト プラクティスを使用したシステムの完全なる再実装を行います。したがって、Barnes & Noble の実装にはない機能も含まれ、システムのパーツ数は多くなります。以降、このドキュメントではプロジェクト REAL の第 2 フェーズについて説明します。

ビジネスのシナリオ

書籍販売の Barnes & Noble (B&N) には米国の各地に約 800 店舗があり、40,000 名の従業員を擁しています。また、Barnes & Noble と B. Dalton という名称を使用し、BookStop と barnesandnoble.com を所有しています。Barnes & Noble が最初に作成したデータ ウェアハウスでは、企業レベルのプランナとバイヤー、店舗管理者、および配送センター管理者に対応することが目標でした。

B&N のデータ ウェアハウスには以下の目標がありました。

このデータの "現実味" を説明するために、図 1 に、2004 年の各月に関して、ある書籍の売上を 5 段階の領域に分けて示します。この図では、"既刊書リスト" として管理されている書籍は、冬期と夏期に売上が高くなり、春期と秋期には低くなりました。"新刊書リスト" として管理されている書籍は、年間をとおしてほぼ一定の売上でしたが、11 月と 12 月 (クリスマスの休暇シーズン) には急上昇しました。

図 1   発注方針ごとの売上
拡大表示する

プロジェクト REAL の目標から、B&N は、既存のデータ ウェアハウス データベースと、3 か月間の日常的な増分更新データを提供しました。このように、プロジェクト REAL システムを運用し、進行しているシステムの使用をシミュレートできます。機密情報を保護するために、プロジェクト REAL 用のデータは "マスキング" されました。B&N のデータベースは、もともと SQL Server 2000 を使用して開発されていましたが、SQL Server 2005 に変換されました。また、SQL Server 2005 のベスト プラクティスを示す多様な方法で採用されました。B&N では、その設計上の新しい特徴と高パフォーマンスを理由として SQL Server Integration Services (SSIS) のプレリリース版を使用して ETL 作業を実行することにした、という点に注意が必要です。B&N で使用するために開発されたパッケージは、プロジェクト REAL で ETL 作業の基礎になりましたが、このときも、その他のベスト プラクティスや機能を示すパッケージが採用されました。

構成とテストの概要

プロジェクト REAL は、単一システムの実装ではありません。構成の長所やパフォーマンスが異なる、多様なアーキテクチャが集まったものです。物理的な実装には関係なく、常に存在する論理コンポーネントとソフトウェア コンポーネントがあります。たとえば、図 2 に示すように、以下のようなコンポーネントが挙げられます。

図 2   アーキテクチャ概要
拡大表示する

これらのコンポーネントの物理的な実装方法には、さまざまな方法があります。パフォーマンス、展開のしやすさ、クライアントの接続性、セキュリティ、およびコストの観点では、それぞれ利点が異なります。

ソフトウェアのアーキテクチャおよび設計にも、さまざまな手法があります。プロジェクト REAL では 2 つの例を紹介します。

上記の各構成については、プロジェクト REAL について公開されている各種ホワイト ペーパーを参照してください。今後のホワイト ペーパーでは、アーキテクチャに及ぼす影響、エンド ユーザーの機能、構成の詳細、メンテナンスのしやすさなど、さまざまなトピックを扱う予定です。ただし、どのような構成であっても、一貫してかかわりのある、パフォーマンス メトリックスが存在します。これらのメトリクスについては、少なくとも、次の点を評価するうえでは一貫性のある測定を行います。

ページのトップへ

SQL Server 2005 の BI 機能

ここでは、SQL Server 2005 の BI 向けの主要機能について、改めて簡単に説明します。他のドキュメントで入手できる情報が数多くあるため、ここでは、概要を説明します。詳細については、Microsoft SQL Server Web サイト (http://www.microsoft.com/japan/sql/) を参照してください。さらに、SQL Server 2005 の初期ビルド (Community Technical Previews のいずれか) を所有している場合は、CD-ROM にリソースに関する節が収録されています。

SQL Server 2005 には、高い機能性、スケーラビリティ、および堅牢性を備えた BI アプリケーションを作成するときに必要なツールが用意されています。そのため、追加の費用はかかりません。

さまざまなソースからのデータを、リレーショナル データ ウェアハウスを作成するように統合して記述するために、SQL Server Integration Services (SSIS) を使用します。SSIS には、新しいパイプライン アーキテクチャが導入されています。このアーキテクチャでは、データを多様なソースから取得し、メモリ内で操作して、対象とするデータベースに格納できます。中間的な場所となるディスクに書き込む必要はありません。このことは、パフォーマンス上の大きな利点になります。パイプラインでは、データ検証、代理キーの検索、新しい列の派生、集計、並べ替えなどの操作を実行できます。

SQL Server のリレーショナル エンジンは、データ ウェアハウスの情報向けに、高い信頼性とスケーラビリティを備えた固定記憶域を実装しています。このことから考えると、他の解析やレポートにも利用できます。

Analysis Services は、リレーショナル データ ウェアハウスからデータを取得し、ユーザーが迅速にアクセスできるように準備します。Analysis Services には集計エンジンがあり、クエリに対して多様かつ詳細なレベルで、すばやく応答します。MDX (Multidimensional Expressions) というクエリ言語を使用しているため、複雑なクエリの表現も容易になります。Proclarity や Panorama などの多くのクライアント ツールでは、MDX 言語を使用して、Analysis Services 経由でデータにアクセスします。Web クライアントでは、HTML または Analysis 用の XML (XMLA) を使用して、MDX クエリを発行できます。

Reporting Services を使用すると、多くの形式 (HTML、Excel、PDF など) でレポートを簡単に作成し、取得することができます。レポートは、共通の定義形式で作成され、格納されます。さらに、使用できるいずれかのレポート形式で表示されることもあります。レポートは、すばやく取得することを目的にキャッシュできます。また、後で取得するために特定時点におけるレポートのスナップショットを保存することも可能です。Reporting Services のレポートは、リレーショナル データベースと Analysis Services のいずれかをデータ ソースとして使用して実行するように定義できます。

ページのトップへ

プロジェクト REAL のデータ

データの説明

Barnes & Noble では関連する複数のデータベースでデータ ウェアハウスを管理しています。プロジェクト REAL の目標から言うと、該当する主要データベースとして、Sales データベースと Inventory データベースがあります。これらの 2 つのデータベースにあるデータは、プロジェクト REAL の REAL_Warehouse という大規模な 1 つのデータベースに統合されています。スター スキーマは、ウェアハウスのエンティティを定義するディメンション テーブルのセットと、主題領域ごとに指標を持つファクト テーブルのセットと共に使用されます。このようなディメンション モデリングを主題にした優れた概要説明については、Ralph Kimball の書籍『The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling』(http://www.kimballgroup.com/html/books.html)(英語情報) を参照してください。

主な主題領域には、店舗売上 (Tbl_Fact_Store_Sales_YYYY_MM_DD テーブル)、店舗在庫 (Tbl_Fact_Store_Inventory_YYYY_MM_DD テーブル)、および配送センター (DC) の在庫 (Tbl_Fact_DC_Inventory_YYYY_MM_DD テーブル) があります。これらの主題領域は、各週のパーティション テーブルに分割され、それぞれパーティションの終了日を記載したタグが付けられています。全体で 15 のディメンション テーブルがあり、主に以下の項目を表します。

表 1 は、増分更新を適用する前の、REAL_Warehouse データベースで使用される最初の空間を示したものです。売上と在庫のファクト テーブルについてはパーティションが各週で維持されるため、テーブルごとの行数は異なりますが、平均はわかります。

表 1   データ ウェアハウスの初期統計値

B&N では、POS トランザクション用データベースと、在庫管理用のデータベースという 2 つの Oracle データベースから SSIS を使用して、増分更新が呼び出されます。また、(SSIS を使用して) データ ウェアハウス データベースに統合される前に、ステージング データベースで管理されます。プロジェクト REAL では、ステージングされた増分更新のコピーが Microsoft に転送されます。プロジェクト REAL で使用できる日常的な増分更新は 3 か月分あります。

ソース データベースの各種テーブルに対する更新は、変更されたときを示す日付押しを含めて、行にキャプチャされます。店舗 (BN_Store_Full)、バイヤー (IMM_Buyer_Full)、売買取引 (SRS_Sales_Trans_Full) など、入力されるデータ型ごとに 1 つのテーブルがあります。表 2 は、増分更新に使用できるデータ量を示したものです。

表 2   増分更新のソース データの統計値

注意が必要なのは、最初のデータ セットに、3 年間の売上データ、1 年間の店舗在庫データ、および 3 か月の DC 在庫データが含まれていたことです。これは、3 か月の増分更新データがシステムに追加されると、店舗在庫のデータ量は、売上データに対して比例的に増加します。また、DC 在庫量は 2 倍になると予想されます。

データの転送とマスキング

ニューヨークにある B&N の運用センターからワシントン州レドモンドにある Microsoft の研究所に、このような規模のデータを移動するという異例の課題に対応するため、いくつかの最新テクノロジを採用しました。まず、Imceda Software の LiteSpeed バックアップ機能を使用して、データベースのバックアップを作成しました。LiteSpeed が採用している圧縮方法により、容量を大幅に節約することができました。そして、作成したバックアップを USB のハード ドライブに書き込み、メール経由で送信しました。USB ハード ドライブを選択したことで、ドライブの接続や搬送に柔軟性を持たせることができました。

データの復元後、B&N のデータ値を保護するために、データを "マスキング" しました。機密情報を不透明にし、競合相手であれば関心を持つような種類の解析に役立たないデータを表示するために、さまざまな作業を行いました。それと同時に、マスキング後のデータも、B&N のデータが持つ運用特性を実際に反映し、解析やデモに役立つ現実的なデータであることも重要でした。このように、目的が矛盾する面もありましたが、すべての参加企業が要件を満たすと判断した解決策が見つかりました。データをマスキングするときに使用した手順を公開する予定はありませんが、結果のデータは現実に即してはいるものの全体的に正確ではない、ということをお伝えすれば十分でしょう。このデータを使用したデモを見ても、あえて触れなければ、それが修正されたデータとは気付かないと考えられます。

ページのトップへ

実装する論理コンポーネント

プロジェクト REAL で採用する全体的なアーキテクチャは、図 2 に示したとおりです。これは、SQL Server を使用して作成される BI システムの中でも典型的なアーキテクチャです。ソース データは、Integration Services を使用して 1 つ以上の場所から抽出され、さまざまな方法で変換されて、リレーショナル データ ウェアハウスに配置されます。Analysis Services キューブとデータ マイニング モデルは、リレーショナル データ ウェアハウスのデータに基づいて作成されます。エンド ユーザーは、キューブに定義されたレポートとして、Reporting Services を使用したリレーショナル データとして、または Analysis Services に対して実行される予備的な表示として、これらのデータにアクセスします。

リレーショナル データベース、Integration Services、Reporting Services、および Analysis Services は、Microsoft Windows® オペレーティング システム (現時点では Microsoft Windows Server™ 2003) で実行されます。次の節では、1 台の物理コンピュータと複数台の物理コンピュータのどちらで実行するかについて検討します。

Integration Services を使用した ETL

Barnes & Noble は、ETL の変換を実行する前に、SSIS を使用して、増分更新データをステージング データベースにコピーする方法を選択しました。この方法は、Microsoft の BI ツールのアーキテクチャで必要なわけではありません。実のところ、新しい SSIS アーキテクチャの利点の 1 つに、中間データをディスクに書き込むというオーバーヘッドを負うことなく、複雑な変換を実行できる機能があります。B&N の実装でステージング データベースを使用するのは、ソース システムから改めて抽出しなくても、ETL を再実行できるようにするためです (例 : 更新の実行後に問題が判明した場合)。この設計はプロジェクト REAL にとって好都合でした。なぜなら、ステージング データベースのコピーを取得することで、増分更新ストリームを再作成できるからです。プロジェクト REAL の目標から言うと、マルチソース システムの代替としてステージング データベースを使用することになります。

ETL プロセスで実行される主な機能は、以下のとおりです。

図 3 は、他のパッケージを呼び出してディメンション データとファクト データを処理する、あるパッケージの概要を示したものです。この例では、SSIS の制御フロー機能を使用して他のパッケージを呼び出します。これにより、ディメンション テーブルとファクト テーブルの更新は、適切な順序で実行されることになります。ここには、ディメンションの更新対象であるパッケージが 4 つあります (Merchant Division、Return Type、Buyer、および Item)。これらのディメンションについては、更新内容を Division Strategy ファクト テーブルに組み込む前に更新することが必要です。その更新が完了し、Store ディメンションが更新されると、Store Sales ファクトが更新されます。これは、B&N の用語で言う "ロード グループ" パッケージの例です。つまり、日常的に稼働しているパッケージ グループを制御します。日次の在庫データには、他のロード グループがあります。また、パーティションの作成を管理する、週次のロード グループもあります (B&N の実際のシステムでは、週次のロード グループが、プロジェクト REAL ではレプリケートされない他のビジネス機能も提供します)。

図 3   ETL 制御フロー例
拡大表示する

ロード グループから呼び出す各パッケージには、システムの特定エンティティ (ディメンション テーブルまたはファクト テーブル) に合わせてカスタマイズされた制御フローがあります。その中心には、データ フロー タスクがあります。図 4 は、ディメンションの単純なデータ フローを示したものです。

図 4   ETL データ フロー例
拡大表示する

制御フローでは、発生する多様なタスクやタスクの発生順序に基づいて条件を処理しますが、データ フローでは、システムを経由するデータのフローを処理します。データ レコードは、指定されたパスに従って移動します。図 4 に示したデータ フローでは、ベンダ情報を含むソース データを読み取り、入力が新しいレコードであるか既存レコードを変更したものかをチェックして表示しています。データがたどるパスは、状況に応じて変わります。ここでは、ETL の最も単純なデータ フロー例を示しました。いくつものデータ検証や複数のエラー処理パスを備えた、はるかに複雑なデータ フローもあります。

データ フロー アーキテクチャは "パイプライン アーキテクチャ" とも呼ばれ、前のリリースで使用されていたアーキテクチャよりもはるかに高速化されています。SSIS では、中間のオンディスク ストレージなしで、ソースから変換処理を経由して配置先へと流れるデータ フローを推奨しています。このデータ フロー アーキテクチャと組み合わせることで、パフォーマンスを大幅に改善できます。

プロジェクト REAL に関係する ETL プロセスと、その作成から得た教訓をより詳しく調査するには、ホワイト ペーパー「Project REAL ETL Design: Integration Services Lessons Learned」(英語情報) を参照してください。

リレーショナル データ ウェアハウス

リレーショナル データの一般的な特性については、このドキュメントの「データの説明」に示しました。ここでは、その他のいくつかの興味深い点について説明します。リレーショナル データにアクセスするビューの使用、テーブル パーティションの使用、および構成データのスキーマの追加に関連する事項について取り上げます。

参照整合性に関するメモ   ディメンション テーブルとファクト テーブルの間に論理的なプライマリ キー/外部キーの関係はありますが、プロジェクト REAL スキーマでは明示的に宣言していません。大規模なデータ ウェアハウスでは、メンテナンスを容易にするために、一般に、この関係を宣言しない方法が採用されます。ETL プロセスにとってより重要なことは、データの参照整合性を維持することです。

テーブルとビュー

B&N では、データベースのオブジェクトに名前付け規則が採用されています。テーブルには "Tbl_"、ビューには "vTbl_" というプレフィックスを付けます。さらに、そのプレフィックスの後に、ディメンション テーブルには "Dim_"、ファクト テーブルには "Fact_" を付加します。大規模なファクト テーブルは週ごとに分割されるため、ファクトのパーティション テーブルには、週の最終日の日付がサフィックスとして付けられます。したがって、店舗のディメンション テーブルは "Tbl_Dim_Store"、2004 年 6 月 19 日で終わる週の店舗在庫データを含むテーブルは "Tbl_Fact_Store_Inventory_WE_2004_06_19" のように名前が付けられます。

優れたデータ ウェアハウス設計における原則の 1 つに、他のシステムまたはエンド ユーザーからアクセス可能な各テーブルのビューを提供することがあります。ビューによって単純なビジネス ロジックを実装する場所を提供できますし、さらに重要な点は、システム設計を変更する場合に、分離したレイヤを用意できることです。在庫のファクト テーブルのビューを例示します。

CREATE VIEW vTbl_Fact_Store_Inventory_WE_2004_06_19 AS 
SELECT 
        INV.SK_Store_ID,
        STORE.SK_Parent_Store_ID,
        INV.SK_Item_ID,
        ITEM.SK_Parent_Item_ID,
        SK_Dept_ID = CAST(CASE WHEN ITEM.Dept_Num = -1 THEN 0
                               ELSE ITEM.Dept_Num
                          END AS Tinyint),
        INV.Sk_Date_Id, 
        INV.Sk_Buyer_Id, 
        INV.Sk_Model_Strategy_Id, 
        SK_Measure_ID = CAST(1 as Tinyint),
        INV.Model_Qty, 
        INV.On_Hand_Qty, 
        INV.On_Order_Qty,
        INV.Return_Qty, 
        INV.Retail_Amt,
        INV.Days_In_Stock
FROM dbo.Tbl_Fact_Store_Inventory_WE_2004_06_19 INV
  INNER JOIN Tbl_Dim_Store STORE ON STORE.Sk_Store_ID = INV.Sk_Store_ID
  INNER JOIN Tbl_Dim_Item ITEM   ON ITEM.Sk_Item_ID   = INV.Sk_Item_ID

このビューでは、Store ディメンションおよび Item ディメンションに対して参照整合性のあるファクト データのみが返されます (言い換えると、在庫の行に関連するエントリが Store ディメンションおよび Item ディメンションにない場合、その行は返されません)。さらに、単純なロジックが適用され (Dept_Num が -1 から 0 に変更されます)、SK_Measure_ID フィールドは tinyint にキャストされます。

ビューにロジックを実装するという案については、ビューからデータを取得するたびにロジックを実行しなければならないことに注意が必要です。パフォーマンス コストを超える価値が得られることが求められます。この例では、SK_Measure_ID と SK_Dept_ID に対する操作は取るに足りないものですが、ファクト テーブルとディメンション テーブル (特にサイズの大きい Item など) との結合はコストが高いため、慎重に検討する必要があります。

リレーショナル テーブルのパーティション化

SQL Server 2005 より前のバージョンでは、リレーショナル データベースで分割されたテーブルを維持するには、複数のテーブルを作成していました。たとえば、元のプロジェクト REAL データベースでは、店舗の売上データのためだけでも 157 のテーブルがありました。しかも、これは 3 か月の増分更新前の数を表しています。

プロジェクト REAL では、この方法でシステムのバージョンを操作しましたが、SQL Server 2005 で新しく導入されたリレーショナル テーブルのパーティション化機能を利用したバージョンのシステムも作成しました。図 5 に示すように、パーティション テーブルを使用するとデータベースが明らかに単純化されます。これは、すべてのパーティション テーブルが、"Tbl_Fact_Store_Sales" という 1 つのテーブル内部のパーティションになったためです。さらに重要な点として、新しい構造によって、Integration Services パッケージ、Analysis Services キューブ、および Reporting Services のレポートの実装が容易になったことが挙げられます。パーティション スキームとその影響に関する詳細については、ホワイト ペーパー「Project REAL Data Lifecycle – Partitioning」(英語情報) を参照してください。

図 5   パーティション テーブルを使用して洗練された設計
拡大表示する

構成スキーマ

SQL Server では、データベース内のテーブルを、論理的に関連するグループに配置できます。この各グループは "スキーマ" と呼ばれます。データ ウェアハウスのディメンション テーブルとファクト テーブルはいずれも、既定のスキーマである "dbo" に含まれます。B&N では、状態情報を維持するために、ETL プロセスで小規模な個別のデータベースを使用しています。このプロジェクトでは、状態データをデータ ウェアハウスに移動しました。結果として、状態情報は常にデータと矛盾しないようになります。プロジェクト REAL では、他にもこのアプローチの利点があります。それは、異なる状態にあるウェアハウスの複数のコピーを維持できることです。これにより、更新される一連のサーバー上にウェアハウスを維持し、それとは別に、複数ユーザーのレポート作成テストをサポートする一連のサーバー上にウェアハウスを維持することができます。

構成テーブルは、ユーザーが混乱する原因にならないように、"config" という異なるスキーマに配置されます。config スキーマへのアクセス権は、管理者アカウントとシステム アカウントにのみ付与されます。

config スキーマのテーブルの使用方法については、ホワイト ペーパー「Project REAL ETL Design: Integration Services Lessons Learned」(英語情報) を参照してください。

ページのトップへ

Analysis Services を使用した OLAP キューブ

Analysis Services は、エンド ユーザーのクエリ ツールを組み合わせて使用すると、対話的にデータの調査や解析を行う環境が実現します。データに対してこのようなシステムがあると、ユーザーの操作が容易になります。内部的な集計エンジンはクエリに対して高速に応答します。このエンジンがないと、応答に長い時間がかかり、必要なリソースも増えます。"高速である" という利点は、レポートを生成するときにも役立ちます。そのため、多くの場合、Reporting Services は Analysis Services と組み合わせて使用されます。

従来の OLAP システムは、ディメンション データの階層的なビューを提供するように構築されていました。ユーザーが理解しやすいため、この方法は有効です。Analysis Services キューブも、この方法で機能します。図 6 は、B&N のキューブについて、製品ディメンションの階層を示したものです。このディメンションは、Product Type レベル (Book、Multimedia など) で始まります。次に Subject レベル (書籍の主題領域には Art、Cookbooks、Education、Fiction などがあります)、Category レベル (Fiction のカテゴリの 1 は Literary Fiction です)、Subcategory レベル (Literary Fiction には 1 つのサブカテゴリしかありません) と続きます。最後に、サブカテゴリの下に、個々のタイトル (Bel Canto、Catch-22 など) である Item レベルがあります。

図 6   項目のディメンション階層の例
拡大表示する

関連する多くの事項は、ありのままに、このようなレベルのパターンでディメンションにモデリングすることができます。Stores は、Countries、Regions、States、Cites などに含まれます。ただし、この方法では簡単にモデリングできない事項もあります。このような場合に対処するために、SQL Server 2005 Analysis Services には "属性の階層" という概念が導入されました。たとえば、その書籍に大きな活字の版があるかどうかを示す情報を階層の一部に含めることは、賢明ではないことがあります。同様に、書籍が割引対象と分類されているかどうかを示す属性が、階層に含まれる可能性はあまりありません。しかし、これらは書籍を解析するには有用な特性です。前のバージョンの Analysis Services には、メンバのプロパティと、その状況に合わせた仮想ディメンションという概念がありましたが、属性の階層を使用することで柔軟なモデリングが可能になります。図 7 は、売上を基準にして、店舗の規模 (平方フィート) と店舗の書棚の総面積 (リニア フィート) を比較する解析を示したものです。店舗規模と書棚の面積のいずれも、店舗の属性です。自然階層には属していません (書棚の面積の広い店舗の方が、狭い店舗よりも売上が低いように見えます。これが真実であれば、興味を抱く発見であることは確かですが、大規模な店舗の数が単に少ないためであることも考えられます。今後のスキーマでは、この点の解析を容易にするように取り組む予定です)。

図 7   属性の解析
拡大表示する

Analysis Services では、基になるデータに関するメタデータを維持しているため、このような解析が可能になります。図 8 は、Business Intelligence Design Studio (設計作業を行うユーザー インターフェイス) の 2 つのスニペットを示したものです。この図は、Store ディメンションの構造体定義の一部を示しています。左側は、Store ディメンションの City 属性と、基になるデータ ソースとのリンクです。このリンクは、ビュー vTbl_Dim_Store と、列 City に由来します。右下には、店舗の属性コレクションがあります。この属性は解析に使用できます。その上には、Store ディメンションの Geography という階層の定義があります。この階層は、Division、Region、District、City、Store という属性の一部を移動するための論理パスを表します。

図 8   BI Design Studio からの引用
拡大表示する

その他にメタデータで重要な部分は、ディメンションと "メジャー グループ" との関連付けです。メジャー グループは、キューブの主題領域であり、リレーショナル データベースのファクト テーブルに直接関連します。また、ディメンションによって互いに関連付けられます。図 9 は、プロジェクト REAL キューブのメジャー グループとディメンションを示したものです。データ ウェアハウスの用語に詳しい読者は、この画面と、Ralph Kimball による "データ ウェアハウス バス" 技術に関する説明 (http://www.ralphkimball.com/html/articlesArchitecture/articlesBusArch.html)(英語情報) との類似点に注目してください。

図 9   メジャー グループとディメンション
拡大表示する

表面的な内容を説明したこれらのメタデータの他にも、Analysis Services と、Analysis Services をプロジェクト REAL で使用する場合の重要な側面があります。

上記を含め、プロジェクト REAL Analysis Services の設計、実装、および展開の側面については、ホワイト ペーパー「Project REAL: Analysis Services Technical Drilldown」(英語情報) で詳しく説明されています。

Reporting Services を使用したレポート管理

このドキュメントの公開時点で、Reporting Services を使用した作業計画はほとんど実行に移されていません。今後の予定では、システムの一般的な使用方法を示す一連のレポートを定義し、そのレポートを Analysis Services キューブとリレーショナル データの両方に対して実行して、さまざまな形式 (HTML、Excel、PDF など) でレポートを作成します。また、大量のスナップショット レポートの格納や、各種展開オプションを使用したテストを行うことを予定しています。数百または数千単位のユーザーが存在する場合の、マルチユーザー ワークロードの展開オプションをテストします。

このドキュメントには、作業の進捗状況を反映し、作業の概要と実行結果の重要な内容を更新していきます。プロジェクト REAL で Reporting Services を使用する場合の詳細な調査については、ホワイト ペーパー「Project REAL: Reporting Services Technical Drilldown」(仮題)(英語情報) で説明する予定です。

Analysis Services を使用したデータ マイニング

このドキュメントの公開時点で、Reporting Services を使用した作業計画はまったく実行に移されていません。複数のデータ マイニング アルゴリズムを使用してプロジェクト REAL データを調査する予定です。たとえば、顧客の購買パターンに基づいて店舗のクラスタを識別するにはクラスタ化アルゴリズムを使用できます。また、在庫切れの条件を予想するには予測アルゴリズムを使用し、買い物かごの解析を実行するには関連付けアルゴリズムを使用できます。

データ マイニング調査の主な目標の 1 つは、データ マイニングに必要なデータの準備方法を見つけ、説明することです。スター スキーマは、エンド ユーザーの調査には適していますが、データ マイニングには最適な形式でないこともあります。

もう 1 つの目標として、日常的なアプリケーションでのデータ マイニングの使用例を示すことが挙げられます。多くの場合、データ マイニングは主として探索ツールであると考えられていますが、SQL Server のデータ マイニング ツールは製品アプリケーションに簡単に統合できるように設計されています。

このドキュメントには、作業の進捗状況を反映し、作業の概要と実行結果の重要な内容を更新していきます。プロジェクト REAL でデータ マイニングを使用する場合の詳細な調査については、ホワイト ペーパー「Project REAL: Data Mining Technical Drilldown」(仮題)(英語情報) で説明する予定です。

BI システムへのクライアント アクセス

BI システムに対するクライアントの接続性を構築する手法は数多くあります。最も単純な手法は、Windows クライアント ツールを企業のイントラネット上にある Analysis Services または Reporting Services に直接接続することです。この手法では、構成上の課題とセキュリティ上の問題が最も少なくなります。プロジェクト REAL の主要な部分は、Web ベースのアプリケーションを展開することをベースとしています。アプリケーションは、イントラネット上に公開したり、イントラネットへのエクストラネット接続によって公開したりすることが望ましい場合もあります。後者の場合、セキュリティとパフォーマンスに関するいくつかの課題が生じますが、概して、インターネットからアクセスするユーザーも利用できるサービスを提供する場合に、検討する課題の数が最も多くなります。これらのシナリオは、プロジェクト REAL のクライアント接続性調査の中心課題となります。今後、このドキュメントには、作業の進捗状況を反映し、作業の概要と実行結果の重要な内容を更新していきます。プロジェクト REAL でデータ マイニングを使用した詳細な調査については、ホワイト ペーパー「Implementing Secure Web Applications on the SQL Server BI Platform」(仮題)(英語情報) を参照してください (このホワイト ペーパーは、今後発行される予定です)。

技術的な検討に没頭するあまり、優れたクライアント ツールで実現するすばらしい機能を紹介し忘れることありがちです。ここでは、本題からはそれますが、プロジェクト REAL で使用している Proclarity ツールと Panorama ツールについて、スクリーン ショットを紹介しながら説明します。

まず、元の Barnes & Noble データはマスキングされていることに注意してください。図に表示されているデータが正確なものであるとは仮定できません。

図 10 は、Panorama ツールで作成した等高線グラフの例を示したものです。2 つの水平軸は、5 つの製品部門と、米国の 5 つの州を示します。垂直軸は、各州における各製品の売上高を示します。このグラフを見ると、2 つのディメンション間の相互関係を簡単に確認できます。色を割り当てることで、データのパターンが見やすくなります。

図 10   等高線グラフ
拡大表示する

(情報開示のために付記すると、図 1、6、および 7 も Panorama クライアントの画面です)。

図 11 は、Proclarity の分解ツリーを示したものです。Proclarity は、対話的にデータを調査できる強力なツールです。たとえば、最上位レベルのノードから始めて、すべての売上を部門ごとに分解するとします。この図から、売上の 40% はペーパーバックの書籍、21% はハードカバーの書籍によることがわかります。次に、ハードカバーの書籍にどのような補充計画を立てるかを調べるとします。これはツールを使用した単純な調査ですが、重要なことは、この時点でディメンションが変わることです。補充計画は、部門とは異なるディメンションであるためです。最後に、店舗で管理していた書籍 (第 1 レベルの調査のため、ハードカバーのみ) について、月間の売上を確認するために改めて調査を実行するとします。ツリーの下に、最下位レベルにある各項目に関連付けられている総計を示すグラフが表示されます。このグラフから、年末になると売上が大幅に上昇し、第 2 四半期にも小幅ながら上昇していることがわかります。

図 11   分解ツリー
拡大表示する

図 12 は、Proclarity の透視図を示したものです。このグラフは一般的な透視図よりも点の数が多いと考えられますが (6,000 を超えます)、それでもデータのパターンを明瞭に確認できます。水平軸は、ビジネス書籍の平均価格を示します。垂直軸は、各書籍の販売数を示します。点は、ビジネス書籍の主題領域内のカテゴリにしたがって色が割り当てられています。不動産 (REAL ESTATE) の書籍は高価ですが、マーケティング/広告カテゴリ (MKT/ADVERTISING)、および会計/経済カテゴリ (ACCOUNTING/ECONOMICS) の書籍は、より低価格であり、売上も大幅に高くなっています。営業 (SALES) に関しては売上が少なく、中価格帯の書籍が多数あります。

図 12   透視図
拡大表示

ページのトップへ

実装する物理コンポーネント

これまで、サポートするソフトウェア システムやデータなどの論理的な観点から、プロジェクト REAL の実装について説明しました。ここからは、サーバー、ストレージ、およびネットワーク構成という物理構成を中心に説明します。システムの多くの部分は複数の方法で実装しました。これは、各種手法の長所と短所を理解するためです。

サーバー システム : 分散型と統合型

Integration Services、Reporting Services、および Analysis Services に関する最も一般的な懸案事項の 1 つに、サービスをリレーショナル データベースとして同じサーバー上で実行するか、別のサーバー上で実行するかということがあります。この懸案事項に答えるときに今まで使用してきた "経験則" はありますが、唯一の正しい答えは存在しません。また、SQL Server 2005 を使用する場合、パラメータは変わる可能性があります。そのため、プロジェクト REAL の 1 つの方針として、これらの各構成に展開し、その環境での長所と短所を調査することにしました。

プロジェクト REAL の目標に対応するために、Unisys から大量のハードウェア リソースが提供されました。結果として、調査とテストが容易になりました。表 3 は、主要なサーバーを示したものです。この一連のサーバーがあれば柔軟にテストできますが、これは一般的な顧客の環境を反映したものではありません。各アーキテクチャのシナリオについて、利点とベスト プラクティスを調査し、プロジェクト REAL での経験をとおして情報を共有します。

分散型環境のサーバーは 4 台あるため、リレーショナル データ ウェアハウス、Integration Services、Analysis Services、および Reporting Services という主なサービスをそれぞれ各コンピュータでサポートします。一般的な "製品" サーバーにするために、コンピュータ 3 台の構成が選択されました。さらに、増分更新のデータ フィードのソースを提供するという処理に専念するコンピュータが 1 台あります。

統合型環境をサポートするために、Unisys からは、32 ビットと 64 ビットの ES7000 サーバーが 2 台提供されました。これらのサーバーは、個々に統合型サーバーとしてテストされます。統合型サーバーとしての役割を果たす場合、1 つのシステムで、リレーショナル データ ウェアハウス、Integration Services、Analysis Services、および Reporting Services が実行されます。

表 3   Unisys から提供されたサーバー

以上の構成には、パフォーマンス、管理性、信頼性の点で長所と短所があることを想定しています。たとえば、次のような点が挙げられます。

このような比較の結果については、ホワイト ペーパー「Project REAL: Performance Results and Architectural Comparisons」(仮題)(英語情報) で報告します (このホワイト ペーパーは、今後発行される予定です)。

注意が必要な点は、分散型と統合型の比較は、スケール アウトとスケール アップの比較とは異なる、ということです。スケール アウトとスケール アップでは、1 つの役割に複数のサーバーが協力する場合と、単一の大規模なサーバーでその役割を果たす場合を比較します。このような概念は、BI 実装では、エンド ユーザーが発行するクエリに対応する複数のレポート サーバーや解析サーバーというフロントエンド システムにおいて、より関連する傾向があります。これらの問題の詳細については、ホワイト ペーパー「Implementing Secure Web Applications on the SQL Server BI Platform」(仮題)(英語情報) を参照してください (このホワイト ペーパーは、今後発行される予定です)。プロジェクト REAL で使用されるサーバーの詳しい説明については、ホワイト ペーパー「Project REAL: Architecture of the Hardware Environment」(仮題)(英語情報) を参照してください (このホワイト ペーパーは、今後発行される予定です)。

ストレージ構成

大規模な BI を展開する場合の一般的な疑問として、パフォーマンスが最適になるようにどのようにストレージ システムを構成するか、という点が挙げられます。この疑問に答えるために、EMC から大量のリソースが提供されました。使用できる設備には、Symmetrix ストレージ (DMX1000-P)、CLARiiON ストレージ (CX700)、バックアップ用に CLARiiON ディスク ライブラリ (CDL)、2 台の Fiber Channel スイッチが含まれます。このような設備を組み合わせると、フォールト トレラントな記憶域ネットワークを実現できます。どのようなコンピュータにも適用できるストレージ容量です。さらに、Emulex から、サーバーをスイッチに接続するホスト バス アダプタ (HBA) が提供されました。

図 13 は、ストレージの接続を示したものです。各ストレージ システム (DMX1000-P と CX700) には物理ディスクが数多くあり、多数の論理ボリュームとして構成されています。各ボリュームは、スイッチ経由でいずれかのサーバーに公開されます。サーバー側では、ドライブ文字 (H: ドライブなど)、またはマウント ポイント (C:\mount\DW4 など) でボリュームを使用します。図は、ホストからストレージへの接続に使用できる複数パスの概要を示しています。各サーバーは、多数の論理ボリュームに対して同時にアクセスできます。

図 13   ストレージの接続
拡大表示する

この論理ボリュームは、システム全体で、特定の役割のパフォーマンスが最適になるように設計されています。たとえば、リレーショナル ログ ファイルを保持するボリュームは、順次書き込みのパフォーマンスに合わせて構成されています。システム全体には、ストレージの役割が数多く実装されています。

EMC からは、複数の構成をテストしている間、データの複数のコピーを保持するのに十分なストレージが提供されました。たとえば、異なる集計設計方法で作成したキューブを格納できます。設計方法が異なると、基になるデータが同じでもパフォーマンスの特性は変わります。さらに、Symmetrix ストレージと CLARiiON ストレージの両方について多様な役割のデータを維持できます。そのため、どちらのストレージ システムについても、各サーバー構成 (統合型と分散型) でテストできます。

前述したデータの役割、ストレージ システム、および複数サーバー構成を複数の製品で調査するのは、プロジェクト REAL 全体の要件が、このようなデータ量を持つ一般的な BI システムよりもはるかに厳しいためです。ただし、単一構成のシナリオはいずれも、一般的な展開で考えられる種類の構成です。

このクラスのストレージ システムでは一般的に見られますが、論理ボリュームは RAID アレイまたはミラーリングされたストレージとして構成されます (役割によって変わります)。この構成は、信頼性を改善することを目的としたもので、論理ボリューム サイズの合計は、使用できる物理ストレージよりも少ないことを意味します。EMC から提供されたストレージ容量を次に示します。

プロジェクト REAL で使用されるストレージ構成の詳しい説明については、ホワイト ペーパー「Project REAL: Architecture of the Hardware Environment」(仮題)(英語情報) を参照してください。

ネットワーク構成

BI システムのバック エンド機能である ETL、リレーショナル ストレージ、および Analysis Services は、企業ネットワークを外部から保護するファイアウォールの内側に配置されている企業ドメインのサーバーで実行されます。このような役割のコンピュータでは、ネットワーク接続は単純であり、一般には高速のイーサネット接続が採用されます。

BI アプリケーションに必要なクライアントの接続性によって異なりますが、エンド ユーザーのアクセスをサポートするフロントエンド システムとの関連性が高くなることがあります。イントラネット クライアント (企業ネットワーク上のクライアント) の接続は単純です。ただし、エクストラネット クライアント (ファイアウォールの外側から企業ネットワークにアクセスするクライアント) では、十分に注意して、適切な接続性とスループットを実現することが必要です。インターネット クライアント (ファイアウォールの外側にいて、企業のセキュリティ モデルを共有していないクライアント) が存在する場合、ユーザーを認証し、必要なデータ アクセス権のみを付与するという、さらに困難な課題が生じます。このような構成のテストをサポートするために、ラボ環境が構築されました。これによって、シミュレート対象の企業 LAN 環境、境界領域ネットワーク環境 (DMZ、緩衝地帯、またはスクリーンド サブネットとも呼ばれ、2 つのファイアウォールの間を指します)、シミュレート対象のインターネット環境 (ファイアウォールの外側) に多様なサーバーを配置できました。インターネット クライアントは、Web サービスを使用して、レポートにアクセスすると想定されています。また、対話的な解析では、イントラネット クライアントとエクストラネット クライアントは、Web サービスを使用する場合と使用しない場合を想定しています。

図 14 は、これらの 3 つのシナリオを示したものです。わかりやすくするために、中間層の Web サーバーを経由して接続するインターネット クライアントのみを表示します。各構成は、プロジェクト REAL のラボ環境で実装されています。このような 3 つの構成を使用すると、サービス、ポート、ルーター、およびセキュリティ設定を正しく構成する方法を判断できます。プロジェクト REAL のクライアント接続性調査の詳細については、ホワイト ペーパー「Implementing Secure Web Applications on the SQL Server BI Platform」(仮題)(英語情報) を参照してください (このホワイト ペーパーは、今後発行される予定です)。

図 14   ネットワークの接続
拡大表示する

ページのトップへ

プロジェクト REAL の成果

ここでは、ベスト プラクティスの提示、長所と短所の理解、またはパフォーマンスの測定という目標に対するこれまでの成果と今後の予定について、重要な事項を概説します。これらの作業には、この原稿を執筆している時点で進行中のものや、まだ着手されていないものがあります。

ETL

リレーショナル データ ウェアハウス

Analysis Services キューブ

Analysis Services のデータ マイニング

Reporting Services

クライアントの接続性

クライアントの接続性を調査する一環で対処が必要な領域は、主に 2 つあります。

クライアントの接続性に関するホワイト ペーパーでは、これらの領域についても取り上げ、それぞれの代替案の概要を説明します。

マルチユーザー ワークロード テスト

展開技術

システム管理

ページのトップへ

まとめ

プロジェクト REAL は、ユーザーがより容易に展開できるように、ベスト プラクティスの情報を調査し、開発するための広範囲に及ぶ取り組みです。この調査が終了するまでには数か月かかります。時折 http://www.microsoft.com/sql/bi/ProjectREAL (英語情報) を参照し、公開されている情報を確認してください。

このホワイト ペーパーでは、プロジェクト REAL のさまざまな側面について概要を説明しました。各領域の詳細な解析については、他のホワイト ペーパーを参照してください。

ページのトップへ