【セッションレポート】AWSではじめるデータクオリティ管理 #AWSSummit

はじめに

AWS Summit Tokyo に参加しました！

2日目 AWS-34 「AWSではじめるデータクオリティ管理」のセッションレポートを投稿いたします。

セッション視聴

AWS Summit Tokyoの登録を行うことでオンデマンドで視聴可能です。（現地参加された方は改めての登録は不要です。）

登録済みの場合、以下から直接遷移できます。

https://jpsummit.awsevents.com/public/session/view/553

セッション概要

データ基盤をビジネス活用する上では、誤ったデータ、欠損したデータ、 古いデータを元に判断することには重大なリスクがあります。 データクオリティ、つまりデータの精度・鮮度を監視・維持することは欠かせない大切なトピックです。 本セッションでは、データクオリティを基礎から学びます。 AWSクラウドでデータを扱い、データ基盤を構築する際に、データクオリティをサーバーレスで効率的に管理するベストプラクティスをご紹介します。

アジェンダ

• なぜデータクオリティ管理が必要か
• データクオリティ管理で欠かせない5つのポイント
• AWS Glue Data Quality を用いたデータクオリティ管理
• モダンデータアーキテクチャにおけるデータクオリティ管理

セッションレポート

なぜデータクオリティ管理が必要か

• 多くのお客様がデータドリブンの意思決定のために、データ基盤を構築し、活用している
• 誤ったデータ、欠損したデータ、古いデータによるビジネス判断には重大なリスクがある
• よくあるトラブル #1 データが古い
  • 3日前からデータが更新されていない。
  • データが届いていない？ジョブが失敗した
• よくあるトラブル #2 誤った結果が帰ってきた
  • クエリしてみると、カラムがNULLになった
  • ファイルの中身が変わったのか？、データの変換に失敗した？
• データクオリティ、データの信頼性の監視・維持はビジネスに欠かせない大切なトピック

データクオリティ管理で欠かせない5つのポイント

1. データクオリティの指標の定義
   • 正常状態を定義し、その状態を維持する
     • データ基盤がどのような状態であれば正常化を定義する
2. データクオリティをチェックする観点
   • 一貫性
     • 想定したカラムが存在するか
   • 精度
     • 値が存在するか。既定値範囲内か
   • 完全姓
     • データの鮮度が十分か
   • 整合性
     • プライマリキーがユニークか
3. データクオリティをチェックするタイミング
   • Data-at-rest（データ保管後）
     • 定期的またはオンデマンドにチェック
     • 分析時の実利用に近いチェックが可能
   • Data-in-transit(データ伝送路上)
     • データ保存前にチェック
     • 分析に影響を与える前にチェックが可能
4. データクオリティをチェックする担当者と方法
   • ETL開発者
     • 画面操作
   • ビジネスアナリスト
     • SQL
   • データエンジニア
     • プログラム
5. データクオリティの問題への対処方法
   • 異常状態を検知し、正常状態に復旧する
   • TTD：問題発生から検知までの時間
   • TTR：問題発生から解決までの時間
   • 復旧方法の例：データ鮮度の低下
     • 原因：データ収集・配信の遅延
     • 対応：データ収集・配信の問題の修正

AWS Glue Data Quality を用いたデータクオリティ管理

• AWS Glue
  • サーバレス データインテグレーションサービス
• AWS Glue Data Quality
  • プレビュー段階
  • レコメンデーション機能もある
• DeeQu をベースにしている
  • データクオリティの管理のために開発されたOSSライブラリ
  • オープンソース
• DQDLという記述言語
  • シンプルな記法
  • 複雑なルールにも対応
  • 高い再利用性
  • 精度
    • 例CustomSql "select count(*) from primary" between 10 and 20
  • 完全姓
    • 例DataFreshness "Order_Date" <= 24 hours
• Data CatalogによるData-at-restのチェックの流れ
  1. Data Catalog上でテーブルを選択(管理者)
  2. テーブルデータを分析し、自動でルールを推薦(AWS Glue Data Quality側)
  3. ルールをレビューし、評価を開始(管理者)
  4. 完成したルールをもとにデータを評価(AWS Glue Data Quality側)
  5. 結果をレビューし必要なアクションを実行 (管理者)
• ルールセットのレコメンデーション
  • ベースラインを自動作成しルール定義の手間を削減
• Glue JobによるData-in-transit のチェックの流れ
  1. ジョブを作成し、データクオリティ評価のアクションを追加、ジョブを実行(管理者)
  2. ジョブ内でルールをもとにデータを評価(AWS Glue Data Quality側)
  3. 結果をレビューし必要なアクションを実行 (管理者)
• AWS Glue Data Quality デモ
  • 利用上のデータをもとにビジネス判断を行う
  • 誤った判断をした。異常値があったことが原因。
  • デモ データエンジニアで異常値を検知したい
    1. コンソールから対象のテーブルからData Qualityのレコメンデーションでルールセットを自動生成
    2. ルールをレビュー
    3. ルールは、異常値や不整地をはじくように設定
    4. Evaluate ruleset で Data Qualityの評価を開始
       • ルールをチェックし、異常値があれば、エラーとなる。スコアで表現される
  • デモ ETLパイプラインでのデータクオリティ
    • 集約の前にデータクオリティをチェックしたい
      • Jobsを作成し、以下のアクションを追加し、ジョブを実行
        • Glue Data Catalog → Evaluate Data Quality → Aggregate → S3
          • ジョブが失敗（利用金額に異常値があり、ルールの１つが失敗）
      • 正確な値をデータレイクに保存できる

モダンデータアーキテクチャにおけるデータクオリティ管理

• データ活用で直面しやすい課題
  • データのサイロ
  • 組織・人のサイロ
  • ビジネスのサイロ
• モダンデータアーキテクチャ
  • 幅広いユースケースに対応
  • データソース → DBや分析、データレイク、それらを司るカタログ/ガバナンス → ユーザーのアプリケーション
• データガバナンスにおける課題
  • 組織内の適切なユーザーが適切なデータを安全に利用できること
• AWS Lake Formation
  • データレイクを構築、管理、保護
  • データレイクのデータアクセスを一元管理
• Amazon DataZone
  • 組織全体のガバナンスを一元管理し、データ活用を実現
• 統合されたデータアクセス・ガバナンス
• モダンデータアーキテクチャ例
  1. 収集
  2. 保存
     • Data-in-transit （データ保管後）
  3. 変換/カタログ化
     • Data-at-rest (データ伝送路上)
  4. 分析/可視化/予測

感想

• セッションでは、データクオリティ管理する上で、欠かせないポイントを学び、AWS Glue Data Qualityを用いたデータクオリティ管理の実現方法を学ぶことができました。
• モダンデータアーキテクチャ導入パターンの例の解説があったため、どのように収集から分析までを実現するかイメージを湧かせながら、理解することができました。
• データクオリティをチェックするタイミングには、「データ保管後」と「データ伝送中」の２つがあり、それぞれユースケースに応じて、チェックする必要があることが分かりました。
• プレビュー中のAWS Glue Data Qualityをぜひ使ってみたいと思うセッションでした！