re:Invent 2024: AWSとVanguardによるGlue Data Qualityの活用
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Monitor and manage data quality (ANT343)
この動画では、データ品質の重要性とAWS Glue Data Qualityの機能について詳しく解説しています。AWS GlueのProduct ManagerであるShiv NarayananとVanguardのChief Technical AdvisorのAndrew Rifeが、データ品質管理の実践的なアプローチを紹介します。特に、AWS Glue Data Qualityが提供するルールベースの品質チェックと異常検知機能、そしてDQDL（Data Quality Definition Language）を活用した具体的な実装方法が示されます。また、9.9兆ドルの運用資産を持つVanguardが、AWS Glue Data Qualityを活用してGalileo42データプラットフォームを構築し、日々の投資データの品質を確保している実例も紹介されており、エンタープライズレベルでのデータ品質管理の実践的な知見を得ることができます。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
データ品質セッションの概要と重要性
おはようございます。本日午前8時30分からのデータ品質に関するセッションにご参加いただき、ありがとうございます。データがなければ、私たちは何もできません。まず、チームの紹介を手短にさせていただきます。私はNavneetと申しまして、Healthcare Life Sciencesのリーダーの一人です。私のチームは、お客様のデータ戦略に取り組んでいます。本日は、AWS GlueのProduct ManagerであるShiv Narayananと、お客様であるVanguardのChief Technical AdvisorのAndrew Rifeにもステージに加わっていただいています。本日は、私たちの経験と素晴らしい取り組みについて共有できることを楽しみにしています。
まずは本日のアジェンダについて手短にお話しさせていただきます。今日は、いくつかのトピックをカバーする予定です。データ品質について具体的な話に入る前に、なぜデータ品質が重要なのかについて時間を取りたいと思います。皆様にデータ品質について知っているかどうか手を挙げていただければ、きっと全員が手を挙げられることでしょう。しかし、より重要なのは、今日のアーキテクチャにおいてなぜそれが重要なのかを理解することです。高品質なデータプロダクトやデータ資産の構築方法について説明し、データガバナンスをサポートするAWSサービスの概要を説明します。また、AWS Data Qualityやその他のツールが提供する機能について解説し、AWS Glue Data Qualityの詳細な説明を行い、最近発表された新機能についても学びます。最後に、VanguardがAWS Data Qualityをデータプラットフォームでどのように活用しているかについてお話しいただきます。
モダンなデータアプローチとデータガバナンス
まず、お客様からよく耳にするテーマを示すスライドから始めたいと思います。これらのポイントを見ていただくと、データレイクの保守や管理ではなく、データを活用したイノベーションに注力したいという点が大きなテーマとなっています。お客様は、データ消費者としてデータ品質に注力したくないのです。なぜなら、データそのものが最初から高品質な製品であってほしいからです。これはデータ品質だけの問題ではなく、データ品質を構成要素の一つとするデータプラットフォームの構築方法に関する問題です。例えば、チームが他のチームから独立したデータセット、パイプライン、リポジトリを所有する必要がある場合や、現在のデータアーキテクチャが遅すぎるという懸念などが挙げられます。
ここで、お客様向けに構築したモダンなデータアプローチをご紹介します。これは主に4つの層またはティアについて説明するものです。このモダンなデータアプローチの最下層には、様々なストレージがあります。昨日のKeynoteでもお聞きになったように、私たちはクラウドでのデータストアの最適化、目的に特化したデータストアの構築、パフォーマンスのスケーリングなど、ストレージの革新を進めています。ストレージは非常に重要です。なぜなら、構築するすべての品質ルールには、実行のための最適化されたコンピュートが必要だからです。ストレージの上には、データガバナンス層があり、ここで大部分のデータ品質ルールと定義が適用されます。私たちはデータガバナンスを「理解」「キュレート」「保護」という3つの柱で考えています。「理解」は、消費者が素早く発見できるよう、適切な品質情報を持つデータをカタログに公開することを意味します。「保護」は、多くのデータ品質ルールが適用されるデータストレージとトランジットのセキュリティ管理に焦点を当てています。「キュレート」には、データ管理、パイプライン、変換、MDMなどが含まれます。
ガバナンス層の上には、データの実際の活用を始める「アクト」層があり、MLモデルやETLパイプラインの構築を行います。このフレームワークは、特定のAWSサービスに依存せず、むしろデータアーキテクチャを構築するためのベストプラクティスに焦点を当てています。最上層には、ダッシュボードの構築や生成AIエージェントなど、さまざまなエクスペリエンスが含まれています。ただし、本日は主にストレージとガバナンスという基盤層に焦点を当てて説明させていただきます。
AWSのデータガバナンスサービスとAmazon DataZone
AWSにおけるモダンなデータガバナンスについて、少しお時間をいただいてお話しさせていただきます。 先ほどのスライドで見た異なるストレージ層、つまりガバナンス、アクション、そしてビルド＆アクトについて、このデータアーキテクチャ全体の中心となるのは、優れたガバナンスモデルの構築です。私たちには3つの主要な柱があります：管理（Manage）、理解（Understand）、保護（Protect）です。理解の部分は、メタデータ、リスト作成、カタログ化、プロファイリング、品質情報に関するすべてを含みます。
ビジネス成果を重視したモデルを構築しようとするConsumerやML科学者、データサイエンティストのことを考えてみてください。彼らがカタログにアクセスしてデータ資産を探す際、そこで品質情報が表示されていれば、どれほど有益でしょうか。品質が90%を満たしていれば、彼らは手元のデータにより大きな信頼を持つことができます。これらはすべて理解の柱に含まれます。管理の柱は、本日のセッションで主に取り上げる、データ検証やデータ変換といったデータルールの実際の実行に関するものです。保護の柱は、ストレージ、Data-at-rest、Data-in-transit、アクセスポリシーの作成などに関するものです。
データ品質とその実装について、大きなエコシステムの一部として考えていただきたいと思います。そしてその大きなエコシステムこそが、データガバナンスなのです。 AWSには、データガバナンスの構築に活用できるサービスがいくつかあります。例えば、AWS Glueは、技術的なデータカタログ、ETLパイプライン、AIと異常検知を使用したデータ品質ルールの作成を可能にします。また、AWS Lake Formationは、データへのきめ細かなアクセスを構築するために活用できるサービスです。まず、高品質なデータが構築され、準備され、利用可能な状態であることを確認する必要があります。次に、データアクセスが適切であることを確認する必要がありますが、これがAWS Lake Formationの役割です。
MLのためのAmazon SageMaker Model Governanceもあります。私たちがデータガバナンスについて考える際、それはデータだけでなく、MLモデルやAIのガバナンスも含みます。構造化、非構造化、半構造化データなど、どのような種類の資産であっても、同じルールが全体に適用されます。そして、Amazon DataZoneもあります。会場の中で、昨年Amazon DataZoneについて聞いたことがある、または使用したことがある方はどれくらいいらっしゃいますか？素晴らしいですね。Amazon DataZoneは2022年に発表したサービスで、データカタログ、ビジネスカタログ、メタデータの構築を支援し、後ほどデモンストレーションするように、データ品質のためにAWS Glueと統合されています。
Amazon DataZoneは、データのProducerとConsumerを結びつけます。Consumerはデータを使用して分析を構築する人々であり、Producerは、Consumerが利用できるデータプロダクトを構築する人々です。このアーキテクチャの優れている点は、ProducerがConsumerになることもできれば、ConsumerがProducerになることもできるという点です。私がConsumerとしてデータを利用している場合、そのデータをカタログに戻すこともできます。ProducerとConsumerがデータ情報を構築し交換する上での重要なテーマの1つは、データが高品質で構築されていなければならないということです。そうでなければ、検証ルールの構築に多大な時間を費やすことになってしまいます。Amazon DataZoneは、ビジネスメタデータの構築、データプロダクトの取り込み、ドメインアーキテクチャの作成、そしてデータ品質情報のためのAWS Glueとの統合を実現するワンストップソリューションです。
Amazon SageMaker Unified Studioとデータガバナンス
昨日発表された Amazon SageMaker Unified Studio についてご存知の方はどれくらいいらっしゃいますか？昨日、私たちは Amazon SageMaker Data, AI and Governance という新しいサービスを発表しました。この図の下部に、データガバナンスの最も重要なコンポーネントが示されています：データ品質、データ分類、Data Lineage、ML Guardrails などです。データがどこにあろうとも、ガバナンスは必要不可欠であり、品質はそのガバナンスの一要素です。現在、私たちは SageMaker Lakehouse アーキテクチャをサポートしており、これによってデータの単一コピーを簡単に保持でき、Iceberg APIを使ってデータレイクやデータウェアハウスからデータにアクセスすることができます。
データとAIガバナンス層の上には、データ、MLモデル、Gen AI、コンピュートをリストアップできるカタログがあります。最上位には Unified Studio があります。Unified Studio のコンセプトは、データプロデューサー、コンシューマー、ガバナンスチームが協働できる共通のポータルです。プロデューサーは私たちが提供する様々なツールや Amazon Q を使ってデータを構築でき、コンシューマーは Amazon Q や手動でクエリ、モデル、Bedrock エージェントを構築でき、ガバナンスチームはドメイン、品質ツール、データ検証を設定できます。Unified Studio を使えば、アーキテクチャをエンドツーエンドで構築できます。では、ここでデータガバナンスと品質について話を移しましょう。
高品質なデータプロダクトを構築する動機は何でしょうか？先ほど説明したように、これらのデータプロダクトはすべて、誰でも検索、発見、アクセス要求できるカタログにリストアップされます。そのため、より多くの品質情報を提供すればするほど良いのです。ここで重要なポイントをいくつか挙げてみましょう：まず、高品質なデータプロダクトがあれば、より良い意思決定が可能になります。正確でタイムリーな情報を提供することで、業務効率を向上させることができます。
これは、最初から高品質なデータプロダクトを作らないと、おそらくコンシューマーに気に入ってもらえず、何度も作り直して品質を改善し、往復を繰り返すことになってしまうというテーマです。そのため、発生する可能性のある運用上の非効率性を減らすことができます。そして、より良いユーザーエクスペリエンスが得られます。高品質なものは、何を作るにせよ、必ず素晴らしいユーザーエクスペリエンスをもたらします。データは製品の一種に過ぎません - 物理的な製品もあれば、データプロダクト、MLプロダクトもあります。どんな製品を作るにせよ、使用するにせよ、良い品質があれば良いユーザーエクスペリエンスが得られます。
高品質なデータプロダクトの重要性とAWS Glue Data Quality
では、今日のAWSではどのようにしてそれを実現しているのでしょうか？その前に、現在どのようなオプションがあるのかを見てみましょう。 大きく分けて3つのオプションがあります。1つ目は従来型の品質ツールです。これらは長年にわたってシェル製品として構築されてきたツールで、主にリレーショナルデータソースで動作します（それだけではありませんが）。2つ目はオープンソースフレームワークです。これは素晴らしいのですが、結局のところ、インフラストラクチャの保守や品質に関する更新やリリースの管理は自分で行う必要があります。そして最後に、ニッチなソリューションがあります - これは特定のニーズに合わせて非常にカスタマイズされたものを構築するもので、目的は達成できますが、スケールはしません。
私はライフサイエンスとヘルスケアの分野で働いていますが、画像データや非構造化データ、半構造化データなど、様々なモダリティのデータを扱うことが多く、それらは常に変化し続けています。モダリティは増え続け、データも進化しています。そのため、特定の問題だけを解決するソリューションを採用して、データのモダリティが変わるたびに一からやり直すようなことは避けたいものです。そこで私たちが提供するのが、AWS Glue Data Qualityの機能とメリットです。 次のように考えてみてください：AWS Glue Data Qualityを使用することで、インフラストラクチャやコンピューティングを気にすることなく、データ品質ルールを構築できる、Serverlessでスケーラブル、かつ高性能なプラットフォームを手に入れることができます。代わりに、Serverlessアーキテクチャを使用して、月に1億件以上のジョブを実行できるルールを構築し、DeeQuのようなオープンソースフレームワークを活用してこれらのルールを構築することができます。
また、ルールの推奨機能も提供しています。これは非常に重要で、この後すぐにデモでご覧いただけます。データアセットに対してデータ品質ルールを構築する際、データをよく理解している場合は一から始めることもできます。しかし、データを完全に理解していない場合や、誰かにルールを推奨してもらいたい場合はどうでしょうか？私たちには、データを検査してルールを推奨するAI搭載の推奨エンジンがあります。そして、それを修正したり、削除したり、追加したりするのは、すべてお客様次第です。また、ルールが失敗した場合のパイプラインを構築できる、組み込みのデータ品質ルールとアクションも用意しています。
私たちはDQDL（Data Quality Definition Language）というオープンソース言語をベースにしています。これについてはShivがより詳しく説明しますが、ルールを作成する際、ブラックボックスのようなアプローチではなく、ルールをオープンに保ち、組織内の他のメンバーと簡単に共有できるようにすることが重要です。そして最も重要なのは、Data-at-restとData-in-transitの両方をサポートしていることです。先ほどのストレージとガバナンスについてのスライドに戻りますが、データが移動中の場合は、セキュアで検証され、高品質である必要があります。データが保存されている場合も、同じレベルの成熟度が必要です。最後に、最新の機能として、Anomaly DetectionとData Profilingがあり、これらを使用することでより効率的に品質ルールを構築することができます。
Shivにバトンタッチする前に、いくつか説明させてください。 カタログにデータアセットを公開するデータ戦略について話すと、そのカタログには品質情報を含むデータアセットが表示されます。これは重要です。なぜなら、消費者が品質に関するすべての情報を得られるようにしたいからです。例えば、患者の名前が70%入力されていて30%がNullであるといった情報です。これは許容される場合もありますが、少なくともこのような情報を消費者が確認できるようにすることで、データへの信頼性が高まります。これは単純なパイプラインです：Data Stewardが AWS Glueでデータセットを選択し、推奨ルールエンジンを使用してすべてのルールの推奨を取得し、そしてデータ品質がこれらのルールを実行して、Amazon DataZoneに表示します。
では、簡単なデモをお見せします。 AWS Glueに移動して、ClinicalDBというデータベースにアクセスし、その中にある複数のテーブルをご覧いただきます。
AWS Glue Data Qualityの実践デモ
これらのテーブルの1つがPatientsテーブルです。 このPatientsテーブルを確認すると、40から50個ほどのカラムが含まれています。AWS Glueのデータ品質タブに移動すると、現時点ではルールが何も定義されていません。これから新しいデータ品質ルールを作成しますが、その方法は2つあります。一つは、一意性や完全性などのカテゴリーに基づいて自分でルールを作成する方法、 もう一つは単純にルール推奨ボタンをクリックする方法です。
ルール推奨を選択すると、S3上のテーブルにアクセスできるIAMロールの指定を求められます。 その後、ルールの推奨プロセスを開始します。これにより、私たちのモデルを活用したバックグラウンドジョブが起動され、 Patientsテーブル全体を分析して適切なルールを推奨します。ジョブが完了したら、生成されたルールを確認しますが、必要に応じてカスタムルールを作成することもできます。
ジョブが完了したので、生成されたルールを確認していきましょう。結果を表示すると、 そのテーブル用に作成されたルールのリストが表示され、完全性、長さ、一意性などの属性ごとに分類されています。これらのルールをすべて採用することにします。 システムは72個のルールを推奨してくれました。これらをこのルールセットに追加します。必要に応じて一部のルールを削除したり、新しいルールを追加したりして修正することができます。これはDQDL（Data Quality Definition Language）を使用して実装されています。
このルールセットを「patients data quality rules」という名前で保存し、実行を開始します。このルールセットを実行すると、 テーブル全体に対してすべてのルールが評価され、どのルールがパスし、どのルールが失敗したかが判定されます。先ほどと同じく、基盤となるデータへのアクセス権を持つIAMロールを使用して実行を開始します。システムは現在、72個すべてのルールを実行しています。 これらが推奨ルールであることを示す小さなインジケータが表示されています。ルールの実行が完了したら、結果を確認します。
ルールの実行が完了すると、 72個のルールのうち、2つを除くすべてのルールがパスしたことがわかります。この機能をデモンストレーションするために、意図的に失敗するデータを含めました。なお、このデモでは実際の患者データではなく、合成された患者データを使用していることを強調しておきたいと思います。この2つの失敗したルールは、要件によっては許容できる場合もあります。今回は合格基準を100%に設定しましたが、 90%など、より低い基準を設定することもできます。この場合、97%の合格率を達成しています。
AWS Glueのパートと最初のData Stewardのフローが完了したので、次はAmazon DataZoneに移りましょう。Amazon DataZone内では、特定のDomainで作業を行います。DataZoneにおけるDomainの概念は、データアセットや製品を公開したい事業部門や組織単位を表しています。私のLife Sciences Domainにアクセスして、Browse Projectsのオプションを見ていきましょう。Carcinoma Real World Dataというプロジェクトを作成しましたが、これは特定のがん種の患者さんに関するデータを含んでいます。
このプロジェクトにアクセスすると、すでにいくつかのアセットを公開済みであることがわかります。これらのアセット、特にInventoryデータを確認してみましょう。これは裏側で設定済みですが、AWS GlueからAmazon DataZoneへのデータ移行は最小限の労力で簡単に行えます。DataZoneはGenerative AIを使用して自動的にメタデータを生成しますが、今回は特にデータ品質に注目します。Data Qualityタブに移動すると、コンソールビューではなくポータルエクスペリエンスが表示され、3つのルールカテゴリが実行されていることがわかりますが、最新の実行結果はまだ表示されていません。
これに対処するため、データソースに移動して更新を行います。これにより、CatalogとAWS Glueから最新の情報がDataZoneにインポートされます。このジョブの実行中、Catalogに新しい情報が更新されるのを待ちます。詳細を確認した後、再度Inventoryデータを見直します。DataZoneにはData Productsという概念が組み込まれています。先ほど説明した患者データを含む、すべてのアセットを確認してみましょう。
更新ジョブを実行したので、患者データが更新されているはずです。Assetsタブに移動して、Patientsテーブルを選択します。この画面では、すべてのメタデータと追加情報を確認できます。Data Qualityセクションを確認すると、現在4つのカテゴリのルールが表示されています。最新の実行結果では、72個のルールのうち70個しかパスしていません。私の基準では不合格となりますが、皆さんの要件によっては許容範囲かもしれません。
時系列での傾向も表示されますが、どのルールが失敗したのかも確認してみましょう。詳細な情報が提供され、Schemaタブからも同様の情報を確認できます。すべてのカラムを確認でき、実行されたルールの数と、そのうち何個のルールが失敗または合格したかを判断できます。
それでは、Data Qualityタブに戻って全体的なスコアを見てみましょう。最大値、最小値、その他の統計的な数値や指標といったカテゴリも表示されていることがわかります。これらのルールが全て表示されています。つまり、データセットを探している利用者や閲覧者として、Patientアセットを確認する際に、トレンドや全ての情報を見ることができます。
もう一つできることがあります。それはPatientアセットを検索することです。上部で検索すると、Data Qualityタブに表示されていたのと同じ情報を得ることができます。ご覧いただいたように、AWS Glueを使ってアセットに対するData Qualityルールを簡単かつ迅速に実行することができました。そして、その全ての情報をAmazon DataZoneやカタログに取り込み、利用者がそれらのルールを確認し、どのルールがパスしたかを見て、そのプロダクトを使用するかどうかについて十分な情報を得た上で判断することができます。
AWS Glue Data Qualityの新機能と異常検知
ここで、DQの実際の仕組みと、最近発表したばかりの競合機能について、より詳しく説明するためにShivに引き継ぎたいと思います。ありがとうございます、Navneet。改めておはようございます。私はShiv Narayananと申します。AWS GlueチームのProduct Managerで、データ管理機能を担当しています。このセッションは何度か実施していますが、いつも光栄に思うのは、時間に関係なく皆さんが参加してくださること、AI・MLの講演よりも優先してくださっていること、もしかしたら偶然ここにいらっしゃるのかもしれませんが。いずれにせよ、お越しいただき、本当にありがとうございます。
ここまでご覧いただいたのは、ビジネスユーザーがData Qualityをどのように活用できるかということでした。AWS Glue Data Catalogからセットアップして、DataZoneまで進み、その結果を利用できることをご確認いただきました。しかし、最も重要なポイントの一つは、AWS Glue Data Qualityはビジネスユーザーだけのものではなく、パイプラインの早い段階でこれらのデータ品質チェックを確実に実行したいと考えているデータエンジニアや技術チームのメンバーのためのものでもあるということです。データエンジニアの方は何人いらっしゃいますか？手を挙げていただけますか。おお、かなり多くの方がデータエンジニアですね。素晴らしいです。これから、ETLパイプラインでこれを実際にどのように使用できるか、そして最近リリースした新機能について説明しますので、皆さんにこれを使い始めていただけるよう、きっと納得していただけると思います。
まず、Data Quality Definition Languageについてお話ししたいと思います。AWS Glue Data Qualityを作成した際、最も大きな議論の一つは、お客様にデータ品質ルールを作成するためにどのような体験を提供するかということでした。私たちは2つの主要なオプションを検討しました。1つは、クリックするだけでデータ品質ルールを作成できる美しいユーザーインターフェースを作ることでした。多くのお客様がそれを持っていましたが、パイプライン全体でそれを大規模に展開することに苦労していました。もう1つのオプションは、JSONファイルや設定ファイルを使用することでしたが、お客様からは、ビジネスユーザーに開き括弧と閉じ括弧を見せると逃げ出してしまうと言われていました。
私たちは、Data Quality Definition Languageという言語を作るという大胆な決断を下しました。それだけでなく、このプラットフォーム間で使用できるデータ品質ルールを一度書けば済むようにするため、オープンソース化も行いました。今年は大きな進展を遂げており、「過去10日間の平均より大きいルールカウント」という例に見られるように、動的なしきい値をサポートするようになりました。これにより、過去10日間、あるいは任意の日数のレコード数を確認し、行数がその80%以上であることを指定できるようになりました。また、最近では、Data Quality Definition Languageでフィルタリングやwhere句を適用する機能もリリースしました。
そして、私たちのチームは、複雑なビジネスデータ品質ルールを記述できるように懸命に取り組みました。これは、お客様がネスト構造のサポートを必要とする、ますます複雑なタイプのデータ品質ルールを採用するようになってきているためです。今では、ネストされた深いルールすべてをサポートする必要が出てきています。複雑さは、これらのルールそれぞれを処理し、統計を収集して適用する必要があることから生じています。かなりの量のエンジニアリング作業が必要でしたが、この機能を提供できるようになって嬉しく思います。私たちのお客様は、私たちが何を提供しても、常に創造的な方法でツールを使用しています。カスタムSQLをサポートしているだけでなく、1つのデータセットだけでなく、データセット間でのデータ品質チェックもサポートしています。データレイク上で参照整合性チェックを実行したり、異なるデータセット間で比較を行ったりすることができます。
基盤となるエンジンについて説明させていただきます。 最近よく見られるアプローチの1つは、お客様がオープンソースのデータ品質エンジンを採用することです。DeeQuは非常に人気のあるエンジンで、その歴史は大規模なデータセットでデータ品質チェックを効率的に実行する方法について議論したAmazonのサイエンスペーパーにまで遡ります。当初、このフレームワークはAmazon内で使用され、非常に大規模なデータレイクの管理に活用されていました。オープンソース化された後、多くの大手顧客が社内で使用し始めました。DeeQuの効果は、データパスを最小限に抑えるという基本原則に基づいています。まず、できるだけ少ないパスでデータを処理して統計を収集し、それらの統計が保存されると、ルールを1つずつ実行するよりもはるかに速くデータ品質チェックを適用できます。
異常検知機能のデモと実装方法
現在、私たちのエンジニアリングチームがこのプロジェクトの管理を行っており、他の貢献者とともに継続的に貢献しています。DeeQuの継続的な改善と、その上に構築したものについて、とても楽しみにしています。では、デモをお見せしましょう。 データエンジニアの方は、特に注目してください。ETLパイプラインでデータ品質チェックを設定する方法をお見せします。 AWS Glue ETLを使用します。まず、Visual ETLジョブを作成するためにETLジョブをクリックします。なお、これらすべての操作はコードAPIを通じても実行できます。
まずは、Glue Data Catalogテーブル、具体的にはCustomerデータベースから始めます。 Studioで対話型セッションを開始します。これにより、処理中の状況をすぐに確認することができます。 ご覧のように、これは顧客名を含むフェイクデータです。ここで任意の変換を追加し、その後データ品質評価の変換を追加します。まずは1つのルールから始めましょう。そのテーブルのプライマリーキーが100%完全であることを確認するための完全性ルールを作成します。書き方は簡単で、「completeness of customer SK equals one」と記述します。これを実行すると、左下にルールが合格したか失敗したかのフィードバックがすぐに表示されます。ご覧のように、このルールは合格しました。
AWS Glue Studioでパイプラインの構築を続けていきましょう。新たに2つのノードを追加します。これらについて説明していきます。 ルールの結果を見ると、そのルールのアウトプットが確認できます。これはデータエンジニアにとって非常に重要です。なぜなら、100万件のレコードを処理する際には、 どのレコードがパスし、どれが失敗したのか、各ルールの状態を把握する必要があるからです。データセットには4つの新しいカラムが追加され、 レコードがパスしたかどうか、そして具体的にどのルールがパスまたは失敗したかが示されます。この情報は必要に応じてフィルタリングや加工が可能です。
では、先ほどのスライドでお見せしたすべてのルールを記述していきます。 これらが記述可能なすべてのルールですが、中にはデータセット1つに対して何千ものルールを設定しているお客様もいます。実装するルールの数は、皆さんの必要に応じて自由に決めていただけます。それでは戻って、ジョブを完了させ、スクリプトを確認してみましょう。
スクリプトをお見せしたかった理由は、 ノートブックでの開発を好むデータエンジニアの方々に向けてです。DQDLをスクリプトで記述し、用意されているAPIに渡すことで、 1回のAPI呼び出しですべての結果を取得できます。非常にシンプルな方法で、コードで記述することができます。
次のステップでは、このData Qualityジョブを実行します。実行すると、Runsタブで成功したことが確認できます。Data Qualityタブを見ると、すぐにData Qualityスコアが表示され、 すべてのルールの合否が確認できます。ここではデータは表示されませんが、S3に書き出して通知を設定することができます。私が重要なポイントとして強調したいトレンドの部分を示すため、これを複数回実行しました。Data Qualityスコアが57のData Qualityトレンド情報が確認できます。作成したルールによって9つの統計情報が収集され、 ルールエンジンがそれらの統計情報に基づいて実行されています。
また、 これらの統計情報を個別に確認し、時系列で見ることもできます。これは非常に有用で、データのパターンを理解することができます。このデモでは全て100%と表示されていますが、実際の増減がある場合はそれらすべてを確認することができます。これらは私たちが追加した新機能の一部です。よくある質問として、APIでアクセスできるのか、書き出してクエリを実行できるのか、といったものがありますが、もちろんそれらはすべて可能です。
お客様からのご要望に基づいて、非常に有用なデータ品質ルールを多数リリースしました。新しいデータ品質ルールはファイルに焦点を当てています。例えば、File Freshnessはファイルが最新であることを確認し、ファイルとS3フォルダの両方で機能します。FileMatchは金融系のお客様がチェックサムを受信ファイルと比較する際に役立ちます。FileUniquenessは、パートナーから受け取ったファイルに重複がないことを確認するのに役立ちます。これらすべてについて、ファイルの50%や80%がユニークであるべきといったように、しきい値を設定することができます。
FileSize（ファイルサイズ）ルールは特に興味深いものです。主な目的は特定のサイズのファイルを取り込んでいることを確認することですが、お客様はこれを使ってデータレイク内の小さなファイルの問題を特定できると考えています。これにより、ビジネスの観点からのパフォーマンス低下も品質の問題として捉え、データ品質チェックに基づいてコンパクション（圧縮）の判断を行うことができます。
ルールとそのETLでの動作について説明しましたが、最も重要な質問は：ルールベースのデータ品質だけで十分なのでしょうか？実は、十分ではありません。あるお客様の事例が印象的でした。彼らはルールベースのデータ品質を使用し、取引限度額のルールを設定していました。例えば、1日の取引合計額を100万ドルと設定していました。データエンジニアの皆さんご存知の通り、時間が経つにつれてこれらのしきい値を調整するモチベーションは低下していきます。ビジネスが成長するにつれ、100万ドルが1,000万ドルになり、ルールは合格し続けました。しかし、ソースシステムの1つがデータの送信に失敗し、1,000万ドルのしきい値が突然200万ドルに下がった時、ルールは依然として合格していましたが、検出されないデータ品質の問題が存在していたのです。彼らはこの急激な下落について通知を受けたかったと考えていました。
これは、ハロウィンのキャンディー販売や年間・週間の季節性パターンのような傾向を検出したい場合の季節性の問題に似ています。年間や週間の季節性パターンが見られるはずなので、ルールベースのデータ品質と、異常検知のような機械学習ベースの機能を組み合わせることが重要です。私たちは、この異常検知機能の一般提供を開始できることを嬉しく思います。これは今すぐAWS Glue ETLで試すことができます。
この仕組みについて簡単にお話しします。統計情報が収集され、それらの統計に機械学習アルゴリズムを自動的に適用して学習し、隠れたインサイトを特定してObservationsを通じて通知するという利点があります。最も素晴らしい点の1つは、これらの異常を視覚的に確認でき、さらに重要なことに、機械学習モデルにフィードバックを提供してより良いものにできることです。
その前に、これがどのように機能するのか説明させていただきます。先ほどのデモでご覧いただいたように、データ品質ルールがあり、それによってデータ統計が生成されます。設定したしきい値を持つルールがあり、統計を確認し、ルールを適用して、データ品質スコアを作成します。どのレコードが合格したか不合格だったかを示すので、それに基づいて作業できます。ここで、Analyzerという新しい概念を導入します。Analyzerはシステムにデータ統計を収集するよう指示します。Analyzerが重要な理由は、データエンジニアとして、すべてのデータ品質ルールを把握していない可能性があるからです。これら5つのカラムが重要だと指定し、何か問題が発生していないかを特定するために、これらのカラムのすべての統計を収集したいと考えるかもしれません。
データについてよく理解している部分についてはルールを作成し、よく分からない部分についてはAnalyzerを作成できます。これらは同じDQDLで組み合わせることができます。Analyzerはデータ統計を生成しますが、しきい値を提供していないため、データ品質スコアには影響しません。ただし、異常検知には非常に役立ちます。強調しておきたいのは、単にルールを記述して異常検知をオンにするだけでも機能するということです。なぜなら、これらのルールがデータ統計を収集し、その異常の結果として、ルールの推奨を得ることができるからです。これらのルールは、将来の問題を検出し、将来のルールを将来に対応させることができ、データ品質ルールを段階的に構築することができます。また、MLモデルにフィードバックを提供して、時間とともに改善されるようにすることもできます。
実際にやり方をお見せしましょう。おなじみのAWS Glue Studioインターフェースで、evaluate data quality transformに移動します。異常検知タブをクリックして、単純に異常検知を有効にします。ルールがある場合は、これだけで済みます。このデモでは、Row Count AnalyzerとColumn Count Analyzerを追加します。すべてのカラムのすべての統計を収集したい場合は、他のAnalyzerも利用可能です。これら2つのAnalyzerでジョブを構築し、保存して、パターンを学習するために少なくとも3日分または3ヶ月分のデータが必要なので、ジョブを複数回実行します。
ご覧のように、ルールは作成せず、Analyzerのみを作成したため、データ品質スコアは0で、ルールカウントとカラム値の2つの統計が収集されています。統計タブをクリックすると、両方の統計と2つの事項が表示されます。1つは値の時間的な推移で、2つ目はルールカウントについて予測している値です。また、データ品質スコアの上限と下限も表示されます。ここで、レコード数が減少し、無効なカラムを含む非常に問題のあるデータファイルを送信すると、すぐに異常が検出され、それに対してアラートを設定できます。
これらの異常を確認する場合は、異常タブに移動して確認できます。異常の内容が明確に説明され、詳細を展開できます。減少したルールカウントがすぐに表示され、それらの異常が検出されます。また、データパイプラインに追加できるルール推奨も提供され、ルール作成プロセスが段階的で非常に簡単になります。最も重要なのは、値が見つかった場合、AWS Glueはそれを通常の操作の一部と考えるということです。確かに異常を検出しましたが、それが異常であり、将来の分析に含めたいかどうかを指定しない限り、システムには分かりません。そのため、その統計または異常を選択して、トレーニングから除外することができます。
選択を行うと、フィードバックに基づいてモデルが調整され、同じ範囲と境界を検出できるようになります。この機能により、ルールベースのデータ品質と異常検知機能を組み合わせることができ、データに対する包括的なデータ品質ソリューションを提供します。
当社のお客様は、この柔軟性とスケーラビリティ、そして何より重要なのは、これを小売のパイプラインに直接組み込めることを高く評価しています。データの読み書きが最もコストのかかる操作であることを覚えておいてください。この方法では、データの集計や変換を行うパイプラインの中にデータ品質チェックを組み込むことができます。ほとんどの場合、データがメモリ上にある状態でこれらの品質チェックを実行するため、非常に効率的なプロセスとなります。また、機械学習ベースのデータ品質とルールベースのデータ品質の両方のパワーを組み合わせることができます。
Vanguardのデータ品質への取り組み
それでは、お客様の一人である Vanguard の Andrew Rife さんにバトンを渡したいと思います。Andrew さんには AWS Glue Data Quality を彼らのプラットフォームでどのように活用しているかをご紹介いただきます。ありがとうございます、Shiv。皆さん、おはようございます。本日は皆様の前でお話しできることを大変光栄に思います。Shiv と Navneet には登壇の機会をいただき、また皆様にはご参加いただき、感謝申し上げます。会場が満席で素晴らしいですね。Swami さん、こちらが本当の基調講演ですよ。冗談です、Swami さん。また呼んでください。
少し思考実験をしていただきたいと思います。もしよろしければ、少しの間目を閉じて、皆さんの組織内で実行されているすべてのデータプロセスについて考えてみてください。かなりの数があると思いますので、抽象的に考えてみましょう。HR、営業、マーケティング、あるいは Vanguard のような投資運用におけるプロセスを考えてください。そして、それらのうち、高品質なデータがあれば恩恵を受けるものの割合を心の中で計算してみてください。ありがとうございます。目を開けてください。
この実験から分かることは、高品質なデータが非常に重要だということです。組織で実行するほぼすべてのプロセスには高品質なデータが必要で、これは私たちの活動の基盤となっています。データ品質を適切に確保できれば、この会議で学んでいる他のすべてのこと、Swami が今話している内容も含めて、実現することができます。そうした取り組みを始めるための強固な基盤を持つことができるのです。皆さんがここにいらっしゃるのは、データ品質が組織にとってどれほど重要かをご存知だからだと思います。また、中には適切に対応できなかった場合の痛みを経験された方もいらっしゃるかもしれません。良くても問題を見つけて修正し、その後始末をするのに何時間もかかってしまうかもしれません。さらに悪いことに、コンプライアンス要件を満たせなかったり、顧客の期待を裏切ってしまったりするかもしれません。
Vanguardでは、このような課題を身近に感じています。私たちの投資システムは高品質なデータによって支えられており、投資業界は規制の泥沼のような状態にあるため、これを正しく行うために多大なエネルギーを費やしています。私たちは数十の異なるマーケットデータプロバイダーからデータを取得しています。また、社内の運用システムから、毎秒、毎分、毎時間と絶え間なく生成されるデータを収集しています。このデータは必ずしもクリーンではなく、タイミングも完璧ではなく、完全でもありません。これから数分間で、この1年間のVanguardのデータ品質に関する取り組みについてお話しさせていただきます。私たちのデータエコシステムとデータの構造について説明し、その後、AWS Glue Data Qualityを活用して構築したカスタムデータプラットフォームについてお話しします。
その前に、手を挙げていただきたいのですが、Vanguardとその事業について聞いたことがある方、あるいは個人の退職貯蓄で私たちのクライアントである方はどのくらいいらっしゃいますか？なるほど、かなりの数ですね。素晴らしい。クライアントの皆様には、将来の重要な部分を私たちに託していただき、ありがとうございます。経済的な自由が皆様にとって重要であることを私たちは理解しており、それがデータ品質を重視する理由の一つでもあります。Vanguardをご存じない方のために、簡単にご紹介させていただきます。Vanguardは世界有数の投資会社の一つです。低コストのミューチュアルファンド、ETF、アドバイス、その他関連サービスを幅広く提供しています。5,000万人以上の投資家を抱え、運用資産額は9.9兆ドルを超え、20,000人以上の従業員（私たちはCrewと呼んでいます）が働いています。
Vanguardはミッション重視の企業です。 私たちの存在意義であるコアパーパスは、すべての投資家のために立ち上がり、公平に扱い、投資の成功に最高のチャンスを提供することです。そして、ファンドの株主やクライアントの価値を追求することに私たちは妥協しません。私はAndrew Rifeと申します。お会いできて光栄です。
私は投資データシステムのChief Technical Advisorを務めています。この会話の理解を深めるために、私たちのデータエコシステムとデータ構造について説明させていただきます。
Vanguardのカスタムデータプラットフォーム「Galileo42」
Vanguardでは、日々高品質なデータに依存しています。私の部門は、それを実現する責任を担っています。私たちはVanguardのデータスチュワードとして、サードパーティからデータを取得し、運用システムから社内データを収集しています。生のデータは、多くの場合、整理されておらず、複雑にネストされています。私たちの仕事は、開発したデータシステムを使用して、データを再構築し、標準化し、重要なビジネスコンテキストで充実させることです。そこから、そのデータは投資判断を可能にし、Vanguardのリスクを軽減し、分析やMachine Learning、その他のデータアプリケーションで活用することができます。
私たちは、データの論理的なグループごとにデジタルプロダクトとして企業全体に提供されるメッシュスタイルのデータエコシステムで運用を行っています。例えば、Vanguardのファンド評価データ、ファンドのパフォーマンスリターン、制裁措置や為替レートに関するデジタルプロダクトなどがあります。私の部門では、組織全体に50以上のデータプロダクトを提供しています。各データプロダクトは、Product Owner、開発チーム、そしてIT部門外に所属する1名以上のData Stewardによって作成・管理されています。このグループが一体となって、データの使いやすさ、アクセシビリティ、品質に責任を持ちます。各データプロダクトには、それぞれ独自の品質基準が設定されています。
これは、私たちのデータエコシステム内で見られる代表的なデータワークフローです。楕円形の各ステージは、データ処理を行うパイプラインの異なる段階を表し、赤い星印はデータ品質の評価ポイントを示しています。ご覧の通り、データ品質の確認は1つのパイプライン内でも一度きりの作業ではありません。このワークフローは比較的シンプルですが、実際にはより複雑になることもあり、ワークフロー間で相互依存関係が生じることもあります。
最初に行うのは整合性チェックです。データが期待通りの形式で、予想される属性をすべて持っているかなど、私たちの期待に沿っているかを確認します。この初期バリデーションは、データ提供者と同じ認識で話ができているかを確認する基本チェックですが、データの正確性や完全性を検証するものではありません。そのためには、データの真偽を確認するより複雑なデータ品質管理が必要になります。
データが世界の他のソースと照らし合わせて正しいかどうかを確認する必要があります。他の提供者から得られるデータと一致しているか？妥当な範囲内に収まっているか？これはVanguardにとって重要なデータ品質の側面です。証券の価格が、私たちがXだと考えている一方で、世界の他の人々がYだと考えているような状況では、責任ある投資判断を下すことはできません。このようなチェックでは、すでに信頼性が確立されているリファレンスデータを品質チェックに組み込んで活用することが多くあります。これは不正確または低品質なデータを特定するための物差しとして機能します。例えば、複数の提供者から同じデータポイントを収集して比較します。2つの提供者が特定のデータポイントで一致しない場合、それは私たちにとって重要な情報となります。
また、特にファンド価格などのデータに対しては分散チェックも実施しています。今日のファンド価格を昨日の価格と比較して変動率を計算します。その変動率を、過去に見られた標準偏差をはるかに超える10％といった、あらかじめ設定された閾値と比較します。変動率が閾値を超えた場合、Data Stewardによるレビューが必要な潜在的な低品質データであることを示します。このようなチェックには、提供者が提供するデータ以外のリファレンスデータが必要となるため、私たちが構築するデータプラットフォームや品質エンジンはこれらの機能をサポートする必要があります。
最後の部分は、完全性と適時性についてです。この側面は重要です。先ほどShivが異常検知やルールベースのデータ品質管理の限界について説明したように、自社内のデータを検証することは比較的簡単ですが、持っていないデータを検証しようとするのは全く別の話です。Vanguardでは、ファンドやETFの市場価格を毎日受け取ることが期待されています。
そのETFは取引されているので、完全なデータセットを受け取れていない場合を把握する必要があります。私たちが構築するデータプラットフォームとその背後にあるデータ品質エンジンは、これらのデータ品質の側面すべてをサポートし、ここで見られるようなワークフローに適合する形で実現する必要があります。これは、毎日または毎月実行される何千ものワークフローの一つに過ぎませんので、スケールの問題も抱えています。
先ほど申し上げたように、私たちは昨年、データシステムのためのデータ品質プラットフォームの問題を本当に解決するよう求められました。 私たちにとって重要だったのは、特定の方法でデータ品質を定義したり強制したりするのではなく、各データシステムが意味のある方法で高品質なデータを利用できるようにする、フェデレーテッドなプラットフォームを作ることでした。彼らは独自のルールを作成し、独自のスケジュールで実行し、データ品質ジョブを独自のスケジュールで実行し、データ品質の結果を彼らにとって意味のある方法で解釈できる必要がありました。さらに、非技術系のData Stewardもそのソリューションの一部となることを望んでいました。
私たちはいくつかのオプションを評価し、 カスタムデータプラットフォームを構築することを決定しました。そして、そのカスタムデータプラットフォームをAWS Glue Data Qualityで動作させることにしました。Galileo42データプラットフォームをご紹介させていただきます。これは内部でAWS Glue Data Qualityによって動作しており、私たちがAWS Glue Data Qualityを選んだ理由は、必要なスケーラビリティを提供し、DQDLによってData Stewardのセルフサービスを可能にし、同じくAWS上に構築された他の多くのシステムやプラットフォームとシームレスに統合できるからです。
Galileo42は、データ管理、パイプラインの可視性、データ品質など、システムの一般的なデータタスクを解決するために調整された、数十の異なるマイクロサービス、データベース、メッセージングコンポーネント、キュー、その他の要素のコレクションです。これはプラットフォームの概念的なビューで、データ品質の側面に焦点を当て、3つのレイヤーに分かれています。 最初のレイヤーはインタラクションレイヤーです。これはData Stewardがルールを作成し、ワークフローに割り当て、データ品質の結果を確認するために使用するレイヤーです。また、データシステムがデータ品質の実行を定義および実行するために使用するデータプレーンとコントロールプレーンのAPIもここに存在します。
次の層はOrchestration層です。数百から数千のワークフローが実行される中で、私たちは1つのデータ品質実行から数百の実行まで、非常にコスト効率の良い方法でスケールできるようにしたいと考えていました。この層には、それらのジョブをキューに入れ、完了までモニタリングするためのメカニズムが存在します。 そして最下層がExecution層です。ここが魔法が起こる場所で、AWS Glue SDKを使用してGlueジョブを実行し、品質をチェックします。また、結果の処理と要約もここで行われます。
実際の動作を見てみましょう。 まず最初に必要なのは、Data Steward、チーム、そしてProduct Ownerがデータ品質の定義を行うことです。彼らはGalileo42データプラットフォーム内でDQDLを使用してこれを行います。すぐに使える標準ルールを使用し、また私たちのデータ品質の成功に大きく貢献しているカスタムSQLも使用します。インターフェース内でこれらの品質ルールを定義し、ワークフローやデータドメインに割り当てることができます。
データは日々、アドホックに、毎日の定期スケジュールで、あるいは月1回など、さまざまなタイミングで入ってきます。データシステムがデータを受け取り、品質チェックを実行する必要がある場合、まずステージングを行います。これは、プラットフォームがアクセスできる形でS3にデータを配置し、データ品質実行がアクセスできるように参照データも含めることを意味します。 その後、Control Plane APIを使用してリクエストを実行し、S3の場所を指定してデータ品質実行を要求します。
これはOrchestrationを通過し、キューに入れられ、モニタリングが設定されます。ここでGlue ETLが起動し、データセットに対してルールを実行して結果を取得します。 これらの結果はプラットフォームによって要約され、Data Stewardが結果に基づいて意思決定を行うために重要なVanguard固有のメタデータで強化されます。そしてEventBridgeを使用して、データシステムに完了を通知します。
データシステムは結果を取得し、意味のある形で解釈して、さらなるアクションが必要かどうか、あるいはこのまま続行して良いかを判断できます。 もし必要であれば、データ品質の問題が見つかり確認が必要だと判断した場合、DataOpsに通知してエスカレーションすることができます。 DataOpsは再びそのインタラクション層を使用して対応し、隔離されたレコードを確認し、失敗の理由を確認することができます。
次の3枚のスライドは、私たちのアプリケーションのスクリーンショットです。これはルールの作成画面で、Data Stewardが作成したルールのリストが表示されており、ルールの名前やデータドメイン、動作など、Vanguard固有のメタデータが付与されています。これらのルールは、ルール違反が発生した際のシステムの動作を決定します。これらのルールはRule Setとしてまとめられ、ワークフローに割り当てられます。
次はパイプラインの可視化画面です。ご覧のように、データサプライヤーから受け取る単一のデータフィードが、データの均質性を高めるために複数のデータパーツに分割されています。これによってデータ品質の管理がより容易になります。下のブランチを見ると、Advisorの評価データが品質の問題で失敗しているのが分かります。このような場合、DataOpsに通知が送られ、システムに戻ってきて失敗した箇所を確認し、対応することができます。
こちらは詳細なデータ品質の結果画面です。実行時のデータの概要が表示され、失敗した行やVanguard固有のメタデータを確認できます。それらの行を開くと、失敗したデータや違反したルールなど、品質チェックの結果を具体的に見ることができます。ここで、私たちが予想していなかった学びや考慮点についてお話ししたいと思います。
最初の点は、プラットフォーム化についてです。データ品質の確認という機械的な作業は、実は全体の半分に過ぎません。それを運用プロセスにどう組み込むかを考える必要があります。データ品質の問題が発生した時、人々はどのように対応すべきでしょうか？長期的な統計をどのように収集し、データ品質を測定し、新しいルールが効果を上げているかを確認するにはどうすればよいでしょうか？カスタムワークフローをどのように構築すればよいでしょうか？これは私たちにとって課題でした。なぜなら、組織によってやり方が異なるからです。私たちは、AWS Glueのコアエンジンを中心にカスタムデータプラットフォームを構築することを決めました。AWS GlueはDQDLを使用してデータ品質管理を非常にうまく行い、技術的な知識を持たないData Stewardもソリューションに参加できますが、それを私たちのワークフローに適合させる必要がありました。
データは多くの場合、高度にネストされており、プロフェッショナルなデータサプライヤーからでも時として整理されていなかったり不完全だったりします。データは変化するものなので、データサプライヤーから受け取るデータには3つの異なるタイプのデータセットが含まれることがあります。このデータを均質なセットに分割することは、私たちにとって非常に有用で、ルールの作成がよりクリーンになりました。結果として、ワークフローの入り組んだネットワークと複数のデータ品質チェックが発生しますが、利点としては、DataOpsが比較的シンプルなルールを作成できることです。なぜなら、データが均質になっているため、あるルールがこの行に適用され、次の行には別のルールが適用されるといった複雑さがなくなるからです。
最後に、検知と防止についてですが、データがデータストアに到達した後に検知することも確かに価値があります。しかし私たちは、ゲートキーパーを設置して防止する方法を選びました。これは、高品質なデータのみが私たちのData Hubsに入り、組織全体に配信されることを確実にするためです。低品質なデータを配信するリスクが私たちにとってあまりにも高かったからです。これは、データのタイムリーさ、データ品質ジョブをいかに迅速に実行するか、そしてデータを可能な限り早くコンシューマーに届けるためにOpsチームにいかに迅速に対応してもらうかといった課題の解決を意味しました。
Shiv Narayanan、Navneet Srivastava、そして私を代表して、本日ご参加いただき、ありがとうございました。アプリ内にアンケートがございます。ぜひ時間を取ってご回答いただければ幸いです。私たちにとって非常に重要です。また、私たちは前方で待機していますので、ご質問がある方や、ソリューションについて詳しくお話ししたい方は、お気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion