re:Invent 2024: AWSがDataZoneの新機能と活用事例を紹介
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Explore what’s new in analytics and governance (ANT303)
この動画では、AWSのData and GovernanceのプロダクトヘッドであるShikha Vermaが、Amazon DataZoneの最新機能と活用事例を紹介します。DataZoneを通じたデータの民主化とガバナンスの統合、Data Lineage、Data Products機能などの詳細なデモに加え、CiscoのOutshift部門とThe Weather Companyによる実践的な導入事例が共有されます。特にThe Weather Companyでは1日1,500億件の気象データリクエストを処理する環境で、Data Gov Opsという概念を確立し、プライバシーレビューの効率化やプロダクト意思決定の加速を実現した具体的な成果が語られます。また、次世代Amazon SageMakerとの統合による新しいデータ分析基盤の展望も示されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
AWSのAnalyticsとガバナンスセッション：概要と議題
みなさん、ようこそお越しくださいました。VenetianからMandalay Bayまでは大変な道のりだったと思いますが、Analyticsとガバナンスの最新情報をお聞きいただくためにお集まりいただき、ありがとうございます。私はAWSのData and Governanceのプロダクトヘッドを務めるShikha Vermaです。本日は、まもなく登壇していただく2人の大切なお客様をお迎えしています。CiscoのShaja Arul Selvamani氏とThe Weather CompanyのTravis Smith氏です。両社についてはみなさんよくご存じだと思いますが、CiscoやThe Weather Companyをご存じない方はいらっしゃいますか？誰もいませんね。そうだと思っていました。
本日は盛りだくさんの内容をご用意していますので、早速始めさせていただきます。まだ到着される方もいらっしゃると思いますが、遠方の方のためにVenetianでもパラレルルームを設けています。この会場まで足を運んでくださり、ありがとうございます。ライブの観客の方々と直接お会いできるのは本当に嬉しいです。まず、AWSの全ての活動の基本となる「お客様の声」から始めます。ご存知の通り、私たちはお客様とお客様のニーズに徹底的にこだわり、そのニーズを満たすための技術ソリューションを開発しています。
次に、AnalyticsとDataガバナンスの最新情報についてお話しします。数年前にローンチしたAmazon DataZoneから始めて、基調講演でお聞きになった方もいらっしゃるかもしれない新しい発表内容に移ります。Data Lineage、Data Products、そして過去1年ほどの間にリリースした新機能についてお話しします。その後、私が最も興味深いと考える、システムの動作の実際のデモをエンドツーエンドでご覧いただきます。そして、CiscoとThe Weather Companyのお客様事例へと移ります。コンテンツは40-45分程度で終了する予定ですので、Q&Aの時間を十分に設けています。ぜひQ&Aにもご参加ください。最後に写真撮影の時間も設けており、皆様にステージにお上がりいただいて一緒に写真を撮りたいと思います。
データドリブン経営の現状と課題：Amazon DataZoneの紹介
それでは、お客様の声から始めましょう。 調査によると、お客様はますますデータドリブンになることに投資を増やしているようですが、皆様の場合はいかがでしょうか。組織の82%がCDOを任命しているとのことですが、CDOがいらっしゃる組織の方はどのくらいいますか？かなりいらっしゃいますね。94%の組織が2023年と2024年にデータ投資を増やしているそうですが、皆様の組織も該当しますか？多くの方がそうですね。データインサイト主導のビジネスは20%の収益成長を達成しているとのことですが、皆様の組織はいかがでしょうか？何人かの方がそうですね。
おそらく、これが難しい理由は、74%のビジネスが投資を成果に結びつけることができていないからではないでしょうか。だからこそ、私たちは今ここに集まっているのです。私はデータアナリティクスのライフワーカーです。お客様として皆様が直面されているのと同じ課題を追い求めて長年過ごし、8年前にそれらの問題を解決するソリューションを開発するためにAWSに入社しました。これは簡単な道のりではありません。
では、エンタープライズのお客様は何を求めているのでしょうか？多くの皆様は、ガバナンスを組み込んだ形でデータの民主化を実現したいと考えています。この考えは理解できますか？この説明は分かりますか？はい、手を挙げてください。理解できますよね？皆様は、ガバナンスを本来の業務とは別のものとして扱いたくないのです。データを民主化したいけれども、ガバナンスコントロールを可能な限り簡単に組み込みたいと考えているのです。
では、コンポーネントの観点から見ると、これは何を意味するのでしょうか？組織全体のデータを発見し、理解し、アクセスする能力が必要です。皆様の多くはAWSにデータを持っているからこそ、ここにいらっしゃるわけですが、ほとんどの方がAWS以外にもデータをお持ちですよね？AWS以外にデータをお持ちの方はどれくらいいらっしゃいますか？ほぼ全員ですね？つまり、これはAWSだけを対象に解決できる問題ではないのです。エコシステムとして、皆様のために機能するエコシステムを作る必要があります。
次に、複数のペルソナが同じデータの問題に協力して取り組める必要があります。Data Scientist、Data Analyst、Data Engineerなど、発見してアクセス権を得たばかりの同じデータに対して、全員が作業できる必要があるのです。 そして、使いやすいツールが必要です。時にはAWSのツール、時にはAWS以外のツールです。多くの方がTableauやSpotfire、ETL用のInformaticaなどを使用していますよね？AWS以外のツールを使用されていますか？
その課題も解決する必要があります。また、多くの方が単一のインターフェースを通じたセルフサービスを望んでいます。 これが理想的な状態です。すべてのユーザーが1つの場所にアクセスし、そこから適切なペルソナに対して適切なツールセットで、すべてのデータにアクセスできる。 そして、ツール、データ、データにアクセスする人々を同じ方法で一貫して管理できる、というのは理にかなっています。
これが、私たちが数年前にAmazon DataZoneを発表し、展開した理由です。 DataZoneを使用したことがある、または知っている方はどれくらいいらっしゃいますか？ご存じない方のために説明すると、これは組織の境界を越えてデータのカタログ化、発見、共有、ガバナンスを行うためのサービスです。Data MeshやData Fabricと呼ばれるものですが、データは組織全体の複数のサイロに存在しており、それらを統合したいと考えています。これを実現するための architectural paradigmは複数存在します。DataZoneを使用すれば、集中型でも分散型でも、それらを実現できます。DataZoneが可能にするのは、データプロデューサーとコンシューマーを結びつけ、プロデューサーが組み込みのコントロールとデータ契約を持つデータを共有し、コンシューマーが自分の選択したツールでデータを利用できるようにすることです。
Amazon DataZoneの機能と活用事例：デモンストレーション
2023年10月にDataZoneのGA（一般提供）を発表して以来、あらゆる業界セグメントの何千もの企業がDataZoneを使い始めています。何百万ものアセットがカタログ化され、ガバナンスが適用され、30の新機能を含む新しい機能セットを継続的にリリースしています。ロゴの中に皆さんの会社は見つかりましたか？CiscoとThe Weather Company以外の企業の方は手を挙げていただけますか？来年はきっと、皆さんの中から新しいロゴが加わることでしょう。
2024年の主要な新機能についてご説明しましょう。 まず、説明文を自動生成するGenerative AI機能を追加しました。これは、データアセットのテーブル内容を分析し、ビジネスアナリストが理解しやすい説明文を自動生成する機能です。この機能のデモをお見せする予定です。また、データ品質メトリクスを統合しました。AWSシステムを使用している場合でも、InformaticaやTalendを使用してデータ品質を管理している場合でも、APIやインターフェースを通じて簡単にアクセスできるように統合されています。
きめ細かなアクセス制御により、データウェアハウスやデータレイク全体で行レベルや列レベルのフィルタリングが可能になりました。この機能は他のサービスではあまり見られないものです。次の機能は、ビジネスユニットやドメインユニットでの組織化です。営業部門、マーケティング部門、財務部門など、それぞれが異なるポリシーに従う必要がある場合、データドメインを個別に設定できます。このような分離を行った後、データプロダクトを作成できます。データプロダクトでは、テーブル、ダッシュボード、SQLスクリプトを組み合わせて、組織内で共有することができます。また、サブスクリプションワークフローを追加し、データ管理や承認プロセスをより柔軟に設定できるようになりました。
では、デモでお見せしましょう。昨日と今日のMattとSwamiによるKeynoteをご覧になった方はどのくらいいらっしゃいますか？多くの方がご覧になったようですね。Amazon SageMakerと次世代SageMakerについてお聞きになったと思います。すべてを統合するという方向性は皆さんの心に響きましたか？もちろん、DataZoneはこの統合とローンチの基盤となっています。これからお見せするデモは、実際にSageMaker次世代版のデモになります。
TableauやClickなど、BIツールをお使いの方はいらっしゃいますか？ほとんどの方がお使いですね。JDBC検索機能を追加したことで、DataZoneで管理されているデータを、お好みのツールで利用できるようになりました。これは非常に興味深い機能で、お客様からも大変好評です。また、セマンティック検索も追加しました。これにより、利益に関連するデータを探す場合、テーブル名や列名の単純な構文検索だけでなく、関連データセットも検索できます。例えば、「利益」で検索すると、収益データや利益計算に使用できる関連テーブルが表示されます。
さらに、その全てに Amazon Q を追加しました。Amazon Q をご存知の方はどれくらいいらっしゃいますか？私たちが追加したデータとのチャット機能では、「スニーカーの売上を見たい」と言うだけで、どのテーブルを使用し、どのメトリクスを適用すべきかを示してくれます。そしてそのデータを使ってモデルを作成することができます。Amazon Q は、私たちの作業を本当に加速化しています。また、Data Lineage の一般提供も発表しました。現在 Data Lineage をお使いの方はどれくらいいますか？何人かいらっしゃいますね。Data Lineage が欲しい方は？みなさんですね。AWS エコシステム全体でご確認ください。現在は自動化された形で提供しています。DataZone の機能を使用すると、全ての Glue パイプライン、Redshift データ、Spark ジョブなどの自動化された Lineage が得られます。
次世代Amazon SageMakerとDataZoneの統合：モダンなデータ基盤の構築
ここで終わりでしょうか？かなりの作業量に思えますね。2024年にこれだけのものをローンチするだけでも大変そうですが、私たちはここで止まるつもりはありません。なぜなら、次のステップに向けて構築を進めているからです。すでにご存知の方もいらっしゃると思いますが、私たちはモダンなデータ基盤を構築しています。つまり、これらの機能を全て統合しているのです。最初のスライドで説明した5つの課題に戻って考えると、これは4層のケーキのようなものです。ケーキの一番下の層は、データウェアハウス、Data Lake、オンプレミスの Teradata、その他どのようなオンプレミスのデータストアソリューションであっても、全てのデータストアです。
その上に統合データガバナンスが来ます。AWSの内外を問わず、全てのデータに対する統合データガバナンスが必要です。さらにその上では、クエリ、ETL、分析、ダッシュボードの作成、モデルの作成など、様々な目的でこのデータを使用できる必要があります。ケーキの上位2層では、私たちが提供する全てのツールを使用して、目指す成果を生み出すことができます。これが私たちの目指す方向性であり、昨日のCEOキーノートで発表した次世代の Amazon SageMaker が登場した理由です。
データ分析とAIのセンターである Amazon SageMaker は、先ほど説明した4層のケーキ全体を統合したスイートです。 そのセンターとなるデータとAIのガバナンス部分は DataZone 上に構築されています。先ほど説明した機能や、この数年間にローンチした全ての機能が、この統合スイートで利用可能です。昨日ローンチしたばかりの新しい統合 Studio をチェックしていただくと、データ基盤の機能が全て組み込まれており、さらにデータの使用方法、活用方法、体験方法に関して多くの機能を追加していることがわかります。このスクリーンショットでは（これは後ほどデモでもご覧いただけますが）、DataZone で導入したプロジェクトとデータカタログのコンセプトが統合 Studio で利用可能になっているのがわかります。Megan のようなユーザーがアクセスして、様々な機能を利用できるデータカタログを閲覧することができます。
Megan のようなユーザーがデータカタログにアクセスすると、統合 Studio 内で直接 Data Lake やデータウェアハウスのデータを使用してチャットアプリケーションを作成できる GenAI プレイグラウンドを利用できます。この Studio には、Redshift クエリエディター、Amazon Glue による ETL 機能、そして SageMaker の既存のモデル構築機能が全て含まれています。全てが Amazon DataZone で導入したガバナンスフレームワーク内に統合されており、データのカプセル化が私たちが導入したプロジェクトのコンセプトに従っているため、非常に強力なものとなっています。
ガバナンス構造はビジネスドメインごとに整理されており、各ドメインの下で複数のプロジェクトを運用しながら、データとツールの一貫したガバナンスをこれらのコンセプトを通じて維持しています。 画面に表示されているように、ドメインごとにアセットを閲覧でき、 Studioのインターフェース内で直接サブスクライブすることができます。これにより、データアクセス権限のための外部ワークフローを開始する必要がなくなり、すべてをStudio内で処理できます。 誰もが必要とするデータリネージ機能もStudioに組み込まれています。 さらに、後ほどデモをお見せするGen AI機能も完全に統合されています。
Ciscoの事例：Data Meshを活用したイノベーション促進
データアセットのページを見ると、Amazon.comの商品詳細ページのように、製品に関するすべての情報が表示されます。このアセット詳細ページには、モデル、ダッシュボード、データを含む、すべてのデータ、ML、AIアセットに関する包括的な情報が表示されます。これを活用して、プロデューサーとコンシューマーが交流しデータを共有できるデータマーケットプレイスを作成しています。 デモの準備はよろしいでしょうか？ みなさんがついてきているか確認させてください。理解できている方は「わーい」と言っていただけますか？
これらの機能が実際のユースケースでどのように機能するか、デモンストレーションをお見せしましょう。営業部門のLeoというデータオーナーと、マーケティング部門のSusanというコンシューマーがいます。Leoが環境にデータアセットを公開し、Susanがそれを見つけて使用します。 Leoは一番上に表示されている営業プロジェクトにアクセスします。プロジェクトをクリックして、 ここでデータを確認できます。 プロジェクトカタログで、すべてのデータをナビゲートできます。収益データを探しているので、その収益項目をクリックし、 ここにある総収益を具体的に選択します。
アセットをクリックすると、AIによって生成された説明が表示されます。AIはカラムの説明とテーブルの内容を分析して、この特定のアセットに含まれているものを説明します。 システムは、データをさまざまな目的でどのように使用できるかを詳しく説明する説明文を生成します。コンシューマーのSusanのために、READMEファイル、用語集、メタデータフォームを追加して、より詳細な情報を提供することができます。Studio内でデータを見つけやすく、使いやすくするために、用語集の用語を選択してデータを分類します。下部には技術的なメタデータが表示され、Amazon Glue データカタログと情報から自動的に統合された技術的な詳細が表示されます。
アセットには追加のメタデータフォームを追加できます。この場合、サブスクリプションワークフローで使用される業務承認要件を追加したいと思います。 このメタデータフォームを必須にすることで、この特定のデータセットへのアクセスを要求する人が必要な情報を提供しなければならないようにできます。
カラムレベルの詳細を見ると、すべての説明文が自動生成されています。必要に応じて編集することもできますが、コードによって説明文が生成されることで、ゼロから作り直す必要がなく、単に編集するだけで済むため、大きな時間の節約になります。
この部分が特に気に入っているのは、Studioのインターフェースから直接、ロールレベルのフィルターを作成できるからです。この特定のアセット、つまりRevenueテーブルに対して、特定のスニーカーカテゴリーに制限をかけています。特定のユーザーにこのデータセットへのアクセスを許可する際、例えば「あなたはNorthwest地域の担当者なので、Northwestのデータだけを見ることができます」というように制限をかけることができます。このようなロールレベルのフィルタリングは、サブスクリプションリクエスト自体の中で行うことができるため、現在多くの人々が行っているような複数のビューを作成する必要がありません。私たちはバックグラウンドでこれを処理し、Amazon Lake Formationの権限も管理しています。バックグラウンドでは、AWS Glue Data CatalogとLake Formationを使用して、この権限を実装しデータセットに適用しています。
ここでは、このデータセットがどのように作成されたかという系統（Lineage）を確認できます。データセットは右側にあり、これを作成するために3つの異なるテーブルが使用されたことがわかります。AWS Glueのデータパイプラインを通過して、そのアセットが生成されました。私たちはこれらすべてをモニタリングし、データをカタログに公開することができます。データセットがカタログで利用可能になると、Susanがそれを検索してサブスクリプションをリクエストできるようになります。これでLeoの作業は完了したので、次に進みましょう。Total Revenueテーブルが利用可能になっているのが確認できます。
Susanは自分のメインページから始めます。上部では、彼女はMarketingプロジェクトにいます。データアセットを検索し、「Total Revenue」や「Revenue」など、必要なキーワードで探すことができます。システム内で見つけることができます。検索には多くのファセットがあり、様々な条件で絞り込むことができます。また、セマンティック検索も追加されているので、様々なアイテムが表示されます。もし「Profit」と入力した場合は、さらに多くの関連項目が表示されたはずです。
彼女は検索結果に満足し、探していたものを見つけました。Leoが追加した詳細な説明のおかげで、このデータをどのように使用できるかを簡単に理解することができます。彼女はLineageを確認し、問題ないと判断して、そこにあるボタンをクリックします。画面上では小さくて見づらいかもしれませんが、実際にはSubscribeボタンで、クリックするとバックグラウンドでアクセスリクエストのワークフローが生成されます。このリクエストは承認のためにLeoに戻されます。
現在、このような作業は Service Now や Jira などのツール外で管理されています。皆さんも独自のワークフローを複数の場所で管理されていることと思います。しかし、ここではそれらがすべて組み込まれています。Leo が自分の Sales プロジェクトに戻ると、いくつかの承認リクエストが保留中であることがわかります。サブスクリプションリクエストを確認すると、Susan がこのデータへのアクセスを要求していることがわかります。クリックしてその場で承認することができます。承認すると、Lake Formation 内でデータへのアクセス権限を管理します。AWS で構築したすべての基盤を活用して、このワークフローを非常に簡単に実現しています。
さて、承認が完了したので、Susan は同じインターフェースに戻ります。彼女は好みのツールでこのデータを使用したいと考え、プロジェクトに戻ってデータブラウザで、先ほど探していた特定のテーブルへのアクセス権が付与されていることを確認できます。売上合計の項目がここにあり、クリックして確認すると、複数の異なるツールで閲覧・分析するオプションが表示されます。管理者が Amazon Athena と Jupyter Notebook の使用を許可しているため、それらのオプションが表示されています。これらを使用してクエリを実行できます。ここでクエリを生成すると、行レベルの制限として適用されたカテゴリがスニーカーだったため、スニーカーのデータのみが表示されます。このように、エンドツーエンドのワークフローがとても簡単になりました。画面が小さくて見づらかったかもしれませんが、ぜひ実際に Studio を試してみてください。非常にパワフルで、これらの機能をすべて統合しているので、自分で構築する必要がありません。皆さんに試していただいて、ご意見をいただけることを楽しみにしています。
これによってどのようなことが可能になるのか、どのような機能を追加すべきか、皆さんのご意見をお聞きしたいと思います。簡単な説明でしたが、お役に立ちましたでしょうか？ありがとうございます。では、Cisco のアナリティクスとデータガバナンスの取り組みについて、Shaja をステージにお招きしたいと思います。
The Weather Companyの挑戦：膨大な気象データの管理とガバナンス
皆さん、こんにちは。Shikha さん、素晴らしい紹介とデモをありがとうございます。私が所属する Cisco の事業部門である Outshift の文脈で、彼女が話した内容に関連する実際の経験を共有したいと思います。Outshift はイノベーションに焦点を当てた事業部門です。Outshift は Cisco のイノベーションハブと考えてください。比較的新しい事業部門で、既存の隣接ビジネスや新しい垂直市場向けの新しいアイデアやプロトタイプの開発におけるイノベーションに主に注力しています。私はこの事業部門でデータサイエンスの取り組みの一部を率いており、私たちが直面している課題、得られた教訓、そして DataZone をどのように活用しているかについて共有したいと思います。
re:Invent で多くの友人に会いました。人々と出会いネットワークを築くのに素晴らしい場所です。データの管理方法について尋ねたところ、SharePoint を使用している人もいれば、Data Warehouse、Data Lake、Lake House を使用している人もいました。これは多くの方々の状況と共通していると思います。Outshift に限らず、どの組織でもデータは本質的にサイロ化されています。私の場合、何かイノベーションを起こそうとすると、ルーターからのデータ、アプリケーション層で動作するビデオストリーミングアプリケーションからのデータ、仮想化データを生成する特定のコンポーネント、そして温度測定や計測に関連する物理層のデータなどを扱う必要があります。データは本質的にサイロ化されており、これは多くの組織に当てはまることです。
データを分断したいと思う人はいませんが、革新的なことをしようとすると、生データは分断され、大きな障壁となってしまいます。これは私が目にしてきた問題の一つで、多くの同僚や友人からも同様の声を聞いています。二つ目の問題は、イノベーションを行う際、データには独自のガバナンスの課題が伴うということです。特定の目的でしかデータを使用できない、あるいは他者と共有できないといった制限があったり、ロールレベルやカラムレベルでの複雑なガバナンスルールやポリシー、時にはPIIの編集に関する規則などが存在したりします。
三つ目の課題は、私たちが今、誰もが機械学習を行っているGenerative AIの世界に生きているということです。多くの場合、これらのML活動は分断され、何が構築されているのか、どのように構築されているのかを発見、共有、理解することが非常に困難です。結果として、多くの人々が微妙なアプローチの違いだけで同じことに取り組み、貴重なリソースと時間を無駄にしている状況に陥ってしまいます。これらが私たちが journey を始めた時に直面した三つの主な課題です。Generative AIに基づく最先端の製品を開発しようとする際、これらの課題にどのように対処できるかを検討しました。 広範な調査、文献研究、相談を重ねた結果、私たちが行き着いたのがData Meshと呼ばれるものでした。Data Meshについて聞いたことがある、または使用している方はどれくらいいらっしゃいますか？多くの方がご存知で、私の説明が楽になりそうですね。他の方々のために、Data Meshがどのように役立つのか、改めて説明させていただきます。
Data Meshの第一の原則は、ドメインの所有権です。誰かがルーターや特定のハードウェアからシミュレートされたデータを作成する場合、他の人が使用するためにそれをコピーして共通の場所に置く必要はありません。Data Meshでは、データを生成する人がそれについて最もよく知っており、所有権を持っているため、理解が不十分で維持に苦労するエンジニアにデータを渡す必要はありません。所有権は、データを生成し、それについての深い知識を持つ人々に与えられます。
第二の原則は、データをプロダクトとして扱うことです。多くの場合、人々はデータのコピーを作成して渡し、それが古くなってしまいます。Data Meshが提唱するのは、適切なドキュメント、説明、メンテナンス、継続的な更新を伴うプロダクトとしてデータを扱うことです。プロダクトがその品質と使用成功によって評価されるのと同様に、データを単なる副産物ではなく、プロダクトとして扱うという考え方です。これにより、人々はその価値を理解し、最大限に活用することができます。
次の原則は、セルフサービスプラットフォームでデータを利用可能にすることです。これは Amazon DataZone が有効だと考える点です。データを実践で使用したい場合、人々は広範な学習やドキュメントを読む必要なく、すぐに使用できるようにすべきです。データが自立的に提供されることを可能にする必要があります。最後の要素は、前のスライドで強調された課題に対応するものです - Federated Computational Governanceです。データが分散していても、全員が好きなように扱えるわけではありません。分散した方法で管理できる共通の原則が必要です。
これまでに挙げた課題を解決するために、私たちはData Meshの4つの原則を実装することが革新につながると考えました。 そこで、いくつかのユースケースでAmazon DataZoneの利用を開始しました。ここでは、いくつかのユースケースについて簡単にご紹介したいと思います。また、他の選択肢についての調査研究や、なぜこのソリューションに至ったのかについても、詳しくお話しできればと思います。
具体例を挙げて説明させていただきます。あるAnalystが、特定のビデオストリーミングアプリケーションが想定された帯域幅でストリーミングせずにクラッシュする原因を理解したいと考えているとします。このエラーは、アプリケーション層、仮想化層、ルーター設定、あるいはルーターファンのオーバーヒートといった物理的なハードウェアの問題など、様々な層で発生する可能性があります。このようなエラーをデバッグするには、アプリケーションデータだけでは不十分で、根本原因を理解するためにはアプリケーション層、仮想化層、ネットワーク層、物理層にまたがるデータが必要になります。これまでは、異なる担当者から許可を得る必要があり、時間がかかっていました。その後、様々な形式のデータを集めてダッシュボードを作成し分析を行う必要がありました。しかし、先ほどお見せしたようにAmazon DataZone上にData Meshを実装した後は、このような複雑なプロセスを経る必要がなくなりました。
現在では、Analystはカタログを見るだけで、異なる層にまたがる必要なデータを、重複してコピーすることなく検索できます。データは元の場所に保持されたまま、1か所から効率的にアクセスでき、特定の問題の原因を診断する作業を迅速に進めることができます。
この図で説明しようとしているのは、左側にあるプロデューサー側の部分です。アプリケーションログ、ルーターログ、物理層のログ、システムログなど、様々なプロデューサーを想像してください。これらのログは異なる形式で生成されます。私たちはAmazon Glueカタログとその組み込みの自動データ品質チェック機能を活用しています。誰かがそれらのログファイルへのアクセスを提供する際、Amazon DataZoneの機能を使用してデータの完全性と充足度を確認します。
このデータは、異なる部門が管理する複数のクラウドアカウントにまたがる、様々なオーナーによって生成され所有されています。1つのプロデューサーや、複数の人が関わる1つのアカウントである必要はありません。これらのデータはすべて、Amazon DataZoneカタログを通じて一元的に利用可能となり、そこで検出可能性が実現されます。デバッグに興味のあるAnalystは、このカタログで全体のデータ状況を把握し、許可を要求し、それらのデータポイントを購読して、問題を迅速に診断するためのアクセス権を得ることができます。
最後のユースケースは、従来型の機械学習モデルやLLMのファインチューニングを行いたいData Scientistに関するものです。これまでの機械学習のライフサイクルは、先ほど説明したアナリストの journey に似ていました。Data Scientistは様々なデータにアクセスしようとし、モデルの異なるバージョンを作成し、ベンチマークを行い、限られた可視性とアクセスで一箇所に保管していました。現在は、分散型データ管理により、Data Scientistは異なる形式のデータを扱うための革新的な機能を手に入れています。データはプロダクトとして管理され、非常に高品質に維持されており、Amazon DataZoneとAmazon SageMakerの連携により、モデルの可視性が一から開発するのではなく、再利用に興味のある全ての関係者に提供されています。
私たちはAmazon DataZoneの利用を開始し、これまでのところ、イノベーションを加速する上で素晴らしく興味深い journey となっています。それ自体が魔法のように機能するわけではありませんが、データとイノベーションを結びつける架け橋として機能しています。ここで、The Weather Companyから興味深いストーリーを共有していただくため、Travis Smithさんをステージにお招きしたいと思います。
The Weather CompanyにおけるAmazon DataZoneの導入効果
私の名前はTravis Smithです。The Weather Companyで働いています。皆さんはThe Weather ChannelやWeather.comとしての方が馴染みがあるかもしれません。私たちはWeather UndergroundとUnderground.comも運営しています。規模感をお伝えすると、1日に1,500億件以上の気象データリクエストを処理し、250億件の予報を生成しています。また、毎日約400テラバイトのデータを取り込んで処理しており、1ヶ月で数ペタバイトに達します。いくつか質問させていただきたいのですが、皆さん昼食を済ませたばかりだと思いますが、どうか反応をお願いします。プロダクトに携わる方々として、データチームに「あの1回のミーティングで話したデータが必要なんだけど、どこにあるのか、誰に聞けばいいのかわからない」と言ったことがある方はどれくらいいらっしゃいますか？
よくある質問ですね。上級リーダーや経営陣から「なぜそのデータを取得するのにそんなに時間がかかるの？なぜ5分以内に教えられないの？」と聞かれた経験がある方はどれくらいいますか？データチームは、まるで何かを作り上げてほしいかのような質問を頻繁に受けます。私たちにとって、Amazon DataZoneは大きなゲームチェンジャーとなりました。全チームにわたる膨大なデータの管理、カタログ化、ガバナンスをシームレスに行うことができ、より迅速なインサイトの獲得とコラボレーションの改善を実現しました。データへのアクセシビリティが向上したことで、4億5000万人のユーザーへのスケーリングにおいて極めて重要だった、より文脈に即した、パーソナライズされた予報インサイトをこれまで以上に迅速に提供できるようになりました。
この問題を見たとき、私たちには3つの課題がありました。1つ目は、エンタープライズデータカタログとデータ用語集です。何百万、何十億ものデータポイントやデータ要素があるのに、データセットの見つけ方がわからないという状況を想像してみてください。まるで世界最大の図書館にカタログシステムがないようなものでした。データ用語集の管理にスプレッドシートを使用していたため、責任の重複や責任の押し付け合いが発生していました。また、データの出所、つまりデータが様々なシステムをどのように移動するのか、データの系統、そして法的コンプライアンスを確保するための信頼性と透明性の確保にも取り組みたいと考えていました。私たちは自分たちのデータで何が起きているのか把握できていませんでした。これは、雨粒が雲から地上に落ちるまでの journey を追跡し、その進行を予測しようとするようなものでした。DataZone以前は不可能でした。
データの探索は非常に重要な側面でした。誰もが自分のデータを探索し、何が起きているのか知りたいと考えています。私たちは、それをすべての人が可能になるようにしたいと考えました。プロダクトの担当者は、素晴らしいアイデアがあってもそれを証明し、正当性を示すためのデータが必要なのに、そのデータがどこにあるのか分からないという問題によく直面します。私たちは、BIアナリストやData Scientistだけでなく、そういった人々にもデータ探索を可能にしたいと考えました。
私たちには様々なユースケースがあります。Legalやプライバシー部門の人々は、ビジネスを可能にし保護するための技術的なソリューションを探しています。彼らは私たちを危険から守り、荒天から保護してくれる守護者です。彼らの保護なしでは、何も不可能です。彼らはデータがどこにあるのかを調べ、データフローを確認し、どの製品がどのデータを使用しているのかを常に確認する必要がありました。以前は、データの伝送パターンや特定のデータセット、テーブルを特定するために技術チームに相談する必要がありましたが、今では彼ら自身でこの情報にアクセスできるようになりました。
プロダクトチームは次の製品や機能を計画するイノベーターです。彼らは特定の決定を下すために、時にはリアルタイムで素早く答えを得られるようにブロックを解除される必要があります。Data Stewardは品質のチャンピオンとして、すべてのデータがシステム全体で適切に整理され、文書化されていることを確認します。System Ownerは技術的な専門家で、誰よりも自分のデータについて詳しいものの、Data Engineeringに関しては技術的な能力が高くない可能性があるため、私たちに依存しています。BIやデータの利用者は、経営陣が必要とするインサイトを生み出すために、クリーンなデータへの迅速なアクセスを必要としています。
アーキテクトとして、私は詳細な図が大好きです。この図では、私たちはData Gov Opsと呼ぶものを作成しました。MLOpsやData Opsを超えて、これは私たちがデータガバナンスと運用効率の分野を統合していることを表現する方法です。この図では、私たちはData Meshではなく、Data Fabricとして示されています。
図が似ているのは、プロデューサーとコンシューマーがいるからです。Data Fabricは、脳が体に送る信号や神経との関係における脊椎のようなものです。脳は意思決定者やBIのようなもので、体の他の部分はコンシューマーとプロデューサーのようなものです。すべてのデータは脊椎を通って流れます。同様に、私たちの場合も、すべてのデータは単一の方向に流れ、単一の場所に存在しますが、プロデューサーとコンシューマーは自律的に活動できます。集団的な側面と自律的な側面があり、私たちの全体的な目標は、人々がブロックされることなく、必要なときに必要なものを必要な方法で取得できるようにすることです。
右下には、自社および外部のデータソースがあります。Weather.comやアプリケーション、そして私たちのサードパーティパートナーがそれにあたります。これらのデータは、ストリーミングやバッチ処理を通じて、Data LakeやData Warehouseに送られます。そのデータは、Blue Ocean Data Governanceアカウントを通じて共有・管理されます。Data Meshのように自身でデータプロダクトを扱える能力のあるチームがある場合、私はこれを疑似Data Meshと呼んでいます。つまり、上部のプロデューサーが直接Data Governanceアカウントにデータを送信するような形です。しかし、実際には当社では、プロデューサーは右側のData Warehouseにデータを送り、そこからガバナンスを通過し、コンシューマーは常にData Governanceアカウントを通じてアクセスする仕組みになっています。
私たちは複数のビジネス成果を達成しました。チームに対する一元的な監視とアクセスを可能にしました。これにより、もはやスプレッドシートを使用して互いの作業を妨げ合うことはなくなりました。代わりに、完全に文書化され、有効化されたシステムを使用しています。データソースのオーナーが、誰がいつアクセスできるかを管理できるようになりました。次に、プライバシーレビューの効率化を実現しました。OneTrustや他のガバナンスシステムを使用する場合、各システムの技術責任者は多くの質問に答えて承認する必要がありましたが、Amazon DataZoneを使用することで、データフローに関するプライバシーレビューは、各技術チームが行っていたような詳細なレベルでは不要になりました。
その代わりに、DataZoneに入って用語集を確認し、使用方法やLineage、可視化を見て、自分で質問に答えることができます。これにより、アーキテクトである私の時間も、より詳細な定義を行う技術リーダーの時間も節約でき、大きな成果となっています。さらに、プロダクトの意思決定と統合も加速しました。プロダクトリーダーは、データが存在するかどうか、そしてグラフを提供できるかどうかを確認するために、データ担当者に問い合わせる必要がなくなりました。
私が最も気に入っている技術的成果は用語集です。メディア企業である私たちは、GDPR、CCPAなどのプライバシー規制によって厳しく規制されています。何年もの間、Google Sheetsで公開用語集を管理していましたが、DataZoneが発表されたことで、それから脱却できたのは素晴らしいことでした。様々なデータガバナンスの連携を通じて、オーナーがアクセスを公開・制御できるようになり、チーム間のデータアクセスが容易になりました。PII/SPIを含む様々なデータシステムについて話す際、必要なアクセス権限のみを付与することができます。全員がアクセスする必要はありません。経営陣は必ずしもアクセスする必要はありませんが、パーソナライゼーションやセグメンテーションのために、データサイエンティストは匿名化または仮名化された形でデータを活用できます。
最後に、多様なデータソースのオンボーディングを実現しました。私たちが直面していた大きな課題の一つは、データ量による解決策の選定でした。多くのソリューションがコスト面で制限があり、そのコストでも必要な機能をすべて備えているわけではありませんでした。私たちは100% AWSネイティブな環境で運用しており、DataZoneを活用することで、すべてのソースをクロールおよび取り込むことができ、まったく問題なく実現できました。
そして最後に、タグ付けのガイドラインを確立することが重要になりました。Team Aが「データが欲しい」と言ってきて、Team Bも「データが欲しい」と言ってきたけれど、実は同じデータだった…そんな経験はありませんか？このタグ付け、ガバナンス、分類体系、説明文によって、誰かがデータを必要とする時に、そのデータが何を意味するのか、どこにあるのかを全員が理解できるようになりました。「誰に聞けばいいんだろう？」から「DataZoneで調べればいい」という状態に変わったんです。
The Weather Companyの今後の展望とセッションの締めくくり
先日、Enterprise Data Architectと話をしていた時のことです。ある特定のデータがどこにあるのか、ふと質問してみたんです。すると彼は私を見て「DataZone」と言っただけで立ち去りました。私自身がDataZoneの構築と設計に関わり、常に新しい可能性を追求しているにもかかわらず、ビジネス全体でDataZoneを使用する必要があることを、自分自身に改めて思い出させなければならなかったんです。近道は許されないということですね。
これが私たちの今後数ヶ月のロードマップです。現在、Data Gov Opsを組織全体の中核的な規律として確立する過程にあります。Amazon SageMaker Unified Studioの導入と進捗状況にも非常に期待しています。現在はConsumer Teamでのみ採用されていますが、Weather Sciencesにも展開していく予定です。The Weather Channelと言えば、天気予報や気象データを思い浮かべますよね。それがビジネスのもう一つの側面で、そちらも取り込んでいきたいと考えています。そこでは400以上のソースを取り込んでおり、そのData Lineageは非常に複雑です。
システムをOpen Lineageと完全にネイティブ互換にして、データの可視性と観測性を確保し、さらにDataZoneの様々な機能や他のAWSサービスとの統合を進めて、完全なデータの民主化とセルフサービス機能を実現したいと考えています。そして終わる前に、楽しい自撮りを一枚撮らせていただけますか？パートナーの皆さんも、こちらに来ていただけますか？もう少し近づいていただいて大丈夫です。手を振ったりポーズを取ったりしましょう。素晴らしいですね。それでは、Q&Aに移りたいと思います。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion