既存のデータウェアハウスを作成、または維持することは、 ストレージに使用されるDBMSの物理的制限の不可避性とユーザーの多数の要望が一致する段階で必然的に発生します。 実際、誰も無限のディスク容量、プロセッサ能力、またはデータを更新するために任意の時間を持つことができません。
この時点で、管理者は、それが以前に発生していなかった場合、データベースでそれほど多くのスペースを占有しているもの、ダウンロードがまだ終了していない理由などについて質問する場合があります。
何に答えるべきかを知るには、アカウントを実施する必要があります。 CDの作成は長いプロセスであり、アーキテクチャを開発した人々はすでに遠く離れている可能性があります。Firefoxブラウザーの新しいバージョンがリリースされるとすぐに、ビジネス要件が変更されることはありません。
顧客が現在のCDに保存して処理できるデータの量について質問を受けたとき、私はおおよそ答えられるとしか言えませんでしたが、事前にすべてを計算する必要があります。 データウェアハウスメトリックを収集します。
まず最初に計算することが望ましい基本的なメトリックの特定のセットを準備しようとしました。これに基づいて、予測に使用できる派生メトリックを取得できます。
このキットを受け取った後、私はこのトピックをグーグル検索することを決定し、ほとんどのCDで数えられると思われるメトリックのリストを含むBill Inmonの記事を見つけました 。
転送開始
すべてにメトリックがあります。 道路には速度制限があり、人々には体重があり、日には気温があり、車にはタコメーターがあります。
メトリックは、推論を整理し、意味のある比較を行うのに役立ちます。 メトリックス自体を意味しない場合でも、イベントとそれらの発現の条件を比較できます。 この場合、データウェアハウスも例外ではありません。 異なる企業のデータウェアハウスを比較する場合、測定可能な特性が必要です。 自分自身や自分の仕事について語り、他の人のメリットと比較できる基準を設定することは、人間性の一部です。
上記を考慮すると、データウェアハウスシステムのメトリックのリストは次のようになります。
大きさ
- テーブルXD。
- インデックスHD。
- 変換領域のボリューム(一時テーブルおよび/またはスプールのボリューム)。
ETL
- ETLプログラムの数。
- 開始頻度。
- ETLによって処理されたデータの量。
- ETLプログラムの実行場所。
データマート
- HDのデータマートの数。
- データマート内のデータ量。
- データ補充の頻度。
詳細なHDデータ
- データアクセス速度(バイト/秒)。
- 物理レコードのサイズ。
HD構造
- テーブルの数。
- 各テーブルの行数。
- 各テーブルの平均行サイズ。
HDからデータをエクスポートする
- HDから出るテーブルごとの行数。
- テーブルごとのエクスポート頻度。
- エクスポート基準。
HDリクエスト
- 1日あたりの処理済みリクエストの数。
- 各リクエストのデータの平均量。
物語
- HDが履歴を保存する期間。
その他
- マイニング日付を使用します。
- 適応データマート。
- 意思決定支援アプリケーション(DSS)。
- ERPアプリケーション。
- ODS。
- テープまたはその他の種類の長期情報ストレージを使用する
- アーカイブストレージ。
ここで、このようなメトリックは、HDを測定するためのものです。
もちろん、このリストはさまざまな方法で展開および変更できます。 改善の可能性の1つは、これらのメトリックに時間を追加することです。これは、一定期間値を追跡することをお勧めします。 そのため、たとえば、サイズメトリックに加えて、サイズがどれだけ変化したかの指標を計算できます。
または、会社の部門ごとにいくつかのテーブルを分割できます。 物理データベーステーブルでそのようなグループ化が提供されていない場合でも、データをグループ化することはしばしば理にかなっています。 もちろん、次のように、どのDBMSがどのテーブルに使用されているかを示すこともできます。
- 表ABC-Teradata
- DEFテーブル-IBM UDB
- 等
では、だれがHDメトリックを使用できますか?
- DB管理者。
- アーキテクトDB。
- DB開発者。
- HDユーザー。
- 魅力的な管理者。
- システムプログラマー
- そして、他の多くの...
翻訳の終わり
このようなセットが、マルチテナントデータウェアハウス(マルチテナントDWH )のプロジェクトで特にメトリックを収集する必要性を判断するのに適していることを考慮して、4つのメトリックグループを選択しました。 これらのグループは次のとおりです。
- テーブル内の行数によるメトリック。
- 各回線のスペースメトリック(バイト数)。 リポジトリ内のデータは、いくつかのOracle DBMSスキーマにあります。
- データ読み込みプロセス(ETL)のメトリック。
- HDで最大のファクトテーブルのメトリック。
各グループからのメトリックは、特定の日付に、各ロードプロセスの後に実行されるPL / SQLプロシージャを使用して個々の所有者ごとに収集されました。
各グループをさらに詳しく考えてみましょう。
行メトリック
このグループのメトリックでは、これらのメトリックが計算された各瞬間にCDスキーマに含まれていた各所有者の行数に関する情報が収集されます。
これらのインジケーターを使用して、CDのさまざまなレイヤー間の関係、詳細データを構成するテーブルの数、データマート、およびステージの領域も判別できます。 新しいテーブルが表示されたとき、または1つのファクトテーブルあたりの平均でいくつのディレクトリ。
また、特定の各テーブルの内容に応じて、さまざまな所有者の定量分析が可能になります。
計算は、標準のアプローチを使用して実行されました-スキーマの特定のリストからすべてのテーブルのサンプリングサイクルでSQLコードを生成および実行します 。
ボリュームメトリック
HDテーブルが占有するボリュームのメトリックについて、DBMSによって報告されるデータが排他的に占有するデータ領域を計算することにしました。
SELECT owner, to_date(v_cur_date, 'RRRR-MM-DD'), sum(bytes) from dba_segments where owner in (' ') group by owner
このメトリックに加えて、ディスク上のデータが占めるスペースの計算も追加します。 両方のインジケータを比較することにより、たとえば、ディスク領域の使用量に関するETL効率の比率を取得できます。
ETLメトリック
ダウンロードに使用されるETLツールはOracle Warehouse Builderです。 以下に示すスクリプトは、特定の読み込みプロセスの実行統計を収集し、下位マッピングから処理された行の数を集計します。
select ae.top_level_execution_audit_id, ae.execution_name, ae.created_on, ae.elapse_time, dt.Selected, dt.Inserted, dt.Updated, dt.Deleted from owbsys.All_Rt_Audit_Executions ae, ( select sum(coalesce(au.number_records_selected, 0)) as Selected, sum(coalesce(au.number_records_inserted, 0)) as Inserted, sum(coalesce(au.number_records_updated, 0)) as Updated, sum(coalesce(au.number_records_deleted, 0)) as Deleted from OWBSYS.ALL_RT_AUDIT_MAP_RUNS au where au.execution_audit_id in (select execution_audit_id from owbsys.All_Rt_Audit_Executions ae where ae.top_level_execution_audit_id = < >) ) dt where ae.top_level_execution_audit_id = < >
個々のマッピングのパフォーマンスを追跡する場合は、収集されたデータのセットを拡張できます。
最大のテーブルメトリック
最大のファクトテーブルは、所有者のアクティブな従業員ごとに月に1回実行されるトランザクションで構成されます。 次のスクリプト:
select p_Customer_Num, t.month_start_date, count(distinct f.Person_Id) as uniq, count(f.Person_Id) as t_cnt from dm.time_dimension t left outer join dm.trans_fact f on f.time_id = t.id and f.customer = p_Customer_Num where month_start_date between p_Start_Date and p_End_Date group by month_start_date;
各月の各データ所有者の行数と各月の一意の従業員数に関するデータを収集できます。
このメトリックは、 BIツールで収集された残りのメトリックを接続し、その結果、次の派生インジケーターを取得できるポイントです。
- 従業員1000人ごとに新しい所有者を追加する場合の座席あたりの平均コスト(GB)。
- 従業員1000人ごとに新しい所有者を追加するための平均時間(時間単位)。
- 従業員1000人ごとに新しい所有者を追加するための行指向データベース管理システムの平均コスト(数百万行)。
また、1日の平均読み込み時間、処理された所有者の数に対するこの時間の依存性などを示す多数の美しいグラフを作成できます。 ETLの変更、DBMSの改善または劣化などの後のメトリックデータを比較します。これは、CDの構築プロセスの改善の結果をより客観的に評価し、この記事を始めた質問に答えるのに役立ちます。
