顧客フロントSEのIT勉強ブログ

2022 Japan AWS Top Engineer / 2022-23 Japan AWS Certifications Engineer。AWS認定12冠、情報処理試験全冠。顧客フロントSEがなるべく手を動かしながらIT技術を学んでいくブログです。

【資格】AWS認定 データアナリティクス-専門知識に合格した勉強法

f:id:se_o_chan:20211227005950p:plain

約3ヵ月ぶりの記事となってしまいましたが、この間にAWS認定資格の内、ネットワーク、データベースを取得し、本日無事データアナリティクスも合格しました!

ネットワーク、データベースについては追々記事にするとして、今日は「AWS認定 データアナリティクスー専門知識」について、私の勉強方法と学んだことを書き出しておこうと思います。

準備期間と結果

準備期間は2021年11月1日~12月26日と約2ヵ月でした。

KinesisやRedshiftなど触れたことが無いサービスが多かったため、サービス内容を腹落ちさせるまで時間がかかり何度か試験日を延期したのですが、結果は795点で何とか合格できました!

無事全分野「コンピテンシーを満たしている」と判定されました。

f:id:se_o_chan:20211226230919p:plain

f:id:se_o_chan:20211226231016p:plain

合格までの勉強法

1.試験ガイド

AWSが公式に提供する試験内容を説明した資料です。リンクはこちら

セキュリティ試験の時と同様、出題される分野と試験対象のAWSサービスだけ確認すればよいです。

f:id:se_o_chan:20211226231541p:plain

(出典)AWS Certified Data Analytics - Specialty 試験ガイド

2.サンプル問題

いつものAWS公式のサンプル問題10問。今回はこちら

特に今回は初見では何を言っているのかさっぱり状態でした・・・

試験前日に再度見直すとようやくそれぞれの選択肢の意味が分かり、ある程度自分の考えて正答を選択できるようになっていました。

3.AWSレーニングライブラリ

いつもはここでAWS提供のデジタルトレーニング動画を参照するのですが、今回は特に確認することなく4以降に。

特に理由は無かったのですが、そのせいでいつもより理解に時間がかかったのかも。

4.AWS WEB問題集で学習しよう

いつもお世話になっているこちらのサイトを今回も学習のメインにしました。

分野によってはこの問題集と全く同じ問題が本番でも何割か出てくるのですが、今回は見たことあった問題は1割くらい。

とはいえ、理解を深めるには非常に役に立ちました。

5.模擬試験

そう言えばここ1~2ヵ月前にAWS Skill Builderからの提供に変わりましたね。

これまで有料だった模擬試験が無料になりました。とはいえほとんどの人が無料バウチャーを持っていたはずなので、ここはそこまで大きなメリットではなく。

大きかったのは模擬試験の各設問の回答と解説が提供されるようになったことです!これまで提供されるのは正答率だけで、どの設問が合っていて間違っていたのかは自分の推測でしかなく、理解を深めるにはイマイチだったのが解消されました。

6.Black Belt サービス別資料

https://cdn-ak.f.st-hatena.com/images/fotolife/s/se_o_chan/20210911/20210911214907.png

EMRは業務で少し触れたことがあり、Athenaはワークショップで独習していましたが、Kinesis、Redshift、Glueは触ったことがなかったので、この資料がとても役に立ちました。

今回学んだこと

今回のデータアナリティクスは、ほとんど次のサービスで9割を占めると思います。

 Kinesis、EMR、Athena、Glue、QuickSight、Redshift、ElasticSearch(OpenSearch

各々のサービスについて、自分の学んだことを書き出しておきます。

Kinesis

f:id:se_o_chan:20211227114525p:plain

まずKinesisは「ストリームデータ」を取り扱うわけですが、これが最初はあまり腹落ちせず、

  • 数十万のユーザがいるネイティブアプリのログ収集
  • Webアプリのユーザの操作ログ収集
  • 数千あるIoTデバイスで発生したデータの収集

というあたりが設問に具体例として出てきて少しイメージ湧いてきました。秒間数百~数千というオーダーのデータをすべてS3やRDSに保存しているとPUTコストもかかるし、データ保存するだけでDBリソースがひっ迫しちゃうわけですね。

そこでKinesisが登場するのですが、兎にも角にもで次のKinesisサービス群の違い(特にStream、Firehose)を理解しないといけません。

Streamは、ストリームデータを一時保持(最大7日間)してくれるサービスでデータを取り出すにはKCL(Kinesis Client Library)やLambdaなどを使って意図的に取得しにいく必要があります。
この辺はSQSに近い特徴を持っていますが、SQSと違って同じデータを複数回取得できます。類似サービスとして「Amazon MSK(Managed Streaming for Apache Kafka)」がありますが、ストリームデータのサイズ(ペイロード)がKinesis上限(1MB)を超える場合に使います。MSKは6MBまで扱えるそうです。 

Firehoseは、データを入れたら意図的に取得せずとも既定のデータサイズ or 期間を超えると勝手に出口のサービスに流れていきます。この辺が「hose」たる所以かと。
ちなみに出口のサービスとはS3、Redshift、ElasticSearchの3つです。
元々はStreamしかなく、データの永続的保存にはユーザが何らか処理を作らないといけなかったところにFirehoseが登場した、という経緯のようです。
StreamからFirehoseがデータ取得もできるし、ストリームデータを直接取り込むことも可能です。また、Firehose内でデータ変換処理を入れ込むこともできます。

Analyticsは、Stream内に一時保存しているストリームデータを分析する機能を提供してくれます。これにより一度データをS3やRedshiftに保存することなく、ほぼリアルタイムな分析が行えるメリットがあります。

Video Streamは、動画をストリーミングしながらAWSに取り込むサービスです。試験上はHLS(HTTP Live Streaming)のキーワードが出てきたら大体このサービスを使ってます。

ストリームデータを発生させKinesisに流し込むサービスを「Producer」、Kinesisからデータを取得するサービスを「Consumer」と言います。

試験では特にProducerのうち、KPL(Kinesis Producer Library)Kinesis APIによるPutRecord/PutRecordsが良く出ます。
前者は一定時間ローカルにデータを保持し、非同期にある程度のデータをまとめてKinesisに送りますが、後者は1件ずつ同期的に送信します。
したがって、Put Record APIのほうがリアルタイム性が高く、緊急データなど即時性が求められるもの向けです。

ConsumerはKCL(Kinesis Client Library)が良く試験に出ますが、EC2などにデプロイするとDynamoDBも作成し、Kinesisからどこまでデータを読み込んだのかカーソル情報を保存するのが特徴です。
なので、Kinesisをスペック(シャード数)を増やすと、このDynamoDBのほうがボトルネックになったりします。

EMR(Elastic Map Reduce)

f:id:se_o_chan:20211227114612p:plain

私の最初の印象は「Hadoopって、コンテナ(ECS、EKS)と何が違うの?」でした。

結局ざっくり言うなら、コンテナはたくさんのサーバが別々に動くものです。メモリやディスクはサーバ間で共有しないので、もし共有したいならEFSを各自マウントするか、S3への退避処理を個別に実装する必要があります。

一方で、EMRで提供されるHadoop環境はたくさんのサーバがあたかも馬鹿でかい1つのサーバのように動くものです。
メモリやディスクがサーバ間で共有されており、この辺りの技術がHDFSEMRFSです。HDFSは揮発性なのでEMRクラスタを停止するとデータが消えてしまいますが、EMRFSは実態がS3なのでEMRクラスタを消しても不揮発性データとして保持されます。

ちなみに、S3の特徴として「結果整合性」がありますが、EMRFSを使うときにその特徴がデメリットとして効いてくることがあります。
これを避けるために「整合性のあるビュー」オプションが用意されており、これを有効にするとEMRFSメタデータストアとしてDynamoDBが作成され、もし更新前ファイルが読み取られたら自動で再読取りするようになります。

EMRを構成するノード(≒サーバ)として、マスターノード、コアノード、タスクノードがあります。
マスタノードはEMRクラスタ1つにつき原則1つ(冗長化もできますが)。EMR全体を管理するので、このノードが消えるとクラスタが消えます。
コアノードとタスクノードは実処理を行いますが、その違いはHDFSを持つか否かです。HDFSをもつコアノードが消えると、EMR内のデータの一部が消失します。
という役割を踏まえて、マスタノードとコアノードはオンデマンドインスタンスなど信頼性の高い方式とし、タスクノードはスポットインスタンスで運用コストを下げるのが良いアーキテクチャとされます。

また、Hadoop環境上で動くアプリとしてSpark、Presto、Pig、Hive、HBaseなどがあり、これらの特徴を押さえておくのも試験としては重要です。

Glue

f:id:se_o_chan:20211227115231p:plain私の中でGlueは、ETLサービスとしてデータ変換を司るものだという認識でした。
それも間違っていないのですが、少なくとも試験上で重要なのは「Glueデータカタログ」です。

データカタログは、S3、Redshift、DynamoDBなどに保存されているデータがなにで、データ型は何なのかというメタデータを管理します。実態はApache Hive(Hadoop上のデータ管理アプリ)メタストアです。

Glueのクローラーがデータソースにアクセスしてデータカタログを自動作成・更新します(Hive DDLで手動作成も可能)。

データカタログはもちろんGlueのETL処理でも使うのですが、EMRでHiveを使用するときのメタストアの代替になったり、AthenaがS3にアクセスするときやRedshift Spectrumでもこれを使います。今回の試験のメインサービス群の土台になるサービスです。

Athena

f:id:se_o_chan:20211227115449p:plain

AthenaはS3内のファイルに対して、アドホック(一発もの)なクエリを発行できるサービスです。S3のファイルをあたかもリレーショナルデータベースのように扱えます。

今日の本番試験でやたら頻出したのが「Apache Parquet(パーケイ)」というデータフォーマットです。

AthenaはS3上のCSVファイルでもデータ源泉として扱えますが、行指向データのため、特定の項目を取得しようとしても行全体を読み取らざるを得ず、不必要に大量データを取り扱うことになります。

一方でParquetはバイナリ圧縮されている列指向データです。分析に必要な項目だけを取得できるので、扱うデータ量を小さく抑えることができます。

ストリームデータとして最初はJSONCSVファイルでKinesisに流れ込んできがちですが、Firehoseのデータ変換処理だったり、Glueを使ってParquetに変換します。

Redshift

f:id:se_o_chan:20211227115714p:plain

データウェアハウス用データベース、というのは有名なところかと思います。

実態は1つのリーダーノードと2つ以上のコンピュートノードで実装され、ストレージはRedshift管理のS3で構成されています。
SQLクエリでデータ参照されるとS3からデータを取得し、コンピュートノードのSSDにキャッシュとして保持します。
ちなみにRedshiftのストレージで管理されるデータも列指向です。Apache Parquetと同じですね。

このキャッシュデータをどのようにスライスし、どのコンピュートノード配下に保持させるのかがRedshiftの性能を左右する重要な概念の1つです。
「Key」としてパーティションキーを指定しキー値毎に分ける方法や、「EVEN」としてパーティションキーをハッシュ化し各コンピュートノードに均等分割する方法、「ALL」として全コンピュートノードに同じデータを複製して保持する方法などがあります。

Redshiftにデータ登録するときは、従来のRDBMSのようにJDBC接続でinsert、updateもできるのですが性能的に非常に遅いので、あらかじめS3に出力したファイルを「COPY」コマンドで一括読み込みする方式が推奨されています。

また、アクセス頻度が低いものはユーザ管理のS3へダイレクトに参照しちゃうことでCOPYの手間を省き、Redshiftのストレージ容量は押さえることもできます。これがRedshift Spectrumという機能ですが、どのS3バケットにどんなデータがあるかをRedshiftが理解しておく必要があるので前提としてGlueデータカタログのようなメタストアが存在していている必要があります。

ElasticSearch(OpenSearch

検索/分析エンジンとして提供されているサービスです。この試験では大体分析データをKinesis Firehoseで取込み、Kibanaを使って可視化するという組み合わせになります。データは揮発性のため、永続ストレージにはなりえないところもポイントです。

まとめ

試験合格にはもちろん上記以上に詳細な情報を理解する必要がありますが、上記の内容を理解しておけば勉強の入り口としては十分ではないかと思います。

個人的にはKinesis、EMR、Glueの理解が深まったことが大きいです。

正直業務上では現状そこまで使うシーンが無いサービスたちですが、データ分析の重要性は今後も高まっていくでしょうから、サービス概要を把握できていることは損にはならないはずです。

PVアクセスランキング にほんブログ村ブログランキング・にほんブログ村へにほんブログ村