AWS Certified Data Engineer – Associate

AWS Glue 接続用に設定されたサブネットに、Amazon S3 VPC ゲートウェイ エンドポイント、またはサブネットのルート テーブルに NAT ゲートウェイへのルートがあることを確認してください。

https://repost.aws/knowledge-center/glue-s3-endpoint-validation-failed

B
AWS Lake Formation: AWS 上のデータレイクを管理するために特別に設計されており、データへのアクセスを保護および制御する機能を提供します。行レベルのセキュリティ: Lake Formation を使用すると、行レベルのセキュリティを含む、きめ細かいアクセス制御ポリシーを定義できます。つまり、各顧客に関連付けられている国など、特定の条件に基づいてデータへのアクセスを制限するポリシーを適用できます。最小限の運用労力: Lake Formation 内でポリシーを定義すると、オプション A、C、D のように国ごとに個別のテーブルやビューを作成する必要がなく、ポリシーを一元管理して S3 バケット内のデータに適用できます。これにより、運用上のオーバーヘッドと複雑さが軽減されます。

A
AWS DataSyncは主に、オンプレミスのストレージ システムとAWS ストレージ サービス間、および異なるAWSストレージ サービス間でのデータの移動を簡素化、自動化、高速化するように設計されたデータ転送サービスに使用されます。その主な役割は、サードパーティのデータセットにアクセスすることではなく、大量のデータを効率的に転送することです。対照的に、AWS Data Exchangeは、クラウド内のサードパーティデータを検出してサブスクライブするために特別に設計されており、これらのデータセットへの直接APIアクセスを提供します。これは、最小限のオーバーヘッドでこのデータを推奨システムに統合するという企業のニーズに完全に一致します。

B
B. カスタム Python スクリプトを Lambda レイヤーにパッケージ化します。 Lambda レイヤーを Lambda 関数に適用します。説明: Lambda レイヤーを使用すると、複数の Lambda 関数にわたる共有コードと依存関係を一元管理できます。カスタム Python スクリプトを Lambda レイヤーにパッケージ化すると、スクリプトに変更が加えられるたびにレイヤーを更新するだけで済み、そのレイヤーを使用するすべての Lambda 関数が更新を自動的に継承します。このアプローチにより、手作業が軽減され、機能間の一貫性が確保されます。

B
CRAWLING と ETL は Glue ワークフローの主な機能であり、MS SQL がサポートされています。
https://docs.aws.amazon.com/glue/latest/dg/crawler-data-stores.html

B
B. Amazon Redshift データ API を使用します。説明: Amazon Redshift Data API は、Amazon Redshift に対してクエリを実行するために JDBC または ODBC ドライバーを使用する代わりとなる軽量の HTTPS ベースの API です。これにより、接続やドライバーを管理することなく、アプリケーション内から直接 SQL クエリを実行できるようになります。これにより、WebSocket または JDBC 接続を管理および維持する必要がなくなるため、運用上のオーバーヘッドが軽減されます。
https://aws.amazon.com/de/blogs/big-data/using-the-amazon-redshift-data-api-to-interact-with-amazon-redshift-clusters/#:~:text=The%20Amazon%20Redshift%20Data%20API%20is%20not%20a%20replacement%20forsupported%20by%20the%20AWS%20SDK

B
B. ユースケースごとに Athena ワークグループを作成します。ワークグループにタグを適用します。タグを使用してワークグループに適切な権限を適用する IAM ポリシーを作成します。説明: Athena ワークグループを使用すると、さまざまなワークロード、ユーザー、権限を分離して管理できます。ユースケースごとに個別のワークグループを作成することで、クエリ履歴へのアクセスを制御し、権限を管理し、ワークロードごとに個別にリソース使用量制限を適用できます。ワークグループにタグを適用すると、ユースケースに基づいてワークグループを分類および整理できるため、ポリシー管理が簡素化されます。
https://docs.aws.amazon.com/athena/latest/ug/user-created-workgroups.html

A
A. Glue ジョブのプロパティで FLEX 実行クラスを選択します。説明: AWS Glue の FLEX 実行クラスを使用すると、ジョブが Glue サービス内のアイドルリソースを使用できるようになり、STANDARD 実行クラスと比較してコストを大幅に削減できます。 FLEX を使用すると、リソースが利用可能なときに Glue ジョブが実行されます。これは、特定の時間枠内に完了する必要のないジョブにとってはコスト効率の高いアプローチです。

A
A. イベントタイプが s3:ObjectCreated:* である S3 イベント通知を作成します。フィルター ルールを使用して、サフィックスに .csv が含まれる場合にのみ通知を生成します。 Lambda 関数の Amazon リソースネーム (ARN) をイベント通知の宛先として設定します。説明: このソリューションは、.csv ファイルが S3 バケットにアップロードされた場合にのみ Lambda 関数を直接トリガーし、Lambda 関数の不要な呼び出しを最小限に抑えます。特定のイベントタイプ (s3:ObjectCreated:*) とフィルタールールを使用して、関連するイベントに対してのみ Lambda 関数が呼び出されるようにします。さらに、Amazon SNS などの追加サービスを必要とせずに Lambda 関数を直接呼び出すため、運用オーバーヘッドが削減されます。

