Cloud LicenseでAWS DEAの対策をした
明日受けるAWS DEAの対策のために、数日前からCloud Licenseというサイトを利用してテスト対策をしていた。勉強と備忘録のために、間違えた部分や新たに知った部分などをこの記事にまとめていく。
が、その前に今後Cloud Licenseのサイトを利用しようか迷っている人のために、簡単にサイトを使ってみた感想だけ書いてみる。
Cloud Licenseの感想
Cloud LicenseはAWSやGCPなどのクラウドベンダー認定資格の対策問題などを提供しているサービスで、有料会員になることで多くの問題集を閲覧することができる。
無料プランもあることにはあるが、3つの認定資格で合計49問しか見れないため、あくまでサービスの利用方法を知るためだけのサンプルという意味合いが強いと思う。今回は有料会員になってAWS DEA（Data Engineer Associate）の問題集を一通りやってみた。
感想を一言で言うと、サイトの完成度は低く問題の質は中程度、しかし全資格を通した問題数が多いという感じだった。
サイト完成度については、UXと言われるようなユーザ体験の部分があまり良くなかった。ひとつ例を挙げると、4択の選択肢の文章が長くて読めない＆スクロール機能がないため、倍率を非常に低くしてモニタに張り付いてみなくてはならなかった。他にもたまに問題が見切れていて読みずらいなどもあった。
次に問題の質だが、これに関してはAWS DEAに限って言うと、問題と解答どちらも怪しいものがある程度存在していた。例えば、問題文に書かれていない条件が解説に書かれていたり、解答に「○○（AWSサービス名）は運用が大変」などと具体性に欠ける説明がされていたりした。
ただ、全資格を通した問題数は6,000問以上とかなり多いため、複数の試験を受ける人にとってはデメリットよりもメリットの方が大きいかもしれない。
間違えた部分・新たに知った部分
1. Amazon Redshift Data API
Amazon Redshift Data API は、データベースドライバー、接続、ネットワーク設定、データバッファリング、認証情報などを管理する必要がなくなるため、Amazon Redshift データウェアハウスへのアクセスを簡素化します。AWS SDK で Data API オペレーションを使用して SQL ステートメントを実行できます。Data API オペレーションの詳細については、Amazon Redshift Data API のリファレンスを参照してください。
Amazon Redshift Data APIは、Amazon Redshiftに対してAWS SDKで操作をすることができる機能で、外部のアプリケーションから裏側でRedshiftにクエリを叩く際などに用いることができる。
こちらのページにもいろいろ書いてあるが、クエリだけではなくETLなどもData APIを通じてできるようだ。サービスもAWS内の多様なものと連携できるようになっている。
2. Apache Arvo / Parquet
これは新しく知った部分ではないが、凡ミスで間違えてしまったので一応書く。
Apache Arvo / Parquetはそれぞれ行・列指向のデータ形式で、Arvoでは特定の範囲の行のみを処理するのが効率が良く、Parquetでは特定の列の範囲のみを処理するのが効率が良い。
一般にデータサイエンスで用いられるのは後者のApache Parquetの方で、機械学習などで特定の列のみを抽出したりすることが多いからだと思う。あとは、データウェアハウスなどに多くの列数を持つデータを保存して、必要な列だけ取り出してくるみたいなユースケースも多いからかな。
3. Amazon Redshift Spectrumのパフォーマンス
以下のページにAmazon Redshift Spectrumのパフォーマンス改善について記載されている。
パフォーマンスを改善させるには以下の方法を用いることができるらしい。
データファイルの形式をApache Parquetにする
ファイルサイズを64MB以上で複数に分割する（なるべくサイズは均等）
クエリで使用する列を少なくする
使用頻度の高い小さなテーブルはRedshiftデータベースに置く
レイヤーにプッシュ可能なクエリを利用する（DISTINCT、ORDER BYはだめ）
パーティションを利用してスキャン範囲を狭める
などなど。
4. AWS Data Exchange
AWS Data ExchangeとはAWSが認定したサードパーティのデータセットを簡単に自身の環境に取り込むことができるサービスとなっている。問題を見るまではこのサービスの存在自体知らなかったが、料金によってはかなり良いサービスなんじゃないかと思う（特にデータ分析用途では）。
無料データセットもあるようで、米国企業の時価総額上位10社の20年分のデータなどもとれるようだ。個人的に金融データ分析基盤を作ろうとしているところなので、データソースの一つとしてこれも使えるような基盤にしたいと思った。
5. Amazon EBSのボリュームタイプの変更
これは初めて知ったのだが、Amazon EBSではボリュームタイプを後から変更できるようで、しかも無停止で変更が完了するようだ。なので、新しくEBSを作って他のAWSサービスを利用してデータを送信するなどの手間をかけなくてよい。
6. AWS Step Functions
AWS Step Functionsは複数のAWSサービスを簡単に統合させることができるサービスとなっており、GUIでワークフローを構築・可視化などができる。
特徴としては、Apache AirflowのようにDAGなどでワークフローを記述せずに、グラフィカルに操作できるため作業難易度が比較的低く、運用コストがあまりかからないというところ。
7. Amazon Redshiftのデータ共有
データ共有は、Amazon Redshift でデータを共有する単位です。同じ AWS アカウントまたは異なる AWS アカウント間でデータを使用するには、データ共有を使用します。また、異なる Amazon Redshift クラスター間で、読み取りのためにデータを共有することもできます。
Amazon Redshiftでは、異なるAmazon Redshiftクラスタにデータの共有を行うことができる機能で、クエリをする際のリソースは共有を受けた方が持つようになっている。
そのため、あるAmazon Redshiftクラスタにあるデータを他のクラスタで使いたいが、リソースをもとのクラスタには加算したくない、といった場合に利用することができる。
8. S3オブジェクトの暗号化キーについて
S3オブジェクトを暗号化する際に、特定の作業者にのみキーをアクセスできるようにしたい場合があるとする。そのとき、S3が管理するキー（S3マネージドキー）ではそういった権限の管理が出来ないため、AWS KMSによってキーを管理する必要が出てくる。
9. S3 Object Lambda
S3 Object Lambdaというサービスでは、既存のS3をコピーしたり編集したりすることなく、特定のアプリケーションに向けて編集した結果を渡すことができる。よくあるユースケースとしては、個人情報など機密データを特定アプリケーションに渡す前にLambdaで編集したりするようなものだ。
他にも、画像の動的なサイズ変更や行のフィルタリングなどにも利用できるとのこと。
10. AWS GlueのFLEX実行クラス
AWS GlueにはGlue Flexという実行ジョブクラスがあり、時間の制限などが特にないワークロードに関してコストを最大で35%削減することができる。デフォルトではスタンダード実行クラスというものが選択されるが、そちらはすぐにジョブを開始することができる。
夜間バッチや1回限りで実行時間にこだわりがないものなどに適している。
11. S3 Intelligent - Tiering
Amazon S3 Intelligent-Tiering ストレージクラスは、3 つのアクセス階層に自動的にオブジェクトを保存します。1 つの階層は高頻度アクセス用に最適化され、1 つの低コスト階層は低頻度アクセス用に最適化されます。またもう 1 つの極めてコストの低い階層は、ほとんどアクセスされていないデータに最適化されます。オブジェクトのモニタリングおよびオートメーションにかかる月額料金を抑えるために、S3 Intelligent-Tiering はアクセスパターンをモニタリングし、30 日間連続してアクセスがなかったオブジェクトを、低頻度アクセス階層に自動的に移動します。90 日間アクセスされていない場合に、オブジェクトはパフォーマンスへの影響や運用上のオーバーヘッドなしで、アーカイブインスタントアクセス階層に移動されます。
S3 Intelligent - Tieringでは、アクセス階層がいくつか存在し、それぞれの階層で取り出しにかかる時間や保存コストが変わってくる。そして、一定日数連続でアクセスがない場合はより保存コストの低い階層に移されるようになっている。
アクセスがない連続日数が90日まではアーカイブインスタントアクセス階層になっており、低レイテンシー高スループットのパフォーマンスが保証されている。しかしそれ以降になると、データの取り出しに数時間以上かかってくるようになる。
12. Amazon AthenaのPartition Projection（パーテーション射影）
Athena では、高度にパーティションされたテーブルのクエリ処理を高速化し、パーティション管理を自動化するためにパーティション射影を使用できます。
パーティション射影では、Athena は AWS Glue のテーブルに直接設定したテーブルプロパティを使用してパーティション値と場所を計算します。テーブルプロパティにより、Athena は AWS Glue Data Catalogで時間をかけてメタデータを検索しなくても、必要なパーティション情報を「射影」または決定できます。多くの場合、インメモリオペレーションはリモートオペレーションよりも高速であるため、パーティション射影は高度にパーティションされたテーブルに対するクエリの実行時間を短縮できます。クエリおよび基盤となるデータの特定の特性によっては、パーティション射影によって、パーティションメタデータの取得時に制限されているクエリのクエリランタイムが大幅に短縮されます。
Amazon Athenaでは、Partition Projection（パーテーション射影）と呼ばれる機能がある。あまり理解が出来ていないのだが、ざっくりと、パーテーション情報を高速に決定するものだということが書いてある。
この記事をみると、テーブル作成の際にパーティション射影を行うカラムを選び、S3に存在するデータに置いて自動的にそれらをパーティションとして利用する感じになるのかな、と思った。（自分で使ってみないと分からなそう）
13. Amazon Redshiftの分散スタイル
Amazon Redshiftでは分散スタイルという、クラスタ内のノードにどういったアルゴリズムでデータを分散するかを決定する設定がある。
分散スタイルには、AUTO、EVEN、キー、ALLがあり、それぞれ適したテーブルがことなる。AUTOのみは他の3種類を自動で設定してくれるものになっており、基本的にはこれを使うのがよさそう。
EVENはデータをラウンドロビン方式でキーなどに関わらず分散させる方法で、適切な分散キーがなく、サイズが大きいようなテーブルに向いている。一方でキーは特定の列に含まれる値に従って分散が行われるため、適切なキーがある場合には手動で設定してパフォーマンスを上げることができる。最後にALLでは、すべてのノードに全データをコピーするため、よく結合で用いられる小さなテーブルに用いるのが適している。
この記事が気に入ったらサポートをしてみませんか？