AWS Certified Data Analytics - Specialty（DAS）要点まとめ

はじめに

AWS Certified Data Analytics - Specialty（DAS） 取得にあたり、備忘がてら、各サービスの要点をまとめした。

これからDASを取得しようとしている人への参考になれば幸いです。

【収集】

▼ AWS IoT Core

• 閾値を超えた時にSNSを使用して通知できるIoTルールを作成できる

ルールエンジン

• 大量のデータをSQLライクな文法で取り込み、分析や視覚化のために10以上のサービスを利用可能
• JSON形式のメッセージをサポート

デバイスシャドウ

• デバイスの状態を把握し、管理

▼ Kinesis Data Streams

拡張ファンアウト

• コンシューマーごとに専用のスループットを提供できる
  • 他のコンシューマーと競合することがない
• シャードあたり１秒間に最大2MBのデータスループットでストリームからデータを受け取ることができる
• Kinesiss Data Firehorseは拡張ファンアウトをサポートしてない

Kinesis Producer Library（KPL）

Streamsのデータ送信する補助ライブラリ
レコードのバッファ処理機能がある

• Aggregation
  • 複数件のデータを 1 データレコードに集約して送信可能
• Collection
  • 複数のレコードをバッファリングして送信

Kinesis Client Library（KCL）

• AWS Kinesis Data Stream に流れるデータ（レコード）を受信して処理を行うコンシューマアプリケーションを実装するためのAWS謹製のライブラリ
• KCLを使用したカスタムアプリケーションは傾向を分析するSQLのようなクエリを実行するには向いていない

暗号化

• サーバー側の暗号化をサポート
• ストリーム入る前にプロデューサーで暗号化する

細かな仕様

• シャード数を増加するとコストも増加する
• リージョン間のログを複製することはできない
• データを永続的に保存し、依存関係なく、複数のコンシューマーにアクセスできる
  • 配信が保証されている
• Kinesis Data StreamsはAWS Glueと直接統合されていない
  • Kinesis Data Firehorseを使用して入力レコード形式の変換を行う
  • データをS3に保存する前に入力データ形式を変更できる
• リアルタイム分析なので、S3からデータを収集するのには向いていない
• データサイズの上限は最大1MB
• 重複レコードの原因
  • プロデューサーの再試行とコンシューマーの再試行が原因
    • プロデューサー側にネットワーク関連のタイムアウトが発生している
    • シャード・レコードプロセッサの両方に変更がある
• 書き込みパフォーマンスの向上
  • ランダム パーティション キーを使用し、それに応じて調整して、シャード間でハッシュキースペースを均等に分散
  • UpdateShardCountのAmazon Kinesis　API を使用して、データストリーム内のシャードの数を増やす

▼ Kinesis Data Firehorse

• ストリーミングデータを取り込んで変換し、S3, Redshift , ESなどに配信できる
  • DynamoDB, EMRは宛先にはできない
• ロード前にデータストリームのバッチ処理、圧縮、変換、暗号化が行われる
  • Lambdaと統合して、配信前にカスタム変換を提供する
• 最小バッファ間隔は 60 秒

暗号化

• KMSを使用したサーバー側の暗号化をサポート

細かな仕様

• データサイズの上限は最大1MB
• 異常検出の機能は無し

▼ Kinesis Data Analytics

• ストリーミングデータをリアルタイムで継続的に読み込み、処理する
  • ほとんどリアルタイムでFirehorseのデータをクエリできる
• 標準SQLを使用してアプリケーションコードを取り込む

細かな仕様

• Kinesis Data AnalyticsはQuickSightと直接統合されていない
• データを強化するためKinesis Data Analyticsから参照できる参照データのS3ソースを追加できる
  • 参照データをアプリケーション内参照テーブルとして保存する
  • リファレンスデータはS3内のオブジェクトとして保存する必要がある
• Kinesis Data Analyticsでデータ ストリームの異常を検出するには、RANDOM_CUT_FOREST関数を使用する

▼ Managed Streaming for Apache Kafka (MSK)

• Kafka ACLを使用することで、トピックごとに読み取り権限と書き込み権限を付与する
• 最大10MBのデータサイズ上限をサポート

【蓄積・保存・データレイク】

▼ S3

• S3 DistCp

  • S3とHadoopを直接統合する
  • S3の大量のデータをHDFSにコピーするときに使用できるオープンソースツール
  • 既存のEMRクラスターでS3バケットからデータを転送する
  • S3DistCp は、Parquetファイルの連結をサポートしていない
    • PySparkを使用して、連結

• S3 ETag

  • オブジェクト内容が変更されていないかを比較して検証できる
  • オブジェクトの整合性チェック

ベストプラクティス