C
C. データ形式を .csv から Apache Parquet に変更します。 Snappy 圧縮を適用します。
説明: Apache Parquet は、分析クエリ用に最適化された列指向ストレージ形式です。列のプルーニングと述語のプッシュダウンの最適化が可能になるため、特にクエリに特定の列の選択が含まれる場合、クエリのパフォーマンスが非常に効率的になります。

A
A. - **センサー データの処理**: リアルタイム データ処理のためのフルマネージド サービスである Apache Flink 用 Amazon マネージド サービスを利用します。このサービスはセンサー データを処理するために使用されます。これには、受信データ ストリームのリアルタイム分析または変換が含まれる可能性があります。 - **Amazon Timestream への Apache Flink のコネクタ**: Apache Flink のコネクタを統合して、処理されたデータをフルマネージドの時系列データベースである Amazon Timestream に書き込みます。 Timestream は、IoT と時系列データ用に最適化されています。 - **Grafana ダッシュボードのソースとしての Timestream データベース**: Timestream に保存されたデータは、Grafana ダッシュボードを作成するためのデータ ソースとして機能します。 Grafana は、時系列データを視覚化する人気のオープンソース分析および監視プラットフォームです。
https://aws.amazon.com/blogs/database/near-real-time-processing-with-amazon-kinesis-amazon-timestream-and-grafana/

B
A、C は完全な S3 アクセスを必要としないため、間違っています。 D は不正解です。DPU をプロビジョニングする必要はなく、宛先は S3 バケットではなくデータベースである必要があります。
B. AWSGlueServiceRole ポリシーを含む IAM ロールを作成します。ロールをクローラーに関連付けます。クローラーのデータ ストアとしてソース データの S3 バケット パスを指定します。クローラーを実行する毎日のスケジュールを作成します。出力のデータベース名を指定します。説明: オプション B は、AWS Glue で使用するように設計された AWSGlueServiceRole ポリシーを使用して、必要なアクセス許可を持つ IAM ロールを正しく設定します。ソース データの S3 バケット パスをクローラのデータ ストアとして指定し、クローラを実行する日次スケジュールを作成します。さらに、出力のデータベース名を指定して、クロールされたデータが AWS Glue データ カタログに適切にカタログ化されるようにします。

B
データエンジニアが Lambda 関数を呼び出して負荷ステータスを DynamoDB テーブルに書き込む最も適切な方法は次のとおりです。 B. Amazon Redshift Data API を使用してイベントを Amazon EventBridge に発行します。 Lambda 関数を呼び出すように EventBridge ルールを設定します。説明: オプション B は、Amazon Redshift Data API を利用して Amazon EventBridge にイベントを発行します。Amazon EventBridge は、AWS のサービス全体でイベントを処理するためのサーバーレスイベントバスサービスを提供します。 Redshift Data API によって発行されたイベントに応答して Lambda 関数を呼び出すように EventBridge ルールを設定することで、データ エンジニアは、Amazon Redshift に新しいトランザクション データがロードされるたびに Lambda 関数がトリガーされるようにできます。このアプローチは、追加の Lambda 関数やサービスに依存せずに、テーブルの負荷ステータスを追跡するための簡単でスケーラブルなソリューションを提供します。

A
A. AWS DataSync 説明: AWS DataSync は、オンプレミスのストレージと Amazon S3、EFS、または FSx for Windows ファイル サーバー間での大量のデータのオンライン移動を簡素化し、高速化するマネージド データ転送サービスです。 DataSync は、大規模なデータセットを効率的かつ増分的かつ信頼性高く転送できるように最適化されており、毎日の更新で 5 TB のデータを転送するのに適しています。

B
B. AWS Database Migration Service (AWS DMS) 説明: AWS Database Migration Service (DMS) は、ダウンタイムやアプリケーションの中断を最小限に抑えて、オンプレミスのデータベースを含むさまざまなソースから AWS にデータを移行するように特別に設計されています。同種の移行 (例: SQL Server から SQL Server) だけでなく、異種の移行 (例: SQL Server から Amazon RDS for SQL Server) もサポートします。

AD
AWS Glue トリガーは、ETL ジョブをスケジュールするためのシンプルで統合された方法を提供します。これらのトリガーを 1 時間ごとに実行するように構成することで、データ エンジニアは、外部のスケジュール ツールやカスタム スクリプトを必要とせずに、データの処理と更新が必要に応じて確実に行われるようにすることができます。このアプローチは AWS Glue と直接統合されており、複雑さと運用オーバーヘッドが軽減されます。 AWS Glue は、Amazon RDS や MongoDB などのさまざまなデータソースへの接続をサポートします。 AWS Glue 接続を使用すると、データ エンジニアはこれらのデータ ソースと Amazon Redshift の間の接続を簡単に設定および管理できます。この方法では、データソース統合に AWS Glue の組み込み機能を利用するため、運用の複雑さが最小限に抑えられ、ソースから宛先 (Amazon Redshift) までのシームレスなデータフローが保証されます。

