背景・目的

2023年11月末に、AWS Glue Data Quality announces anomaly detection and dynamic rulesが発表されました。しばらく経ってしまいましたが、興味がある分野でしたので試してみたいと思います。

まとめ

2023 年12月16日現在
- プレビューです。
- 下記のリージョンで利用が可能です。
  - 米国東部 (オハイオ州、バージニア北部)
  - 米国西部 (オレゴン州)
  - アジアパシフィック (東京)
  - ヨーロッパ (アイルランド)
- Glue4.0のETLとGlue Studio Visual ETLのみ提供されています。

過去の統計を分析し、パターンを観測してレポートする
Glue MLアルゴリズムにより識別される
統計の収集は3回実行してから開始される。
下記のような事ができます。
- ルールを作成せずに、データの異常を検出する
- 品質ルールだけでは検出できない潜在的な問題を検出する
- 経時的に変更されるデータを検出する

概要

Anomaly detection in AWS Glue Data Qualityを元に整理します。

AWS Glue データ品質の異常検出はマシンに適用されます異常を検出するための経時的なデータ統計の学習 (ML) アルゴリズムパターンや隠れたデータ品質の問題を検出するのは困難です。ルール。現時点では、異常検出は AWS Glue 4.0 でのみ利用可能です。この機能は現在利用可能です AWS Glue Studio Visual ETL と AWS Glue ETL のみ。この能力 AWS Glue Studio ノートブック、インタラクティブセッション、AWS Glue データプレビューでは機能しません。

Anomary detectionは、Glue4.0のみ対応可能
ETLのみ

How it works

データ品質ルールを評価する際、AWS Glue は必要なデータ統計を取得します。データがルールに準拠しているかどうかを判断します。たとえば、Data Quality は次のように計算します。データセット内の個別の値の数を調べ、その値を期待値と比較します。

データ品質ルールエンジンは、統計値を定義されたしきい値と比較します。そして品質要件を評価します。これらの統計は時間の経過とともに収集されるため、 ETL パイプラインで異常検出を有効にして、AWS Glue に異常検出を学習させることができます。過去の統計を分析し、隠れたパターンを観察としてレポートします。観察は未確認の洞察であり、 AWS Glue の ML アルゴリズムが識別します。これらには、推奨されるデータ品質ルールが付属しています。検出されたパターンを監視するためにルールセットに適用できます。でジョブを実行することをお勧めします。定期的なスケジュール (時間ごと、毎日など)。不規則な実行では、不十分な洞察が得られる可能性があります。

※出典：AWS Glue Data Quality announces anomaly detection and dynamic rules

過去の統計を分析し、パターンを観測してレポートする
Glue MLアルゴリズムにより識別される

Using analyzers to inspect your data

データ品質ルールを作成する時間がない場合もあります。ここでアナライザーが役に立ちます。アナライザーはルールセットの一部であり、構成は非常に簡単です。たとえば、ルールセットに次のように記述することができます。

Analzyers = [
      RowCount,
      Completeness “AllColumns”
]

これにより、次の統計が収集されます。

データセット全体の行数

データセット内のすべての列の完全性

しきい値を気にする必要がないため、アナライザーを使用することをお勧めします。データを実行できますパイプラインを実行し、3 回実行すると、AWS Glue Data Quality が生成を開始します。異常を発見した場合には、観察とルールの推奨を行います。を確認できます。観察、関連する統計を分析し、ルールの推奨事項を簡単に組み込むことができます。あなたのルールセット。始めるには、以下を参照してください異常検出の構成と洞察の生成。アナライザーはデータ品質スコアに影響を与えないことに注意してください。これらは、時間をかけて分析して観察を生成できる統計を生成します。

しきい値を設定することが面倒であれば、アナライザーが使える。
3回の実行でGlue Data Qualityが生成を開始する。
observationsとルールのレコメンデーションを行う。

Using the DetectAnomaly Rule

場合によっては、異常が検出されたときにジョブを失敗させたい場合があります。制約を強制するには、次のことを行う必要があります。ルールを設定します。アナライザーはジョブを停止しません。代わりに、彼らは統計を収集し、データを分析します。のルールセクションで DetectAnomaly ルールを設定します。ルールセットは、ジョブがスキャン内のすべてのルールに合格しなかったことが DQ スキャンによって報告されたことを確認します。

anomary detectionは、ジョブの制御は行わない。

Benefits and use cases of Anomaly Detection

エンジニアは、いつでも何百ものデータパイプラインを管理できます。各パイプラインはさまざまなソースからデータを抽出でき、それをデータレイクにロードします。各パイプラインは異なるソースからデータを抽出してデータレイクにロードする可能性があるため、データの形状が大きく変わったか、既存の傾向から逸脱したかなど、データに関するフィードバックを即座に得るのは困難です。

過去には、上流のデータソースがデータエンジニアリングへの警告なしに変更されました。チームがこのプロセスに追跡困難な「データバグ」を持ち込むことになります。 Data Quality ノードを追加することによって問題が見つかるとジョブが失敗するため、これにより作業が大幅に楽になります。ただし、これでは削除されませんデータチームが懸念しているすべての障害モードは、他のデータバグが侵入する扉を開いたままにしています。

障害モードの 1 つはデータ量に関するものです。企業のデータストアが時間の経過とともに増加するにつれて、データパイプラインによって生成されるレコードの数も増加します指数関数的に成長する可能性があります。データチームは毎週、ETL ジョブを手動で更新して、データ品質ルールを設定する各データ品質ルールを強化する必要がある場合があります。取り込まれる行数を制限します。

もう 1 つの障害モードは、データ品質ルールの制限の一部が非常に広いことです。取引量が曜日によって異なるという事実に対応します。の上週末はトランザクションがほとんどなく、月曜日には約 3 倍のトランザクションが発生します他の平日よりも。データチームには 2 つの選択肢があります。どちらかが、ロジックを実装してデータを変更します。日によってその場でルールを設定したり、非常に幅広い期待を設定したりすることもできます。

データに関する件数の確認が難しいのは、下記のように動的にデータが変動することである。
- データ量によるもの。経時的に増えたり、突発的に増える。
- 曜日によって取引量が異なる。

最後に、データチームは、明確に定義されていないデータのバグにも懸念を抱いています。モデルは特定の特性を持つデータでトレーニングされており、そして、これらが予期せぬ方向に歪み始めた場合、チームはそれを知りたいと考えています。たとえば、 2 月企業がモンタナ州に進出する可能性があるため、「MT」コードを含む取引が開始されましたより頻繁に現れます。これにより、ML 推論が壊れる可能性があり、その結果、モデルが誤って作成される可能性があります。モンタナ州の取引はすべて詐欺であると予測しました。

突発なイベントにより、データの外れ値によりモデルが誤って判断される。

ここで、データ品質の異常検出がこれらの問題の解決に役立ちます。データ品質異常検出の利点のいくつか含む：

スケジュールベース、イベント駆動ベース、または手動ベースでのデータのスキャン。

意図しないイベント、季節性、または統計的異常を示す可能性のある異常の検出。

データ品質異常検出によって検出された観察に対してアクションを実行するためのルール推奨事項を提供します。

これは次のような場合に役立ちます。

データ品質ルールを作成することなく、データの異常を自動的に検出したいと考えています。

データ品質ルールだけでは検出できない、データ内の潜在的な問題を検出したいと考えています。

数の制限など、時間の経過とともに進化する一部のタスクを自動化したいデータ品質監視のために取り込まれた行。

ルールを作成せずに、データの異常を検出する
品質ルールだけでは検出できない潜在的な問題を検出する
経時的に変更されるデータを検出する

実践

GlueでAnalyzerを設定する

Glueのページで、ジョブを新規に作成します。
「Evaluate Data Quality」を追加します。
「Anomaly detection」タブをクリックします。
「Add analyzer」タブをクリックします。
ポップアップが上がるので、「RowCount」を選択し、Add analyzerをクリックします。
次に「Ruleset editor」タブをクリックします。

下記のようなコードを書きます。過去3回の最小値と、過去3回の最大値の間に入ることを確認します。

# Example rules: Completeness "colA" between 0.4 and 0.8, ColumnCount > 10
Rules = [
 RowCount between min(last(3)) and max(last(5)),
 DetectAnomalies RowCount
]
Analyzers = [
    RowCount 
]

実行

一回目を実行します。ファイルは50件です。

$ ls -l test.json ; wc -l test.json;tail test.json                                           
-rw-r--r--  1 XXX  YYY  491 12 16 13:48 test.json
      50 test.json
{"id":41}
{"id":42}
{"id":43}
{"id":44}
{"id":45}
{"id":46}
{"id":47}
{"id":48}
{"id":49}
{"id":50}
$

実行完了しました。
エラーになっていました。３回実行される前ですがエラーになっていたようです。
observationsをクリックすると、未だクラフ化はされていません。3回実行する必要があると記載されています。
二回目を実行しました。変わらずエラーになっていました。
三回目を実行しました。変わらずエラーになっていました。
やはり、未だグラフはできてません。
四回目を実行しました。エラーになっています。50回〜50回の間に入るのでエラーにならないかと思っていましたが。設定を間違えたのかも。
変わらずグラフ化されていません。
〜8回まで実行しました。変わらずでした。

100件に増やしてアップしてみます。

$ ls -l test.json ; wc -l test.json;tail test.json                                            
-rw-r--r--  1 XXX  YYY  992 12 16 15:13 test.json
     100 test.json
{"id":91}
{"id":92}
{"id":93}
{"id":94}
{"id":95}
{"id":96}
{"id":97}
{"id":98}
{"id":99}
{"id":100}
$

実行しました。Anomalies RowCountがエラーになりました。
Observationsが、できていました。
- Dataset.*.RowCount
  - ActualValue: 100.00
  - ExpectedValue: 50.00
  - LowerLimit: 50.00
  - UpperLimit: 50.00
リンクをクリックします。トレンドがわかります。
実行しました。DetectAnomailes　RowCountがPassになりました。
min 68〜 max 136です。

件数を90件に変更し、実行します。

$ ls -l test.json ; wc -l test.json;tail test.json                                           
-rw-r--r--  1 XXX  YYY  891 12 16 15:44 test.json
      90 test.json
{"id":81}
{"id":82}
{"id":83}
{"id":84}
{"id":85}
{"id":86}
{"id":87}
{"id":88}
{"id":89}
{"id":90}
$

両方、パスしました。

考察

今回、anomaly detectionとdynamic rulesを試してみました。ジョブのミスなど早々に気付けるようになりそうです。とても良いですね。

参考