ホーム > ライブラリー > Teradata コラム > Ask the Expert 「企業の中核として活用されるアクティブ・データウェアハウジング」(2)

企業の中核として活用されるアクティブ・データウェアハウジング

鮮度の高いデータの必要性がアプリケーション設計に及ぼす影響は?

データ鮮度を高めるには、データの取得、移動、変換およびデータウェアハウスへの取込み方法を変更する必要がある。場合によっては、データの取得頻度を増やすと他のインフラストラクチャ・コンポーネントの変更が必要になる。連続フィードのデータは、メッセージング、キュー、EAIツール、連続ETLツール、或いはこれらツールの組み合わせを使って移動させなければならない。
データウェアハウスへのデータの取込みには、データの連続更新ツールが必要である。連続更新が可能なツールがなければ、システム上の他のワークロードと並行して、一括更新ツールを一日中何度も繰り返し実行しなければならない。Teradataは、データアクセス・ワークロードと並行して連続更新または反復一括更新を実行できるTpumpという連続更新ツールとワークロード管理機能によってデータ鮮度の維持をサポートしている。

ワークロードの管理方法は?

第一線ユーザーのワークロードに対するサービスレベルは、一般的に在来型データウェアハウス・アプリケーションの場合と大きく異なる。システムは、連続更新、戦術的意思決定、イベント主導の意思決定、在来型戦略的クエリー・ワークロードなど、あらゆる側面で、それぞれ異なったサービスレベルで管理しなければならない。Teradataは、オペレーティングシステムの管理が必要なく、ユーザー単位およびリクエスト単位で動く精密な自動ワークロード管理ツールによってこのようなワークロードの管理をサポートしている。Teradata Priority Schedulerは、システムのリソースを最大限に利用しながら、異なったユーザーのために異なったサービスレベルで複雑なワークロードを管理する。また、Teradata Dynamic Query Managerは重要度の低い処理を止め、重要度の高い処理に必要なシステムリソースを優先的に割当てる。

新しい可用性要件がもたらす変化は?

アクティブ・データウェアハウスにはまったく異なった可用性が求められる。第一線ユーザーをサポートする場合、特にグローバル企業では、24時間アクセス可能であることが前提となる。データの連続更新も不可欠だ。CEOは最新の情報が利用できることを期待する。CEOが貴重な業務時間中に、1時間ごとに更新されるデータに大きく依存しているのだ。また、一般消費者は曜日や時刻に関係なくいつでも企業とコンタクトできることを期待する。これに比べると、在来型データウェアハウスの要件ははるかに緩いと言える。システムが一時的に利用できなくなったとしても、ユーザーは不便に思いながらも企業の経営に支障はない。在来型データウェアハウスでオペレーショナルアプリケーションもサポートする際には、可用性要件を慎重に見直す必要がある。システム可用性、データ可用性、ディザスターリカバリー、混合ワークロード管理などをすべて検討しなければならないのだ。

CEOは、最新の情報をいつでも利用できることを期待する。 そして一般消費者は、曜日や時刻に関係なくいつでも企業とコンタクトできることを期待する。

アクティブ・データウェアハウスでのシステム可用性の違いは?

在来型データウェアハウスは、多くの場合、可用性要件があまり厳しくないプラットフォーム上に構築される。コストと可用性要件とのバランスを取るため、システム内の単一サーバーなど単一障害点は許容されるが、アクティブ・データウェアハウスの可用性要件ははるかに厳しくなる。フェールオーバーおよびフォールト・トレランス(耐障害性)機能をプラットフォームに組込み、ソフトウェアでサポートする必要がある。
Teradataは、RAIDディスク、デュアルコントローラ、デュアルI/Oパス、完全なフォールト・トレランス型インタコネクト、多重ネットワーク/チャネル接続、多重ファン、多重UPS、多重電源接続などのコンポーネントを使ってこのような要件を自動的にサポートしている。すべてのTeradata MPPシステムは自動的にノード障害に対応できるフェールオーバー機能を内蔵しているため、特殊なオプション機能や別個のソフトウェア、別個のシステム管理機能など必要としない。

可用性が問題となる理由は?

単にハードウェアとソフトウェアが動いている状態は、アクティブ・データウェアハウスでは十分な可用性とはいえない。ユーザーが作業をする上で、ウェアハウスのデータに確実にアクセスできることも不可欠なのだ。在来型データウェアハウスでは、多くの場合、データロード、バックアップ、データメンテナンスあるいはデータモデル変更のためデータをオフラインにできることが前提となっている。アクティブ・データウェアハウスでは、データをオフラインにすることは絶対にできない。
Teradataはデータ可用性を様々な方法でサポートしている。例えば、ユーザーアクセスと並行して一括/連続データロードやバックアップを実行することができる。また、データ管理オペレーションは自動的かつ継続的に行われるため、デフラグ、リオルグ(reorg)、インデックス・リビルド、マテリアライズド・ビューの再パーティションや更新などの処理によりデータがオフラインになることはない。データモデル変更は、データをアンロードせずに実行することができ、またハイパフォーマンス・ビューを使うアプリケーションから完全に隠すことができる。

ディザスターリカバリーが必要な理由は?

アクティブ・データウェアハウス上のアプリケーションがビジネス・クリティカルな場合、何らかのディザスターリカバリーが必要だ。他の業務系システムと同じように、各アプリケーションのビジネス・クリティカリティを考慮しなければならない。データおよびアプリケーションのほんの一部しかビジネス・クリティカルではないことも十分予想されるが、その場合、ディザスターリカバリー用システムは本来のシステムよりかなり小規模で済むことがよくある。
ディザスターリカバリーには、バックアップ・ソリューション、オフサイト・ホスティング、通常は他の処理作業に使用されるウォームスタンバイ・システム、デュアル・アクティブシステムなど、様々な選択肢がある。

全体的なシステム管理の相違点は?

世界最高のテクノロジーでもあらゆる管理やコントロール上の問題を解決できるわけではない。アプリケーション、ユーザー、そしてビジネス・クリティカリティを理解する必要がある。
単一テーブル、システム全体など、可用性の側面に影響を及ぼす決定を下す際には、その決定がビジネス・クリティカルなアプリケーションに及ぼす影響を把握していなければならない。在来型データウェアハウスには十分なバックアップ、ロード、スケジューリング、ワークロード管理などの処理であっても、アクティブ・データウェアハウスの高いサービスレベルを満たすことはできないため、これらの処理を見直す必要がある。開発スタッフは、アクティブ・データウェアハウス環境の影響または別の開発・テスト環境への移行の影響に対処する必要がある。
Teradataツールは、データウェアハウスをオペレーショナル環境にする上で役立つのだ。例えば、データモデルやシステム構成情報のエクスポート/ロードを利用して小規模の開発・テスト環境で本番環境のシミュレーションを行うことができ、またサンプリングによってデータの一部を移動して実行テストにかけることもできる。プロセス変更やワークロード管理は、柔軟性および新規ビジネス要件へのデータウェアハウスの対応力とのバランスを検討する必要がある。

Copyright (C) Teradata Magazine - June 2003

ページの先頭に戻る