B
B. Redshift クラスターのワークロード管理 (WLM) キュー レベルで同時実行スケーリングをオンにします。説明: Amazon Redshift の同時実行スケーリングにより、クラスターはワークロードの需要に応じてコンピューティングリソースを自動的に追加および削除できます。ワークロード管理 (WLM) キュー レベルで同時実行スケーリングを有効にすると、クエリ ワークロードに基づいて同時実行スケーリングの恩恵を受けるキューを指定できます。
https://docs.aws.amazon.com/redshift/latest/dg/concurrency-scaling-queues.html

BE
B
https://docs.aws.amazon.com/step-functions/latest/dg/sample-athena-query.html
E
https://aws.amazon.com/blogs/big-data/orchestrate-amazon-emr-serverless-spark-jobs-with-amazon-mwaa-and-data-validation-using-amazon-athena/

A
A. AWS Glue: AWS Glue は、アマゾン ウェブ サービス (AWS) が提供するフルマネージドの抽出、変換、ロード (ETL) サービスです。 B. Amazon EMR: Amazon Elastic MapReduce (EMR) は、AWS が提供するクラウドベースのビッグデータ プラットフォームです。ユーザーは、Apache Hadoop、Apache Spark、Apache Hive、Apache HBase などの一般的なフレームワークを使用して、大量のデータを処理および分析できます。
https://docs.aws.amazon.com/emr/index.html
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-best-practices.html
https://docs.aws.amazon.com/emr/latest/ManagementGuide/emr-manage.html
https://docs.aws.amazon.com/emr/latest/DeveloperGuide/emr-developer-guide.html

C
C. AWS Glue Studio の Detect PII 変換を使用して PII を識別します。 AWS Glue Data Quality でルールを作成して、PII を難読化します。 AWS Step Functions ステートマシンを使用してデータ パイプラインを調整し、データを S3 データ レイクに取り込む

B
StepFunction を使用する方法があります。
https://aws.amazon.com/blogs/big-data/orchestrate-amazon-emr-serverless-jobs-with-aws-step-functions/

C
質問には「最も費用対効果の高い方法」について言及されています。 C は最もコスト効率が高く、依然として可用性が高くなります。この要件は、取得時間の要件を示すものではありません。

A
Redshift クラスター間でデータを共有し、重要な分析タスクを中断したり、ETL クラスターのコンピューティング リソースの使用量を最小限に抑えたりすることなく、ETL クラスター データを営業チームと共有するという要件を満たすには、Redshift データ共有が最適です。
https://docs.aws.amazon.com/redshift/latest/dg/data_sharing_intro.html
"さまざまな種類のビジネスクリティカルなワークロードのサポート – 複数のビジネス インテリジェンス (BI) クラスターまたは分析クラスターとデータを共有する中央の抽出、変換、ロード (ETL) クラスターを使用します。このアプローチでは、個々のワークロードの読み取りワークロードの分離とチャージバックが提供され、ワー​​クロード固有の価格とパフォーマンスの要件に応じて、個々のワークロードのコンピューティングを調整できます。

C
Federated Query が一般的であるため、C を選択します。さらに、S3 にリソースを追加/複製する必要はありません。しかし、Athena は S3 に対してより最適化されているため、これは難しい問題であると考えられます。私の意見では、データを S3 に集中させた方がデータ ガバナンスが容易になるなど、考慮すべきトレードオフがさらに増える可能性があるためです。

AD
A. - AWS では、スケーラビリティ、耐久性、費用対効果の点から、Amazon S3 を Amazon EMR の永続データストアとして使用することをお勧めします。 HDFS にデータを保存するには、追加のインフラストラクチャの管理と維持が必要となり、Amazon S3 を使用する場合と比較して、ストレージ、管理、スケーラビリティの点でコストが高くなる可能性があります。 AWS のドキュメントでは、コストの最適化と効率化のために Amazon EMR を Amazon S3 と統合する利点が強調されています。 D. - Graviton インスタンスは特定のシナリオではコスト削減につながる可能性がありますが、特定のワークロード要件や互換性のあるソフトウェアの可用性によっては、常に最もコスト効率の高いオプションであるとは限りません。 x86 ベースのインスタンスは、より幅広いソフトウェアやフレームワークでサポートされることが多く、場合によってはパフォーマンスと互換性が向上する可能性があります。さらに、インスタンスのタイプと価格に関する AWS のドキュメントを参照すると、x86 ベースのインスタンスと比較した Graviton インスタンスの費用対効果についての洞察が得られます。

C
Kinesis Data Stream の Redshift 外部スキーマで自動更新を備えたマテリアライズドビューを直接使用すると、既存の BI ツールを使用してほぼリアルタイムの洞察を得る最も合理化された効率的なアプローチが提供されます。
https://aws.amazon.com/blogs/big-data/real-time-analytics-with-amazon-redshift-streaming-ingestion/

