データウェアハウスのテスト

IvanovAlekseyに代わって公開されました 。

データウェアハウスのテストに関するインターネット上の情報はほとんどありません。

一般的な要件（データの完全性、品質など）を見つけることができます。

しかし、プロセスの組織の説明や、これらの要件に対応できるチェックはどこにもありません。

この記事では、 Tinkoff Bankでデータウェアハウスをテストする方法を説明します。

データウェアハウス

最初に、倉庫について簡単に説明します。

データのロードと処理のプロセスは、ジョブの形式で実装されます。 通常、スケジューラで実行されるジョブは、外部システムを使用している人がいない夜間（負荷が最小）、および営業日が終了した後です。

データベース構造は、さまざまなサイズ（数行から30億以上）、さまざまな列数（1から200）、履歴あり、なしのさまざまなテーブルです。 ベースのサイズは約35Tbです。

外部データソースが使用されます：Oracle、CSV / XLSファイル、MySql、Informix、BINファイル、CDH-Cloudera（Hadoop）。 Oracle、SASテーブル、およびCSV / XLSファイルの形式でも外部システムにデータをアップロードします。

ストレージオブジェクト（データベース、ジョブ、テーブル、ビューなどの説明）はSAS Data Integration Studioで開発され、SASサーバーにメタデータとして保存されます。 物理的には、テーブルはGreenplumおよびSASデータベースにあります。

ジョブを実行するために、メタデータはコードを生成し、それを展開サーバーに転送します。 その後、それらをスケジューラで実行できます。

環境への変更は、メタデータとスクリプトで構成されるパッケージの形で転送されます（物理学、データの作成/編集用）。 転送を簡単にするために、開発者は特別なプログラム「Autorelysis」を作成しました。

ジョブを手動で起動するためのWebポータルがあります。 ここで、実行中のプランナーと、それらで動作するジョブのステータスを確認できます。

テストオブジェクト

DWHの改訂は、テーブルとジョブの物理とメタデータの作成/変更です。 または、これは既にダウンロードされたデータのスクリプトによる修正です。

たとえば、新しいストアフロントが作成されています。 パッケージには、新しいジョブとターゲットのメタデータ、およびデータベース内の新しいテーブルの物理を作成するスクリプトが含まれます。

したがって、テストオブジェクトは、タスク、ターゲットテーブルのデータ、および依存作業のターゲットテーブルのデータ（ある場合）によって変更/作成されたジョブです。

テストのレベルと種類

テスト回路は生産性を完全に繰り返します。また、鉄、同じデータ、同じ体積の鉄が同じプロセスを使用してロードされ、処理されます。 この機能と、ソースに必要なデータがすべて揃っているときにタスクが開発されるという事実を考えると、品質を損なうことなく検査の量を減らすことができます。

パフォーマンステストと大量のデータのテスト（ボリュームテスト）を実行するのは、タスクをテストに転送するときだけです。ジョブの作業時間、スタンドの負荷（たとえば、 Grafanaを使用）、およびクーラーのボリュームをチェックします（これらのチェックについては詳しく説明しません）この記事）。

システムレベルでは、ジョブのパフォーマンスとデータ品質が自動的にチェックされます。 ジョブは、ナイトプランナー自体と、クーラーの音量を制御するスクリプトによって監視されます。 また、ダウンロード後のデータは、Data Quality Daemonを使用してチェックされます（以下について）。 データに問題がある場合、責任のある手紙には誤りがあります。

「ホワイトボックス」からは、環境の正しい表示のみが表示されます（テストおよび開発回路のハードコードにエラーがありました）。 将来的には、開発者がパッケージを公開するときに、これを自動的に確認する予定です。

主なものは、コンポーネントと統合のレベルでの機能テスト（「ブラックボックス」）と回帰の検証です。

前の段落で定義されたテストオブジェクトを考えると、チェックの完全なセットは次のようになります。

• 単体テスト 新規/変更されたジョブ自体とそのターゲットテーブルのデータを確認します。
  
  機能テスト：プロトタイプを作成し、ターゲットテーブルの新しい/変更された列の値と比較します。
  
  回帰テスト：バックアップとの比較を実行します。リビジョンの影響を受けないデータは一致するはずです。
• 統合テスト 。 従属作業の出力（変更が行われなかった）および外部システムでデータの品質をチェックします。
  
  機能テスト：改訂の影響を受けるデータの品質は、ToRに準拠する必要があります。
  
  回帰テスト：改訂の影響を受けないデータの品質は変わらないはずです。

「バックアップとの比較」とは、ジョブの新しいバージョンと以前のバージョンの結果の検証を意味します。 つまり、古いジョブと新しいジョブは同じデータで実行されます。 そして、それらのターゲットテーブルが比較されます。

「プロトタイプ」-TKに従って収集され、完了後にウィンドウに表示されるデータセット。 これは、完全に新しいテーブルのレイアウト、または古いテーブルの列を変更しただけのレイアウトにすることができます。

タスクによっては、これらのチェックの一部が冗長になる場合があります。 改良のタイプを識別することにより、冗長なチェックを取り除き、テスト時間を短縮できます。

変更とチェックの種類

銀行のデータウェアハウスプロジェクトは絶えず進化しています。新しいストアフロントが作成され、古いストアフロントが完成し、ロードプロセスが最適化されています。 しかし、実際には、すべてのタスクは、独自の十分なテストセットを持つ4つのグループに分割できます。

1. テクニカル
   
   最適化、移行など -つまり、アルゴリズムが変更されないタスク。 また、ターゲットテーブルのデータも変更しないでください。
   
   回帰チェックを実行するだけで十分です。変更されたジョブのターゲットをバックアップと比較します。 依存ジョブはチェックできないため、 ターゲットがバックアップと一致する場合、依存ジョブもそれを処理します。
2. 古い機能を変更します。
   
   アルゴリズム、フィルターが変更され（行数が変更）、新しいフィールドとソースが追加されます。 つまり、ターゲットテーブルに設定されているデータが変更されています。
   
   すべてのチェックを実行する必要があります。変更されたジョブのターゲットテーブルのデータをバックアップおよびプロトタイプと比較し、依存作業および外部システムのターゲットテーブルのデータの品質をチェックします。
3. 新しい店の窓の開発。
   
   それらをロードする新しいテーブルとワークロードが作成されます。
   
   機能テストのみを実行します。ターゲットテーブルとプロトタイプを比較します。
   
   アップロードが外部システムに送信される場合、統合をさらに確認します。ロードされたデータが外部システムでどのように表示されるかを確認します。
4. データの編集。
   
   重複、古いレコードの削除、バージョン管理の修正、正しい値の記録。
   
   これらの変更の検証はかなり複雑であり、2つの文で説明することはできません。 次の記事で詳しく説明します

プロジェクト/タスクのフレームワーク内で一度にいくつかのタイプの変更がある場合、テストスイートでそれらのそれぞれに対してチェックを行います。

これらのチェックは、ほとんどのタスクの要件と開発結果への準拠を保証するのに十分です。

ブリッツをチェック

プロトタイプの構築と比較の実行には、多くの時間がかかります（環境のパフォーマンスとデータの量によって異なります）。 テスト回路が生産的な回路よりも弱い場合、この問題に遭遇しました。 比較のために時間を無駄にせず、重大な欠陥をすぐに発見するために、クイックチェックが使用されました。

あらゆる種類のタスクに適しており、テスト前に実行されます。

• タスクがテストに来て、ジョブが実行されます（はい、時々チェックを忘れます）
• ヌルがなく、キーごとに重複していてはなりません（作業ステートメントで特に指定されていない限り）。 テーブルのバージョン管理を尊重する必要があります。
• データは新しいフィールドに入ります。table1からの選択カウント（new_field）は0より大きくなければなりません。
• 新しいレコードがテーブルにロードされます。バックアップとターゲットのレコード数を比較します。

失敗した場合は、すぐにタスクを開発に戻すか、重大な欠陥を作成できます。

ツール

テスト中の主なアクション：タスクをテストにローリングし、テーブルを比較します。

既に述べたように、転送は独自の開発プログラム「自動再解析」を使用します。 これにより、時間が節約され、手動の移行エラーが回避されます。

プログラムは次のように動作します。

• テーブルの物理のバックアップと変更されたオブジェクトのメタデータは削除されます。
• 新しいメタデータをインポートする前に実行する必要があるスクリプトが実行されます
• メタデータをインポートします。
• メタデータをインポートした後、スケジューラでジョブを実行する前に実行する必要があるスクリプトが実行されます。
• ジョブを展開し、スケジューラーで実行します。
• ジョブが完了した後に実行する必要があるスクリプトが実行されます。

