ablog

不器用で落着きのない技術者のメモ

AWS認定 Data Engineer - Associate 勉強メモ

Lake Formation

AWS Lake Formation 行レベルのアクセス許可を使用すると、データコンプライアンスとガバナンスポリシーに基づいて、テーブル内の特定の行へのアクセスを提供できます。

行レベルのアクセスコントロールによるデータレイクの保護 - AWS Lake Formation
Amazon Kinesis Streams

Auto Scaling を使用すると、適切なメトリクスに基づいて自動的にインスタンスを拡張できます。詳細については、Amazon EC2 Auto Scaling ユーザーガイドを参照してください。

シャードの数を変更するには、再シャーディング、スケーリング、並列処理を使用します。 - Amazon Kinesis Data Streams

Amazon Kinesis Data Streams では、拡張ファンアウトと呼ばれる機能を使用するコンシューマーを構築できます。この機能を使用すると、コンシューマーはシャードあたり 1 秒あたり最大 2 MB のデータのスループットでストリームからレコードを受信できます。このスループットは専用です。つまり、拡張ファンアウトを使用するコンシューマーは、ストリームからデータを受け取る他のコンシューマーと競合する必要がありません。Kinesis Data Streams は、ストリームのデータレコードを、拡張ファンアウトを使用するコンシューマーに送信します。そのため、これらのコンシューマーはデータをポーリングする必要はありません。

専用スループットで拡張ファンアウトコンシューマーを開発する - Amazon Kinesis Data Streams

[レポート]ANT322 – 「Amazon Kinesisによるハイパフォーマンスデータストリーミング: ベストプラクティス」 #reinvent | DevelopersIO

厳密な保証を必要とするアプリケーションは、レコード内にプライマリキーを埋め込んで、後ほど処理するときに重複を削除する必要があります。
（中略）
この問題に対するソリューションは、複雑性と正確性に応じて異なります。最終的なデータの送信先が重複を適切に処理できる場合は、冪等処理の実行は最終送信先に任せることをお勧めします。例えば、Opensearch では、バージョニングと一意の ID の組み合わせを使用して重複処理を防ぐことができます。

重複レコードを処理する - Amazon Kinesis Data Streams
Amazon Data Firehose

Amazon Data Firehoseでは、Lambda 関数を呼び出して、着信ソースデータを変換してから宛先に配信できます。Amazon Data Firehose のデータ変換は、Firehose ストリームの作成時に有効にすることができます。

Amazon Data Firehose でソースデータを変換する - Amazon Data Firehose

Firehose ストリームにデータを送信すると、選択した送信先にデータが自動的に配信されます。次の表は、さまざまな宛先へのデータ配信について説明するものです。

デスティネーション 詳細
HTTP エンドポイント サポートされているサードパーティーサービスプロバイダーが所有する HTTP エンドポイントへのデータ配信のために、統合された Amazon Lambda サービスを使用して、着信レコードをサービスプロバイダーの統合が想定している形式に一致する形式に変換する関数を作成できます。受信したレコード形式の詳細については、送信先に HTTP エンドポイントを選択したサードパーティーサービスプロバイダーにお問い合わせください。
Amazon Redshift Amazon Redshift へのデータ配信では、Firehose は最初に着信データを前に説明した形式で S3 バケットに配信します。次に Firehose は、Amazon Redshift COPY コマンドを発行して、S3 バケットから Amazon Redshift プロビジョンドクラスターまたは Amazon Redshift Serverless ワークグループにデータをロードします。Amazon Data Firehose が複数の着信レコードを Amazon S3 オブジェクトに連結した後に、Amazon S3 オブジェクトを Amazon Redshift プロビジョンドクラスターまたは Amazon Redshift Serverless ワークグループにコピーできることを確認します。詳細については、「Amazon Redshift COPY コマンドのデータ形式パラメータ」を参照してください。
OpenSearch Service と OpenSearch Serverless OpenSearch Service と OpenSearch Serverless へのデータ配信では、Amazon Data Firehose は Firehose ストリームのバッファリング設定に基づいて着信レコードをバッファリングします。次に、OpenSearch Service または OpenSearch Serverless への一括リクエストを生成して、OpenSearch Service クラスターまたは OpenSearch Serverless コレクションに複数のレコードのインデックスを作成します。Amazon Data Firehose に送信する前に、レコードが UTF-8 でエンコードされ、1 行の JSON オブジェクトにフラット化されていることを確認します。また、1 秒ごとに設定される明示的なインデックスを使用して一括リクエストを行うには、OpenSearch Service クラスターの rest.action.multi.allow_explicit_index オプションを true (デフォルト) に設定する必要があります。詳細については、「Amazon OpenSearch Service デベロッパーガイド」の「OpenSearch Service Configure Advanced Options」を参照してください。
https://docs.aws.amazon.com/ja_jp/firehose/latest/dev/basic-deliver.html

AWSのAPIイベントなどを契機にアクションを起こすことが出来るサービス「CloudWatch Events」ですが、アクションを起こすターゲットとして「Kinesis Firehose」が選択できるようになりました！

【アップデート】CloudWatch EventsのターゲットにKinesis Firehoseを選択できるようになりました！ | DevelopersIO

集計
集約は、複数レコードを 1 つの Kinesis Data Streams レコードに保存することを意味します。集約を使用すると、API コールごとに送信されるレコード数を増やすことができ、効率的にプロデューサーのスループットを高めることができます。
Kinesis Data Streams シャードは、1 秒あたり最大で 1,000 レコードまたは 1 MB のスループットをサポートします。1 秒あたりの Kinesis Data Streams レコードの制限により、お客様のレコードは 1 KB 未満に制限されます。レコードの集約を使用すると、複数のレコードを単一の Kinesis Data Streams レコードに結合できます。そのため、お客様はシャードあたりのスループットを改善することができます。

KPL の主要な概念 - Amazon Kinesis Data Streams

KPL では、ライブラリ内で最大 RecordMaxBufferedTime まで追加の処理遅延が生じる場合があります (ユーザーが設定可能)。RecordMaxBufferedTime の値が大きいほど、パッキング効率とパフォーマンスが向上します。この追加の遅延を許容できないアプリケーションは、 AWS SDK を直接使用する必要がある場合があります。

Amazon Kinesis Producer Library (KPL) を使用してプロデューサーを開発する - Amazon Kinesis Data Streams
EMR

You can use the SetKeepJobFlowAliveWhenNoSteps to configure a cluster (job flow) to terminate after the step execution, i.e., all your steps are executed. If you want a transient cluster that shuts down after the last of the current executing steps are completed, you can configure SetKeepJobFlowAliveWhenNoSteps to false. If you want a long running cluster, configure SetKeepJobFlowAliveWhenNoSteps to true.

SetKeepJobFlowAliveWhenNoSteps - Amazon EMR

ブロックパブリックアクセスのアカウントレベル設定を使用して、Amazon EMR クラスターへのパブリックネットワークアクセスを一元管理することができます。

のユーザーがクラスター AWS アカウント を起動すると、Amazon EMR はクラスターのセキュリティグループのポートルールをチェックし、インバウンドトラフィックルールと比較します。セキュリティグループに、パブリック IP アドレス IPv4 0.0.0.0/0 または IPv6 ::/0 に対してポートを開くインバウンドルールがあり、それらのポートがアカウントで適切に指定されていない場合、Amazon EMR はユーザーにクラスターの作成を許可しません。

Amazon EMR のパブリックアクセスブロックの使用 - Amazon EMR

YARNMemoryAvailablePercentage: YARN に対する利用可能な残りのメモリの割合 (YARNMemoryAvailablePercentage = MemoryAvailableMB / MemoryTotalMB)。この値は、YARN のメモリの使用状況に基づくクラスターリソースのスケーリングに役立ちます。

CloudWatch で Amazon EMR のメトリクスをモニタリングする - Amazon EMR
  • PEM
    • このオプションを選択すると、zip ファイル内で提供する PEM ファイルを使用できます。zip ファイル内では、privateKey.pem と certificateChain.pem の 2 つのアーティファクトが必要です。3 つ目の trustedCertificates.pem ファイルはオプションです。詳細については、「Amazon EMR 暗号化を使用して転送中のデータを暗号化するための証明書の提供」を参照してください。[S3 object] (S3 オブジェクト) で、zip ファイルフィールドの Amazon S3 の場所または Amazon S3 ARN を指定します。
Amazon EMR コンソールまたは を使用してセキュリティ設定を作成する AWS CLI - Amazon EMR

Amazon EMRではいくつかのデプロイオプションが用意されています。
従来のEC2やEKSではクラスターの柔軟なカスタマイズができる反面、クラスターの運用や管理が必要で事前に適切なインスタンスのプロビジョニングも必要でした。
EMR Serverlessでは必要なタイミングで必要なリソースが割り当てられるので、需要の増減が予測出来ない場合やクラスターの運用・管理を避けたい場合に適しています。

Amazon EMR Serverless が GA になったので使ってみた | DevelopersIO

Amazon EMR リリース 6.12.0 以降では、LDAP over SSL (LDAPS) プロトコルを使用して、企業の ID サーバーとネイティブに統合されるクラスターを起動できます。LDAP (Lightweight Directory Access Protocol) は、データにアクセスして管理する、ベンダーに依存しないオープンなアプリケーションプロトコルです。LDAP は一般的に、Active Directory (AD) や OpenLDAP などのアプリケーションでホストされている企業 ID サーバーに対するユーザー認証に使用されます。このネイティブ統合により、LDAP サーバーを使用して Amazon EMR のユーザーを認証できます。

Amazon EMR での認証に Active Directory または LDAP サーバーを使用する - Amazon EMR
Amazon QuickSight

Amazon QuickSight には、Standard と Enterprise の 2 つのエディションがあります。2 つのバージョン間の可用性、ユーザー管理、アクセス権限、セキュリティの違いの詳細については、次のトピックを参照してください。

どちらのエディションにも、データのビジュアルを作成および共有するための機能一式が用意されています。Enterprise Edition ではさらに、保管時のデータの暗号化、Microsoft Active Directory との統合も可能です。Enterprise Edition では、 AWS Directory Serviceで Microsoft Active Directory ディレクトリを選択します。そのアクティブディレクトリを使用して、Amazon QuickSight のユーザーと管理者を識別して管理します。

Amazon QuickSight の異なるエディション - Amazon QuickSight
  • 行レベルセキュリティ

Amazon QuickSight の Enterprise Edition では、行レベルのセキュリティ(row-level security/RLS)を設定することで、データセットへのアクセスを制限できます。

Amazon QuickSightでデータセットへのアクセスを制限する | DevelopersIO

管理者ユーザーは、TeamID カラムが "TEAM_A" の行しか見れなくなり、閲覧者ユーザーは "TEAM_B" のカラムしか見れなくなります。(前述の prefecture_dataset.csv の TeamID カラムと連動しています。)

QuickSight 行レベルセキュリティを試してみた | DevelopersIO

Amazon QuickSight では、データを表示するために使用できる幅広いビジュアルタイプが提供されます。このセクションの各トピックで、各ビジュアルタイプの機能の詳細を確認してください。
トピック

  • メジャーとディメンション
  • 表示制限
  • その他のカテゴリーの非表示または表示
  • 表示するデータポイント数のカスタマイズ
  • AutoGraph を使用する
  • 棒グラフの使用
  • ボックスプロットの使用
  • コンボグラフの使用
  • カスタムビジュアルコンテンツの使用
  • 円グラフの使用
  • ファネルグラフの使用
  • ゲージグラフの使用
  • ヒートマップの使用
  • Highcharts の使用
  • ヒストグラムの使用
  • イメージコンポーネントの使用
  • KPI の使用
  • レイヤーマップの使用
  • 折れ線グラフの使用
  • マップおよび地理空間チャートの作成
  • スモールマルチプルの使用
  • 円グラフの使用
  • ピボットテーブルの使用
  • レーダーチャートの使用
  • サンキー図の使用
  • 散布図の使用
  • ビジュアルとしてのテーブルの使用
  • テキストボックスの使用
  • ツリーマップの使用
  • ウォーターフォールグラフの使用
  • ワードクラウドの使用
Amazon QuickSight のビジュアルタイプ - Amazon QuickSight

Connecting to relational data

  • You can use any of the following relational data stores as data sources for Amazon Quick Sight:
  • Amazon Athena
  • Amazon Aurora
  • AWS Glue Data Catalog can be accessed using AWS Glue data catalog compatible services, such as Athena or Redshift Spectrum
  • Amazon OpenSearch Service
  • Amazon Redshift
  • Amazon Redshift Spectrum
  • Amazon S3
  • Amazon S3 Analytics
  • Apache Impala
  • Apache Spark 2.0 or later
  • AWS IoT Analytics
  • Databricks (E2 Platform only) on Spark 1.6 or later, up to version 3.0
  • Exasol 7.1.2 or later
  • Google BigQuery
  • MariaDB 10.0 or later
  • Microsoft SQL Server 2012 or later
  • MySQL 5.7 or later
  • Oracle 12c or later
  • PostgreSQL 9.3.1 or later
  • Presto 0.167 or later
  • Snowflake
  • Starburst
  • Trino
  • Teradata 14.0 or later
  • Timestream
  • Amazon EC2
  • Local (on-premises) databases
  • Data in a data center or some other internet-accessible environment

（中略）

Software as a service (SaaS) data
Quick Sight can connect to a variety of Software as a Service (SaaS) data sources either by connecting directly or by using Open Authorization (OAuth).
SaaS sources that support direct connection include the following:

  • Jira
  • ServiceNow

SaaS sources that use OAuth require that you authorize the connection on the SaaS website. For this to work, Quick Sight must be able to access the SaaS data source over the network. These sources include the following:

Supported data sources - Amazon Quick Suite

Amazon QuickSight を Amazon Redshift インスタンスに接続できるようにするには、そのインスタンスの新しいセキュリティグループを作成する必要があります。このセキュリティグループには、対象の AWS リージョンにある Amazon QuickSight サーバーの、適切な IP アドレスからのアクセスを許可するインバウンドルールが含まれます。

Amazon QuickSight から Amazon Redshift クラスターへの接続の認可 - Amazon QuickSight

https://d1.awsstatic.com/webinars/jp/pdf/services/20180228_AWS-BlackBelt_QuickSight_v2.pdf

新しい ML Insights機能により、Amazon QuickSight は、隠れたデータの傾向を発見し、ビジネスを左右する重要な要因を見つけ、将来の結果を予測したり、データを要約して理解しやすい自然言語で表現したりできます。また、手作業による分析と調査の時間の節約に役立ちます。すぐに使える 機械学習と Amazon QuickSight の豊富な分析機能を統合する包括的な BI ソリューションを構築することで、組織の全員にインタラクティブなダッシュボードを配布できます。ML インサイトを使用すると、機械学習が容易となり、技術や ML スキルセットに関わらず、誰でも簡単に数週間ではなくわずか数分でデータからインサイトを得ることができます。ML によるインサイト機能は次のとおりです。

  • ML を活用した異常検知は、何十億ものデータポイントを継続的に分析することによって、隠れたインサイトを発見するのに役立ちます。
  • ポイントアンドクリックで簡単に成長とビジネストレンドを予想するML を活用した予測
  • ダッシュボードの内容をやさしい言葉で伝えるのに役立つ自動ナラティブ。
新機能 – Amazon QuickSightへの機械学習（ML）によるインサイト機能をプレビューで提供 | Amazon Web Services ブログ

実行するウィンドウ関数または集計関数の粒度のレベル (前者はパーティション化するウィンドウ、後者はグループ化するレベル) を指定できるようになりました。実はLACにはLAC-AとLAC-Wの2つの機能があります。それぞれどういった違いがあるのかみてみましょう。

【アップデート】Amazon QuickSightでLevel Aware Calculation(LAC)が利用可能に | SunnyCloud

LAC には次の 2 つのグループがあります。

  • レベルアウェア計算 – 集計関数 (LAC-A) – これらは新しくリリースされた関数です。既存の集計関数 ( sum ()、max ()、count () など ) に引数を 1 つ追加することで、集計に必要な任意の Group by ディメンションを定義できます。LAC-A の一般的な構文は sum (measure, [group_field_A]) です。LAC-A を使うことで、ビジュアル集計が行われる前に集計ステップを追加できます。追加したレイヤーは固定できますが、ビジュアルのディメンションには依存しません。また、ビジュアルのディメンションと動的に相互作用することもできます。この記事の後半で、いくつかの具体的な例を紹介します。サポートされている集計関数の一覧については、レベルアウェア計算 – 集計 (LAC-A) 関数を参照してください。
  • レベルアウェア計算-ウィンドウ関数 (LAC-W) – こちらは既存の機能で、以前は Level Aware Aggregation (LAA) と呼ばれていました。ウィンドウ関数と集計関数の根本的な違いから、関数の性質をよりよく反映させるために最近この名称を変更しました。LAC-W はウィンドウ関数 ( sumover ()、maxover ()、denseRank () など) のグループで、3 番目のパラメーターを使用して、計算を PRE_FILTER ステージで実行するか PRE_AGG ステージで実行するかを選択できます。LAC-W の一般的な構文は sumOver (measure, [Partition_field_A], pre_agg) です。サポートされているウィンドウ関数の一覧については、レベルアウェア計算-ウィンドウ (LAC-W) 関数を参照してください。
Amazon QuickSight のレベルアウェア計算 (LAC) を使用して高度なインサイトを作成する | Amazon Web Services ブログ

Amazon Athena を Amazon QuickSight のデータソースとして使用するとアクセス拒否エラーが表示される一般的な原因は次のとおりです。

  • Amazon Simple Storage Service (Amazon S3) バケットへのアクセスに要求される権限が QuickSight アカウントにない。
  • データファイルが AWS Key Management Service (AWS KMS) キーで暗号化されている。
  • 必要となる AWS Identity and Access Management (IAM) アクセス権限ポリシーが割り当てられていない。
  • Amazon S3 バケットが存在しない。または、データのクエリに使用する IAM ロールに要求される S3 アクセス権限がない。
  • (AWS Organizations を使用する QuickSight アカウントの場合) 必要となるサービスコントロールポリシー (SCP) が割り当てられていない。
  • (Lake Formation を使用する Athena アカウントの場合) QuickSight ユーザーまたはグループに AWS Lake Formation アクセス権限がない。
Athena データから QuickSight へのアクセス拒否エラーを解決する | AWS re:Post

Amazon QuickSight Enterprise Edition では、行レベルのセキュリティ (RLS) を設定してデータセットへのアクセスを制限することができます。これは、データセットを共有する前または後に行います。RLS が設定されたデータセットをデータセット所有者と共有する場合、所有者は引き続きすべてのデータを表示できます。しかし、それを閲覧者と共有する場合、閲覧者は許可データセットのルールによって制限されたデータしか表示できません。

Amazon QuickSight での行レベルのセキュリティの使用 - Amazon QuickSight

Short description
Example Amazon RDS data source and Amazon Virtual Private Cloud (Amazon VPC) configuration:

Account type Amazon RDS data source in the same Region Amazon RDS data source in a different Region
Same AWS account Amazon VPC connection in Quick Sight Amazon VPC peering
Different AWS account Amazon VPC peering Amazon VPC peering

Resolution
The following resolution applies to Quick Sight Enterprise edition.

Connect QuickSight to a private Amazon RDS data source | AWS re:Post

機械学習 (ML) と自然言語機能を使用し、Amazon QuickSight Enterprise Edition は記述分析と診断分析を超えて、ユーザーの予測と意思決定をサポートします。

Amazon QuickSight での機械学習 (ML) を使用したインサイトの取得 - Amazon QuickSight

Amazon QuickSight では、Random Cut Forest (RCF) アルゴリズムの組み込みバージョンが使用されています。以下のセクションでは、その意味と Amazon QuickSight でどのように使用されるかを説明します。

Amazon QuickSight で使用される機械学習アルゴリズムについて - Amazon QuickSight

ランダムカットフォレスト (RCF) は、異常検出のユースケースで広く使用されているアルゴリズムの 1 つです。一般的には、入力データに対して RCF アルゴリズムを高いスループットで実行したい場合が多く、ストリーミングデータ処理フレームワークはそのようなケースで役立ちます。Amazon Managed Service for Apache Flink 上で RCF が使用可能になり、ストリーミングデータ処理において異常検出ができるようになりました。Apache Flink は、データストリーム上でリアルタイムでステートフルな計算を行うための人気のオープンソースフレームワークで、高いスループットで RCF を入力ストリームに実行するために使用できます。

Amazon Managed Service for Apache Flink のランダムカットフォレストによるリアルタイム異常検出 | Amazon Web Services ブログ
S3

S3 Glacier ストレージクラスは以下の 3 種類があります。

  • S3 Glacier Instant Retrieval
  • S3 Glacier Flexible Retrieval
  • S3 Glacier Deep Archive

このうち 1 つ目の S3 Glacier Instant Retrieval は即時取り出しが可能です。
S3 Glacier Flexible Retrieval と S3 Glacier Deep Archive では「復元」という操作を行わないと、データを取り出すことができません。復元には以下の時間がかかります。

  • S3 Glacier Flexible Retrieval
    • 迅速取り出し：1～5 分
    • 標準取り出し：3～5 時間
    • 大容量取り出し：5～12 時間
  • S3 Glacier Deep Archive
    • 標準取り出し：12 時間以内
    • 大容量取り出し：48 時間以内

[アップデート]Amazon S3 Glacier Flexible Retrieval でデータの復元時間が最大 85% 短縮されました | DevelopersIO

Amazon S3 は、次の宛先にイベントの通知メッセージを送信できます。

（中略）

PUT、POST、COPY などの Amazon S3 API オペレーションはオブジェクトを作成できます。これらのイベントタイプで、特定の API を使用してオブジェクトが作成されたときに通知を有効にできます。または、オブジェクトの作成に使用された API に関係なく、s3:ObjectCreated:* イベントタイプを使用して通知を要求できます。

イベント通知のタイプおよび送信先 - Amazon Simple Storage Service

Amazon S3 インベントリを使用してストレージを管理できます。例えば、ビジネス、コンプライアンス、および規制上のニーズに対応して、オブジェクトのレプリケーションや暗号化のステータスを監査およびレポートするために使用できます。また、Amazon S3 同期 List API オペレーションのスケジュールされた代替手段として Amazon S3 インベントリを使用し、ビジネスワークフローやビッグデータジョブを簡素化、高速化できます。Amazon S3 インベントリは、List API オペレーションを使用してオブジェクトを監査しないため、バケットのリクエストレートには影響しません。

Amazon S3 インベントリは、カンマ区切り値 (CSV)、Apache Optimized Row Columnar (ORC)、または Apache Parquet 出力ファイルを通じて、S3 バケットや共有プレフィックス (オブジェクト名の先頭が共通文字列) を持つオブジェクトについて、オブジェクトおよび対応するメタデータを毎日または毎週一覧表示します。毎週のインベントリを設定すると、最初のレポートの後は毎週日曜日 (UTC タイムゾーン) にレポートが生成されます。

S3 インベントリを使用したデータのカタログ化と分析 - Amazon Simple Storage Service

S3 Object Lambdaとは？
S3に対するGETリクエストをトリガーにLambdaを起動し、レスポンスを自由に加工できる機能です。例えば以下のようなユースケースが想定されています。

行のフィルタリング
画像の動的なリサイズ
機密データのマスク
この機能を利用するには、S3アクセスポイントをラップした「オブジェクト Lambda アクセスポイント」が必要になります。クライアントが「オブジェクト Lambda アクセスポイント」経由でオブジェクトのGETを試行するとLambdaが起動し、Lambdaによってカスタマイズされたレスポンスが返却されるという流れになります。

（中略）

S3 Object Lambdaを利用してS3からのレスポンスをオンデマンドでレスポンスを加工できるようになりました。クライアントの属性によってレスポンスを微調整したいようなユースケースでは便利に使えそうです。Lambdaでレスポンスを加工するという特性から、速度やコスト面では多少なりともデメリットがあるので、その点には注意が必要です。例えば今回紹介したような文字コードの変換などは事前にCP932に変換したファイルもS3に配置しておき、クライアント側で適切なオブジェクトをGETしてもらうという方法も考えられます。コストや性能面での要件と管理コストを考慮して適切な方式を選択するようにしましょう。

【アップデート】S3に対するGetリクエストのレスポンスをLambdaで加工するS3 Object Lambdaが利用可能になりました | DevelopersIO
Athena

UNLOAD ステートメントでは、次の構文を使用します。

UNLOAD (SELECT col_name[, ...] FROM old_table) 
TO 's3://amzn-s3-demo-bucket/my_folder/' 
WITH ( property_name = 'expression' [, ...] )

（中略）
次の例では、Parquet ファイル形式、ZSTD 圧縮、および ZSTD 圧縮レベル 4 を使用して、クエリ結果を指定された場所にアンロードします。

UNLOAD (SELECT * FROM old_table) 
TO 's3://amzn-s3-demo-bucket/' 
WITH (format = 'PARQUET',compression = 'SNAPPY')
UNLOAD - Amazon Athena

: パーティションされたテーブルを作成する
次の例では、WITH 句で partitioned_by と他のプロパティを使用した、異なるストレージ形式のパーティション テーブルに対する CREATE TABLE AS SELECT クエリを示します。

（中略）

CREATE TABLE ctas_csv_partitioned 
WITH (
     format = 'TEXTFILE',  
     external_location = 's3://amzn-s3-demo-bucket/ctas_csv_partitioned/', 
     partitioned_by = ARRAY['key1']) 
AS SELECT name1, address1, comment1, key1
FROM tables1;
CTAS クエリの例 - Amazon Athena

Athena では、クエリごとの制限とワークグループごとの制限の 2 つのタイプのコスト制御を設定できます。ワークグループごとに、クエリごとの制限を 1 つとワークグループごとの制限を複数設定できます。

  • クエリごとの制御制限は、クエリごとにスキャンされるデータの合計量を指定します。ワークグループで実行されるクエリが制限を超えると、キャンセルされます。ワークグループに作成できるクエリごとの制御制限は 1 つだけであり、その中で実行される各クエリに適用されます。

（中略）

  • ワークグループ全体のデータ使用量の制御制限は、指定された期間中にこのワークグループで実行されるすべてのクエリに対してスキャンされるデータの合計量を指定します。ワークグループごとに複数の制限を作成できます。ワークグループ全体のクエリ制限を使用すると、ワークグループで実行されているクエリによってスキャンされたデータの時間単位または日単位の集計に複数のしきい値を設定できます。
クエリごとおよびワークグループごとのデータ使用量の制御を設定する - Amazon Athena

EXPLAIN syntax

EXPLAIN [ ( option [, ...]) ] statement

（中略）

EXPLAIN ANALYZE syntax
In addition to the output included in EXPLAIN, EXPLAIN ANALYZE output also includes runtime statistics for the specified query such as CPU usage, the number of rows input, and the number of rows output.

EXPLAIN ANALYZE [ ( option [, ...]) ] statement
Using EXPLAIN and EXPLAIN ANALYZE in Athena - Amazon Athena

ワークグループへのアクセスを制御するには、リソースレベルの IAM 許可、またはアイデンティティベースの IAM ポリシーを使用します。IAM ポリシーを使用するときは、常に IAM のベストプラクティスに従うようにしてください。

IAM ポリシーを使用してワークグループのアクセスを制御する - Amazon Athena

新しく追加されたキャパシティ予約は、使用した分の従量課金ではなく、あらかじめ確保したコンピューティングリソースに対して時間単位で課金されます（後述）。これにより毎月の料金が予測可能になります。また専用のコンピューティングリソースを常時稼働させるため、低レイテンシーおよびキューイングなしで重要度の高いクエリが実行可能になります。

[新機能] Amazon Athenaにキャパシティ予約を使用したSQLクエリができるようになりました | DevelopersIO

パーティションを使用するテーブルを作成するには、CREATE TABLE ステートメントの中で PARTITIONED BY 句を使用します。次の例のように、PARTITIONED BY はデータのパーティションに使用するキーを定義します。LOCATION 句では、パーティションされたデータのルートロケーションを指定します。

CREATE EXTERNAL TABLE users (
first string,
last string,
username string
)
PARTITIONED BY (id string)
STORED AS parquet
LOCATION 's3://amzn-s3-demo-bucket'

テーブルを作成した後、クエリ用にパーティションにデータをロードします。Hive スタイルのパーティションでは、MSCK REPAIR TABLE を実行します。Hive スタイルではないパーティションの場合、ALTER TABLE ADD PARTITION を使用して手動でパーティションを追加します。

データのパーティション化 - Amazon Athena

Parameterized Queriesとは、よく使用されるSQLをパラメータのみ変更して実行できる新機能です。これによって、Athena上で実行されている日々のワークロードを単純化できる他、SQLインジェクションに対する保護としても有効します。

Parameterized Queriesの実行には、事前にPrepared Statements（準備ステートメント）を作成する必要があります。Prepared Statementsには、パラメータ用のプレースホルダーが含まれ、PREPARE、EXECUTE、DEALLOCATE PREPAREの3種類のステートメントが用意されています。

まずはSELECT文でPrepared Statementsを作成してみます。

PREPARE test1 FROM
SELECT * FROM "cm-haruta"."cloudfront_logs"
WHERE status = ?
LIMIT 10

（中略）
作成したPrepared Statementsでパラメータを付与して実行してみます。

EXECUTE test1 USING 200

status = 200のレコードが無事出力されました。これは超便利！DEALLOCATE PREPAREで削除してみます。

DEALLOCATE PREPARE test1
【新機能】Amazon Athenaでパラメータ変更できるSQLを実行可能になりました！ | DevelopersIO

Athena コンソールのクエリエディタでのパラメータ化されたクエリの実行には、PREPARE、EXECUTE、および DEALLOCATE PREPARE の SQL ステートメントを使用できます。

プリペアドステートメントの SQL 構文 - Amazon Athena

MSCK REPAIR TABLE は、パーティションをメタデータに追加するだけであり、パーティションを削除しません。Amazon S3 でパーティションが手動で削除された後でメタデータからそれらのパーティションを削除するには、コマンド ALTER TABLE table-name DROP PARTITION を実行します。

MSCK REPAIR TABLE - Amazon Athena

関連する削除ファイルのサイズと数に基づいて、データファイルをより最適化されたレイアウトに書き換えることにより、Apache Iceberg テーブル内の行を最適化します。

OPTIMIZE [db_name.]table_name REWRITE DATA USING BIN_PACK
  [WHERE predicate]
OPTIMIZE - Amazon Athena

OPTIMIZE table REWRITE DATA 圧縮アクションは、関連する削除ファイルのサイズと数に基づいて、データファイルをより最適化されたレイアウトに書き換えます。構文とテーブルプロパティの詳細については、「OPTIMIZE」を参照してください。

例
次の例では、削除ファイルをデータファイルにマージし、ターゲットファイルサイズに近いファイルを生成します。ここでは、category の値が c1 です。

OPTIMIZE iceberg_table REWRITE DATA USING BIN_PACK
  WHERE category = 'c1'

（中略）

VACUUM はスナップショットの有効期限切れと孤立ファイルの削除を行います。これらのアクションにより、メタデータのサイズが小さくなり、現在のテーブル状態にないファイルのうち、テーブル用に指定された保持期間よりも古いファイルが削除されます。構文の詳細については、「VACUUM」を参照してください。

例
次の例では、テーブルプロパティを使用して過去 3 日間のデータを保持するようにテーブル iceberg_table を設定し、VACUUM を使用して古いスナップショットを期限切れにし、孤立ファイルをテーブルから削除します。

ALTER TABLE iceberg_table SET TBLPROPERTIES (
  'vacuum_max_snapshot_age_seconds'='259200'
)

VACUUM iceberg_table
Iceberg テーブルを最適化する - Amazon Athena

Athena データソースコネクタ

使用可能なデータソースコネクタ - Amazon Athena

そのAthenaをプログラム上から使う場合、CLIかBoto3あたりを使用すると思う。
start_query_execution でqueryを実行し、
その終了を get_query_execution で監視すると思う。

コードでは、この get_query_execution をつかってqueryのステータスを監視し、waitしたりException吐いたりしたいと思う。
get_query_execution が返してくるqueryのstatusは以下である。

QUEUED
RUNNING
SUCCEEDED
FAILED
CANCELLED

AthenaのQUEUEのステータス #AWS - Qiita

Partition Projectionとは
パーティションの設定は手動で行うこともできますが、AthenaではPartition Projectionという機能を提供しています。
この機能を使えばパーティション管理を自動化できます。
手動の場合、パーティションのデータが増えるたびに追加する必要がありますが、Partition Projectionを使うことで増えた場合に自動で認識しパーティションを追加してくれます。

（中略）

まずはDDLが以下のようになります。

CREATE EXTERNAL TABLE IF NOT EXISTS `<データベース名>`.`partition_test_table_01` (
  `temperature` string,
  `pressure` string,
  `humidity` string,
  `date` string
)
PARTITIONED BY (
`partition_date` string
)
ROW FORMAT SERDE 'org.openx.data.jsonserde.JsonSerDe'
LOCATION 's3://<S3バケットのパス>/'
TBLPROPERTIES (
  'classification' = 'json',
  'projection.enabled'='true',
  'projection.partition_date.type' = 'date',
  'projection.partition_date.range' = '2020/10/01,NOW',
  'projection.partition_date.format' = 'yyyy/MM/dd/HH',
  'projection.partition_date.interval' = '1',
  'projection.partition_date.interval.unit' = 'HOURS',
  'storage.location.template' = 's3://<S3バケットのパス>/${partition_date}'
)
Amazon Athena のPartition Projection(パーティション射影)の設定方法の確認と、手動でパーティションを追加する場合との比較 | DevelopersIO

パーティションプルーニングとパーティション射影を理解する
パーティションプルーニングは、メタデータを収集し、クエリに適用されるパーティションのみに「プルーニング」します。多くの場合、これによってクエリが高速化されます。Athena は、パーティション射影用に設定されたテーブルなどのパーティション列があるすべてのテーブルに対してパーティションプルーニングを使用します。

通常、クエリを処理する場合、Athena はパーティションプルーニングを実行する前に AWS Glue Data Catalog に対して GetPartitions 呼び出しを行います。テーブルに多数のパーティションがある場合、GetPartitions を使用すると、パフォーマンスに悪影響が及ぶ可能性があります。これを回避するには、パーティション射影を使用します。パーティション射影を設定すると、Athena が独自にパーティションを構築するために必要なすべての情報を得ることができるため、GetPartitions を呼び出す必要がなくなります。

Amazon Athena でパーティション射影を使用する - Amazon Athena

Amazon Athena では、リソースの計画、設定、管理を必要とせずに、Apache Spark を使用してインタラクティブに簡単にデータ分析と探索を実行できます。Athena で Apache Spark アプリケーションを実行するということは、処理用 Spark コードを送信し、追加の設定をしなくても結果を直接受け取ることを意味します。Amazon Athena コンソールのシンプルなノートブックエクスペリエンスを使用すると、Python または Athena ノートブック API を使用して Apache Spark アプリケーションを開発できます。Amazon Athena の Apache Spark はサーバーレスであり、オンデマンドで自動的にスケーリングされるため、データ量や処理要件の変化に合わせて瞬時に処理できます。

Amazon Athena で Apache Spark を使用する - Amazon Athena

Athena では、ワークグループ、データカタログ、キャパシティ予約などのリソースはタグ付け可能なリソースです。たとえば、アカウントにワークグループの一連のタグを作成して、ワークグループの所有者を追跡したり、目的によってワークグループを識別したりできます。また、Billing and Cost Management コンソールでタグをコスト配分タグとして有効にすると、クエリの実行に関連するコストがそのコスト配分タグとともにコストと使用状況レポートに表示されます。
スキャンされたデータの合計量がしきい値を超えた場合に、Amazon SNS トピックに通知をプッシュできます。

Athena リソースにタグ付けする - Amazon Athena
Glue

VPC エンドポイントを使用する場合は、そのエンドポイントをルートテーブルに追加します。詳細については、「AWS Glue 用のインターフェイス VPC エンドポイントの作成」と「前提条件」を参照してください。

VPC の JDBC データストアに接続する - AWS Glue
  • スケジュール – 定義したスケジュールに基づいて、ワークフローが開始されます。スケジュールは、日次、週次、月次その他に設定することも、cron 式に基づきカスタムスケジュールを構成することも可能です。
  • オンデマンド – ワークフローは、AWS Glue コンソール、API、あるいは AWS CLI から手動で開始されます。
  • EventBridge イベント – ワークフローは、単一の Amazon EventBridge イベントまたは、バッチ化された Amazon EventBridge イベントの発生時に開始されます。このトリガータイプでは、AWS Glue はイベント駆動型アーキテクチャのイベントコンシューマとして機能します。すべての EventBridge イベントタイプがワークフローを開始できます。一般的なユースケースとしては、Amazon S3 バケット に新しいオブジェクトが保存された(S3 の PutObject オペレーション) 場合が挙げられます。
AWS Glue のワークフローの概要 - AWS Glue

動的フレームの作成時の Amazon S3 ストレージクラスの除外

ダイナミックフレームの作成時に Amazon S3 のストレージクラスを除外するには、excludeStorageClasses で additionalOptions を使います。AWS Glue では指定されたストレージクラスに対応するファイルを、独自の Amazon S3 Lister の実装を使用して自動的にリストアップし、除外します。

次に、動的フレームの作成時に GLACIER および DEEP_ARCHIVE ストレージクラスを除外する、Python および Scala の例を示します。

Python の例

glueContext.create_dynamic_frame.from_catalog(
    database = "my_database",
    tableName = "my_table_name",
    redshift_tmp_dir = "",
    transformation_ctx = "my_transformation_context",
    additional_options = {
        "excludeStorageClasses" : ["GLACIER", "DEEP_ARCHIVE"]
    }
)
Amazon S3 ストレージクラスの除外 - AWS Glue

FindMatches 変換を使用すると、レコードに共通の一意の識別子がなく、正確に一致するフィールドがない場合でも、データセット内の重複レコードまたは一致するレコードを識別できます。

Glueの「FindMatches 変換」機能を使ってデータセット内の「一致するレコードの重複排除」、「検索」をする | DevelopersIO

postactions: COPY コマンドが成功した後に実行する SQL コマンドをセミコロンで区切ったリスト。コマンドが失敗すると、Amazon Redshift は例外をスローします。
注: 後処理パラメータには改行文字を含めることはできません。

AWS Glue ジョブに対する SQL コマンドを Amazon Redshift で実行する | AWS re:Post

AWS Glue のワークフローの概要
開始トリガーには、以下の 3 種類があります。

  • スケジュール – 定義したスケジュールに基づいて、ワークフローが開始されます。スケジュールは、日次、週次、月次その他に設定することも、cron 式に基づきカスタムスケジュールを構成することも可能です。
  • オンデマンド – ワークフローは、AWS Glue コンソール、API、あるいは AWS CLI から手動で開始されます。
  • EventBridge イベント – ワークフローは、単一の Amazon EventBridge イベントまたは、バッチ化された Amazon EventBridge イベントの発生時に開始されます。このトリガータイプでは、AWS Glue はイベント駆動型アーキテクチャのイベントコンシューマとして機能します。すべての EventBridge イベントタイプがワークフローを開始できます。一般的なユースケースとしては、Amazon S3 バケット に新しいオブジェクトが保存された(S3 の PutObject オペレーション) 場合が挙げられます。
AWS Glue のワークフローの概要 - AWS Glue

Flexジョブとは？
専用ではなく予備のコンピューティングリソースを利用してAWS Glueジョブを実行することで、最大34%コストを削減可能な実行オプションです。
（中略）
リソースが無い場合は確保できるまでジョブ開始されませんが、特に開発環境でのテスト実行や、時間がかかっても問題ない優先度の低い夜間実行などのケースでコスト削減できるうれしいアップデートですね。設定も簡単ですのでGlue 3.0をお使いでユースケースに当てはまる方はぜひお試しください！

[アップデート]AWS GlueでのETLワークロードのコスト削減する実行オプション『Flexジョブ』が登場しました | DevelopersIO

クローラーに既存のロールを指定する場合は、そのロールに AWSGlueServiceRole ポリシーまたは同等のポリシー (またはこのポリシーのスコープダウンバージョン) と、必要なインラインポリシーが含まれてることを確認します。

クローラーの前提条件 - AWS Glue

AWS Glue DataBrew

  • NEST_TO_MAP コマンドは、複数の列の値をマップ形式（キーと値のペア）に変換し、単一の列として格納する。
  • NEST_TO_ARRAY コマンドは、指定した複数の列を配列としてネスト化するコマンド。
  • UNNEST_ARRAY はネストされたデータから配列を生成するが、既存のデータから配列として列を分解する。
  • UNNEST_MAP は、ネストされたマップ形式のデータを分解するためのコマンド。
Data structure recipe steps - AWS Glue DataBrew

AWS Glue メトリクスは、Amazon CloudWatch でも利用できます。スケジュールされたジョブのどの AWS Glue メトリクスでもアラームを設定できます。
アラームを設定するいくつかの一般的なシナリオは次のとおりです。

  • ジョブのメモリ不足 (OOM): メモリ使用率が AWS Glue ジョブのドライバーまたはエグゼキュターの通常平均を超えた場合にアラームを設定します。
  • 散在したエグゼキュター: AWS Glue ジョブでエグゼキュターの数が長時間一定のしきい値を下回ったときにアラームを設定します。
  • データバックログまたは再処理: CloudWatch の数式を使用して、ワークフローの個別のジョブから得られたメトリクスを比較します。その後、生成された式の値 (あるジョブにより書き込まれたバイトと後続のジョブにより読み込まれたバイトの割合など) でアラームをトリガーできます。
AWS Glue ジョブプロファイルでの Amazon CloudWatch アラームの設定 - AWS Glue

Amazon EventBridge 統合でのアラートと通知の設定
AWS Glue Data Quality は EventBridge イベントのパブリッシュに対応しています。このイベントは、Data Quality ルールセットの評価実行が完了すると生成されます。これにより、Data Quality のルールが失敗した場合のアラートを、簡単に設定できます。

アラート、デプロイ、スケジュールの設定 - AWS Glue

Detect PII transform は、データソース内の個人識別情報 (PII) を識別します。エンティティを選択し、データのスキャン方法、Detect PII transform によって識別されてきた PII エンティティで何を行うかを識別します。

Detect PII transform は、定義したエンティティ、または AWS によって事前定義されたエンティティを検出、マスク、削除する機能を提供します。これにより、コンプライアンスを高め、責任を軽減できます。例えば、個人を特定でき読み取りが可能な情報がデータ内に存在しないことを確認した上で、固定文字列の社会保障番号 (例: xxx-xx-xxxx)、電話番号、または住所をマスクすることが考えられます。

AWS Glue Studio の外部で機密データを使用するには、「AWS Glue Studio 外での機密データ検出の使用」を参照してください。

機密データを検出して処理する - AWS Glue

AWS Glue Studio では機密データを検出することができますが、AWS Glue Studio 外でこの機密データ検出機能を使用することも可能です。
AWS マネージド PII タイプを使用した機密データの検出
AWS Glue は、AWS Glue ETL ジョブで 2 つの API を提供します。これらは、detect() および classifyColumns() です。

  detect(frame: DynamicFrame, 
      entityTypesToDetect: Seq[String], 
      outputColumnName: String = "DetectedEntities",
      detectionSensitivity: String = "LOW"): DynamicFrame

 detect(frame: DynamicFrame, 
      detectionParameters: JsonOptions,
      outputColumnName: String = "DetectedEntities",
      detectionSensitivity: String = "LOW"): DynamicFrame
      
  classifyColumns(frame: DynamicFrame, 
      entityTypesToDetect: Seq[String], 
      sampleFraction: Double = 0.1, 
      thresholdFraction: Double = 0.1,
      detectionSensitivity: String = "LOW")
AWS Glue Studio 外での機密データ検出の使用 - AWS Glue

Example for write_dynamic_frame
This example writes the output locally using a connection_type of S3 with a POSIX path argument in connection_options, which allows writing to local storage.

glueContext.write_dynamic_frame.from_options(\
frame = dyf_splitFields,\
connection_options = {'path': '/home/glue/GlueLocalOutput/'},\
connection_type = 's3',\
format = 'json')
DynamicFrameWriter class - AWS Glue

AWS Glue トリガー
起動されると、トリガーは指定されたジョブとクローラを開始できます。トリガーは、オンデマンドで、スケジュールに基づいて、またはイベントの組み合わせに基づいて起動します。

AWS Glue トリガー - AWS Glue

Athena のテーブルをパーティショニングする場合、AWS Glue Data Catalog以外にもPartition Projectionも使えます。
Partition Projectionは GetPartitions API を呼び出さないため、大量のパーティションにも強い一方で、Amazon Athenaにしか使えません。
一方で、今回紹介したパーティション・インデックスはAWS Glue Data Catalogの一機能のため、同カタログを利用するAthena, EMR, Redshift Spectrumなど様々なサービスがインデックスの効果を享受できます。
AWS上でデータレイクを構築し、様々なビッグデータサービスを利用している場合は、AWS Glue Data Catalogでメタデータを一元管理し、 AWS WAFなどのログ解析のためにピンポイントに S3/Athena だけを利用している場合は、Athena Projection も検討しましょう。

大量のパーティションを持つデータソースにはAWS Glue Data Catalogパーティション・インデックスを有効にしてクエリを最適化しよう | DevelopersIO

AWS Glue Data Qualityとは？

自動的にデータを分析、データの統計情報を収集
推奨されるデータ品質ルールを設定し、それに基づき検証を開始する。推奨されたデータ品質ルールは変更することも、新しいルールを追加することも可能。
データ品質が低下した場合に、ユーザに警告するアクションを設定することも可能。データ品質ルールとアクションは、データパイプライン上でGlueのETLジョブに設定することも可能。
OSSのDeequを使用してルールを評価する。

AWS Glue Data Qualityを試してみた #glue - Qiita

テーブルのプロパティを設定しておくと、Amazon S3 データストアからファイルが読み取られる際に、AWS Glue の ETL ジョブでそれらのファイルをグループ化させることができます。これらのプロパティを使用すると、各 ETL タスクでは入力ファイルのグループを単一のインメモリパーティションに読み取ることができます。これは、Amazon S3 データストアに多数の小さいファイルがある場合に便利です。特定のプロパティを定義する際には、Amazon S3 データパーティション内のファイルをグループ化し、そのグループの読み取り用のサイズを設定することを AWS Glue に指示します。また、create_dynamic_frame.from_options メソッドを使用した Amazon S3 データストアからの読み取りのために、これらのオプションを設定することもできます。

大きなグループの入力ファイルの読み取り - AWS Glue

GroupSize パラメーターの値を増やす
ダイナミックフレームを使用しており、Amazon Simple Storage Service (Amazon S3) データセットに 50,000 を超えるファイルがある場合、AWS Glue ETL ジョブは自動的にファイルをグループ化します。より少なく、サイズが大きい出力ファイルを作成するには、GroupSize の値を大きくします。詳細については、「大きなグループでの入力ファイルの読み取り」を参照してください。

より大きなファイルを出力するように AWS Glue ETL ジョブを設定する | AWS re:Post

複数の型を発見した場合に両方の型を持つことで処理を中断することなく進めることができます。Choice型はResolveChoiceメソッドで型を解決します。（ResolveChoice クラス）

AWS再入門ブログリレー2022 AWS Glue編 | DevelopersIO

Spark のシャッフルデータの保存
シャッフルは、データがパーティション間で再配置されるたびに行われる Spark ジョブの重要なステップです。これが必要なのは、join、 groupByKey、reduceByKey、repartition などのさまざまな変換に、処理を完了するために他のパーティションからの情報が必要なためです。Spark は各パーティションから必要なデータを収集し、新しいパーティションに結合します。シャッフル中、データはディスクに書き込まれ、ネットワーク経由で転送されます。その結果、シャッフルオペレーションはローカルディスク容量に制約されます。Spark の No space left on device または MetadataFetchFailedException エラーは、エグゼキュターに十分なディスク領域がなく、リカバリがない場合に発生します。

Spark のシャッフルデータの保存 - AWS Glue

AWS Glue バージョン 1.0 以前のジョブでは、コンソールを使用してジョブを設定し、[Worker type] (ワーカータイプ) に [Standard] (標準) を指定する場合は、[Maximum capacity] (最大キャパシティー) が設定され、[Number of workers] (ワーカー数) は [Maximum capacity] (最大キャパシティー) から 1 を引いた値になります。AWS Command Line Interface (AWS CLI) または AWS SDK を使用する場合は、[Max capacity] (最大キャパシティー) パラメータを指定することも、[Worker type] (ワーカータイプ) と [Number of workers] (ワーカー数) の両方を指定することもできます。

AWS Glue バージョン 2.0 以降のジョブでは、[最大キャパシティ] の指定はできません。代わりに、[Worker type] (ワーカータイプ) と [Number of workers] (ワーカー数) を指定します。

AWS Glue で Spark ジョブに関するジョブプロパティの構成 - AWS Glue

このブログ記事では、AWS Glue リソースを備えているのとは異なるアカウントや AWS リージョンのデータストアにアクセスする方法について説明します。

AWS Glue のクロスアカウントおよびクロスリージョンの接続を行う | Amazon Web Services ブログ
Amazon MSK
AWS Data Exchange

AWS Data Exchangeは、Reuters、Foursquare、Change Healthcare、Vortexa、IMDbなどのサードパーティが提供するデータセットをAmazon Simple Storage Service（Amazon S3）を介して購読・利用できるサービスです。欲しいカタログをサブスクライブして必要データをまとめて自身が持つS3バケットにエクスポートできます。データセットを利用するだけでなく、データを提供する側（データプロバイダー）になることも可能です。

[新機能]データセットへの新たなアクセス手段 AWS Data Exchange for APIsが発表されました #reinvent | DevelopersIO
Redshift

Amazon S3 にファイルをアップロードする前に、ファイルを複数のファイルに分割します。分割されたファイルは COPY コマンドで並列処理を使ってロードされます。ファイルの数はクラスター内のスライスの数の倍数である必要があります。ロードデータファイルを分割して大体同じサイズにし、圧縮後に 1 MB ～ 1 GB になるようにします。

COPY コマンドを使用し、Amazon S3 からロードする - Amazon Redshift 
copy favoritemovies from 'dynamodb://ProductCatalog'
iam_role 'arn:aws:iam::0123456789012:role/MyRedshiftRole'
readratio 50;
COPY from Amazon DynamoDB - Amazon Redshift
  • Cross-account integration considerations with CMK
  • DynamoDB zero-ETL integration with Amazon Redshift
  • Loading data from DynamoDB into Amazon Redshift with the COPY command
Integrating with Amazon Redshift - Amazon DynamoDB

EventBridge で、Data API イベントをモニタリングできます。EventBridge では、データは AWS Lambda や Amazon SNS などのターゲットにルーティングされます。これらのイベントは、CloudWatch Events に表示されるイベントと同じで、AWSリソースの変更を記述するシステムイベントのストリームをほぼリアルタイムで配信します。イベントは、Amazon Redshift データベースを含むアカウントに送信されます

Amazon EventBridge での Amazon Redshift データ API のイベントのモニタリング - Amazon Redshift

ネイティブ ID プロバイダー (IdP) フェデレーション
ID プロバイダーと Amazon Redshift の間の事前設定を完了するには、いくつかの手順を実行します。まず、Amazon Redshift をサードパーティーアプリケーションとして ID プロバイダーに登録し、必要な API アクセス許可を要求します。次に、ID プロバイダーでユーザーとグループを作成します。最後に、ID プロバイダーに固有の認証パラメータを設定する SQL ステートメントを使用して、ID プロバイダーを Amazon Redshift に登録します。

Amazon Redshift 用のネイティブ ID プロバイダー (IdP) フェデレーション - Amazon Redshift

このコマンドはマテリアライズドビューでも機能します。

TRUNCATE materialized_view_name
TRUNCATE - Amazon Redshift

Federated queries can work with external databases in

Querying data with federated queries in Amazon Redshift - Amazon Redshift

STL_ALERT_EVENT_LOG
パフォーマンスの問題を示している可能性のある条件がクエリオプティマイザによって特定された場合にアラートを記録します。クエリパフォーマンスを向上させる機会を特定するには、STL_ALERT_EVENT_LOG ビューを使用します。

STL_ALERT_EVENT_LOG - Amazon Redshift

Amazon RedshiftからAmazon Kinesis Data Streamのストリームデータをマテリアライズド・ビュー経由でニアリアルタイムにインジェストする機能が2022年2月からパブリック・プレビュー提供されています。
（中略）
Amazon Kinesis Data StreamのストリームデータをRedshiftから利用したい場合、従来は Amazon Kinesis Data Firehoseを経由して一度 S3 に出力し、S3 データを Redshift に COPY する必要があり、ストイームデータのリアルタイム性が損なわれていました。

本機能を利用すると、マテリアライズド・ビューの更新レイテンシーが発生するものの、ニアリアルタイムにKinesis Data Streamsのデータをインジェストできます。

Amazon RedshiftからAmazon Kinesisのストリームデータをニアリアルタイムにインジェストしてみた | DevelopersIO

Amazon Redshift Query Editor V2 を使用すると、SQL クエリを自動化してスケジュールに従って実行させることができます。スケジュール設定されたクエリとは、指定された時間または間隔で自動的に実行される SQL ステートメントであり、定期的に繰り返されるデータオペレーションや分析タスクを効率的に管理できます。バッチ処理の効率化、定期的なレポートの生成、Amazon Redshift 環境内のデータパイプラインのメンテナンスなどを行う場合は、クエリのスケジュールを設定できます。

スケジュールされたクエリを使用すると、抽出、変換、ロード (ETL) ワークフローの自動化、最新のインサイトでのダッシュボードの更新、さまざまなデータ管理ルーチンの運用が容易になります。次のページでは、Amazon Redshift ワークロードを最適化するためにスケジュール設定されたクエリを作成、設定、管理するプロセスについて詳しく説明します。

クエリエディタ v2 でスケジュールされたクエリ - Amazon Redshift

クラスターキーの管理に HSM を使用するように選択した場合、Amazon Redshift と HSM の間に信頼されたネットワークリンクを構成する必要があります。これを行うには、クライアント証明書とサーバー証明書の設定が必要です。信頼された接続は、暗号化と復号化のオペレーション中に、HSM と Amazon Redshift との間で暗号化キーを渡すために使用されます。