AB
A. S3 バケット内のデータをパーティション分割します。データを年、月、日ごとに整理します。 • Amazon S3 でデータをパーティショニングすると、クエリのパフォーマンスが大幅に向上します。データを年、月、日ごとに整理することで、AWS Glue と Amazon QuickSight はデータの関連するパーティションのみをスキャンできるため、読み取りおよび処理されるデータの量が削減されます。このアプローチは、クエリが特定の時間範囲を対象とすることが多い時系列データに特に効果的です。 B. ワ​​ーカータイプをスケールアップして、AWS Glue インスタンスのサイズを増やします。 • ワーカータイプをスケールアップすると、より多くの計算リソースが AWS Glue ジョブに提供され、データをより速く処理できるようになります。これは、大規模なデータセットや複雑な変換を扱う場合に特に有益です。スケールアップによるパフォーマンスの向上とコストへの影響を監視することが重要です。

C
C が正解です。マップの状態は、説明されている要件に合わせて正確に設計されています。これにより、項目のコレクションを反復処理して、各項目を個別に処理できます。 Map 状態は反復を自動的に管理し、各項目に対して指定された変換を並列実行できるため、大規模なデータ ファイルのコレクションの並列処理に最適です。

B
「一致の検索」 ソース データ内の重複レコードを検索します。サンプル データセットにラベルを付けてどの行を示すかによって、この機械学習変換を学習します。 match. 機械学習変換は、サンプルのラベル付きデータを教えれば教えるほど、どの行が一致するかを学習します。
https://docs.aws.amazon.com/glue/latest/dg/machine-learning.html

BC
B. カラムナ型ストレージ ファイル形式を使用する: これは優れたアプローチです。 Redshift Spectrum では、Parquet や ORC などの列指向ストレージ形式を使用することを強くお勧めします。データを列に保存することで、Spectrum がクエリに必要な列のみをスキャンできるようになり、クエリのパフォーマンスが大幅に向上し、スキャンされるデータ量が削減されます。
C. 最も一般的なクエリ述語に基づいてデータを分割する: 一般的に使用されるクエリ述語 (日付、地域など) に基づいて S3 内のデータを分割すると、Redshift Spectrum は特定のクエリに無関係なデータの大部分をスキップできます。これにより、特に大規模なデータセットの場合、大幅なパフォーマンスの向上につながる可能性があります。

CD
このソリューションは、DB インスタンスのセキュリティ グループの受信ルールのみを変更しますが、Lambda 関数のセキュリティ グループの送信ルールは変更しません。さらに、このソリューションでは Lambda 関数から DB インスタンスへのプライベート接続が容易にならないため、Lambda 関数は引き続きパブリック インターネットを使用して DB インスタンスにアクセスする必要があります。したがって、このオプションは要件を満たしていません。

B
Amazon API Gateway を使用して、Lambda 関数の HTTP エンドポイントを備えた Web API を作成できます。 API Gateway は、HTTP リクエストを Lambda 関数にルーティングする Web API を作成および文書化するためのツールを提供します。認証と認可の制御を使用して API へのアクセスを保護できます。 API は、インターネット経由でトラフィックを処理することも、VPC 内でのみアクセスできるようにすることもできます。
https://docs.aws.amazon.com/lambda/latest/dg/services-apigateway.html

D
クロスアカウント配信: セキュリティアカウントの Kinesis Data Streams により、指定されたセキュリティ重視の環境にログが確実に存在します。 CloudWatch Logs の統合: CloudWatch Logs にレコードを Kinesis Data Stream に入れる権限を付与すると、本番アカウントからの合理化された安全なデータフローが直接確立されます。フィルタリング制御: 運用アカウントのサブスクリプション フィルタは、どのログ イベントがセキュリティ アカウントに送信されるかを正確に制御します。

C
AWS サービスを使用するため、オプション A が最良の選択のように見えますが、Delta/Iceberg API を使用する方が、Lambda でカスタム コードを記述するよりも簡単だと思います。
https://aws.amazon.com/blogs/big-data/implement-a-cdc-based-upsert-in-a-data-lake-using-apache-iceberg-and-aws-glue/

AC
パーティション プロジェクションを使用したパーティション処理の最適化 パーティション情報の処理は、次の場合に Athena クエリのボトルネックになる可能性があります。非常に多くのパーティションがあり、AWS Glue パーティションのインデックス作成を使用していません。 Athena でパーティション プロジェクションを使用すると、高度にパーティション分割されたテーブルのクエリ処理を高速化し、パーティション管理を自動化できます。パーティション プロジェクションを使用すると、メタストアからパーティション情報を取得するのではなく、パーティション情報を計算してパーティションをクエリできるため、このオーバーヘッドを最小限に抑えることができます。これにより、パーティションのメタデータを AWS Glue テーブルに追加する必要がなくなります。
https://aws.amazon.com/blogs/big-data/top-10-performance-tuning-tips-for-amazon-athena/

D
30 分間にわたる時間ベースの分析のための Apache Flink の Amazon マネージド サービス: このオプションは、最大 30 分間の時間枠で時間ベースの分析を実行するための Apache Flink の Amazon マネージド サービスの使用を正しく識別します。 Apache Flink は、このようなシナリオの処理に熟達しており、複雑なイベント処理、時間枠での集計、長期にわたる状態の維持の機能を提供します。このオプションは、サービスの管理された性質により、高いフォールト トレランスと最小限の運用オーバーヘッドを提供します。

C
GiorgioGss のリンクの「AWS マネジメント コンソールを使用して Amazon EBS ボリュームを変更するには」セクションを確認します。Amazon EBS Elastic Volumes を使用すると、ボリュームをデタッチしたりインスタンスを再起動したり (変更の要件) せずに、ボリューム タイプを gp2 から gp3 に変更できます。これは、変更中にアプリケーションが中断されないことを意味します。

C
SQL ビューの活用: ソース データベースにビューを作成すると、データ抽出プロセスが簡素化され、SQL ロジックが一元化されます。 Glue クローラーの効率: Glue クローラーを使用して、ビューのメタデータを自動的に検出してカタログ化することで、手動セットアップが削減されます。 ETL 用の Glue ジョブ: 専用の Glue ジョブは、(Parquet への) データ変換と S3 へのロードに適しています。 Glue ジョブには、組み込みのスケジュール機能が備わっています。運用効率: このアプローチではカスタムコードを最小限に抑え、データの移動とカタログ化にネイティブの AWS サービスを活用します。

B
クエリまたはユーザー定義のパフォーマンスしきい値に関連するアラート/通知を記録します。これにより、潜在的なパフォーマンスの問題に関するオプティマイザー アラートがキャプチャされます。 STL_PLAN_INFO は、実行計画に関する詳細情報を提供します。オプティマイザーの統計と警告により、問題のあるクエリ プランについての洞察が得られます。 STL_USAGE_CONTROL はユーザーのアクティビティを制限しますが、異常はログに記録しません。 STL_QUERY_METRICS には実行統計がありますが、プラン診断はありません。アラートを有効にし、STL_ALERT_EVENT_LOG および STL_PLAN_INFO をチェックすることにより、データ エンジニアは、オプティマイザによって問題があるとフラグが付けられたクエリを、パフォーマンスが低下する前に検出し、トラブルシューティングすることができます。これは、潜在的な長時間実行クエリを捕捉するという要件を満たします。

D
最もコスト効率が高い=parquet

BD
https://docs.aws.amazon.com/lake-formation/latest/dg/data-filters-about.html
https://docs.aws.amazon.com/lake-formation/latest/dg/access-control-fine-grained.html

BD
E は、失敗の理由を特定するためのオプションではありません。
https://docs.aws.amazon.com/step-functions/latest/dg/procedure-create-iam-role.html
https://docs.aws.amazon.com/step-functions/latest/dg/service-integration-iam-templates.html

C
追加の EBS ボリュームをアタッチする必要があります。 インスタンスが終了するとき、アタッチされている各 EBS ボリュームの DeleteOnTermination 属性の値によって、ボリュームを保持するか削除するかが決まります。デフォルトでは、ルート ボリュームの DeleteOnTermination 属性は True に設定されます。
https://repost.aws/knowledge-center/deleteontermination-ebs

B
Amazon Athena で Apache Spark を使用するには、Spark エンジンを使用する Amazon Athena ワークグループを作成します。
https://docs.aws.amazon.com/athena/latest/ug/notebooks-spark-getting-started.html

C
Amazon S3 にデータを書き込むコードを使用して、Boto3 AWS Glue create_partition API 呼び出しを呼び出します。このアプローチにより、新しいデータが S3 に書き込まれるとすぐにデータ カタログが更新され、新しいパーティションを反映する際の待ち時間が最小限に抑えられます。

B
Amazon AppFlow は、データを安全に転送できるようにするフルマネージド統合サービスですSalesforce、Marketo、Slack、ServiceNow などの Software as a Service (SaaS) アプリケーションと、Amazon S3 や Amazon Redshift などの AWS サービスの間を、わずか数クリックで接続できます。 SaaS アプリケーションから取得した生データを Amazon S3 に保存し、AWS Glue データ カタログと統合してメタデータをカタログ化して保存できます。
https://d1.awsstatic.com/solutions/guidance/architecture-diagrams/integrating-third-party-saas-data-using-amazon-appflow.pdf

C
GROUP BY 句の後に HAVING sum(sales_amount) > 0 を追加します。売上ゼロの製品: 元のクエリには、2023 年の売上高がゼロの製品が含まれていない可能性があります。この変更により、グループ化された結果がフィルタリングされ、売上がプラスの製品のみが表示されるようになります。他のオプションでは核心的な問題に対処できない理由: A. 集計の sum(sales_amount) を count(*) に置き換えます。これは、製品の販売トランザクションの数を示しますが、収益を生み出したかどうかは示しません。これでは商品不足の問題は解決しません。 B. WHERE year = 2023 を WHERE extract(year FROM sales_data) = 2023 に変更します。 year 列がすでに整数型である場合、これは元の WHERE 句と機能的に同等です。不足している製品は修正されません。 D. GROUP BY 句を削除します。これでは、製品の内訳なしで 2023 年のすべての売上が集計されるため、必要な粒度が失われます。

B
S3 Select を使用すると、単純な SQL 式を使用して、S3 に保存されているオブジェクトからデータのサブセットを取得できます。 Parquet 形式のオブジェクトを直接操作できます。
https://docs.aws.amazon.com/AmazonS3/latest/userguide/storage-inventory-athena-query.html

C
Amazon Redshift は、マテリアライズドビューが自動リフレッシュオプションを使用して作成された場合、または自動リフレッシュオプションを使用するように変更された場合に、ベーステーブルの最新データでマテリアライズドビューを自動的にリフレッシュできます。
https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-refresh.html

A
AWS Step Functions を使用するオプション A は、最小限の管理オーバーヘッドで要件を満たす最適なソリューションです。 Step Functions は、Lambda や Glue などの AWS サービスと簡単に統合できるように設計されており、ワークフローを調整するためのマネージド型のローコード アプローチを提供します。これにより、他のオプションと比べてセットアップがより簡単になり、継続的な管理が少なくなります。

B
AWS Glue クローラーと AWS Glue データカタログを使用することで、最小限の運用オーバーヘッドで要件を満たす最適なソリューションです。これは、広範な手動構成やカスタムコーディングを必要とせずに、さまざまな AWS データストアにわたる構造化データと半構造化データの両方をカタログ化するためのフルマネージドの統合ソリューションを提供します。

C
AWS Application Auto Scaling を使用して、ピーク使用時間にはより多くのプロビジョニング容量をスケジュールし、オフピーク時間にはより少ない容量をスケジュールするもので、説明したシナリオにとって最もコスト効率の高いソリューションです。これにより、企業は DynamoDB の容量コストを実際の使用パターンに合わせて調整し、必要な場合にのみスケールアップし、使用量が少ない期間にはスケールダウンすることができます。

B
サーバーレスでコスト効率が高い: AWS Glue データカタログはサーバーレスのメタデータリポジトリを提供し、運用オーバーヘッドを削減し、コスト効率を高めます。外部データ カタログとして使用すると、追加のデータベース インフラストラクチャを管理する必要がなくなります。シームレスな移行: 既存の Hive メタストアを Amazon EMR に移行すると、現在の Hadoop セットアップとの互換性が確保されます。 EMR は Hadoop ワークロードを実行し、このプロセスを容易にするように設計されています。柔軟性: AWS Glue の外部データカタログは、柔軟性と懸念事項の分離を提供します。メタストアは引き続き Hadoop ワークロードに対して EMR によって管理されますが、Glue はより広範な AWS データ ソースに対して一元化されたカタログを提供します。

B
(分散キーを変更する) は、5 つのコンピューティング ノードすべてにわたって負荷をより均等に分散するための最も効果的なソリューションです。クエリ パターンとデータの特性に合わせて適切な分散キーを選択すると、データとワークロードがより均一に分散されるため、あるノードが過剰に利用され、他のノードが十分に活用されていないという可能性が低くなります。
https://docs.aws.amazon.com/redshift/latest/dg/t_Distributing_data.html

A
AWS Glue スキーマ レジストリを設定します。新しい AWS Glue ワークロードを作成して、分析部門が Amazon Redshift Serverless に使用するデータの取り込みを調整します。オプション C (Amazon Athena および Apache Spark) は、アドホックなクエリと探索には適していますが、Athena は複雑なデータ変換ではなくインタラクティブなクエリ向けに設計されているため、分析部門の継続的なデータ分析のニーズには最適な選択ではない可能性があります。

D
AWS CloudTrail でデータ イベントの証跡を作成する、最小限の操作で要件を満たす最適なソリューションです。努力。必要なアクティビティを別の S3 バケットに直接ログに記録し、Lambda 関数や Kinesis Data Firehose ストリームなどの追加リソースの開発やメンテナンスは必要ありません。
https://docs.aws.amazon.com/AmazonS3/latest/userguide/logging-with-S3.html

C
AWS Glue データ カタログを使用します。最小限の開発労力で要件を満たす最適なソリューション。 AWS Glue データカタログは、EMR や Athena などのさまざまな AWS サービスと統合できる中央メタデータ リポジトリとして設計されており、Hive 互換性が組み込まれたメタデータ管理のためのマネージドでスケーラブルなソリューションを提供します。
https://aws.amazon.com/blogs/big-data/metadata-classification-lineage-and-discovery-using-apache-atlas-on-amazon-emr/

D
データレイクストレージに Amazon S3 を使用し、アクセス制御に AWS Lake Formation を使用する、最も適切なソリューションです。行レベルおよび列レベルのアクセス制御の要件を満たし、Amazon Athena、Amazon Redshift Spectrum、EMR 上の Apache Hive と適切に統合され、他のオプションと比較して運用オーバーヘッドが低くなります。
https://docs.aws.amazon.com/lake-formation/latest/dg/cbac-tutorial.html

CE
https://docs.aws.amazon.com/athena/latest/ug/performance-tuning.html

AD
A および D ほとんどが書き込みで少数の読み取りが行われるワークロードでは、読み取りの多いワークロードに比べて、キャッシュによる CPU 使用率の削減効果は低くなります。
https://repost.aws/knowledge-center/rds-aurora-postgresql-high-cpu

C
スペースの再利用: 更新および削除後、Redshift テーブルは削除されたデータ ブロックを保持し、スペースを占有する可能性があります。 VACUUM REINDEX コマンド: 削除された行によって占有されていたスペースを再利用します。ソートキー列のインデックスを再構築します。ソートキーの分析: ソートキー列には AWS リージョンが含まれているため、この列のインデックスを再構築すると、リージョンに従ってデータをクラスタリングするのに役立ちます。このクラスタリングにより、リージョンごとにフィルタリングまたはグループ化するクエリのパフォーマンスが向上します。

