re:Invent 2024: AWSのBusiness Data Catalogでデータ活用を民主化
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Demystify and democratize access to your data with a business catalog (ANT202)
この動画では、Business Data Catalogの戦略的重要性とAWSでの実装方法について解説しています。Amazon DataZoneやAmazon SageMaker Data Catalogを活用したデータガバナンスの実現方法が示され、特にBusiness GlossaryやMetadata Formを用いたデータの文書化プロセスが詳しく説明されています。また、Bristol Myers Squibbの事例では、DataZoneを中心としたData Meshアーキテクチャの構築により、18ヶ月未満でAI向けの高品質データプロダクトを5倍に増やした実績や、ServiceNowとの連携でサブスクリプションワークフローの50%以上を削減できた具体的な成果が共有されています。Gen AIを活用したデータ公開・消費の簡素化など、最新の取り組みについても言及されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Business Data Catalogの戦略的重要性と本セッションの概要
皆様、おはようございます。私はLuis Camposと申します。Europe、Middle East、AfricaのData & AI Governance GTM Leadを務めております。本日は、Data GovernanceのPrincipal Analytics Specialist ArchitectであるLeonardo Gomezが私と一緒に登壇いたします。そして後ほど、Bristol Myers SquibbのHaribabu Muppananiが、彼らのData Governanceの取り組みについてお話しいただく予定です。re:inventでは多くのセッションが同時進行していますが、皆様は本セッションを選んでくださいました。ご参加いただき、心より感謝申し上げます。本日ここにいらっしゃる方々は、Business Data Catalogについてより深く知りたいとお考えの方々だと思います。すでに構築された経験がある方、これから構築しようとしている方、あるいは他のシステムから移行を検討されている方など、何らかの理由があってここにいらっしゃるのだと思います。もし間違った部屋に来てしまったと思われる方がいらっしゃいましたら、そのための前置きでした。
本日は盛りだくさんの内容をご用意しております。まず私から、Business Data Catalogの戦略的重要性と、企業戦略における役割について簡単にご説明させていただきます。その後、Leonardoが昨日発表された新機能を含め、AWSでこのソリューションを構築するためのBuilding Blocksについてお話しします。そしてデモンストレーションもご覧いただきます。昨日発表されたばかりの機能が実際に動くところをお見せできるのは、とてもエキサイティングですね。メモを取っていただき、最後に質問がございましたら、Leonardoがお答えいたします。そして、カスタマーの声として、Bristol Myers SquibbのHaribabuが登壇します。彼らは長期にわたって私たちとData Governanceソリューションの開発に取り組んでこられました。昨日、彼らとの長期的な協力関係が発表されたことは非常に喜ばしいことです。Haribabuが初めてre:inventに登壇し、彼らの経験を共有してくださることは、とても特別な機会となります。
考古学とData Scienceの類似点と相違点
私は考古学の大ファンで、近年最も注目すべき考古学者の一人がSarah Parcakです。Sarahが特別なのは、考古学的発見が空からスタートできることに気づいた点です。彼女は衛星画像を使って考古学的遺物を発見する手法の生みの親とも言えます。彼女には、今日の私たちの話題に非常に関連する重要な言葉があります。「考古学において、コンテキストはすべてです。遺物は私たちに過去を再構築する手がかりを与えてくれます。」
では、過去を再構築するという観点から、この画像を見てみましょう。これは実在するものではありませんが、200年後の未来の文明がこの遺物を発見したとして、「これは過去の文明の女神だったのだろう。本と炎を持っていることから、火と知識の女神だったに違いない」と解釈するかもしれません。ここにはコンテキストがありません。これは考古学を始めたときに直面する状況で、徐々に理解を深めていくのです。
考古学とData Scienceには共通点があります。より多くの遺物を発見すれば、それだけコンテキストは豊かになります。同様に、Data Scienceでも、より多くのデータポイントを収集し、より多くのデータの痕跡を集め、より多くのデータセットをSandboxに取り込めば、それだけ豊かになります。これは誰もが同意できる点でしょう。しかし、考古学とData Scienceには興味深い違いが一つあります。
考古学では、発見によってカタログが作られていきます。10年後にこれが見つかるという予測は誰もできません - カタログは最初からあるわけではありません。人々は何を発見するかわからないのです。時には何かを発見し、テクノロジーを使って「これは5000年前のものだ」と判断しますが、その後別のものを発見して、最初の評価が正しくなかったかもしれないと気づくこともあります。このように考古学にはカタログがありませんが、Data Science - これを包括的な用語として使っていますが - では違います。
このData Scienceという包括的な用語には、データ管理やデータに関する科学的な活動全般が含まれますが、これらはカタログなしには成り立ちません。仮説を検証したり、ユースケースを構築したり、アプリケーションを開発したりするために必要なデータを見つけるには、カタログが必要不可欠です。発見はカタログによって可能になるのです。私はこの業界で何十年も（正直に言いたくないほど長く）働いてきて、少なくとも3大陸のお客様を見てきました。率直に申し上げますと、考古学の発掘現場のようにデータを管理している人々もいて、成り行き任せになっています。これこそが、今日私たちが取り組むべき課題なのです。
Business Data Catalogの基本概念と重要性
Sarah Parcakの引用から始めたように、コンテキストが最初に重要です。コンテキストを持つためには、共通言語が必要です。それによって、異なる部門や会社の下位部門に属していても、人々は互いに何を話しているのか理解できるようになります。共通言語は必須であり、皆さんがすでにご存知かもしれませんが、次のステップに進むために、ここで基本的な認識を共有させていただきます。 共通言語には、特定のコンテキストで使用する用語の合意された定義が必要です。この場合、私たちは用語集や語彙について話しています。つまり、何かをカタログ化する前に、その定義が存在していなければならないのです。
特定のコンテキストやドメインで、ある用語が何を意味するのかを人々が理解できるように用語集の用語を定義し始めると、階層構造を作る必要が出てきます。あるものが、あるカテゴリーのサブカテゴリーに属するというような具合です。生物学を考えてみてください。種や亜種のことを思い浮かべてください。実際、スウェーデンの植物学者が最初にこのTaxonomyのコンテキスト、つまり概念を作り出しました。これは用語集の用語の階層構造です。 ここから始めれば順調です。なぜなら、後でこの情報が必要になったとき、カタログ化を始めると、より多くの用語集の用語が必要になり、Taxonomyを異なる方法で整理する必要があることに気づくでしょう。
物事には異なる定義が必要で、エンティティは正式に、そして技術的に定義される必要があります。これは電子的またはデジタル的に管理できるようにするためです。 用語集によって定義された概念を持ち、Taxonomyによって定義された階層構造を持つことはできますが、コンピュータは定義では動作しません。コンピュータはエンティティ、属性、関係性で動作します。そこでOntologyが必要になってくるのです。
例を挙げてみましょう。アメリカのSocial Security Number（社会保障番号）のフォーマット、あるいは世界中のどの国の社会保障番号でも、もしくはあなたの国のものでも構いません。このデータに関連する用語集の例としては、「極めて機密性の高い」または「個人情報」といった用語が挙げられます。Taxonomyの観点では、これはData Classificationに属し、このデータを極めて機密性の高いものとして分類します。Ontologyの観点では、フォーマットを定義し、エンティティの中での位置づけや役割を定めます。この場合、地理的位置を示す部分と、北米の9桁フォーマットのシリアル番号があります。これは「市民」というエンティティの固有の属性であり、Background Checkなどの他のエンティティやプロセスと関連しています。
Business Data Catalogの重要性は、すべてがコンテキストから始まるという点にあります。最初に一連のユニークなデータポイントがあります。実は、妻が会話を始めて質問で終わるとき、最初の数文を聞き逃してしまうことが何度あったか数え切れません。何が気を散らしたのかわかりません。
質問を聞いていなかったことを悟られたくないのですが、的外れな返事もしたくありません。この状況に心当たりがある方は、同じような状況で質問を受ける会社での仕事を想像してみてください。「データはどこにある？コンテキストは？ここで調査が必要だな」と考えることでしょう。
最初に持っているユニークなデータポイントは、より広いコンテキストを提供するBusiness Data Catalogによって強化されるべきです。そしてそれがあってこそ、発見が始まります。すべての情報を持っていない状況に対処することは、単なる職務記述書の要件ではありません - これは日々の実践でなければなりません。より標準化された方法でその発見を行うためのツールが必要です。より豊かなコンテキストを持つことで、より多くの選択肢が生まれます。選択肢が増えれば、魔法のようなものを生み出せます：アクション、アウトカム、結果の関連付けです。これにより、プロセス全体を把握できる素晴らしいループが生まれます。これが必要なデータなので、もう発見は必要ありません。このプロセスを運用可能にすれば、開始に必要なデータがあり、このアウトカムを達成するために必要なアクションが明確になります。
Technical CatalogとBusiness Catalogの違いと構成要素
Catalogには何種類あるのでしょうか？これは私たちがよく受ける興味深い質問です。Business Data Catalogについて話し始めると、人々は通常Technical Catalogを思い浮かべますが、ここでは非技術的な例を挙げてみましょう。そうすれば、後でLeoがより技術的な用語を使用する際に、その類似点が理解できるでしょう。Technical Data Catalogには、それらすべてのエンティティのOntologyが含まれます。これには、テーブルの定義、テーブル間の関係、属性、データ型、長さなど、すべての技術的なデータとそのデータに関連する技術的なMetadataが含まれます。
例えば、元素としての金（Gold）について考えてみましょう。金には原子番号や原子量といった技術的なメタデータがあります。しかし、ジュエリービジネスに携わる人間として、そういった用語を使うわけではありません。新しいメタデータのレイヤーを追加する必要があるのです。Business Data Catalogは、それに基づいて作られた何かを定義するための特定の用語集とタクソノミーをもたらします。これはSilent Discoなので互いに話すことはできませんが、金で作られた何か、例えば結婚指輪やその他の指輪を想像してみてください。ここで私たちは、指輪のデザイン、サイズ、そして10から24までの金のカラット数について話しています。これらは技術的なカタログでは重要ではありませんが、技術的なカタログはこの件に関して非常に重要です。誰も金の指輪がプラスチックや銅で作られているのは望まないでしょう - 金の指輪なのですから、金の特質を期待するわけです。
もう少し掘り下げてみましょう。データソースはマネージドかアンマネージドのいずれかになり得ます。これについては後ほど詳しく説明しますが、まず最初のステップは、技術的なプロデューサーがそのデータをカタログ化することです。より自動化されているほど良いのです。そのため、私はマネージドカタログについて話してきました。時には手動でカタログ化する必要があり、それは恐らくビジネス側のデータセットやデータアセットのプロデューサーの役割となります。彼らがメタデータキュレーションレイヤーをもたらすのです - 金を取り上げ、指輪の特徴を与えるわけです。これらは技術的なメタデータには関係ありませんが、ビジネス面では非常に重要になります。
キュレーションが完了すると - このメタデータのキュレーションには多くのやり取りが必要なので、キュレーションと呼んでいます - それは最終的ではありません。最終的になったら、共有する準備が整い、そこでビジネスコンシューマーを持つEnterprise Data Catalogができあがります。
これで、指輪と金の両方を見ることができるビジネスコンシューマーと技術的なコンシューマーの両方が存在することになります。彼らが何を見たいかによって異なります。しかし、もし金以上の何かについてのコンテキストが必要な場合は、指輪のサイズやカラット数を確認できます。つまり、データセットに関して言えば、技術的な定義から始まり、その後で用語集からのそれらの概念を全て重ねていくのです。例えば、ソーシャルセキュリティ番号かもしれませんが、その属性の上に他のすべてのプロセスや定義を重ねることができます。
さらに金の指輪の例を続けると、ジュエリー業界にいるとして、ビジネスコンシューマーがいます。これらは指輪を販売するB2C領域の人々です。彼らはカタログを見て、在庫供給、デザインカテゴリー、カラット値などの属性に関する情報を探すでしょう。一方で、職人や作業員がいる指輪工場では、人々の購買からのパイプラインを理解し、すべての作業に必要な原材料が十分にあるかを確認する必要があります。異なるユーザーは異なるものを見たり消費したりしますが、カタログは全体として一つとなり、その強力なコンテキストを提供するのです。
Amazon DataZoneとSageMaker Data Catalogの機能と実装
それでは、ビジネスデータカタログの実装方法についてより深く理解していただくために、私の同僚のLeonardoをステージにお呼びしたいと思います。ありがとうございます。どうぞ。みなさん、おはようございます。 Luisありがとうございます。Luisが言及したように、これから私は Technical Catalog と Business Catalog の技術的な側面についてお話しします。また、デモもご用意していますので、理論だけでなく実際の動作もご覧いただけます。私はLeonardo Gomezと申します。AWSのPrincipal Analytics Specialist SAを務めています。
まず、技術系ユーザーについてお話しします。 彼らが必要とするメタデータは、データそのものに関連したものです。具体的に言えば、パーティション、データタイプ、インデックスといった情報が必要になります。データのビジネスケースを理解する必要はなく、データを最適化して共有するために、データがどのように機能するかを理解する必要があります。そのために、AWS Glue Data Catalogがあります。これは5年以上、あるいは10年以上前から提供されているサービスです。マネージドサービスなので、特別な操作は必要なく、構造化データや半構造化データのカタログ化を支援してくれます。
仕組みはとてもシンプルです。 Amazon S3、RDS、Redshiftなどの様々なソース（サードパーティベンダーのソースも含む）があり、Glue Crawlerというオプションを提供しています。これは、それらのソースからメタデータを収集するプロセスで、Glue Catalogにメタデータのテーブルを作成します。先ほど述べたように、そこでは列情報、データタイプ、パーティションなどの情報を確認できます。また、テーブル上でデータ品質チェックを実行するオプションもあります。ここで行うのは、Data Quality Scoreを生成することです。例えばS3上にデータがあり、そのデータに関するメタデータがGlue Catalogにあり、その上でData Quality Scoreを生成できます。この場合、メタデータ情報、実際のデータ、そしてそのデータのステータス（ユーザーが利用可能か、それとも事前にクリーニングが必要か）を確認できます。
実際の画面はこのようになっています。 現在のGlueコンソールでは、一般的な情報（例えば、この場合の入力フォーマットはParquet）を確認できます。このサンプルでは、スキーマ情報、パーティション情報、インデックス情報、ファイルフォーマットが表示され、列に説明を追加するオプションもあります。ただし、この場合は技術的な説明で、開発者やエンジニアがその特定の列をより詳しく理解するのに役立つものです。また、データタイプやアセットバージョンも確認できます。
先ほど述べたように、データ品質情報も確認できます。これは簡単な例ですが、テーブルのパーティションに関するパラメータなど、さらに多くのメタデータを持つことができます。
それでは、Business Userについて説明しましょう。 Business Userは全く異なる特徴を持っています。というのも、彼らはデータ型が何であるかを気にしませんし、何個のパーティションがあるかにも関心がありません。彼らが重視するのは、その情報から得られる価値であり、それを素早く手に入れることです。システムの裏側でパーティションが動いているのは良いことですが、彼らにとってはどうでもいいことなのです。彼らは必要な情報を、しかも素早く手に入れたいと考えているのです。
では、Enterprise Data Catalogが備えるべき主要なコンポーネントとは何でしょうか？ まず、後ほど詳しく見ていくMetadata作成があります。そして、Data Lineageも非常に重要です。データを利用するためには、そのデータがどこから来ているのかを理解する必要があるからです。Data Qualityも極めて重要です。なぜなら、大量のデータがあったとしても、そのデータの質が良くなければ、何の価値も引き出せないからです。また、Business Glossaryもあります。Business Userとしては、そのデータが何のためのものなのかというコンテキストを理解する必要があるからです。さらに、アセットを望む形式で文書化できるMetadata Formや、ドメインも用意されています。マーケティング部門、営業部門、クレーム部門など、異なる部門の人々をData Catalog内で適切に組織化する必要があるのです。
Enterprise Business Data Catalogに対する私たちのソリューションは何でしょうか？Amazon DataZoneは約1年前からサービスを開始し、お客様のデータ組織化を支援する上で大きな成功を収めています。素晴らしいData Meshを構築し、優れた組織化とセキュリティを実現したにもかかわらず、誰も使用しないというお客様の事例を見てきました。なぜでしょうか？それは、そのData Lakeの中身を確認する機会やオプションが誰にもなかったからです。DataZoneが提供する価値は、Data Lake全体を可視化することです。すべてのデータアセットの場所や所有者を確認でき、直接利用することもできます。つまり、企業データを発見できる単一のUIに、すべてを一元化することこそが、このコンテキストにおけるDataZoneの付加価値なのです。
そして昨日発表されたAmazon SageMaker Data Catalogも登場しました。このカタログはDataZoneを基盤としています。そのため、DataZoneが提供するすべての機能は、SageMaker Catalogでも利用できます。体験は異なりますが、コア機能はまったく同じです。
Business GlossaryとMetadata Formについて説明しましょう。これらは非常に重要で、Business Data Catalogには不可欠な要素です。なぜでしょうか？それは、ここにこそ、データアセットについてより深く理解し、コンテキストを得るために消費者が必要とするすべての情報が集約されているからです。
それでは、DataZoneとSageMaker Catalogでこの側面をカバーするためにどのようなコンポーネントを提供しているのかご説明しましょう。まず最初に、Assetについてです。Assetにはテーブル、ダッシュボード、Machine Learningモデル、Gen AIモデルなどがあります。Data CatalogやEnterprise Data Catalogの一部としてカタログ化するすべてのコンポーネントがAssetとなります。
次に、Business Glossaryがあります。先ほど申し上げたように、Business Glossaryはコンテキストを追加します。例えば、テーブルというAssetがあって、そのデータアセットが何に関連しているのかを利用者が理解できるように、用語を追加したい場合などに使用します。
そして、Metadata Formがあります。これは、好きな方法でデータを文書化するのに役立つカスタムフォームです。独自のフォームを作成することができます。例えば、承認者情報や、よく使用されるクエリ、ビジネス上の理由付けなど、データアセットにさらなるコンテキストを提供するために追加したい情報を、Metadata Formを使って追加することができます。
詳しく見ていきましょう。右側にテーブルがありますが、このテーブルを一緒に文書化していきます。まず最初に、Asia、Americas などの異なる地域を含む「region」というBusiness Glossaryがあります。Business Glossary用語をMetadata Formにリンクすることができます。この例では、「sales identifiers」と「asset ownership」という2つのMetadata Formを作成しました。Business Glossaryの「region」をMetadata Formにリンクし、そのMetadata Formをデータアセットの一部として文書化のために追加します。
プロデューサーとして、データアセットを文書化する際には、公開するために真ん中にあるMetadata Formに記入する必要があり、そのMetadata FormはBusiness Glossaryの情報を使用します。2つ目のアプローチは、Business Glossary用語を直接データアセットの一部として使用することです。この場合、データ分類という一般的な例があり、public、confidentialなどがありますが、Business Glossary用語を直接データアセットに割り当てることができます。アプローチ1と2の違いは、Metadata Formは必須にできるため、データアセットを公開するにはMetadata Formに記入する必要がありますが、Glossary用語はオプションだということです。
3番目のアプローチは、先ほどと同じ例で、Metadata FormとBusiness Glossaryが直接アセットに紐づくというものです。アセットが完成すると、アセット自体からのデータ、Glossary用語、Metadata Formからの情報が組み合わさって表示されます。これがデータとAmazon SageMaker Catalogのコンテキストにおいて、データアセットを文書化する正しい方法です。具体的にはこのような形になります。アセットのビジネスラベルやビジネス名があり、上部には関連するGlossary用語が表示され、ソースからの技術的なMetadataも表示されます。データの出所を理解する必要があるため、この情報は必須です。また、先ほど言及したMetadata Formもデータアセットの一部として表示されます。これについては後ほどのデモでご覧いただけます。ご覧の通り、2つの異なるタイプのカタログがあります。技術的なカタログはデータタイプやパーティションに重点を置いているのに対し、こちらはビジネスコンテキストに重点を置いています。
データカタログの重要な側面として、Data Lineageがあります。データの出所を理解する必要があるのです。重要なレポートを作成するためにデータを使用する場合、そのデータが正しいソースから来ていることを100%確信する必要があります。ペルソナに基づいた例をいくつかご紹介しましょう。技術系ユーザーのJuliaはData Engineerで、影響分析を行う必要があります。これは、レポートやアセットを変更する必要があるが、その変更がパイプライン全体にどのような影響を与えるかを理解する必要があるということです。変更したいアセットにアクセスし、そのアセットのすべての利用者と、データの出所を可視化することができます。
これは技術的なユースケースですが、よりビジネス寄りのユースケースとしては、Susanの例があります。Susanは規制上の問題で、特定のカラムの計算方法を確認するよう依頼されました。その数値がどのように計算されているかを確認する必要があります。そのために、Amazon SageMaker Catalogにアクセスし、Lineageダイアグラムでそのカラムがどこで計算されたかを確認できます。技術的な知識が十分にある場合は、特定のカラムの計算に使用されたコードを確認することもできます。
技術系とビジネス系という2つの異なるユースケースがありますが、解決策は同じLineageから得られます。次はData Qualityについてです。先ほど申し上げたように、Data Qualityは非常に重要です。3テラバイトのデータがあっても、データの品質が良くなければ、良い結果は得られません。そのため、優れたData Qualityが必要なのです。
私たちはAWS Glue DQまたはAWS Glue Data Qualityと完全に統合されているため、効果的なData Qualityを提供できます。仕組みとしては、AWS Glueテーブルがあり、そのデータに対してData Qualityジョブを実行してQualityスコアを特定し、そのMetadataを収集してData Catalogの一部として公開します。技術者がこれらのQualityルールを実装し、ビジネスユーザーは意思決定プロセスの一環としてそれらのスコアを確認できます。この機能で私が特に気に入っているのは、ルールごとにスコアが表示されることです。完全性ルールや値ベースのルール、その他実装したルールについて、それぞれのスコアを確認できます。また、一定期間にわたるQualityスコアの変化も確認できます。つまり、Qualityスコアが一貫しているかどうかを確認し、それに基づいてそのデータアセットを使用するかどうかを判断できます。繰り返しになりますが、AWS Glue DQと完全に統合されており、これらのルールは技術ユーザーが実装できます。
では、すべてをまとめてみましょう。 下部に Technical ユーザーと Business ユーザーがいます。Technical ユーザーは、すでにご覧いただいたように、AWS Glue Crawler を使用してソースから Technical メタデータを収集します。これは選択肢の1つで、手動で行うこともできますが、このプロセスを自動化するために AWS Glue Crawler を提供しています。Technical ユーザーまたは Technical オーナーは、すべての Technical メタデータを AWS Glue Catalog に登録します。Technical メタデータにパーティション情報やインデックス情報を追加して充実させ、品質スコアを生成することができます。これらの情報が整ったら、Business ユーザーは Amazon DataZone Catalog にアクセスして Technical メタデータを取得し、ビジネス情報を追加できます。先ほど見たように、データの系統、品質、ビジネス用語集、メタデータフォームがあります。そして、データプロデューサーは、アセットが適切に文書化されたら、それを公開して社内の他のメンバーと共有します。
このような体験を想像してみてください：あなたはデータコンシューマーで、データレイクについて何も知りませんが、売上に関する情報を取得したり分析を作成したりする必要があります。エンタープライズの Business データカタログにアクセスして「売上」で検索すると、売上に関連するすべてのアセットが表示されます。興味のあるアセットを見つけてクリックすると、そのアセットの概要情報が表示されます - ユースケース、最も一般的なクエリ、ビジネス用語集の用語、データの系統、品質などです。品質が良好で信頼できるソースであることを確認し、このアセットを使用するかどうかを判断するために必要な情報がすべて表示されます。すべてが1か所に集約されており、マーケットプレイスのような体験を提供します。必要なものを検索して購読すれば、消費したいアセットを特定するために必要なメタデータとビジネスコンテキストをすべて持った状態で、必要な分析を生成することができます。
理論的な話はここまでにして、デモに移りましょう。 2人のユーザーがいます。1人目は、データオーナーの Leonardo です。
データオーナーとコンシューマーの視点からのデモンストレーション
2人目は、データコンシューマーの Susan をご紹介します。 Leonardo はデータアセットを作成し、ビジネスメタデータを追加し、データアセットを公開し、購読リクエストを承認します。Susan はデータアセットを検索・発見し、それらのデータアセットを購読し、消費します。デモの一部としてこれらのユースケースを見ていきます。
このデモでは、新しい Amazon SageMaker データカタログの一部である新しいUIを使用します。まずは、データアセットを作成する Leonardo から始めましょう。 ここにホームページが表示されています。プロジェクトの「sales」を選択し、「data」に移動します。 上部に Business カタログが、下部に Technical カタログが表示されています。 ここにデータアセットの一覧があります。今日文書化する「total revenue」というアセットを選択します。
まず最初に、「Generate Descriptions」をクリックします。これは、AIを使用して説明文を生成する機能を提供しているためです。クリックすると、ユースケースの説明とアセットのサマリーが生成されます。必要に応じて編集することもできますし、拒否することもできます。今回はこれを承認します。また、データアセットの一部としてREADMEセクションを追加することもできます。ここでは、そのアセットで実行できるサンプルクエリを記載しておきました。次に、このアセットの性質に関連するGlossary用語を割り当てています。この場合、これらのアセットはスニーカーの販売に関連しています。
ここでは、データが格納されているバケットなどの技術情報を含むメタデータフォームを確認できます。ここで、メタデータフォームを追加します。これは、このアセットの公開に関するビジネス承認者についての非常にシンプルな例です。承認日と承認者の名前、アクセスレベルを入力しています。ご覧の通り、すべての情報が文書化されています。先ほど説明したように、AI機能はアセットレベルの情報だけでなく、列レベルのメタデータも生成します。そのデータアセットの各列すべてが文書化されることになります。
完璧ですね。すべての推奨事項を承認することにします - もちろん、必要に応じて拒否することもできます。もう一つの素晴らしい機能はアクセスコントロールです。ここでは、消費のためにデータアセットにどのようなフィルターを適用するかを決定できます。例えば、カテゴリーがスニーカーに等しい場合という行フィルターを適用しています。これにより、このデータアセットの利用者は、スニーカーカテゴリーのみを閲覧できるようになります。次に品質スコアがあります。全体的な品質スコアとルールごとのスコアが表示されます。ここでは、一定期間にわたる品質スコアの変化を確認できます。
私のお気に入りの機能はLineageです。このLineageダイアグラムには、このアセットのソースとして使用する3つのアセットが表示されています。中央には、これらすべてのアセットをマージするために使用したGlue jobが表示されています。そのジョブを使用して作成したデータセットも確認でき、さらにそのアセットがAmazon SageMaker Catalogでカタログ化される様子も見ることができます。必要な情報をすべて揃えたら、データアセットを公開します。公開をクリックすると、そのアセットは社内の他のメンバーが検索できるようになります。完了です。これで公開され、誰でもこのアセットを検索できるようになりました。
ここで、Susanに切り替えて、消費者の体験とデータアセットの検索方法を見てみましょう。今度はSusanのビューを見ています。ここでは、プロジェクト（この場合はマーケティング）を選択し、検索オプションのあるData Catalogの部分を選択します。より詳細な検索機能をご紹介したいと思います。ここには利用可能なすべてのアセットのリストと、使用できるすべてのフィルターが表示されています。Glossary用語でフィルタリングできるのは非常に強力な機能です。なぜなら、データアセットにGlossary用語を割り当てることで、それらの用語を使ってデータアセットを検索できるようになるからです。
Glueテーブルでフィルタリングすると4つの結果が表示されます。Leonardoがドキュメント化したTotal Revenueのアセットを選択します。 ここでは、Data Qualityスコアやデータリネージを含むすべての情報を確認できますが、今回はコンシューマーとしての立場です。 このデータを利用したいので、オーナーにアクセスリクエストを送信します。サブスクリプションの理由を記入してリクエストを送信します。
ここで承認プロセスをお見せするために、プロデューサーの視点に切り替えましょう。プロデューサーのプロジェクト、 Salesに戻り、Leonardoとしてカタログを再度選択します。Subscription Requestというカテゴリーがあります。 ここでサブスクリプションリクエストを確認できます。承認するだけでOKです。リクエストに関連する すべてのメタ情報が表示され、フルアクセスを許可するか、フィルターを適用するかを選択できます。今回は、 先ほど作成したフィルターを適用します。これにより、Susanはスニーカーカテゴリーのレコードのみを閲覧できるようになります。
Susanの視点に戻って、データアセットの利用方法を見てみましょう。Marketingプロジェクトに戻り、DataセクションのAssetタブ、そしてSubscribeタブに移動すると、私のアセットが表示されます。 クリックすると、先ほどと同じ情報が表示されますが、今度はJupyter NotebookまたはSQLインターフェースのいずれかを選択してデータを利用できます。今回は例を簡単にするために、SQLインターフェースを使用します。ここでスニーカーカテゴリーの レコードのみが表示されているのが確認できます。
Bristol Myers SquibbにおけるData Governanceの取り組み
以上が私からの説明です。次は、すでにこのシステムを導入しているお客様に、その経験を共有していただきます。 私はHaribabu Muppananiと申します。Bristol Myers Squibbのデータプラットフォームを統括しています。BMSをご存じない方のために説明しますと、私たちは深刻な病気に打ち勝つための革新的な医薬品の発見、開発、提供に専念するバイオ医薬品企業です。本日は、DataZoneに関する実際の経験と私たちの取り組みについてお話しさせていただきます。私たちは このプロダクトがプレビュー段階だった1年半以上前からこの取り組みに参加しており、おそらく最初に本番環境に移行した企業の一つだと思います。
データガバナンスの話題に入る前に、BMSの組織でなぜデータガバナンスが必要なのかについて説明させていただきます。AIは私たちのビジネスのあらゆる側面を変革しており、その勢いは日々増しています。この分野では多くの活動が行われています。例えば、現在では小分子実験の100%がin silicoスクリーニングから始まります。つまり、どの分子やどの実験を進めるかをコンピューターモデルが判断しているのです。大分子の分野では、全分子実験の25%がAIを通じて実行されています。しかし、AIについて語る際によく言われることですが、AIはそれが依存するデータの質が重要になります。これは本当に重要なポイントです。
このように重要性が高いことから、AIの精度を向上させるためにはデータのガバナンスが不可欠です。そのため、AIガバナンスが極めて重要なのです。ガバナンスというと、一般的に官僚主義や進歩を妨げる遅さというイメージが付きまといます。BMSでは、この概念を見直し、顧客を中心に据えて、私たちにとって真のガバナンスとは何か、そして重点的に管理すべき領域は何かを理解しようとしています。
これらは、過去2年間にわたって顧客と日々協力しながら構築してきた3つの重要な柱です。以前は、中央集権的なData Lakeがあり、顧客へのデータ配信はPoint-to-Pointで行われていました。しかし、Computational Scientistの数が増えるにつれて、彼らのデータへの要求も増大しました。データを見つけることが彼らの最大の課題となっています。データを見つけても、そのアクセス方法や理解の仕方がわからないことが多いのです。AIの世界では、データを見つけやすく、理解しやすく、信頼できるものにするための十分なMetadataを含むビジネスカタログが必要です。私たちはこの領域のガバナンスに多くの時間を費やしています。
2番目の柱はセルフサービスです。データを見つけた後、どのように利用すればよいのでしょうか？機械学習を実行するために、どのようなコンピューティングリソースをすぐに利用できるのでしょうか？また、プロデューサーの観点からは、新しいデータプロダクトを作成するリクエストを受けた際にコンピューティングインフラが必要です。2年前は、アカウントとインフラのプロビジョニングに少なくとも6週間かかっていました。現在では、DataZoneがバックグラウンドで動作するコントロールプレーンを通じて、プロデューサーとコンシューマーの両方に15分以内でインフラを提供できるようになりました。
3番目の柱はデータアクセスに関するものです。現在、ほとんどのデータはサブスクリプションが必要で、誰かが承認してS3バケットにポリシーを適用するというガバナンスプロセスを経る必要があります。バックエンドプロセスは数多くあり、データとコンピューティングリソースを見つけても、承認を適時に得られずに苦労する人が多いのです。私たちはこれらの障壁を理解し、取り除くためにガバナンスを実装しました。2つの重要な点に気付きました。まず、プロデューサーはすべてのデータを管理したがりますが、実際には60%以上のアセットにガバナンスは不要で、使用状況を追跡する監査だけで十分です。例えば、外部データやPIIを含まない内部データには厳格なガバナンスは必要ありません。
コンシューマー側では、すべてのデータへのアクセスを要求することも正しいアプローチではありません。私たちはこの問題に対して、ライセンスや契約要件についてプロデューサーと話し合うことで対処しました。その結果、知的財産、プライバシー規制、コンプライアンスのために本当にガバナンスが必要な領域のみを管理し、その他の領域はより迅速なイノベーションを可能にするために開放することにしました。これは2年間の journey であり、技術だけでは解決できません。人、プロセス、技術を組み合わせた強力なデータカルチャーの構築が必要です。人とプロセスについて話してきましたが、スライドを進めると、 どのようにしてこれを実現したかをお見せできるはずです。これは、1年半前にDataZoneを中心に開発した私たちのGreenfield Data Meshアーキテクチャです。
アーキテクチャの中心部分について見ていきましょう。これは私たちのような中央チームが管理している部分です。Central Hubの主な目的は標準化を構築することです。データの生成、公開、消費に関するベストプラクティスを含め、ProducerとConsumerが従うべき標準化されたプロセスを確立します。また、企業全体のビジネスカタログを管理し、すべてのガバナンスワークフローを一元的に可視化します。さらに、ProducerとConsumerの作業を簡素化する多くのアクセラレーターを提供しています。
Producer側では、データを本当に理解しているビジネスチームと密接に協力しています。彼らは400以上のアプリケーションを扱い、データを使用可能なData Productに変換します。私たちのデータは多種多様で、テーブルだけでなく、シーケンス、画像、X線なども含まれており、それぞれ異なるガバナンスアプローチが必要となるため、Producerに対して選択肢と柔軟性を提供しています。データパイプラインの基本的なスキャフォールディングを備えたインフラストラクチャをワンクリックで提供する一方で、さらなるデータ処理のために独自のツールを持ち込むことも可能です。
Consumer向けには、「彼らのいる場所で対応する」という指針を掲げています。特定のツールの使用を強制することはできません。そのようなアプローチは往々にして失敗するからです。例えば、Amazon SageMakerを使用している人に、Dominoに切り替えるよう依頼することはできません。中央チームの責任は、既存のワークフローに対応しながら、必要なインフラストラクチャを提供し、必要なアクセラレーターを構築することです。Consumerには2つのタイプがあります。データを探索してダウンロードし、NVIDIAスーパーポッドなど自身の環境で使用するクエリオンリーユーザーと、AWSサービスでリアルタイムにデータを使用するユーザーです。
BMSのData Governance実装の成果と今後の展望
クエリオンリーのConsumerに対しては、ドメインごとに共有可能な1つのアカウントを提供します。CPUやGPUのワークロードについては、コストを正確に追跡するために別個のアカウントを提供します。これにより、1から100のConsumerを管理しながら、アカウントの増加を制御することができます。図は単純に見えるかもしれませんが、これはDataZoneとBMS独自のエンジニアリング開発を組み合わせることで、摩擦のないエコシステム体験を実現している強力な仕組みを表しています。
ビジネス用語集に関して、中央の1か所で1人の担当者がビジネスカタログを管理することは不可能です。規制コンプライアンス、プライバシー、データの所在地など、企業レベルの要件には、それぞれ独自のメタデータを持つ横断的な組織が関与します。しかし、真の発見は、企業が指示できないローカルドメインから得られるメタデータを通じて行われます。この責任は、ドメインチームに委譲する必要があります。
例えば、Biomarkerデータの場合、それがどの患者コホートから得られたものか、どの研究に属するものかを知る必要があります。データを有効活用するためには、どの適応症に関するものか、どの人口統計に属するものかという情報も必要です。このような情報を提供できるのは、データに近い立場にいる人々だけです。そのため、エンタープライズではなく、データオーナーにその部分の所有権を持たせることが重要なのです。私たちは、データを管理・保護する水平組織と呼ばれるものを所有していますが、すべてのデータがすべての水平組織の成熟度サイクルを経る必要はありません。
私たちは、緩やかな成熟度ライフサイクルを作成しました。成熟度レベル1は、ドメイン内でローカルに共有されるデータで、基本的なメタデータセットが必要です。シルバーレベルでは、データが複数のビジネスドメインをまたがり、検証情報を含みます。ゴールドレベルでは、データは会社全体向けに作成され、規制情報も含まれます。私たちは、メタデータを段階的に完成させることで信頼を構築しています。ゴールドレベルを維持することを強制することは決してありません。
過去2年間でDataZoneとAWSサービスを使って達成したことは非常に大きいものです。 以前は、分析のために異なるドメインのデータを統合することは、多大なリソースと煩雑な手続きを必要としました。このDataZoneの実装により、すべてのアカウントを単一のマーケットプレイスに統合し、ユーザーは1つのドメインでデータを購読し、消費プロジェクトに追加できるようになりました。例えば、DC youthのケースでは、Large Moleculeドメインからのモノクローナル抗体と、Small Moleculeドメインからのサイトトキシックペイロードとリンカーペイロードを即座に取得して分析を実行できます。
明確なビジネスコンテキストについてはLuisとLeoが説明しているので、ここでは触れません。 私たちのCustomer-Producerフィードバックプロセスを通じて、18ヶ月未満でAI向けの高品質データプロダクトを5倍に増やすことができました。これは重要なマイルストーンです。ドメインごとにビジネスライン全体を編成し、分離することができるようになりました。 それらをFinsモードに移行することで、コストの動向やビジネス価値の創出方法を明確に理解できます。 ServiceNowでサブスクリプションワークフローを使用し、新しいAdvanced Metadataルールのリリースにより、AWSサービス外の承認ワークフローを50%以上削減しています。
今後の展望として、私たちはDataZoneをバックエンドとして使用し、その上に多数のフロントエンドソリューションを構築しています。例えば、DataZoneのOAuthプロセスを経るデータAPIを構築し、それをバックボーンとして様々なアプリケーションを提供しています。ディスカバリーレイヤーをデータだけでなく、 分析データプロダクトにも拡張しています。Gen AIを使用してデータの公開と消費を簡素化しており、スキャフォールディングを行う必要はなく、話すだけで完全なデータプロダクトラインのコードを生成します。DataZone上でデータとのチャットを可能にする多くの実証実験に成功しています。 最後に、アクセスガバナンスをコード化して、誰もが簡単にアクセスできるようにしています。皆様、ありがとうございました。短い Lightning Talk でしたが、ご質問がありましたら、ここにいますのでお気軽にお声がけください。ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion