Amazon Redshift との Amazon DynamoDB ゼロ ETL 統合の始め方

Amazon DynamoDB と Amazon Redshift のゼロ ETL 統合の一般提供(GA)を発表できることをうれしく思います。これにより、DynamoDB 上の本番ワークロードへの影響をほとんどまたはまったく与えることなく、Amazon Redshift で DynamoDB データに対して高パフォーマンスな分析を実行できます。データが DynamoDB テーブルに書き込まれると、Amazon Redshift でシームレスに利用できるようになるため、複雑なデータパイプラインを構築およびメンテナンスする必要がなくなります。

ゼロ ETL 統合は、データパイプラインの作成と管理の必要なく、ポイントツーポイントのデータ移動を容易にします。Amazon Redshift Serverless ワークグループまたは RA3 インスタンスタイプを使用した Amazon Redshift プロビジョニングクラスター上で、ゼロ ETL 統合を作成できます。その後、高パフォーマンス SQL、ビルトイン機械学習(ML) と Spark インテグレーション、自動および増分リフレッシュによるマテリアライズドビュー(MV)、データ共有、複数のデータストアとデータレイク間でのデータ結合など、Amazon Redshift の高度な分析機能を使って、この DynamoDB データで拡張分析を実行できます。

Amazon Redshift との DynamoDB のゼロ ETL 統合は、お客様の抽出、変換、ロード(ETL)パイプラインを簡素化するのに役立ちます。
以下は、自社開発のソリューションに代わって DynamoDB とのゼロ ETL 統合を利用したシームレスなレプリケーションを利用し、業務を改善したお客様である Verisk Analytics の DevOps ディレクター、Keith McDuffee 氏のコメントです:

“Amazon Redshift のトランザクションデータを基にダッシュボードが構築されています。以前は、自社開発のソリューションを使用して DynamoDB から Amazon Redshift にデータを移動しましたが、それらのジョブはタイムアウトすることが多く、運用上の負担が大きくなり、Amazon Redshift に関するインサイトを見逃していました。 Amazon Redshift と DynamoDB ゼロ ETL インテグレーションを使用することで、このような問題に遭遇することはなくなり、インテグレーションによってシームレスかつ継続的にデータが Amazon Redshift にレプリケートされます。”

この投稿では、EC サイトのアプリケーションにおいて、この ETL 不要の統合を使って、位置情報や登録日などの属性ごとの顧客分布を分析する方法を紹介します。また、異なる期間でのアクティブなプロファイル数を比較することによって維持率を計算し、維持率や離反率の分析にもこの統合を利用できます。

ソリューションの概要

ゼロ ETL 統合は、DynamoDB テーブルから Amazon Redshift へデータをシームレスに移動できる、エンドツーエンドの完全マネージドプロセスを提供します。これにより、手動の ETL プロセスが不要となり、Amazon Redshift 環境で効率的かつ増分的な更新が保証されます。このインテグレーションは、DynamoDB エクスポートを利用して、DynamoDB から Amazon Redshift へ 15-30 分ごとにデータの変更を増分的にレプリケートします。初期データロードはフルロードで、データ容量に応じて時間がかかる場合があります。また、複数の DynamoDB テーブルから単一の Amazon Redshift プロビジョンドクラスタやサーバーレスワークグループへデータをレプリケートできるため、さまざまなアプリケーションにまたがるデータを一元的に参照できます。

このレプリケーションは、DynamoDB テーブルのパフォーマンスや可用性への影響がほとんどまたはまったくなく、DynamoDB の読み取り容量ユニット(RCU)を消費することなく行われます。アプリケーションは引き続き DynamoDB を使用する一方で、これらのテーブルからのデータはシームレスに Amazon Redshift にレプリケートされ、レポートやダッシュボードなどの分析ワークロードに使用されます。

次の図はこのアーキテクチャの説明です。

以下のセクションでは、Amazon Redshift との DynamoDB ゼロ ETL 統合の使用を開始する方法を示します。
この一般提供リリースでは、AWS Command Line Interface (AWS CLI)、AWS SDK、API、および AWS Management Console を使用して、ゼロ ETL 統合の作成と管理をサポートしています。この投稿では、コンソール操作による使用方法を紹介します。

前提条件

次の前提条件ステップを完了してください:

DynamoDB テーブルでポイントインタイムリカバリー(PITR)を有効にします。
ターゲットの Redshift データウェアハウスで大文字と小文字の区別を有効にします。
DynamoDB と Amazon Redshift の両方に、こちらに記載されているリソースベースのポリシーをアタッチします。
統合を作成するAWS Identity and Access Management(IAM) ユーザーまたはロールが、こちらにリストされているアクションを承認するアイデンティティベースのポリシーを持つことを確認します。

DynamoDB のゼロ ETL 統合の作成

DynamoDB コンソールまたは Amazon Redshift コンソールのいずれかでインテグレーションを作成できます。
次の手順では、Amazon Redshift コンソールを使用します。

Amazon Redshift コンソールで、ナビゲーションペインのゼロ ETL 統合を選択します。
Create zero-ETL Integration を選択します。

DynamoDB コンソールでインテグレーションを作成する場合は、ナビゲーションペインでインテグレーションを選択し、次に統合を作成とAmazon Redshiftを選択してください。

Integration nameに名前を入力してください。(例として ddb-rs-customerprofiles-zetl-integration).
次へを選択します.

DynamoDB テーブルを参照を選択し、このインテグレーションのソースとなるテーブルを選択します。
次へを選択します。

Redshift クラスタ内の単一のテーブルからのみデータを選択できます。
複数のテーブルからデータが必要な場合は、各テーブルについて個別にインテグレーションを作成する必要があります。

ソースの DynamoDB テーブルで PITR が有効になっていない場合、ソースの選択中にエラーが表示されます。
この場合、ソーステーブルで PITR を有効にするために DynamoDB の Fix it for me を選択できます。
変更を確認し、Continue を選択してください。

次へを選択します.

移行先の Redshift データウェアハウスを選択します。同じアカウント内にある場合は、ブラウズして移行先を選択できます。移行先が別のアカウントにある場合は、移行先の Redshift クラスタの Amazon リソースネーム(ARN)を指定できます。

リソースポリシーに関するエラーが発生した場合は、この作成プロセスの一環としてポリシーを修正するために Amazon Redshift の Fix it for me を選択してください。
あるいは、ゼロ ETL 統合を作成する前に、Amazon Redshift のリソースポリシーを手動で追加することもできます。
変更を確認し、Reboot and continueを選択してください。

次へを選択し、インテグレーション設定を完了します。

ゼロ ETL 統合の作成は、ステータスが作成中と表示されるはずです。ステータスがアクティブに変わるのを待ちます。

Redshift データベースの統合からの作成

Redshift データベースを作成するには、次のステップを完了します:

Amazon Redshift コンソールから, 新しく作成されたゼロ ETL 統合を選択します。
統合からデータベースを作成を選択します。

データベース名に名前を入力します(例としてddb_rs_customerprofiles_zetl_db)。
データベースの作成を選択します。

データベースの作成後、データベースの状態が作成中 から アクティブ に変わる必要があります。
これにより、ソース DynamoDB テーブルから、デスティネーションデータベース(ddb_rs_customerprofiles_zetl_db) のパブリックスキーマ下に作成されるターゲット Redshift テーブルへのデータのレプリケーションが開始されます。

これで Amazon Redshift と DynamoDB の統合を使用して、データをクエリできるようになりました。

データの構成を把握する

DynamoDB から Amazon Redshift にエクスポートされたデータは、ゼロ ETL 統合から作成した Redshift データベース(ddb_rs_customerprofiles_zetl_db)に格納されます。DynamoDB ソーステーブルと同じ名前のテーブルがデフォルト(パブリック)の Redshift スキーマの下に作成されます。DynamoDB はプライマリキーの属性(パーティションキーと省略可能なソートキー)に対してのみスキーマを適用します。このため、DynamoDB テーブル構造は Amazon Redshift に 3 つのカラムとしてレプリケートされます: パーティションキー、ソートキー、およびすべての属性を含む SUPER データ型のカラム value です。この value カラム内のデータは、DynamoDB JSON 形式です。データ形式の詳細については、DynamoDB テーブルのエクスポート出力形式を参照してください。

DynamoDB のパーティションキーは Redshift テーブルの分散キーとして使用され、DynamoDB のパーティションキーとソートキーの組み合わせが Redshift テーブルのソートキーとして使用されます。 Amazon Redshift では、ゼロ ETL 統合レプリケートテーブルのソートキーを ALTER SORT KEY コマンドを使用して変更することもできます。

Amazon Redshift の DynamoDB データは読み取り専用データです。 Amazon Redshift テーブルでデータが利用可能になった後、PartiQL SQL を使用してvalue列を SUPER データ型としてクエリしたり、自動的に増分更新されるマテリアライズドビューを作成してクエリすることが可能です。

SUPER データ型の詳細については、Amazon Redshift のセミストラクチャデータを参照してください。

データのクエリ

インジェストされたレコードを検証するには、Amazon Redshift クエリエディタを使用して PartiQL SQL で Amazon Redshift のターゲットテーブルをクエリできます。たとえば、次のクエリを使用して email を選択し、value 列のデータをアンネストして、顧客名と住所を取得できます:

select email, 
       value.custname."S"::text custname, 
       value.address."S"::text custaddress, 
       value 
 from "ddb_rs_customerprofiles_zetl_db".public."customerprofiles"

インクリメンタルな変更のレプリケーションがどのように機能するかを示すために、ソース DynamoDB テーブルに次の更新を行います:

DynamoDB テーブルに 2 つの新しいアイテムを追加:

##Incremental changes 
##add 2 items 

 aws dynamodb put-item --table-name customerprofiles --item  '{ "email": { "S": "sarah.wilson @ example.com" }, "custname": { "S": "Sarah Wilson" }, "username": { "S": "swilson789" }, "phone": { "S": "555-012-3456" }, "address": { "S": "789 Oak St, Chicago, IL 60601" }, "custcreatedt": { "S": "2023-04-01T09:00:00Z" }, "custupddt": { "S": "2023-04-01T09:00:00Z" }, "status": { "S": "active" } }'

 aws dynamodb put-item --table-name customerprofiles --item  '{ "email": { "S": "michael.taylor @ example.com" }, "custname": { "S": "Michael Taylor" }, "username": { "S": "mtaylor123" }, "phone": { "S": "555-246-8024" }, "address": { "S": "246 Maple Ave, Los Angeles, CA 90001" }, "custcreatedt": { "S": "2022-11-01T08:00:00Z" }, "custupddt": { "S": "2022-11-01T08:00:00Z" }, "status": { "S": "active" } }'

DynamoDB テーブル内のアイテムの住所を 1 つ更新:

##update an item 
 aws dynamodb update-item --table-name customerprofiles --key '{"email": {"S": "sarahjones @ example.com"}}' --update-expression "SET address = :a" --expression-attribute-values '{":a":{"S":"124 Main St, Somewhereville USA"}}'

email が michaelwilson@example.com のアイテムを削除:

# # delete an item  

 aws dynamodb delete-item --table-name customerprofiles --key '{"email": {"S": "michaelwilson @ example.com"}}'

これらの変更により、DynamoDB テーブル customerprofiles には、次のスクリーンショットに示すように、4 つのアイテム(既存の 3 つ、新規の 2 つ、削除の 1 つ)が含まれます。

次に、クエリエディタに移動して、これらの変更を検証できます。この時点で、Redshift テーブルに増分変更が反映されているはずです(テーブル内の 4 つのレコード)。

ゼロ ETL でレプリケーションしたテーブルに対するマテリアライズドビューの作成

一般的な分析のユースケースでは、複数のソーステーブルにまたがるデータを集計するために、複雑なクエリを使用してレポートやダッシュボードを生成し、ダウンストリームのアプリケーションで使用することが多いです。お客様は通常、このようなユースケースを満たすために遅延バインドビューを作成しますが、ビューを表示するためのクエリに長い実行時間がかかるため、厳格にクエリの SLA を満たすように常に最適化されているわけではありません。別の選択肢は、複数のソーステーブルにまたがるデータを格納するテーブルを作成することですが、ソーステーブルの変更に基づいてデータを増分更新およびリフレッシュする必要があるという課題があります。

このようなユースケースに対応し、従来のオプションに関連する課題を回避するために、Amazon Redshift のゼロ ETL でレプリケーションしたテーブルに対してマテリアライズドビューを作成できます。これにより、元となるデータが変更されるにつれて、インクリメンタルに自動更新されます。マテリアライズドビューは、ゼロ ETL 統合によって SUPER 列の value に格納されたデータをアンネストおよび分割することで、頻繁にアクセスされるデータを格納するのにも便利です。

たとえば、次のクエリを使用して、customerprofiles テーブル上にマテリアライズドビューを作成し、顧客データを分析できます。

CREATE MATERIALIZED VIEW dev.public.customer_mv
AUTO REFRESH YES
AS
SELECT value."custname"."S"::varchar(30) as cust_name, value."username"."S"::varchar(100) as user_name, value."email"."S"::varchar(60) as cust_email, value."address"."S"::varchar(100) as cust_addres, value."phone"."S"::varchar(100) as cust_phone_nbr, value."status"."S"::varchar(10) as cust_status,
value."custcreatedt"."S"::varchar(10) as cust_create_dt, value."custupddt"."S"::varchar(10) as cust_update_dt FROM "ddb_rs_customerprofiles_zetl_db"."public"."customerprofiles"
group by 1,2,3,4,5,6,7,8;

このビューは AUTO REFRESH に設定されているため、元になるソーステーブル customerprofiles に新しいデータが到着すると、自動的かつ増分的に更新されます。

次に、さまざまなステータスカテゴリにわたる顧客の分布を理解したいとします。ゼロ ETL DynamoDB テーブルから作成されたマテリアライズドビュー customer_mv に対して、次のようにクエリを実行できます:

-- Customer count by status 
 select cust_status,count(distinct user_name) cust_status_count 
 from dev.public.customer_mv 
 group by 1 ;

次に、異なる期間におけるアクティブな顧客プロファイル数を比較したいとします。このデータを取得するために、customer_mv で以下のクエリを実行できます:

-- Customer active count by date 
 select cust_create_dt,count(distinct user_name) cust_count 
 from dev.public.customer_mv 
 where cust_status ='active'
 group by 1 ;

いくつかの増分変更を試してみましょう。次の AWS CLI コマンドを使用して、ソース DynamoDB テーブルに 2 つの新しいアイテムを追加し、1 つ削除します。

aws dynamodb put-item --table-name customerprofiles --item  '{ "email": { "S": "robert.davis @ example.com" }, "custname": { "S": "Robert Davis" }, "username": { "S": "rdavis789" }, "phone": { "S": "555-012-3456" }, "address": { "S": "789 Pine St, Seattle, WA 98101" }, "custcreatedt": { "S": "2022-07-01T14:00:00Z" }, "custupddt": { "S": "2023-04-01T11:30:00Z" }, "status": { "S": "inactive" } }'

 aws dynamodb put-item --table-name customerprofiles --item '{ "email": { "S": "william.jones @ example.com" }, "custname": { "S": "William Jones" }, "username": { "S": "wjones456" }, "phone": { "S": "555-789-0123" }, "address": { "S": "456 Elm St, Atlanta, GA 30301" }, "custcreatedt": { "S": "2022-09-15T12:30:00Z" }, "custupddt": { "S": "2022-09-15T12:30:00Z" }, "status": { "S": "active" } }'

 aws dynamodb delete-item --table-name customerprofiles --key '{"email": {"S": "emily.brown @ example.com"}}'

マテリアライズドビューの増分リフレッシュの検証

マテリアライズドビューの更新履歴を監視するには、SYS_MV_REFRESH_HISTORY システムビューを使用できます。次の出力でわかるように、マテリアライズドビュー customer_mv が増分更新されました。

それでは、ゼロ ETL テーブルから作成されたマテリアライズドビューをクエリしてみましょう。2 つの新しいレコードが表示されます。変更は増分更新によってマテリアライズドビューに反映されました。

ゼロ ETL 統合のモニタリング

Amazon Redshift との DynamoDB ゼロ ETL 統合のパフォーマンスとステータスに関するメトリクスを入手するオプションがいくつかあります。

Amazon Redshift コンソールで、ナビゲーションペインのZero-ETL 統合を選択します。
希望のゼロ ETL 統合を選択し、そのインテグレーションに関連する Amazon CloudWatch メトリクスを表示できます。
これらのメトリクスは、CloudWatch で直接利用できます。

インテグレーションごとに、利用できる情報が含まれる 2 つのタブがあります:

統合メトリクス – ラグ (分単位)やデータ転送量 (KBps 単位) のようなメトリクスを表示します。

テーブルの統計情報 – DynamoDB から Amazon Redshift にレプリケートされたテーブルの詳細を示します。ステータス、最終更新時刻、テーブルの行数、テーブルサイズなどが含まれます

ソース DynamoDB テーブルで行の挿入、削除、更新を行った後、次のスクリーンショットに示すように、テーブルの統計情報セクションに詳細が表示されます。

CloudWatch メトリクスに加えて、インテグレーションに関する情報を提供する次のシステムビューをクエリできます:

SVV_INTEGRATION – 統合の設定詳細を提供します
SYS_INTEGRATION_ACTIVITY – 完了した統合実行に関する情報を提供します
SVV_INTEGRATION_TABLE_STATE – テーブルレベルの統合情報を記述します

料金設定

AWS はゼロ ETL 統合に追加料金を請求しません。DynamoDB と Amazon Redshift の既存のリソースを使用して変更データを作成および処理するために発生する料金のみが請求されます。これには、DynamoDB PITR、DynamoDB からのエクスポート(DynamoDB の初期データおよび継続的なデータ変更)、レプリケートされたデータの保存に使用される追加の Amazon Redshift ストレージ、ターゲット上の Amazon Redshift コンピューティング料金が含まれます。DynamoDB PITR と DynamoDB エクスポートの料金については、Amazon DynamoDB の料金を参照してください。Redshift クラスターの料金については、Amazon Redshift の料金を参照してください。

クリーンアップ

ゼロ ETL 統合を削除すると、DynamoDB テーブルや Redshift からデータは削除されませんが、その時点以降に発生するデータの変更は Amazon Redshift に送信されなくなります。

ゼロ ETL 統合を削除するには、次のステップを完了します:

Amazon Redshift コンソールから, ナビゲーションペインにある ゼロ ETL 統合を選択します。
削除したいゼロ ETL 統合をアクション メニューから選択して削除をクリックします。

削除を確認するために、削除 と入力し、削除を選択してください。

まとめ

この投稿では、DynamoDB から Amazon Redshift へのゼロ ETL 統合を設定することで、複数のアプリケーションにまたがる包括的なインサイトを得たり、組織内のデータサイロをなくしたり、大幅なコスト削減と運用効率化を実現できる方法を説明しました。

ゼロ ETL 統合の詳細については、ドキュメントを参照してください。

著者について

Ekta Ahuja は AWS の Amazon Redshift スペシャリストソリューションアーキテクトです。彼女は、お客様がスケーラブルで堅牢なデータおよび分析ソリューションを構築できるよう支援することに情熱を注いでいます。 AWS に入社する前は、データエンジニアリングと分析のさまざまな職務に携わっていました。仕事以外では、風景写真、旅行、ボードゲームを楽しんでいます。

Raghu Kuppala は、データベース、データウェアハウス、分析分野での経験が豊富なアナリティクススペシャリストソリューションアーキテクトです。仕事以外では、さまざまな料理を試したり、家族や友人と時間を過ごしたりしています。

Veerendra Nayak は、カリフォルニア州ベイエリアを拠点とするプリンシパルデータベースソリューションアーキテクトです。データベース移行、レジリエンシー、運用データ分析やAIサービスとの統合に関するベストプラクティスをお客様と共有しています。

翻訳はソリューションアーキテクトの小役丸が担当しました。原文はこちらです。

Amazon Web Services ブログ