Go to Qiita Advent Calendar 2024 Top
LoginSignup
14
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 5 years have passed since last update.

@suzuki-naviin株式会社BeeX

AWS Certified Big Data - Specialty 合格しました

Posted at

先日、AWS認定ビッグデータ専門知識の試験を受験し、合格しました！
その記録を残しておきます。

（2020年4月から「AWS認定データ分析 AWS Certified Data Analytics - Speciality」という名前に変わるそうです。）

（いちおう私のバックグラウンドを書きますと、AWSを触っていた期間としてはたぶん4年ぐらいありますが、アプリ開発側とプリセールス中心で、AWSを理解しているとはあまり言えない状態でした。8月後半からちゃんとAWSのいろんなサービスを触り始めたところで、本格的に業務で使いこなしているとはまだ言えない状態です。9月終わりごろにソリューションアーキテクトアソシエイトを受験して合格しました。その1か月後が今回のビッグデータです。）

勉強方法

データ分析に関して詳しくはないので、まずは本を読みました。以下の本です。

ビッグデータを支える技術―刻々とデータが脈打つ自動化の世界 (WEB+DB PRESS plus)

AWSの内容ではなく、ビッグデータの一般的な知識を得るためです。この本を読むことで「ファクトテーブル」とか「ディメンション」とか、基本的な言葉に触れられて、よかったです。こういう言葉がAWSのいろんな資料に当たり前のように出てくるのに、言葉自体の解説はAWSの資料には当然ありません。

本を読んだあとはすでに合格している先輩方のブログ記事やAWSの公式資料を読んでました。特に参考にした記事や資料を挙げておきます。

合格体験記

以下のサービス別の勉強ノートはだいぶ参考にさせていただきました。各記事の上のほうのリンク先をノートを取りながら読んでから記事にあるこの方のノートと答え合わせをする感じです。

Redshift、EMR、Kinesis、DynamDBは触った経験がまだほとんどなかったのですが、たとえ資料ベースのみでもこのあたりのサービスは勉強しておいてよかったです。

あとは、以下のAWS公式のSlideshareをいくつか見ました。

AWS クラウドサービス活用資料集 | サービス別資料

この中で読んでよかったものとしては、DynamoDB、Redshift、Kinesis、EMRあたりです。

他のAWS認定の試験と違って模擬試験がありませんでした。10問の英語でのサンプルがPDFで開示されているのみです。ので、ぶっつけ本番です。

試験当日

リモート監視の試験会場だったのですが、最初の身分証明書のスキャンがうまくできず、なんどもログインからやりなおし、開始時間がだいぶ遅れました。たぶん試験マシン付属のスキャナーが調子悪かったのだと思います。

65問170分で、時間は目一杯使いました。

1問目がたまたまよくわかっている箇所で、お！いけるじゃん、って思ったら2問目以降は自信をもって答えられる問題があまりありませんでした。最初の3分の1ぐらいでもう駄目だろうと思って、残りほとんど消化試合のつもりで臨んでました。

130分ぐらいでひととおり解いて、残り時間は見直しフラグを立てた問題を見直しました。最初に解いたときによくわからなかった問題に見直しフラグを付けるのですが、8割ぐらいの問題にフラグを付けることになりました。（前回受験したソリューションアーキテクトアソシエイトではフラグを付けたのは3割ぐらい）

フラグを付けなかった2割は、わかる問題で見直し不要と判断したものもありますが、見直しても意味がなくはじめからあきらめたものもあります。

見直し時間は一巡しただけで時間ぎりぎりになりました。

日本語で試験を受けたのですが、翻訳があまりよくなく、問題文を理解するのが難しいのもありました。問題文を日英で切り替えることはできるので、そういうときは英語も読んでみます。英語力ないので英語を読んだからといってすぐに理解できることも少ないのですが、1問だけ英語を読むことで趣旨のわかったものもありました。

結果

こんな感じで結果はだめだろうと思っていたので、最後の画面の「おめでとうございます。」という文言を見て、おどろきました。基準がよくわからないのですが、点数はぎりぎりだったのかもしれません。

総合成績： 66%
分野別の成績 :
1.0  Collection: 50%
2.0  Storage: 77%
3.0  Processing: 87%
4.0  Analysis: 62%
5.0  Visualization: 85%
6.0  Data Security: 40%

セキュリティが弱いのは自覚しています。。。

勉強ノート

自分のノートの一部です。箇条書きのみでこれだけでは内容は伝わらないかもしれませんが、このあたりのキーワードの意味は軽く理解しているつもり、ぐらいのレベルです。

Kinesis Streams

  • 順序付きイベントストリーム
  • 複数のアプリケーションから同時に読み取り可能
  • 3つのAZの永続ストレージに強い整合性でレプリケーション
  • 1つのデータをデータレコードという
  • 24時間、最大で7日間データを保持する
  • パーティションキーでシャードに分散される
  • リシャーディング
  • シャードごとにユニークなシーケンシャル番号をデータレコードごとに振られる
  • 入力側のキャパシティは1シャード1秒あたり1MBまたは1000PUT
  • データ処理側のキャパシティは1シャード1秒あたり2MBまたは5回の読み取りトランザクション
  • データ処理側はシーケンシャル番号でレコード取得開始ポジションを指定可能
  • 料金体系
    • 1シャード1時間あたり
    • PUTペイロードユニット
    • 延長データ保持期間
  • プロデューサー（データ送信側）
    • AWS SDK
    • KPL (Kinesis Producer Library)
      • C++
      • CloudWatchにメトリクスを送信可能
    • Kinesis Agent
      • スタンドアロンなJavaアプリケーション
      • Kinesis Firehoseにも送信可能
      • CloudWatchにメトリクスを送信可能
    • Kinesis Log4j Appender
    • IoT
    • CloudWatch Events
    • CloudWatch Logs
    • Fluentd
      • Kinesis Firehoseにも送信可能
  • コンシューマー（データ受信側）
  • KMSを使ってサーバサイドの暗号化ができる

Kinesis Firehose

  • ストリームデータをS3、Redshift、Elasticsearch Serviceへ簡単に配信
  • Lambdaによる変換が可能
  • Redshiftへの配信
    • 中間にS3に保存する
  • Elasticsearch Serviceへの配信
    • 変換失敗したソースレコードはS3に保存可能
  • データソースにKinesis Streamsを指定した場合はそのほかを同時にデータソースにすることができない
  • 1つのKinesis Streamsから複数のKinesis Firehoseやそのほかに対して同時に配信することは可能

DynamoDB

  • NoSQL
  • 10ms未満のレイテンシー
  • EMR, Redshift, Data Pipeline, S3などと統合されている
  • データは3つのAZに自動でレプリケートされる
    • 少なくとも2つのAZに書き込み完了できたら書き込み完了扱い
  • データ量に制限はない
  • 1個のデータは400KBまで
  • テーブルごとにRead、Writeそれぞれスループットキャパシティを割り当てられる（プロビジョンできる）
    • キャパシティはオンラインで変更可能
    • 書き込み1ユニット：最大1KBを1秒に1回書き込み
    • 読み込み1ユニット：最大4KBを1秒に2回読み込み (強力な整合性の場合は1回)
  • 料金体系
    • プロビジョンしたスループットによって時間当たりの料金が決まる
    • ストレージの容量にも料金が発生
  • on-demand
  • 読み取りは結果整合性
    • 強力な整合性の場合は2倍のRead Capacity Unitを消費
  • トランザクション可能
  • 自動でパーティションイングされる
    • パーティション数を知るすべはなく、気にする必要がないようになっている
  • プライマリキー
    • パーティションキー
    • ソートキー
  • セカンダリインデックス
    • Local Secondary Index
    • Global Secondary Index
  • Conditional Write
  • TTL
    • スループットを消費することなく有効期限が切れたデータを自動で削除できる
    • タイムスタンプを保存しているカラムを設定する
    • Unixタイムスタンプ形式で期限切れの日時をカラムに保存する
    • 即座に削除されるわけではなく最大で48時間かかる場合がある
  • DynamoDB Streams
    • テーブルで発生するすべてのデータアクティビティをキャプチャし、リージョン間でのレプリケーション機能を設定して可用性を高められる
    • 24時間経過したら削除される
    • ハッシュが同じ複数の操作は順番が保証されるが、異なる場合は順序が入れ替わる場合がある
    • DynamoDB SDK、KCL(Kinesis Client Library)で読み取り可能
    • Writeプロビジョニングスループットの2倍速で読み取り可能
    • LambdaはDynamoDB Streamsをトリガーにして起動し、データを読み取ることが可能
  • DynamoDB Local
    • ローカルに開発環境を作れる
    • Jarファイル
  • DynamoDB Accelerator
    • DynamoDB 用完全マネージド型インメモリキャッシュ
    • DynamoDB の応答時間をミリ秒からマイクロ秒に短縮
    • Amazon DynamoDB Accelerator (DAX) | AWS
      https://aws.amazon.com/jp/dynamodb/dax/