C
最小限の運用オーバーヘッドで要件を満たす最適なソリューションです。 Amazon Kinesis Data Streams を使用してリアルタイムのセンサーデータを取り込みます。 ネストされた JSON データを Amazon DynamoDB に保存して、低レイテンシーのクエリを実行します。 オプション C の主な利点は次のとおりです。 Kinesis Dataストリームは自動スケーリングと永続性によりリアルタイムのデータ取り込みを完全に管理します DynamoDB はクエリに対して 1 桁のミリ秒のレイテンシを提供します DynamoDB はネストされた JSON データ モデルをネイティブにサポートします フルマネージド サービスにより運用オーバーヘッドが最小限に抑えられます 対照的に: オプション A では Kafka クラスターの管理が必要です オプション B は Lambda を使用します。永続的なストレージを提供しない オプション D では、SQS、Glue、RDS を統合する必要があり、複雑さが生じます。

A
Amazon Athena を使用してデータをクエリし、データフィルターを使用して AWS Lake Formation を設定することで、同社はユーザーグループが必要な個人識別情報 (PII) のみにアクセスできるようにすることができます。クエリ用の Athena とアクセス制御用の Lake Formation を組み合わせることで、PII アクセス要件を効果的かつ安全に管理するための包括的なソリューションが提供されます。

BD
オプション B: AWS Glue ワークフロージョブを使用した Amazon EventBridge ルール (15 分ごと) - 合理化されたプロセス、自動スケジュール、およびスキーマ変更を処理する機能。オプション D: ファイルのロード時に AWS Lambda で AWS Glue ワークフローを呼び出す - ファイル到着への応答性とスキーマ変更への適応性のためですが、オプション B よりも若干複雑です。

B
Amazon Athena のクエリ結果の再利用機能を使用します。これにより、Athena の組み込み機能を利用して冗長なデータ スキャンが削減され、クエリ コストが削減されます。
https://docs.aws.amazon.com/athena/latest/ug/performance-tuning.html

C
めったに更新されない小さなテーブルには ALL 分散スタイルを使用します。このアプローチは、これらの小さなテーブルに関係する結合のパフォーマンスを最適化し、Redshift データ ウェアハウスにおける一般的なベスト プラクティスです。大きなテーブルの場合は、EVEN 分散スタイルを維持するか、KEY ベースの分散 (共通の結合列がある場合) を検討する方が適切な場合があります。

B
AWS Glue DataBrew は、大規模なコーディングを必要とせずにデータを簡単に変換できる視覚的なデータ準備ツールです。 DataBrew の NEST_TO_MAP 変換を使用すると、列を JSON マップに変換でき、住所データに必要な JSON 形式と一致します。

C
AWS KMS キー (SSE-KMS) を使用したサーバー側暗号化を使用して、顧客情報を含むオブジェクトを暗号化します。オブジェクトを暗号化する KMS キーへのアクセスを制限する IAM ポリシーを構成します。 AWS KMS (SSE-KMS) を使用したサーバー側の暗号化は、AWS Key Management Service (KMS) によるきめ細かいアクセス制御を可能にしながら、S3 オブジェクトに強力な暗号化を提供します。 SSE-KMS を使用すると、IAM ポリシーを使用して暗号化キーへのアクセスを制御し、特定の従業員のみが暗号化キーにアクセスできるようにすることができます。このソリューションは、AWS のマネージド暗号化サービス (SSE-KMS) を活用し、S3 とシームレスに統合するため、最小限の労力で済みます。さらに、KMS キーへのアクセスを制限するように IAM ポリシーを簡単に構成できるため、暗号化キーにアクセスできるユーザーを詳細に制御できます。

D
S3 Intelligent-Tieringのデフォルトのアクセス階層は次のとおりです。 1. アクセスが 30 日未満: 頻繁なアクセス階層 2. 30 ～ 90 日間アクセスされない: 低頻度アクセス階層 3. 90 日を超えてアクセスされない: アーカイブインスタントアクセス層 他の層では、アクティベーションが必要な取得時間が長くなります。
https://docs.aws.amazon.com/AmazonS3/latest/userguide/intelligent-tiering-overview.html

DE
D. 認証情報を AWS Secrets Manager に保存する: AWS Secrets Manager は、独自のインフラストラクチャを運用するための先行投資や継続的なメンテナンス費用を必要とせずに、アプリケーション、サービス、IT リソースへのアクセスを保護するのに役立つサービスです。これは、認証情報を安全に保存および取得するために特別に設計されているため、Redshift クラスターの認証情報を処理するのに適切な選択肢です。
E. AWS Glue ジョブに保存された認証情報への IAM ロールアクセスを付与する: AWS Glue の IAM ロールにより、ジョブは AWS Secrets Manager の認証情報にアクセスするために必要なアクセス許可を持つロールを引き受けることができます。この方法では、資格情報をスクリプトまたは構成ファイルに直接埋め込むことが回避され、資格情報の一元管理が可能になります。