コンソールを実行します。 タスク番号、環境の名前、および追加のパラメーター（たとえば、各ステップの後に一時停止）が入力されます。

テーブル（プロトタイプとバックアップのターゲット）を比較するには、指定されたキーの行の値をチェックし、フィールドの占有率を比較するマクロが使用されます。

テーブルのマクロ名と比較キーが入力に渡されます。

作業結果の例：

列の違いの数。 差異自体については、違いを参照してください。

オブス	column_name	differ_base_to_comp
1	column_1	0
2	column_2	20
3	column_3	0

_cdおよび_flgフィールドによるグループ化の不一致の数。

オブス	column_name	column_group	base_groups	compare_groups	diff	base_group_pct	compare_group_pct	diff_group_pct
1	column_2	A	18743	63	18680	0.0021	0.0024	-0.0003
2	column_2	B	4451740	17756	4,433,984	0.4897	0.6877	-0.1980
3	column_2	C	4619311	7813	4611498	0.5082	0.3026	0.2056
4	column_2	ヌル	191	188	3	0.0000	0.0073	-0.0073

データの品質を確認するために、プロファイリングマクロが使用されます。 これは、各列にnull、キーによる重複とnull、フラグと値によるグループ化の行、列の量によるmin / max / avgを持つレコードの数と割合をカウントします。

入力はテーブルの名前とキーです。

出力では、計算ごとにタブレットを含むレポートを取得します。

例：

列ごとのミッションの数。

オブス	column_name	base_nulls	nulls_pct
1	column_1	0	0.00
2	column_2	0	0.00
3	column_3	7	0.03
4	column_4	0	0.00
5	column_5	0	0.00

2つのテーブルのプロファイルを互いに（または製品上のテーブルと）比較するためのマクロもあります。 動作原理は同じです。各テーブルのプロファイリングが実行され、結果が比較されます。

出力レポートは通常のプロファイリングに似ていますが、2つのテーブルのデータのみが含まれます。

データ品質管理

ウェアハウス全体のデータの品質を管理するために、自己作成のデータ品質デーモン（DQD）が使用されます。これは、データ品質管理部門のアナリストとスペシャリストによって作成されたルールへの準拠をすべてのテーブルで確認します。

DQDは、更新されたテーブルを10分ごとに検索し、指定されたSQLクエリを実行するプロセスです。 結果を参照インジケーター（定義済みの値）と比較し、偏差のあるレポートを送信します。

レポートの例：

制約の定義	SQLスクリプト	破損した行cnt
test_schema.table1 /一意のエンティティキー[id]	合計（cnt）をcntとして選択（cnt unionとして0を選択し、test_schema.table1グループからcntとしてcount（*）を持つidで選択します） nullではない））sq	15

テストケースを作成する

私たちの銀行では、テストはZephyr（Jiraアドオン）で行われています。 改訂タスク自体は、Jiraではチケットとして発行され、Zephyrではテストケースとテスターとして発行されます。

いくつかのオプションを試しましたが、変更されたジョブごとにケースを開始するという事実に落ち着きました。 「<jiraのタスク番号>：<ジョブ名>」というケースを呼び出します。 チケットへのリンク。

このアプローチの主な利点：

1. タスクでは、ケースのカバレッジを確認できます（どのジョブがチェックされます）
2. 実行/合格/失敗の割合を簡単に計算できます
3. ジョブの名前で簡単に検索すると、書かれたすべてのケース、ステータス、誰がいつ、いつ、どのタスクを書いたかが返されます。
4. 再度、ケースの名前から、改訂のタスク番号を見つけることができます。 そして、それを開いたら、リンクからアクセスします。

おわりに

DWHテストは、独自の仕様を持つ簡単なプロセスではありません。 古典的な方法論に固執する場合、それは非常に面倒であることが判明します。

このアプローチにより、迅速にテストを実行でき（平均して、1人のテスターが3日間でタスクを実行します）、見逃したエラーの数はゼロになります。 半年間、400を超えるタスクが生産性を高めました。

私たちはそこで止まるつもりはない。 次の目標は、ほとんどのチェックを自動化することです。