EMR

  • Hadoop
  • 分散処理基盤、分散処理アプリケーション
  • S3DispCpを使うとS3とHDFSとの間で高速にデータをコピーできる
  • インスタンスタイプ
    • メモリを大量に使用する場合はm1, m2, m3
    • CPUを大量に使用する場合はc1, c3
    • CPUとメモリの両方を大量に使用する場合はcc2
  • クラスタタイプ2種類
    • transient cluster 一時的なクラスタ
      • 常時起動している必要がない場合
        • HDFSへのロードに時間がかかり、同じデータを繰り返し使う場合には、常時起動のほうがいい場合もある
    • permanent cluster 永続的なクラスタ
  • アーキテクチャパターン
    • ストレージとしてS3を使用
      • 一時的なクラスタで使用できる
    • S3からHDFSにコピー
      • 一時的なクラスタで使用できる
    • HDFSをプライマリストレージとして、S3に定期的にバックアップ
      • EC2インスタンスが異常終了した場合にはデータが失われるリスク
  • コスト最適化の3つの価格モデル
    • オンデマンドインスタンス
    • リザーブドインスタンス
    • スポットインスタンス
  • クラスタの構成 (3種類のノード)
    • マスターノード
    • コアノード
      • HDFS
        • インスタンスストア or EBS
    • タスクノード
      • HDFSを持たない点以外はコアノードと同じ
      • クラスタ内で一部のタスクノードだけスポットインスタンスにするなどが可能
  • EMRFS
    • S3をHDFSのように扱える
    • 「整合性のあるビュー」のオプションを選んだ場合はS3だけでなく内部でDynamoDBが使用される
  • Bootstrap Action
    • ノード起動時に任意のスクリプトを実行できる
      • Bash, Ruby, Python, Perl, C++, Java, etc
  • Private SubnetでもEMRを起動可能
    • S3, DynamoDBへのアクセスはエンドポイントが必要
  • IAM Roleは2つ指定が必要
    • EMR Role
      • EC2を起動するのに必要な権限
    • EC2 instance profile
      • EC2インスタンスがS3などにアクセスするのに必要な権限

Redshift

  • データウェアハウス
    • カラム指向の格納方法でDWHに向いている
  • PostgreSQL互換のSQL
    • PostgreSQLと同じJDBC、ODBCドライバで接続できる
  • データサイズ数百GBから1ペタバイト以上に対応
  • 列指向ストレージ
  • 複数ノードでの並列処理
    • leader node
      • 利用料がかからない
    • compute node
    • 1ノード構成の場合はリーダーノードとコンピュートノードが同居
  • スライス: ノード内でメモリとディスクを分割した論理的な処理単位
  • ノードタイプ
    • dc1: dense compute
      • SSD
    • ds2: dense storage
      • HDD
  • シングルAZ
    • マルチAZにするにはミラーを設定してレプリケーションとフェイルオーバーを設定する
  • Redshiftが向いていないユースケース
    • SQLの並列実行数が多い
    • きわめて短いレイテンシー
      • ElastiCacheやRDS
    • 更新アクセス
      • RDSやDynamoDB
    • データが巨大であっても集計はしない
      • RDSやDynamoDB
    • データセットが 100 GB 未満
      • Redshift の機能は過分であるため、RDS の方が適している
  • 圧縮のアルゴリズムが複数用意されている
    • テーブルの列単位で選択
    • テーブル作成後は変更できない
  • SORTKEY
  • データの分散方法
    • EVEN
      • デフォルトはこれ
      • ラウンドロビン
    • KEY
      • キーとして指定したカラムを使って分散
      • カーディナリティの高いキーを指定する必要がある
    • ALL
      • 全ノードの特定のスライスに集約
  • ユニークキー、外部キーなどの制約はない
    • 指定することでオプティマイザへのヒントとして使うことは可能
  • ANALYZEコマンドにより統計情報を更新
    • 統計情報はクエリプラン決定に使われる
  • VACUUM
    • Redshiftは追記型
    • レコード削除は削除フラグを付けるのみ
  • S3へのスナップショットのバックアップが可能
    • 自動と手動
    • テーブル単位でのリストアも可能
  • Workload Management
    • クエリの用途ごとにキューをわけることが可能
    • 長い時間のかかるクエリが短いクエリをブロックしないようにする目的でも使える
  • Query Monitoring Rules
  • UDF
    • Pythonでユーザ定義関数を作成可能
  • SQA ショートクエリアクセラレーション
  • リザルトキャッシュ
  • リサイズの方法
  • Redshiftアドバイザ
14
12
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
14
12

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?