ホワイトペーパー紹介｜データウェアハウスの迅速化

こんにちは！インサイトテクノロジーマーケティング本部です。

多くの企業が、データウェアハウスプロジェクトは膨大なビジネス価値をもたらすことができると信じてきました。では、なぜ、これほどにまで期待外れに終わることが多いのでしょうか。時間がかかりすぎて価値を実現できない、コストがかかりすぎて構築も維持も不可能、変化するビジネス要件に対応できない、などの原因が考えられます。では、こうしたデータウェアハウスの問題を克服するためには何をすべきなのでしょうか？

本日ご紹介するホワイトペーパーでは、従来のデータウェアハウスのプロセスステップを分析した上で、それを改善するために必要なソリューションとしてQlik Compose™ for Data Warehouseを紹介しています。

従来のデータウェアハウスのプロセスステップ

まず、各プロジェクトフェーズで従来のデータウェアハウスを設計、構築、維持するには何が必要かを（時間、コスト、リソース）見てみましょう。

要件収集

紙やPowerPointを使ったりサンプルレポートを利用したりすることもできますが、データウェアハウスの設計フェーズで使用できるアーチファクトに手動で変換する手段が必要です。

データウェアハウスの設計

通常は、論理または物理モデリングツール（ERWinなど）を使って、その当時のビジネス要件に従って実施されますが、データモデルと方法（Kimball、Inmon、またはData Vault アプローチを採用するかどうか）は、最初に決定する必要があります。

データウェアハウスの構築

論理設計をデータベース上に物理的にウェアハウススキーマとして構築するには、SQLプログラミングが必要です。すべての主要、外部、代理キー管理、およびビジネスエンティティと属性の間の関係を指定し、検証する必要があります。

データ統合

データをデータウェアに統合するためには、ソースデータにアクセスしてからそれを共通の形式に変換し、ソースデータをデータウェアハウスにロードする工程が含まれています。また、すべてのビジネスルール定義、メタデータ管理、エラー処理、待機処理、プロジェクトドキュメント、ロギング、監査証跡アクティビティについても、手動での開発が必要です。このステップは、データウェアハウス構築プロセスの中で最も複雑で時間がかかります。企業からの報告によると、データウェアハウスの設計と構築にかかる時間の半分以上が、データ統合とETLの作成および検証に費やされています。

テスト

非常に多くのETLおよびSQLプログラムが作成されているため、設計およびデータ統合中に実行されるすべての処理ジョブと計算を、チーム全体で検証しテストする必要があります。

リリースから実稼働へ

サンドボックスから開発、ユーザー利用、実稼働へと進めていくには、多くの場合、複数の環境で多くの移行ステップが求められ、問題がないことを確認するためのテストも必要です。

変更管理

実稼働環境に入ったら、データウェアハウスチームは、新しいビジネス要件とデータソースシステムに合わせて、データウェアハウス環境全体を調整および強化し続ける必要があります。さらに、プロセスで使用されているソフトウェアツールとの互換性が確保されていることを確認し、システムを制御された状態で確実に稼働させなければなりません。データウェアハウスの物理テーブルとデータエンティティの間の関係は、通常、従来のETLベースのシステムではハードコードされているため、新しいデータソースまたは新しいエンティティが必要となる場合に、それに伴う変更が必要になる箇所を特定し、全ての変更を実装するという困難な作業も発生します。

したがって、プロジェクトの規模によって、上記のプロセスを完了するのに1年以上の期間と、数千万円ものコストがかかる場合があります。

必要なソリューション：俊敏なデータウェアハウス自動化

幸いにも、このプロセスはすべて、非常に簡単な手順とツールを使って完了することができます。IT部門は、俊敏なデータウェアハウスの自動化を使用することで、コストを抑えつつ、より迅速かつ効率的な方法でデータウェアハウスを設計、構築、展開、運用できます。

下記の表では、お客様にとっての俊敏なデータウェアハウス自動化のメリットをまとめております。Qlik Compose™ for Data Warehouseを導入することによって、これらの全てのメリットを実現できます。

データウェアハウスの迅速化と自動化に課題を感じる方は、ぜひこちらから資料をダウンロードしてご一読ください。