B
フルマネージド、サーバーレス: Redshift Serverlessにより、クラスターを手動で作成、管理、削除する必要がなくなります。ワークロードに基づいてリソースを自動的にスケールし、運用オーバーヘッドを大幅に削減します。頻度の低いワークロードに対する費用対効果の高い: 分析プロセスは月に 1 回だけ実行されるため、Redshift Serverless の従量制モデルはダウンタイム中のコストを最小限に抑えるのに最適です。シームレスな S3 統合: Redshift Serverlessは、バックアップおよび復元操作のために S3 とネイティブに統合し、既存のプロセスとの互換性を確保します。

D
AWS Glue DataBrew: AWS Glue DataBrew は、データエンジニアやデータアナリストがコードを書かずにデータをクリーンアップおよび正規化できるようにする視覚的なデータ準備ツールです。 DataBrew を使用すると、データ エンジニアは顧客の姓名を連結したレシピを作成し、COUNT_DISTINCT 関数を使用できます。これには複雑なコードは必要なく、DataBrew ユーザー インターフェイスを通じて実行できるため、運用労力が軽減されます。

B
Amazon Redshift のストリーミング インジェスト機能を使用する: Amazon Redshift は最近ストリーミング データ インジェストを導入し、Redshift がデータを直接消費できるようにしました。 Kinesis Data Streams からほぼリアルタイムで。この機能は、中間のステップやサービスの必要性を排除することでアーキテクチャを簡素化し、特にほぼリアルタイムの分析をサポートするように設計されています。
https://docs.aws.amazon.com/redshift/latest/dg/materialized-view-streaming-ingestion.html

CD
権限関連のエラーを引き起こす可能性が最も高い 2 つの要因は次のとおりです。
C. QuickSight は S3 バケットにアクセスできません。 S3 バケットのデータにアクセスするには、QuickSight に明示的な S3 権限が必要です。これは通常、QuickSight サービスに関連付けられた IAM ロールを通じて処理されます。
D. QuickSight には S3 データを復号化するためのアクセス権がありません。 S3 内のデータが暗号化されている場合 (例: KMS を使用)、QuickSight は関連する KMS キーを使用してデータを復号化するために必要なアクセス許可を持っている必要があります。他のオプションが主な原因である可能性が低い理由を分析してみましょう。

E. QuickSight に割り当てられた IAM ロールがありません。 QuickSight には、全体的な機能のために IAM ロールが必要です。ロールが欠落していると、特定のデータ アクセス エラーではなく、より広範なサービス障害が発生する可能性があります。

A
Athena による統合クエリ: Athena は、従来のデータベースだけでなく、S3 の JSON や CSV などのさまざまなデータ ソースをクエリするための SQL のようなインターフェイスを提供します。 PartiQL サポート: Athena の PartiQL 拡張機能を使用すると、半構造化された JSON データを直接クエリできるため、別のクエリ エンジンが必要なくなります。サーバーレスとマネージド: AWS Glue と Athena はどちらもサーバーレスなので、データ エンジニアのインフラストラクチャ管理が最小限に抑えられます。不必要な変換なし: JSON データの変換を回避することで、パイプラインが簡素化され、運用オーバーヘッドが削減されます。

B. Redshift Spectrum: Spectrum は外部データをクエリできますが、主に Redshift データ ウェアハウス拡張機能を目的としています。これにより、RDS および DynamoDB データ ソースがさらに複雑になります。

C
SageMaker のアクセス許可: AmazonSageMakerFullAccess 管理ポリシーは、SageMaker Studio や AWS Glue などの他の AWS サービスと対話する機能など、Amazon SageMaker の機能を使用するための広範なアクセス許可を提供します。最小特権: このポリシーはかなり寛容ですが、即時アクセスの問題に対する最も直接的な解決策です。エラーを解決した後、より詳細なアプローチのために権限を調整できます。

B
操作上のオーバーヘッドが最も少ないオプションは B です。

B
Amazon S3 Object Lambda を使用すると、S3 GET リクエストに独自のコードを追加して、アプリケーションに返されるデータを変更および処理できます。たとえば、S3 オブジェクト Lambda を使用して、S3 から取得したデータから個人を特定できる情報 (PII) を動的に編集できます。これにより、データのコピーを複数作成して管理することなく、さまざまなアプリケーションのニーズに基づいて機密情報へのアクセスを制御できるようになります。

D
オプション D: AWS Glue Python シェル ジョブを作成し、pandasを使用してデータを変換するのは、説明されているシナリオにとって最もコスト効率の高いソリューションです。 AWS Glue の Python シェル ジョブは、小規模な ETL タスク、特にそれぞれ 100 MB 未満の .csv ファイルを扱う場合に適しています。 Python の強力で効率的なデータ操作ライブラリである pandas を使用すると、この種のファイルを処理および変換するための理想的なツールになります。このアプローチにより、Amazon EKS や EMR などのより複雑なソリューションに関連するオーバーヘッドと追加コストが回避されます。これらのソリューションは一般に、大規模で複雑なデータ処理タスクにより適しています。毎日受信する小さなサイズの .csv ファイルを処理するという要件を考慮すると、このソリューションは最小限のリソースで必要な機能を提供し、費用対効果の目標にうまく適合します。