Amazon Redshift データベース暗号化 - Amazon Redshift
  • ファイルタイプが Redshift Spectrum クエリのパフォーマンスに大きな影響を与えることを検討してください。パフォーマンスを向上させるには、ORC や Parquet などの列エンコードされたファイルを使用し、非常に小さなディメンションテーブルにのみ CSV 形式を使用します。
  • プレフィックスベースのパーティショニングを使用して、パーティションプルーニングを活用します。つまり、データレイク内のパーティションにキー指定されたフィルターを使用します。
  • Redshift Spectrum は大規模なリクエストを処理するために自動的にスケーリングされるため、Redshift Spectrum ではできるだけ多くの処理を行います (述語のプッシュダウンなど）。
  • 頻繁にフィルタリングされる列のパーティションファイルには注意してください。データが 1 つ以上のフィルタリングされた列によってパーティション分割されている場合、Redshift Spectrum はパーティションプルーニングを活用し、不要なパーティションやファイルのスキャンをスキップできます。一般的な方法では、時間に基づいてデータをパーティション化します。
Amazon Redshift Spectrum を使用するためのベストプラクティス - AWS 規範ガイダンス
Lambda

Lambda レイヤーは、補助的なコードやデータを含む .zip ファイルアーカイブです。レイヤーには通常、ライブラリの依存関係、カスタムランタイム、または設定ファイルが含まれています。

レイヤーの使用を検討する理由は複数あります。

  • デプロイパッケージのサイズを小さくするため。関数コードとともにすべての関数依存関係をデプロイパッケージに含める代わりに、レイヤーに配置します。これにより、デプロイパッケージは小さく整理された状態に保たれます。
  • コア関数ロジックを依存関係から分離するため。レイヤーを使用すると、関数コードと独立して関数の依存関係を更新でき、その逆も可能となります。これにより、関心事の分離が促進され、関数ロジックに集中することができます。
  • 複数の関数間で依存関係を共有するため。レイヤーを作成したら、それをアカウント内の任意の数の関数に適用できます。レイヤーがない場合、個々のデプロイパッケージに同じ依存関係を含める必要があります。
  • Lambda コンソールのコードエディターを使用するため。コードエディターは、関数コードの軽微な更新をすばやくテストするのに便利なツールです。ただし、デプロイパッケージのサイズが大きすぎる場合は、エディターを使用できません。レイヤーを使用すると、パッケージのサイズが小さくなり、コードエディターの使用制限を解除できます。
  • 組み込み SDK バージョンをロックするため。AWS が新しいサービスや機能をリリースすると、組み込み SDK は予告なく変更される場合があります。SDK バージョンは、必要な特定のバージョンで Lambda レイヤーを作成することでロックできます。その後、サービスに組み込まれたバージョンが変更されても、関数は常にレイヤーのバージョンを使用します。
レイヤーによる Lambda 依存関係の管理 - AWS Lambda
  • Reserved concurrency – This sets both the maximum and minimum number of concurrent instances allocated to your function. When a function has reserved concurrency, no other function can use that concurrency. Reserved concurrency is useful for ensuring that your most critical functions always have enough concurrency to handle incoming requests. Additionally, reserved concurrency can be used for limiting concurrency to prevent overwhelming downstream resources, like database connections. Reserved concurrency acts as both a lower and upper bound - it reserves the specified capacity exclusively for your function while also preventing it from scaling beyond that limit. Configuring reserved concurrency for a function incurs no additional charges.
  • Provisioned concurrency – This is the number of pre-initialized execution environments allocated to your function. These execution environments are ready to respond immediately to incoming function requests. Provisioned concurrency is useful for reducing cold start latencies for functions and designed to make functions available with double-digit millisecond response times. Generally, interactive workloads benefit the most from the feature. Those are applications with users initiating requests, such as web and mobile applications, and are the most sensitive to latency. Asynchronous workloads, such as data processing pipelines, are often less latency sensitive and so do not usually need provisioned concurrency. Configuring provisioned concurrency incurs additional charges to your AWS account.
Configuring provisioned concurrency for a function - AWS Lambda
DataSync

AWS DataSyncとは、オンプレミスからAWS（Amazon S3 / Amazon EFS）へ、AWS（Amazon S3 / Amazon EFS）からオンプレミスへ、データの移動を簡単におこなえるマネージド型のデータ転送サービスです。

AWS DataSyncはオンプレミスにエージェントを導入することで使用可能です。このエージェントを使用することで、仮想マシンとしてデプロイされ、NFSプロトコルを介して既存のストレージに接続し、AWS DataSyncサービスとの間でデータの送受信を行います。

AWS DataSyncについて調べてみた #Cloud - Qiita

AWS DataSync は、オプトインリージョンを含め、商用 AWS パーティションのすべてのリージョン間でのエージェントレスのクロスリージョンデータ転送をサポートするようになりました。今回の更新により、DataSync エージェントをデプロイまたは管理することなく、異なるリージョンの Amazon S3、Amazon EFS、Amazon FSx などの AWS ストレージサービス間で数百万のファイルまたはオブジェクトを転送できるようになります。

AWS DataSync、エージェントレスのクロスリージョンデータ転送のサポートを拡大し、オプトインリージョンも対象に - AWS
Step functions
  • Amazon States Language とは
  • 共通 State フィールド
  • Task
  • Choice
  • Wait
  • Succeed
  • Fail
  • Parallel
  • Map
  • Pass
Step Functionsのステータス(State)用語についての説明と使い方についてまとめてみました。 | DevelopersIO
Open Table Format

RDBをリアルタイムにdata lakeに連携したい/CDC (Change Data Capture)/なぜ実現困難だったのか/Upsertとトランザクション/データレイクをデータソースにする

Open Table Format (OTF) のユースケース (#6, #7)
DynamoDB

Application Auto Scaling では、ユーザー定義の条件に従ってスケーラブルリソースを自動的にスケールすることができます。

  • ターゲット追跡スケーリング – 特定の CloudWatch メトリクスのターゲット値に基づいてリソースをスケールします。
  • ステップスケーリング – 超過アラームのサイズによって異なる一連のスケーリング調整値に基づいてリソースをスケーリングします。
  • スケジュールに基づくスケーリング – 1 回のみ、または定期的なスケジュールでリソースをスケールします。
  • 予測スケーリング – 履歴データに基づいて予想される負荷に合わせてリソースをプロアクティブにスケーリングします。
Application Auto Scaling とは - Application Auto Scaling
KMS

Amazon S3 のサーバーサイド暗号化のオプションに二重層サーバーサイド暗号化 (DSSE-KMS) が追加されたため、このブログでは DSSE-KMS の概要について記載します！
（中略）
SSE-KMS は、Amazon S3 バケットへオブジェクトをアップロードする時に、 Amazon S3 バケット内のオブジェクトに2層の暗号化を適用する新しい暗号化オプションです。
FIPS 準拠のための CNSSP 15と DAR CP バージョン5.0ガイダンスを満たすよう設計されており、データに複数層の暗号化を適用する規制要件に対応できます。
米国国防総省（DoD）の顧客など、高度に規制された業界の厳格なセキュリティ基準も簡単に満たせます。

DSSE-KMS による暗号化の各層では、256ビットの AES-GCM（Advanced Encryption Standard with Galois Counter Mode）アルゴリズムが使用されます。
256ビットの鍵の長さを使用する AES は、軍用レベルの暗号化技術で、米国政府の重要機密情報の暗号化にも採用されており、米国政府の中で極秘情報に分類されるデータを暗号化できるほど安全とされています。

[アップデート] Amazon S3 に二重層サーバーサイド暗号化が追加されました。 | DevelopersIO
DMS

タスクメトリクスは、レプリケーションホストとソースエンドポイント、およびレプリケーションホストとターゲットエンドポイントの統計に分割されます。CDCLatencySource と CDCLatencyTarget を使用して、これらの関連する統計を比較することで、タスクのレイテンシーの原因を特定できます。たとえば、CDCLatencySource 値が CDCLatencyTarget 値とほぼ同じである場合は、まずソース側を確認する必要があります。ただし、CDCLatencyTarget が CDCLatencySource よりも高い場合は、ターゲット側のレイテンシーの確認に集中する必要があります。

DMS AWS タスクのモニタリング - AWS データベース移行サービス
git
CloudWatch

Example 1: Subscription filters with Kinesis Data Streams
Example 2: Subscription filters with AWS Lambda
Example 3: Subscription filters with Amazon Data Firehose
Example 4: Subscription filters with Amazon OpenSearch Service

Log group-level subscription filters - Amazon CloudWatch Logs
Amazon Detective

Amazon Detective では、潜在的なセキュリティ問題や不審なアクティビティの根本原因を簡単に分析、調査し、すばやく特定できます。Amazon Detective は、AWS リソースからログデータを自動的に収集し、機械学習、統計的分析、グラフ理論を使用して、リンクされたデータセットを構築します。これにより、より迅速かつ効率的なセキュリティ調査を簡単に行えます。

セキュリティ調査の可視化 - Amazon Detective - AWS

（中略）

このフェーズをがっぽり置き換えたものが下記の図です。

[神ツール]セキュリティインシデントの調査が捗るAmazon DetectiveがGAしたのでメリットとオススメの使い方を紹介します | DevelopersIO
VPC エンドポイント
特徴 ゲートウェイエンドポイント インターフェースエンドポイント
対応サービス S3とDynamoDBのみ 多数のAWSサービス
料金 無料 時間単位の料金とデータ処理料金が発生
技術的実装 ルートテーブルにエントリを追加 VPC内にENI (Elastic Network Interface) を作成
接続方法 AWS内部ネットワーク経由 プライベートIPアドレス経由
リージョン制限 同一リージョン内のみ クロスリージョン接続可能
2種類のエンドポイント、違いを比べてみた！〜ゲートウェイ型&インターフェース型〜 | DevelopersIO
Storage gateway

Amazon S3 File Gatewayは、オンプレミス環境とAWSクラウドをシームレスに接続するハイブリッドクラウドストレージサービス、AWS Storage Gatewayのソリューションの一つです。
AWS Storage Gatewayは、以下の3つのゲートウェイソリューションを提供しています。

  • Amazon S3 File Gateway
    • オンプレミスのアプリケーションで使用するファイル共有（SMBまたはNFSプロトコル）をAWSクラウドに接続し、Amazon S3をバックエンドストレージとして利用可能なソリューションです。
  • Tape Gateway
    • 仮想テープライブラリ（VTL）を提供し、オンプレミスのバックアップアプリケーションを変更せずに、AWSクラウドで仮想テープを管理するためのソリューションです。
  • Volume Gateway
    • オンプレミスのブロックストレージ（iSCSI接続）をAWSクラウドに統合するためのソリューションです。頻繁にアクセスするデータをオンプレミスにキャッシュし、その他のデータをクラウドに保存するキャッシュモードと、完全なデータコピーをオンプレミスに保持しながら、クラウドにバックアップを作成するストアモードを提供します。
ファイルサーバーをAWSに移行！Amazon S3 File GatewayとAmazon FSxの選び方＆構築手順について解説します | コラム | クラウドソリューション｜サービス｜法人のお客さま｜NTT東日本
Amazon Managed Workflow for Apache Airflow（MWAA）

MWAAは次の3つについて使用した分だけの料金がかかります。

1つ目は環境クラスで、Small、Medium、Largeの3種類が提供されており、各ノードのvCPUが異なります。2つ目がWorkerインスタンスの追加分で、オートスケーリングでノードが増減するため、2ノード目以降の追加されたインスタンスがカウントされます。3つ目がメタデータベースの保存量です。環境クラスと追加のWorkerインスタンスは秒単位で課金されます。

AWSのマネージドAirflow、Amazon Managed Workflow for Apache Airflow（MWAA）が登場！ | DevelopersIO

Amazon MWAA は AWS サービスとオンプレミスのシステム間でシームレスなオーケストレーションを実現します。

Amazon MWAA v1.x から v2.x へのアップグレードのベストプラクティス | Amazon Web Services ブログ

参考