re:Invent 2024: AWSが解説 DynamoDBのzero-ETL統合機能の詳細
はじめに
海外の様々な講演を日本語記事に書き起こすことで、隠れた良質な情報をもっと身近なものに。そんなコンセプトで進める本企画で今回取り上げるプレゼンテーションはこちら！
📖 AWS re:Invent 2024 - Deep dive into Amazon DynamoDB zero-ETL integrations (DAT348)
この動画では、Amazon DynamoDBのzero-ETL統合機能について詳しく解説しています。ETLパイプラインの構築・保守に多くの時間を費やしている現状の課題に対し、AWSが提供するzero-ETLソリューションによって、データの取り込みやレプリケーションを自動化できることを説明しています。DynamoDBからAmazon Redshiftへのデータ連携は15-30分以内に完了し、Amazon OpenSearch ServiceやSageMaker Lakehouseとの統合も可能です。特に新しく発表されたLakehouse統合では、データのアンネスト機能やApache Icebergインターフェースのサポートにより、より柔軟なデータ活用が実現できます。CloudWatchを使った監視機能やクロスアカウント機能など、実用的な機能も備えており、運用負荷を大幅に軽減できる点が強調されています。
※ 動画から自動生成した記事になります。誤字脱字や誤った内容が記載される可能性がありますので、正確な情報は動画本編をご覧ください。
※ 画像をクリックすると、動画中の該当シーンに遷移します。
re:Invent 2024関連の書き起こし記事については、こちらのSpreadsheet に情報をまとめています。合わせてご確認ください！
本編
Zero-ETLの概要と本セッションの目的
みなさん、こんにちは。Amazon DynamoDBのzero-ETL統合についてお話しするDAT348へようこそ。私はAWS GlueのPrincipal Product ManagerのSean Maです。zero-ETLを担当しています。本日は、DatabasesチームのPrincipal Solution ArchitectであるDavid Gardnerと一緒に進行させていただきます。
始める前に、皆様が適切なセッションにいらっしゃることを確認させてください。会場の皆様にお聞きしたいことがあります。組織のETLデータ移行パイプラインの構築を担当されているData EngineerやArchitectの方は、手を挙げていただけますでしょうか？ かなりの数の方がいらっしゃいますね。最後の質問です。ビジネスの取り組みをサポートするために、複数のデータソースを1つの場所に集約する必要がある方は何人いらっしゃいますか？会場の皆様全員ですか？素晴らしいですね。まさに今日お話しする内容がそれに関することなので、適切なセッションに来ていただいたと思います。
zero-ETLについて、以下の内容をカバーしていきます。これはAmazon DynamoDBで数年前から提供している機能ですが、さらに機能を追加しています。まず、zero-ETLで何ができるのかを簡単に説明し、その後、利用可能な機能についてより詳しくお話しします。Davidがアーキテクチャと具体例について詳しく説明します。最近、zero-ETLとDynamoDBに関して複数の新機能がリリースされましたので、それらについても触れていきます。最後にデモを行い、まとめに入ります。時間が許せば質疑応答も行いたいと思います。
データ駆動型ビジネスの課題とZero-ETLソリューション
お客様の間で、どのような傾向が増えているのでしょうか？多くの企業が、パーソナライゼーション、マーケティング最適化、IoTなど、幅広いユースケースにおいてデータ駆動型になることを目指しています。より効果的に事業を進めるためにデータが必要となるシナリオは数多くあります。ビジネスがより早く洞察を得られるよう、そのデータを変換する必要があります。特に生成AIの登場により、単一のソースからのデータだけでは十分ではないというのが課題です。多くの場合、モデル開発やモデルのトレーニング、幅広い分析を行うために、複数のソースからデータを集めて一元化する必要があります。データの更新頻度が高く、常に変化している状況では、最新の推奨事項や分析を提供するために、最新バージョンのデータを確保したいものです。
では、どうすればよいのでしょうか？通常、次のステップは独自のETLパイプラインを構築することです。これは先ほどのアンケートで多くの方が確認されたことだと思います。現在Amazon DynamoDBを運用ベースで多用されているお客様であれば、よく見覚えのある光景でしょう。最初のステップはそのシステムからデータを取り込み、ビジネスアプリケーションロジックを適用し、追加の変換を実行し、エラー処理を確実に行うことです。それが完了したら、パイプラインのデプロイ、スケジューリング、メンテナンスが必要になります。これには特定のスキルセットと、このプロセスを理解している専門チームが必要です。もちろん、カスタムビジネスロジックやより複雑な処理が必要な複雑なシナリオの場合など、これが正しいアプローチとなる場合も多々あります。
お客様とお話をする中で分かってきたのは、作業時間の25%以上が、単にデータを取り込んで目的の場所に移動させたり、他の人がデータウェアハウスやData Lakeでデータを活用できるように、データを複製して確実に表示されるようにすることに費やされているということです。高度な変換処理はほとんど行っていません。一部のユースケースでは、達成しようとしている目的に比べて、日々の運用とメンテナンスの負担が大きすぎることがあります。常に多くの人員が監視やメンテナンスを行う必要はなく、シンプルに設定して後は放っておけるようなものが望まれています。 これこそが、AWSがZero-ETLの未来に投資している理由です。この取り組みは、re:Invent 2022でAuroraとRedshift間の最初のZero-ETL機能をリリースしたことから始まりました。2023年から2024年にかけて、DynamoDBからAmazon OpenSearch Serviceへの連携など、さらに多くのZero-ETL機能をリリースしてきました。最近では10月に、DynamoDBからAmazon Redshiftデータウェアハウスへの連携も発表しました。
この概念をさらに説明すると、Zero-ETLはAWSが完全に管理するデータパイプラインのセットで、データの取り込みやレプリケーションといった一般的なユースケースにおいて、ETLパイプラインを構築する必要性を最小限に抑えます。DynamoDBからデータを取得し、そのデータの更新を常に反映した複製コピーを保持することが目的であれば、Zero-ETLは非常に適した選択肢となるでしょう。
Zero-ETLの全体的な目標は、トランザクションデータ、運用データ、アプリケーションデータを一箇所に集約し、分析や機械学習をより簡単かつ迅速に実行できるようにすることです。 DynamoDBや先ほど言及したAurora RDSなどのAWSデータソースだけでなく、Salesforce、SAP、ServiceNowといったアプリケーションもサポートしており、さらに新しいSageMaker Lakehouseもサポートしています。これはデータを一元化するためのもう一つの選択肢となります。
Zero-ETLのメリットには3つの重要な側面があります。1つ目は俊敏性の向上です。AWSがETLパイプラインの構築、保守、更新を担当するため、チームはビジネスに必要な変換作業に専念できます。新しいプロジェクトを見ると、システムへのデータ取り込みを心配する必要がなくなったため、さまざまな組み合わせを試すことができます。効率性に関しては、すべてクラウドベースでPay-as-you-goなので、入力されるデータと出力先に書き込まれるデータのコストだけを考慮すればよいのです。サーバーレスサービスとしてクラウドで実行されるため、スケールの心配も必要ありません。
最後に、データは一元化された目的地に配信され、さらに重要なことは、一元的に管理され、セキュアであるということです。Amazon RedshiftやLakehouse、Amazon OpenSearchと連携できるAWSサービスであれば、ほぼ即座にそのデータを活用できます。データへのアクセスがはるかに容易になります。以上が簡単な概要説明でしたが、ここからはDavidに引き継ぎ、Zero-ETLのアーキテクチャについてより詳しく説明してもらいます。
DynamoDBとAmazon Redshiftの特徴とZero-ETL統合
はい、Sean、ありがとうございます。そして本日ご参加いただいた皆様、ありがとうございます。それでは、アーキテクチャについて見ていきましょう。 DynamoDBは長年存在していますが、改めて確認させていただきますと、DynamoDBはAWSが提供するマネージドNoSQLサービスです。あらゆる規模で高いパフォーマンスを発揮し、サーバーレスで、セキュリティと回復性が組み込まれており、常に最新バージョンをご利用いただけます。1秒あたり数トランザクションという小規模な処理から、先日のPrime Dayでamazon.comをサポートした1秒あたり1億4600万トランザクションという大規模な処理まで、柔軟にスケールします。
多くのお客様がDynamoDBを運用データベースとして使用されており、Key-Value形式のルックアップで数ミリ秒という応答時間でGetやPut操作を実行できます。セッション状態の管理をはじめ、様々な運用データベースのユースケースにDynamoDBが活用されています。 次に、Amazon Redshiftについてお話しさせていただきます。RedshiftはAIを活用したフルマネージドのクラウドデータウェアハウスです。トランザクションデータ、クリックストリーム、IoTテレメトリーなど、様々なデータセットを1つのウェアハウスに集約し、それらのデータセット全体にわたってクエリを実行して重要なインサイトを見出すことができます。これこそがRedshiftの本質です。つまり、あらゆる場所からのデータを1つの集中管理されたSQL基盤に取り込み、そこからインサイトを引き出すことができるのです。データ共有機能、使い慣れたSQLインターフェース、自己学習・自己チューニング機能を備え、大量のデータに対する高い同時実行性を実現し、データの成長に合わせて文字通りスケールします。さらに、Redshiftにはサーバーレスオプションもご用意しています。
これは、それぞれのテクノロジーが独自の目的を持っているということを示しています。先ほど説明したDynamoDBは、組織やアプリケーションの運用面を担当します。フロントエンドアプリケーション、Eコマースウェブサイト、ゲームのユーザーインターフェースなどがこれに該当し、ビジネスサイドではその運用データから分析を行いたいというニーズがあります。商品やゲームの販売状況、どのユーザーがどのゲームをプレイしているかなど、運用データからインサイトを得たいというわけです。私も理解していますが、確かに多くの要素があります。
この課題に対処するアーキテクチャの一つが、Command Query Response Segregation（CQRS）です。運用データベースを管理しながら、その上でレポーティングや分析を行うという古典的な課題に対応します。このアーキテクチャでは、これらの処理を別々のストリームに分離することで、分析クエリの実行が運用データベースシステムに影響を与えないようにします。運用タスクの迅速な実行は誰もが望むところであり、このアーキテクチャがそれを実現します。
運用面を分離することで、Amazon API Gatewayやその他の運用フロントエンドを通じたAPIは、Amazon DynamoDBからの信頼性の高いデータ配信を実現します。この例では、DynamoDB Streamsを使用して、分析目的の他のターゲットシステムにほぼリアルタイムでデータを送信しています。Seanが言及したAmazon OpenSearch Serviceは、このDynamoDB Streamsを使用してデータを送信します。Amazon S3のような他のリポジトリは、より分析的なユースケースに適しています。数秒以内のニアリアルタイムな更新は必要なく、15分程度のバッチ処理という低コストなオプションで十分な場合もあります。
DynamoDBのデータレプリケーションパイプラインについてお話ししました。中央の大きな赤いボックスは、データエンジニアが従来行ってきた差別化されていない作業を表しています。以前は、夜間に実行されるバッチETLプロセスが、誰かが新しいカラムを追加したときに壊れることがあり、エンジニアは翌朝のレポート作成に間に合うようにETLプロセスを修正しなければなりませんでした。これは本当に差別化されていない重労働であり、AWSで追加している Zero-ETL 機能が解決しようとしている課題です。DynamoDB Streams、Amazon S3、AWS Lambda、そして分析ターゲットへの接続があります。この場合は Amazon Redshift ですが、他の分析ユースケースもあり得ます。
ここで Zero-ETL ソリューションの魔法が登場します。セットアップが簡単で、管理が容易で、パワフルな分析を可能にします。これこそが、皆様の作業を楽にするために私たちが目指していることです。ETLパイプラインを心配する代わりに、ビジネスアプリケーションやユーザーにとってより価値のある機能に集中できます。朝食のパンケーキの例えを使うのが好きなのですが、この場合、私たちがパンケーキを作ります - お客様は必要な数を言うだけで、私たちがお届けします。
DynamoDBからAmazon Redshiftへのエンドツーエンドのレプリケーションは通常15〜30分以内に完了します。ほとんどの分析ユースケースでは、数分でデータが到着するこのスピードで十分機能します。規模に関しては、Seanが言及したように、これはすべてバックエンドでサービス提供されるため、DynamoDBテーブルと連携して、変更の速度に応じて必要なだけパイプラインをスケールアップします。複数のDynamoDBテーブルから単一のRedshiftクラスターにデータを取り込むことができます。これは、DynamoDBでは結合できない複数のテーブルを持つお客様のよくある要望に対応しています - Zero-ETLを使ってRedshiftにデータを送り、好きなだけ結合操作を行うことができます。
これらのパイプラインの設定方法をコンソールで実際に見ていきましょう。これは約1ヶ月前に一般提供が開始されました。まずDynamoDBコンソールから始めます。メニューに新しく追加されたIntegrationのドロップダウンがあります。まずそこをクリックしてIntegrationを作成すると、ドロップダウンにAmazon RedshiftとAmazon OpenSearch Serviceが表示されます。Redshiftは分析ユースケース向け、OpenSearchは検索機能が必要な場合に使用します。例えば、レンタカー会社が利用可能なTeslaを検索したい場合などです。
例えば、今日フランクフルトで利用可能な赤いTeslaを全て検索したい場合、そのような検索機能はAmazon OpenSearchが適しています。DynamoDBはキーバリュー検索であり、OpenSearchのような検索機能は提供できません。同様に、Amazon Redshiftの場合、先月フランクフルトで特定の価格帯で何台の車をレンタルしたかを分析したい場合、Redshiftで素早く簡単に調べることができます。これはDynamoDBの得意分野ではありません。
Amazon SageMaker LakehouseとZero-ETL統合の新機能
次に、ソースを選択していきます。今回の場合はDynamoDBを使用しますが、ブラウザ上でDynamoDBのテーブル一覧から選択していきます。 この操作を行うと、適切なIAMポリシーがないことを示すウィンドウがポップアップします。皆さんご存知の通り、中括弧や角括弧、コンマを使ったJSONの記述は楽しいものですよね。このサービスがそれを代わりに行ってくれます。これは、サービスチームがこのプロセスの一部として組み込んだ素晴らしい機能です。「Fix it for me now」ボタンをクリックしましょう - これは私たち全員にとって非常に便利な機能です。では、修正ボタンをクリックし、DynamoDBテーブルを選択して、nextボタンをクリックします。
これで、Zero-ETL統合の詳細が表示されました。一般設定が確認でき、取り込みからデータベースを作成して、素早く簡単に稼働させることができます。これを自分で実装しようとすると必要な作業 - Lambda関数の作成、一時的なS3バケットへのデータ配置、DynamoDBストリームからのデータ取得など - すべてがここで魔法のように処理されます。 次に、ターゲットを選択します。ここでRedshiftデータウェアハウスを選びます。特筆すべき点として、多くのお客様は運用用のAWSアカウントと分析用のアカウントを分けて持っています。この機能は、データを別のAWSアカウントに移動することを標準でサポートしているため、私たちが余計な作業をする必要がなく、分析データの利用がとても簡単になります。
データ自体について説明しましょう。 DynamoDBは、テーブルについて考えるとき、より柔軟なコンテナのようなものです。パーティションキーを持ち、NoSQLソリューションとして、すべての行が同じ属性を持つ必要のない列を追加できます。一方、Redshift側は明確に異なります - 同様にテーブルを持ちますが、列指向のデータウェアハウスなので、データの保存方法が全く異なります。DynamoDBでは属性を持つアイテムと呼び、Redshiftでは列を持つテーブルと呼びます。 DynamoDBにはパーティションとソートキーがあり、Zero-ETLプロセスの一部として、これらをDynamoDBからRedshiftに引き継ぎます。
DynamoDBテーブルの他の属性は、RedshiftではSUPERデータ型として取り込まれます。これは基本的にネストされたJSONで、文字型大容量オブジェクトのようなセットアップです。このSUPERデータ型にはすべての属性が含まれます。これは、DynamoDBテーブルの異なるアイテムや行の間で属性が変化する可能性があるため必要となります。 ベストプラクティスと考慮事項として、「Fix it for me now」ウィザードは素晴らしい機能です。IAMポリシーを書く心配がなく、クロスアカウント機能もすぐに利用できるからです。
ここまでお話ししたDynamoDBからRedshiftへの機能は、すでに数ヶ月前からご利用いただけます。 火曜日には、多くの発表があったと思います。その中には、Amazon SageMaker、新世代のAmazon SageMakerプラットフォームがあり、お気に入りのサービスをStudioという統合された体験にまとめています。 さらに、Lakehouseについてもお話ししたいと思います。これは新しいデータの目的地となります。重要なポイントは、Zero-ETLとLakehouseの組み合わせにより、データウェアハウス、データレイク、DynamoDBのような運用データベース、そしてアプリケーションのデータを一つの場所に統合できることです。Lakehouse自体がオープンで相互運用可能、そして安全であることを確保するのが目標です。
データを保存する際、Redshift管理ストレージのメリットとS3のスケーラビリティを兼ね備えた単一のコピーとして保存されます。データの保存場所を一箇所に集約できるのです。さらに、このデータは基本的にLake Formationによってガバナンスが行われています。
このガバナンスは、AWS Glue Data Catalogを通じてメタデータがカタログ化されることで補完されています。これにより、データへのアクセスが容易になり、セキュリティポリシーの定義が簡素化される一方で、複数のサービスからの利用が可能になります。アクセスに関して、後ほどデータ取り込みのためのZero-ETLについて詳しく説明しますが、Lakehouse自体は標準的なApache Iceberg APIインターフェースを通じてアクセス可能です。つまり、Icebergを理解できるサービスであれば、そこに保存されているデータにアクセスできるということです。
Zero-ETLの概念とDynamoDBの機能を組み合わせて、 新しい機能としてAmazon DynamoDBとAmazon SageMaker Lakehouseの間のZero-ETL統合を発表しました。この機能の目的は、本番環境のワークロードに影響を与えることなく、データを利用可能にするために、データのレプリケーションと取り込みのニーズを簡素化することです。これは継続的な更新で実現でき、進行中の運用に影響を与えることなく、単一のデータコピーが挿入、更新、削除を一箇所で受け取ることができます。主な目的は、このユースケースにおける日々の運用負担を軽減することです。
では、この新しいローンチによって実現された変更点や改善点について説明し、その後Davidが実際のデモをお見せします。まず、Zero-ETLが拡大していることがわかります。 最初にAmazon DynamoDBがあり、また別のZero-ETLローンチで言及したアプリケーションも追加されています。Amazon DynamoDBに焦点を当てると、 お客様に好評な「Fix it for me」機能を引き継いでいます。今回の違いは、Amazon Redshiftをウェアハウスとして選択するだけでなく、Lakehouse内のカタログを選択することでLakehouseを目的地として指定できることです。「Fix it for me」機能は、必要なIAMパーミッションを判断し、設定の誤りを検出した場合にそれを適用します。
Lakehouseの目的地に関するもう一つの改善点として、 新しい出力設定があります。これらの設定により、データに対して限定的な変換を実行できます。Davidが言及したように、以前のデータはキーと値のペアを持つネストされたJSONでした。現在は、ネスト解除のレベルを指定する選択肢があります。最上位レベルだけを解除するか、さらに深く進むか、あるいはすべてのデータを解除して、行と列で簡単にアクセスできる形式でLakehouseに保存することができます。
この画像を見ると、Davidが先ほど説明した微妙ですが重要な違いがあります。その違いは、Lakehouseではデータレイクとして保存されているため、SUPER型が利用できないということです。そのため、SparkエンジンやAmazon Athenaなど、他のシステムから読み取る際に簡単にアクセスできるように、データをアンネストして定義することがより一般的です。Lakehouseでアンネストされた形式でデータを保存できるため、他のシステムは自身でデータをアンネストする心配をせずに活用できます。
Zero-ETL統合のデモンストレーション
残りの統合プロセスは、Davidが先ほど示したものと似ています。セキュリティ暗号化モード、アプリケーション設定、この統合に付ける名前を指定できます。Zero-ETL統合の作成手順を簡単に説明すると、まず先ほどと同様にソースを定義し、次に新しいLakehouseターゲットを定義します。アンネストをオプションとして含む出力フォーマットを選択し、暗号化設定を構成します。レプリケーション設定は、ほとんどのお客様が分析に使用している15分がデフォルトとなっています。これでアプリケーションの作成は完了です。実際には3つのステップだけです：ソースの定義、ターゲットの定義、設定の定義を行えば、アプリケーションが作成できます。
しかし、皆さんはまだ半信半疑かもしれませんので、実際のデモをお見せしましょう。WiFiの問題に備えて、ここに録画しておきました。それでは早速、DynamoDBから始めていきましょう。
Zero-ETLを有効にするには、いくつかの前提条件があります。最初の前提条件は、DynamoDBテーブルのPoint-in-time Recoveryを有効にすることです。ここにTransactionテーブルがありますが、Point-in-time Recoveryが有効になっていないことがわかります。Point-in-time Recoveryの編集をクリックして、Save Changesをクリックして有効にします。
TransactionテーブルからLakehouseにデータを送信するための次の前提条件は、権限に関するものです。Permissionsをクリックします。選択するシステムに応じて、GlueとRedshiftがDynamoDBテーブルにアクセスできるようにするResource Policyが必要です。PrincipleとしてRedshiftとGlueを指定し、Describe TableとExport Point-in-time機能の権限を含むResource Policyを作成します。これらはすべてドキュメントに記載されています。Resource-based Policyのために実装が必要なJSONがあります。このResource-based Policyを作成したら、Zero-ETLプロセスのセットアップを開始できます。
DynamoDBテーブルに必要な要件は以上の2つです。では、私たちのTransactionテーブルがどのようなものか簡単にご紹介しましょう。これは私が作成した不正利用のユースケース例です。Transaction ID、AWS Region、国、カードブランド、IPアドレス、ローカライゼーション、そして取引が承認されたか拒否されたかを示すTransaction Statusなどのフィールドがあります。また、取引時刻やその他の属性も含まれています。素晴らしい機能の1つは、アプリケーション側で新しい属性を追加すると、Zero-ETLプロセスが自動的にそれを反映することです。これはDynamoDBのNoSQL機能の特徴をよく表しています。
では、GlueコンソールでのZero-ETLの設定に移りましょう。左側のメニューにZero-ETL統合のオプションが表示されています。ソースとしてDynamoDBを選択し、テーブルのリストから私たちのTransactionテーブルを選びます。次に、ターゲットの詳細を設定します。ここではクロスアカウント機能も利用可能です。データウェアハウスまたはカタログのオプションでは、RedshiftまたはGlue Catalogから選択できます。このデモでは、ドロップダウンからGlue Catalogを選択し、Zero-ETLデータベースを選びます。
S3にデータを送信するために必要な権限を持つGlueのデフォルトポリシーを選択します。統合にはリソースポリシーが必要であることが示されています。「Fix it for me now」ボタンをクリックすると、自動的に設定が完了します。DynamoDBテーブルとS3データレイク間で異なるKMSキーを使用したり、ネットワークプロトコル設定を調整したりする追加オプションも用意されています。出力設定では、テーブルを展開して、DynamoDBの属性を個別のカラムとしてAthenaやGlue Catalogで簡単にクエリできるようにすることができます。
最後の設定ステップでは、異なるKMSキーを指定したり、デフォルトで15分に設定されているレプリケーション設定を調整したりできます。名前と説明を入力し、Nextボタンをクリックして、これから構築しようとしているものを確認します。このZero-ETLのセットアップは、Glueコンソールで大量のコードを手動で書く必要がある従来の方法と比べて、わずか数回のクリックと画面遷移で完了します。実質的に5分程度でZero-ETLパイプラインを構築できたことになります。
すべてを確認してCreateをクリックすると、数秒で開始されます。最初はステータスが「Creating」と表示されます。実際の構築プロセスには約10分かかり、すべての基盤となるセットアップ（私が「パンケーキ作り」と呼んでいる、すべての材料を混ぜ合わせるプロセス）が完了します。この初期セットアップの後、ステータスは「Active」に変わります。
設定が完了すると、すべてのカラムが定義されたテーブルが自動的にAWS Glue Catalogに表示され、S3バケットでも確認できるようになります。そのプロセスを待つ間に、システムの他のコンポーネントを見ていきましょう。CloudWatchログとCloudWatchメトリクスを通じて監視機能が利用できます。 こちらが「glue-zero-ETL-target」というS3バケットで、Zero-ETLプロセスを使ってデータレイクに統合した全てのテーブルの一覧が表示されています。S3バケットは各テーブルのフォルダを自動的に作成します。
CloudWatchログをご存知の方は、一緒に確認してみましょう。 CloudWatchログでは、バックグラウンドで実行されているすべての操作を確認できます。これは新しい統合なので、表示されるまでに数分かかります。 既存のZero-ETLの例を見てみましょう。ロググループをクリックして、 すでにセットアップされて実行中のものを確認します。 ログには、ソース、ターゲット、実行された統合、移動された行数などの詳細が表示されます。 データ移動には2種類あります：テーブルの初期シードまたはハイドレーションを行うシードプロセスと、CDC（Change Data Capture）です。ここではCDCプロセスが表示されており、挿入、更新、削除の件数が確認できます。シードプロセスでは、テーブルに最初にハイドレーションされたデータが表示されます。
次に、可観測性のためのCloudWatchメトリクスを見てみましょう。 これもサービスに組み込まれており、データ移動を最初にセットアップする際の初期ハイドレーションであるシードプロセスと、 CDCオペレーションの両方のメトリクスを表示します。シードプロセスでは、最後の同期タイムスタンプ、取り込みが完了した時刻、挿入件数を確認できます。CDCについては、同様のタイムスタンプ情報に加えて、テーブルへの削除、更新、挿入の件数も確認できます。これにより、データパイプラインが正しく機能していることを監視できます。例えば、1秒あたり約1000件のトランザクションが発生することがわかっている場合、15分ごとにデータがデータレイクに流れ込んでいることを確認するCloudWatchアラートを設定し、データサイエンティストがレポートや分析を実行できるようにすることができます。
クイックリフレッシュをしてみましょう。 実行には約10分かかるので、10時20分前、22時20分頃に開始しました。確認時には、新しいテーブルがS3バケットとAWS Glue Catalogの両方に表示されているはずです。既存のセットアップを見てみると、 メタデータフォルダと実際のデータフォルダがあり、データはAthenaでの効率的なクエリのためにParquet形式で保存されています。 前述の通り、Apache Icebergに対応しており、異なる行への更新、挿入、削除を追跡できます。
各テーブルには独自のフォルダがあります。待っている間に、Athenaを見てみましょう。 AWS Data Catalogで、zero-ETLデータベースを使用すると、テーブル一覧が表示されます。すでに6つのテーブルがあります。トランザクションテーブルは、現在パイプラインを構築しているものと似ています。DynamoDBのカラムがすべてAthenaの個別のカラムにアンネストされていることに注目してください。ここでは、 シンプルなSQLクエリを書いてテーブルにクエリを実行できます。zero-ETL transactions fraud oneからselect starを実行し、transaction timestampで並び替えています。 このような種類のクエリはDynamoDBで書くとかなり複雑になりますが、ここでは任意のカラムや属性でクエリを実行する柔軟性があり、かなり高いパフォーマンスを発揮します。一桁ミリ秒の応答時間ではありませんが、これらのクエリは数秒で完了します。 これは、DynamoDBからAthenaにデータが転送された後のクエリ用データの様子を示しています。
では、S3バケットリストに戻って、パイプラインをもう一度確認してみましょう。これが構築されるまでには10〜15分ほどかかります。 その後、データが利用可能になり、パイプラインは15分ごとに継続してデータを分析用のLake Houseデータベースに送信します。
S3タブに戻って、新しいテーブルが作成されているかを確認してみましょう。実行完了まで約10分かかりました。 S3で更新すると、すぐに7つのオブジェクトが表示され、新しいTransactionsテーブルが下の方に表示されているはずです。ご覧のように、ライブフィードの取得が始まっています。データの取り込みが始まるまでに10〜15分ほどかかりましたが、 先日デモを作成して以来、ずっと動作し続けています。
これでデモはほぼ完了です。ご覧の通り、構築は簡単で、AthenaやGlue Catalogとも連携しており、 運用データに対する分析を非常に簡単に実現できます。ここでのポイントは、データに自由を与え、誰もがそのデータにアクセスできるようにすることです。これまでは、アナリストがデータにアクセスするために Data Engineerに連絡する必要がありましたが、今では適切な権限さえあれば、Data Scientistやアナリストが自分でこれを構築できるようになりました。
今ご覧いただいたデモで強調したいのは、セットアップが簡単なだけでなく、誰もパイプラインやその内部の保守を行う必要がないということです。 Zero-ETLとは、AWSがバックグラウンドでETLパイプラインの構築と保守を行うことを意味します。CloudWatchでログや情報を確認することはできますが、基本的にはソース、ターゲット、結果に集中すればよく、保守や継続的な調整について心配する必要はありません。すべてが内部で処理されているからです。
Zero-ETL統合の意義とまとめ
ご覧いただいた内容を振り返り、より広い文脈で説明すると、DynamoDBのZero-ETL統合がLake Houseに組み込まれたことについて説明しました。Amazon SageMaker Unified Studioを使用することで、データ処理、SQL分析、モデル開発、Gen AIアプリケーションのデプロイメントにアクセスできるようになりました。DynamoDBの既存の機能を基盤とするこの新機能のゴールは、データの保存場所の選択肢を増やし、より多くの使用方法を提供することでした。DynamoDBはまずOpenSearchをサポートし、数ヶ月前にRedshiftをサポートし、そして今回Zero-ETLを通じてLake Houseが利用可能になりました。
このディスカッションの重要なポイントは、アーキテクチャとデータ管理の取り組み全体をシンプル化し、必要なエンジニアリング作業を削減できることです。これにより、ビジネス課題の解決においてより高い俊敏性が得られます。これらはすべてクラウド上のServerlessテクノロジーで構築されており、使用した分だけ料金を支払い、最終結果だけを気にすれば良いのです。AWS のZero-ETLチームが常時チューニングを行っているため、継続的なメンテナンスのためにリソースをデプロイする必要もありません。
ご参加ありがとうございました。Zero-ETLについてさらに詳しく知りたい方は、上のQRコードでZero-ETL全般について、下のQRコードでこの特定の統合についての情報をご確認いただけます。アプリ内のセッションアンケートへのご記入もお願いいたします。お時間をいただき、ありがとうございました。
※ こちらの記事は Amazon Bedrock を利用することで全て自動で作成しています。
※ 生成AI記事によるインターネット汚染の懸念を踏まえ、本記事ではセッション動画を情報量をほぼ変化させずに文字と画像に変換することで、できるだけオリジナルコンテンツそのものの価値を維持しつつ、多言語でのAccessibilityやGooglabilityを高められればと考えています。
Discussion