• レコードごと（小さなファイルごと）にS3にアップするとすべてに対してPUT料金が加算され、コスト効率が良くない
  • これはDynamoDBと比較してもコスト効率が良く無い

▼ Lake Formation

• AWSでデータレイクを構築・運用するためのマネージドサービス
  • 実態はほとんどのAWSサービスをラッピングしたもの（IAM, S3, Glue, etc.）
  • すでに登録してある、S3バケットのパス を登録する
• データレイクの構築、セキュア化、および管理を容易にする
  • ユーザーとアプリケーションのためのセキュリティポリシーベースのルールをロールごとに集中的かつ簡単に、最小限の運用オーバーヘッドで定義するのに役立つ。
  • きめ細かなアクセス制御が可能

FindMatches

• FindMatches 変換を使用すると、レコードに共通の一意の識別子がなく、正確に一致するフィールドがない場合でも、データセット内の重複レコードまたは一致するレコードを識別できる
• コードを記述したり、機械学習の仕組みを知る必要が無い

▼ Glue

AWS Glue BlackBelt

クローラー

• Glueのデータカタログにメタデータを作成するプログラム
  • 分類子の優先度に従って、スキーマ情報を自動で判断する
• Glueクローラーの最小精度は5分
  • ジョブとクローラーの時間ベースのスケジュールを行うことができる（cronで指定）
• リージョンをまたいでのクロールも可能
  • すべてのリージョンのデータセットをカタログ化できる

分類子

• データのスキーマを決定するGlueの機能。分類子がデータ形式を認識するとスキーマを形成する
• Glueは 確実性が最も高い分類子の出力を使用します。0.0を超える確実性を返す分類子がない場合、AWS Glue はデフォルトの分類文字列(UNKNOWN)を返す

データカタログ

• Apache Hiveメタストア互換のメタデータリポジトリ
• 暗号化
  • KMSキーを指定して、データベースやテーブルなどデータカタログ全体の暗号化が設定可能
• リソースポリシー
  • データカタログに対するクロスアカウント・クロスリージョンのアクセス制御が可能
• AthenaはGlueデータカタログに登録されたデータセットをおよびデータソースのクエリをネイティブにサポートする
  

サーバレスエンジン

• Glue Schema Regisory
  • スキーマの変更を追跡できる
• Glue ワークフロー
  • StepFunctionsと同じようなことをGlue上で実現できる

接続管理

ジョブ

• DataFrame

  • データをテーブル構造で扱えるSparkの機能。SparkSQLを用いて、DataFrameを操作する

• DynamicFrame
  

• ブックマーク

  • ジョブの実行状態を保持する機能
  • 状態情報を永続化することで、 増分データ処理をサポートする

細かな仕様

• Amazon EMRをAWS Glue PySparkに置き換えることで、ダウンストリームソリューションの費用対効果が高くなる
• Glueのメモリエラー
  • Glueジョブが複数の小さなファイルを処理するために発生するドライバーのメモリ問題
  • ETLコードを変更して、ファイルをグループ化する

【加工・分析】

▼ EMR

動的でスケーラブルなEC2インスタンス全体で、膨大なデータを簡単かつ高速に管理できるHadoopフレームワークを提供する

暗号化

• S3サーバー側の暗号化(SSE-S3, SSE-KMS)
  • SSE-Cはサポートしていない
• LUKS
  • ブロックデバイスディスクの暗号化
• ルートボリュームの暗号化
  • EBS暗号化が推奨される。ルートボリュームの暗号化にLUKSは使用できない
• クラスターボリュームの暗号化
  • ローカルディスクの暗号化を有効にして、ルートボリュームとストレージボリュームを暗号化
• HDFS での透過的暗号化
  • 透過的なデータ暗号化により、データの転送中と保存中のデータの暗号化を設定することができ、Apache Ranger を使用して承認を設定することができます。

コスト

• クラスターの90%を超えたタイミングで課金開始
• 1秒あたりの課金となるので、短時間で多くのスポットインスタンスで使うとコスト最適
• マスターノード・コアノードにはリザーブドインスタンスを検討
  • コアノードには、プロビジョニングタイムアウトを備えたインフタンスフリートを使用する
  • HDFSはコアノードに存在するので、スポットインスタンスの使用はデータの欠損を招く恐れがあるので推奨されない
• タスクノードには、スポットインスタンス

パフォーマンス

• 同時マッパータスクの数を調整する
• ジョブ設定で入力分割サイズを変更する

EMRFS

• EMR ファイルシステム (EMRFS) は、すべての Amazon EMR クラスターが Amazon EMR と Amazon S3 の間で通常のファイルを直接読み書きするために使用する HDFS の実装
• EMRFSの暗号化
  • バケットごとのオーバーライドオプションを提供することで、S3に保管中のEMRFSのデータを暗号化
• 整合性のあるビュー
  • EMRFS の整合性のあるビューは、 DynamoDB テーブルを使用して整合性を追跡し、EMRFS と同期された、または EMRFS により作成された Amazon S3 内のオブジェクトを追跡します
• EMRFSとSpark MLを組み合わせたEMRを使用すると機械学習アルゴリズムを実行できるようになる

細かな仕様

• EMRクラスターのアイドル状態は、TrustedAdvisorではカバーできない
• EMRで複数のIAMロールを関連づけることはできないため、ユーザーごとに複数のアクセスを切り替えたりすることもできない
• EMRはオンプレミスのデータに直接アクセスすることができない
• EMRをAWS Glue PySparkに置き換えることで、ダウンストリームソリューションの費用対効果が高くなる
• EMRのインスタンスグループは自動スケーリングを提供する
  • インスタンスフリートには自動スケーリングポリシーが無い

クエリエンジン

データベースからデータを取り出す時にはSQLみたいに簡単にデータの取り出したい.
そのような思いからMapReduceの演算結果をSQL"風"に取り出せるように開発されたのがHive

• Hive

  • オープンソースのDWH
  • SQL風に記述されたHQLを使用することでデータを取り出す
  • 大容量のデータをバッチ処理したりするのには向いている
  • 外部メタストアに使用可能
    • Glue Data Catalog
    • RDS or Aurora

• Presto

  • Facebookで開発された対話型に特化した高速クエリエンジン
  • Hiveに比べて非常に高速
  • 複数のデータソースを使用したアドホック分析処理に向いてる

Apache ライブラリ

• Apache Spark
  • EMRクラスターを使用して機械学習・ストリーム分析・グラフ分析
• Apache HCatalog
  • カスタムアプリケーション内からHiveのメタテーブルにアクセスするためのツール
• Apache HBase
  • 非リレーショナルな分散型データベース
• Apache Hue
  • オープンソースのウェブグラフィカルインターフェース
• Apache Pig
  • HadoopアプリケーションとしてHadoop上で稼動し、利用者に「Pigによるデータ操作プログラミング環境」
• Apache Zeppelin
  • Zeppelinはデータの取り込み、データの発見、データの分析、データの視覚化をするノートブック
  • ノートブック : ブラウザで、コードとコメントを入力してそれらを別々に処理した結果を出力するもの

【DWH】

▼　Redshift

• 非構造化データはRedshiftには読み込みできない
  • データが構造化されていない場合は、EMRでETLを実行してRedshiftで実行可能なデータを取得できる
  • SQL準拠のワイヤプロトコルを使用しているため、適切に 構造化されたデータ（複雑なデータ） に対するアドホック分析をサポートしている
• Redshiftクラスターは自動的にスケーリングできない
• 監査ログはS3に保存される

ノード構成

• クラスターごとに、リーダーノードと 1 つまたは複数のコンピューティングノードがあります
• 小さいノードをから増やしていったほうがコスト効率が良い
  • 増やせるのはコンピュートノードのみ（リーダーノードは増やせない）

暗号化

• RedshiftでHSMによる暗号化を使用するには、クライアントとサーバー証明書を利用して信頼されたアクセスを確立する必要がある
  • VPNを介して企業のオンプレHSMと統合できる

データロードのベストプラクティス

• COPYコマンド
  • 超並列処理 (MPP) アーキテクチャを利用し、S3, DynamoDBなどの複数のデータソースから並行してデータをロードする
    • 大きなファイルは小さなチャンクに分割した方が良い
    • ファイル数がRedshiftクラスターのスライス数の倍数になるようにファイルを分割したほうが効率が良い
  • 複数のCOPYコマンドは Redshiftへの直列ロードを実行する
• UNLOADコマンド
  • Amazon Redshift クエリの結果を、分析用の効率的なオープン列指向ストレージ形式であるApache ParquetのS3データレイクにアンロード
    • Redshift Spectrumにはロードできない
  • ENCRYPTEDオプション
    • クライアント側の暗号化を使用して暗号化されたデータを自動的に保存し、S3への転送中にHTTPSを使用してデータを暗号化する
• データを複数のファイルに分割し、テーブルに分散キーを設定すれば、並列処理の長所を最大限に活用できます。
  • 単一のファイルでは並列処理をサポートしない
• ロード中に一時的なステージングテーブルを使用する
  • 変換用のデータを保持する。ETLセッションが完了すると自動的に削除される
• NOLOADオプション
  • データベースにデータを実際にロードせず、すべての データファイルの整合性をチェックする

ワークロード管理（WLM)

• 大規模な顧客のために専用のキューを定義し、残りの顧客のために別のキューを定義することで、大規模な顧客からのクエリが干渉しないようにすることができる
• 待機時間を発生させないようにできる
  • インタラクティブで長時間実行されるジョブの優先順位づけに役立つ

Redshift時系列テーブル

• バキュームを作成することなく、古いデータを効率的に削除してクエリを実行できる
• TTLはサポートしていない

Redshift Spectrum

• S3にデータを保存したまま、Redshiftにデータをロードでできる機能
  • Glacierに対しては使用できない
• アクセス頻度の高いものをローカルに保存して、低いものをS3に保存することでコスト削減を実現
  • ローカルに保存しておくよりも費用対効果が高い
    

Redshift フェデレーションクエリ

• データ本体は外部データベースに置いたまま、外部データベースのテーブルに直接クエリできる機能
  • RDS, Aurora PostgreSQLのテーブルにRedshiftから直接アクセスできるようになりました。いわゆる、RedshiftからPostgreSQLに対してデータベースリンクする機能

分散スタイルとテーブル

• ファクトテーブル

  • 複数のディメンションテーブルの外部キーを複合キーにしているテーブルです。集計したい値を持っています。
  • レコードが変更できない（サービスログや測定情報）

• ディメンションテーブル

  • マスター情報のテーブルです。データを分析する際にグルーピングしたい項目が列に含まれます。

• ALL 分散

  • データ転送を排除したいとき

• Event 分散

  • どの分散スタイルに適合されるか不明なとき
  • テーブルが高度に非正規化されており、頻繁な結合に参加していないとき

【アドホックな分析・可視化】

▼　Athena

ワークグループ

• チーム・ワーク・アプリケーションごとのクエリを分離するのに役立つ。ワークグループごとの使用量制限、コスト管理も役立つ
• チームを分離して暗号化を実施できる
• 制御制限
  • ワークグループ全体のデータ使用量制限
    • ワークグループごとに各クエリの制御制限を規定の閾値にすることで、データ量を超えてスキャンできないようにする
  • クエリごとの制御制限
    • クエリごとにスキャンされるデータの合計量を指定

パフォーマンスチューニング

1. データをパーティションに分ける
   • GROUP BYを使用する
2. ファイルを圧縮・分割する
3. 列指向データの作成を最適化する
   • Apache Parquet形式を使用する
4. ファイルサイズを最適化する
   • より大きなファイルサイズにするため、ファイルをマージする

クエリの種類

• ずらしウィンドウクエリ
  • 到着時間に一貫性のない、データグループの分析に適したウィンドウ処理メソッドを使用している
  • 不定期間隔で届くデータを処理するのに向いている
• スライディングウィンドウクエリ
  • ストリーム内のトレンドを見極めるのに適している
  • 時間ベースまたは行ベースのウィンドウを定義するのに役立つ
• 継続的クエリ（連続クエリ）
• タンブリングウィンドウクエリ

細かな仕様

• 異なるリージョンとGlacier内のオブジェクトアクセスはできない
• AthenaはGlueデータカタログに登録されたデータセットをおよびデータソースのクエリをネイティブにサポートする

▼　QuickSight

SPICE

• SPICEというインメモリ型の高速データベースが内蔵されている
  • クエリ速度と、DBへの負荷軽減
• S3やPC上のファイルをデータソースにする場合は、SPICEに取り込むことで分析が可能
  • S3をデータソースとして作成された、QuickSightのデータセットはSPICEに自動的にインポートされる（S3バケットの権限を設定する必要あり）
• リアルタイム分析には向いていない

セキュリティ

• 行レベルのセキュリティ機能（RLS）が組み込まれており、データセットで定義する
• Enterprise エディションでは、SPICE に保存されているデータが、AWS管理のブロックレベル暗号化を使用して暗号化される

細かな仕様

• エクセルファイルを直接扱えるため、事前にLambda等で変換する必要無し
• 機械学習を使用して、データの隠れた洞察と傾向を明らかにし、主要な要因を特定し、ビジネス指標を予測するのに役立ちます
  • MLを活用した異常検出
• Amazon QuickSight Enterprise エディションは、AWS Directory Service for Microsoft Active Directory と Active Directory Connector の両方をサポートしています。
  • Enterprise エディションでは、SPICE に保存されているデータが AWS管理のブロックレベル暗号化キーを使用して暗号化されるためです。AWS KMS にインポートされたカスタマーマネージドキー使用できません。

その他

▼　DMS

• データソースとしてElasitcSearchをサポートしていない

▼　DataSync

• Data Syncエージェントはオンプレミス環境にインストールする。デフォルトで転送中の暗号化をサポートし、データの整合性を検証する

▼　DataPipline

• RDS　から DynamoDBへのダウンタイムのない移行をサポート
• DataPiplineを利用することで、DynamoDBのクロスリージョンレプリケーションを利用できる