More than 1 year has passed since last update.

DASが終了するのでお蔵入りしてた記事を公開する

Last updated at 2023-11-29Posted at 2023-11-28

ハンズオンテキスト, AWS公式の無料トレーニング, Udemy, Tech Stockなどをやって、でてきた用語や設定などを網羅的に調べたり操作してキャプチャや説明をまとめてました。DAS勉強してる人向けに奇麗にまとめてqiitaにアップしようと思っていましたが、書き方とか網羅性が気に入らず結局お蔵入りになってました。DASが終了するとのことでせっかくなのでアップします。当初のタイトル案は「眺めるだけでDASの得点が上がる記事」です。当時、資格勉強してる人が求めてるのは得点アップにつながる記事だと思ったんですよね(合格記はあふれてるので実践的なやつがいいんじゃないかと)。資格試験の合格が目標になると座学に寄りがちですが、実際に操作してるキャプチャ集の記事があると、普段出てくる用語はここで出てくるのかとかこう設定するのかと理解の一助になると思ってました。こう見るとGlueとか全然書いてないなあ

redshift

ノードの種類

DC2/RSAが主流
RSAはコンピュート/ストレージを分離してキャッシュの仕組みなど新しいアーキテクチャを採用してる高パフォーマンスタイプ

DC2 (Dense Compute/高密度コンピュート),

RA3 (何の意味か不明/次世代コンピュート・インスタンス)

DS2 (Dense Storage/高密度ストレージ)はレガシーとなってる

エラスティックリサイズ

ノードタイプを変更したりノード数を変えたりできる

以下方式がある
エラスティックリサイズ(伸縮自在なサイズ変更) .. 15分程度で可
クラシックリサイズ(従来のサイズ変更) .. 時間がかかる

リファレンスに仕様や制限色々書いてある

マルチAZ

2023/1/31時点ではプレビュー機能となっていて、クラスタ一覧で表示項目はあるが設定はできない

preview clusterの作成ウィザードで、preview_2022を選択すると、マルチAZを指定可能になる

制限設定

同時実行スケーリングの使用制限

毎日N時間まで、それに到達したときに「システムログにログ出力」「SNSにアラートを飛ばす」などを設定できる

他、以下がある
Redshift Spectrum の使用制限
クロスリージョンデータ共有の使用制限

クロスリージョンスナップショット

自動および手動スナップショットを別の AWS リージョンに自動的にコピーするように Amazon Redshift を設定します

パフォーマンスモニタリング系

クラスタメトリクス.. クラスタのサーバとか全体に関すること (CPU使用率とかディスク使用率とか状態とかクエリの合計とか)

クエリのモニタリング.. クエリのパフォーマンスとか、ワークロードごとのパフォーマンスとか色々なメトリクスがある
一例
優先度別の平均キュー待機時間、のキャプチャ

同時実行スケーリングアクティビティ、のキャプチャ

テーブルの復元

スナップショットから特定のテーブルを復元できる

監査ログの暗号化方式

Q: 監査ログの暗号化方式は?
A: SSE-S3(AES-256)のみ

クラスタ作成 -> 作成したクラスタをクリック -> プロパティタブをクリック -> 編集をクリック

監査ログ記録をオンにする
S3/CloudWatchを選べる
どちらも暗号化の選択肢なし(S3バケットに、SSE-S3(AES-256)で格納される)

S3バケットに格納するときはバケット名を入力する

CloudWatchに格納するときは、ログの指定ができる(ユーザーログ/接続ログ/ユーザーアクティビティログ)

監査ログの内容

リファレンス

接続ログ – 認証試行、接続、切断をログに記録します。
ユーザーログ – データベースのユーザー定義の変更に関する情報をログに記録します。
ユーザーアクティビティログ – 各クエリをデータベースで実行される前にログに記録します。

暗号化

クラスタを作成するときに暗号化を設定できる
KMS/HMS
KMSの場合はAWSマネージドキー/CMK/別アカウントのCMKを指定できる

パラメータ

パラメータとワークロード管理は、パラメータグループで管理されてる
デフォルトのものはさわれない

新規に作成すると、パラメータとワークロード管理を設定できる
パラメータは以下がある

通信セキュリティを高めるときに、require_sslをtrueに設定する

ワークロード管理

WLMモードに自動/手動がある

キューを追加する

メモリ量、並列数(メインでの同時実行)、同時実行スケーリングモード(OFF/自動)、タイムアウトを入力する

クエリモニタリングルールを追加する
テンプレートからルールを追加、で以下を選択できる

diststyle(分散スタイル)

テーブルを作成する場合は、AUTO、EVEN、KEY、または ALL という 4 つの分散スタイルのいずれかを指定します。
分散スタイルを指定しない場合、Amazon Redshift は AUTO 分散を使用します。

AUTO 分散
AUTO 分散では、Amazon Redshift はテーブルデータのサイズに基づいて最適な分散スタイルを割り当てます。

EVEN 分散
リーダーノードは、特定の列の値に含まれている値にかかわらず、ラウンドロビン方式によって複数のスライス間で行を分散させます。
テーブルが結合に参加しない場合は、EVEN ディストリビューションが適切です。
KEY ディストリビューションと ALL ディストリビューションのどちらかを明確に選択できない場合にも適しています。

キー分散
行の分散は、特定の列に含まれている値に従って行われます。

ALL 分散
テーブル全体のコピーがすべてのノードに分散されます。
ALL 分散では、クラスタ内のノードの数だけ必要なストレージが増える
小さいディメンションテーブルを DISTSTYLE ALL として定義しても大きな利点はありません。

ベストプラクティス超要約

Amazon Redshift の概念実証の実施

データのロード時間 – COPY コマンドの使用は、データをロードするためにかかる時間をテストするための一般的な方法です。

データセキュリティ — Amazon Redshift では、保管時のデータと転送中のデータを簡単に暗号化できます。また、キーを管理するための数多くのオプションがあります。

バックアップとスナップショット – バックアップおよびスナップショットが自動的に作成されます。ポイントインタイムのスナップショットは、いつでも作成することも、スケジュールに基づいて作成することもできます。

サイズ変更 — Amazon Redshift ノードの数またはタイプの増加を含める必要があります。サイズ変更の前後のワークロードスループットが、ワークロードボリュームのばらつきに

同時実行スケーリング – この特徴を使用すれば、データウェアハウス内のトラフィック量の変動を処理できます。同時実行スケーリングを使用すると、一貫した高速のクエリパフォーマンスで、事実上無制限の同時ユーザーと同時クエリをサポートできます。

自動ワークロード管理 (WLM) – 自動 WLM を使用して、ビジネスクリティカルなクエリを他のクエリよりも優先します。ワークロードに基づいてキューを設定してみてください

テーブル設計 – Amazon Redshift は、ほとんどのワークロードですぐに使用できる優れたパフォーマンスを提供します。テーブルを作成する場合、デフォルトのソートキーとディストリビューションキーは AUTO です。

レイクハウスの統合 – 組み込みの統合機能を使用して、すぐに使用できる Amazon Redshift Spectrum 機能をお試しください。Redshift Spectrum を使用すれば、データウェアハウスをデータレイクに拡張し、既存のクラスターを使用して Amazon S3 のペタバイト規模のデータに対してクエリを実行できます。

Amazon Redshift テーブル設計のベストプラクティス

最良のソートキーの選択

ソートキーに応じたソート順でデータをディスクに保存します。
最適なクエリプランを決定する際にソート順を使用します。

適切なソート順を選択するには、ソートキーとして AUTO と入力します。

最新のデータが最も頻繁にクエリ処理される場合は、タイムスタンプ列をソートキーの主要な列として指定します。

1 つの列に対して範囲フィルタリングまたは等価性フィルタリングを頻繁に実行する場合は、その列をソートキーとして指定します。

テーブルを頻繁に結合する場合は、結合列をソートキーとディストリビューションキーの両方として指定します。

最適な分散スタイルの選択

クエリを実行すると、必要に応じて結合と集計を実行するために、クエリオプティマイザによって行がコンピューティングノードに再分散されます。
テーブル分散スタイルの選択は、クエリを実行する前にデータを必要な場所に配置しておくことによって、再分散ステップの影響を最小限に抑えるために行われます。

ファクトテーブルと 1 つのディメンションテーブルをそれらの共通の列に基づいて分散させます。
ファクトテーブルに指定できる分散キーは 1 つだけです。
ディメンションテーブルのプライマリキーとそれに対応するファクトテーブルの外部キーをいずれも DISTKEY として指定します。

フィルタリングされたデータセットのサイズに基づいて最大ディメンションを選択します。
テーブルのサイズではなく、フィルタリング後のデータセットのサイズを考慮します。

フィルタリングされた結果セットで高い濃度の行を選択します。
日付列の販売テーブルを配信する場合、例えば、ほとんどの販売が季節的でなければ、おそらくほぼ均等なデータ分散を取得します。
範囲が制限された述語を使用して狭い日付期間をフィルタリングする場合は、フィルタリングされた行のほとんどはスライス限られたセットになり、クエリのワークロードもスキューされます。

ALL 分散を使用するように一部のディメンションテーブルを変更します。
ファクトテーブルやその他の重要な結合テーブルとディメンションテーブルをコロケーションできない場合は、テーブル全体を全ノードに分散させることによってパフォーマンスを大幅に向上させることができます。
ALL 分散を使用すると、ストレージ領域要件の増大、ロード時間の長期化、メンテナンス操作の増加を招くため、ALL 分散を選択する前にすべての要因を比較検討しておく必要があります。

Amazon Redshift が適切なディストリビューションスタイルを選択できるようにするには、ディストリビューションスタイルに AUTO を指定します。

COPY による圧縮エンコードの選択

テーブルを作成するときに圧縮エンコードを指定できますが、ほとんどの場合、自動圧縮が最も適切な結果を生み出します。

COPYは自動的に圧縮かける

COPY コマンドは、データを分析し、ロード操作の一部として自動的に空のテーブルに圧縮エンコードを適用します。

プライマリキーおよび外部キーの制約の定義

プライマリキーおよび外部キーの制約を定義します。
より効率的なクエリプランを生成します。

最小列サイズの使用

列の最大サイズを使用しないようにしてください。
VARCHAR 列に格納する可能性が高い最大値を考慮し、それに応じて列のサイズを決定します。

varcharは可変長の文字列を格納

日付列での日時データ型の使用

DATE および TIMESTAMP データを CHAR または VARCHAR よりも効率的に保存するので、クエリパフォーマンスが向上します。

データをロードするための Amazon Redshift のベストプラクティス

要するに、1つの大きいファイルは圧縮して、スライスの倍数になるように1MB～1GBに分割し、単一のCOPYコマンドを実行すると良い (自動的に並列でロードされる)

COPY コマンドを使用したデータのロード

COPY コマンドは、Amazon S3、Amazon EMR、Amazon DynamoDB、またはリモートホスト上の複数のデータソースから同時にデータをロードします。
COPY コマンドは INSERT ステートメントを使う場合よりもはるかに効率的に大量のデータをロードし、データを保存します。

単一の COPY コマンドを使用した複数のファイルからのロード

複数の圧縮データファイルからの並列的なデータロードを、自動的に実行します。

ただし、複数の COPY コマンドを同時に使用して複数のファイルから 1 つのテーブルにデータをロードする場合には、Amazon Redshift はそれらの読み込みを直列的に実行します。
この種類のロードはかなり低速で、
テーブルにソート列が定義されている場合は、最後に VACUUM プロセスが必要になります。

ロードデータの分割

複数のファイルから COPY コマンドを使用して圧縮データをロードすると、それらの読み込みは並列的に実行されます。これにより、クラスター内のノード間でワークロードが分割されます。
大容量で圧縮された単一のファイルから全データをロードする場合、Amazon Redshift は読み込みを直列的に実行します。つまり、この処理はかなり低速になります。

大きな圧縮ファイルからデータをロードしようとする際には、圧縮が完了したデータを、ほぼ等しいサイズ (1 MB から 1 GB 程度) の小さいファイルに分割することをお勧めします。
並列処理にとって最適なファイルサイズは、圧縮後で 1～125 MB 程度です。
ファイルの数はクラスター内のスライス数の倍数である必要があります。

データファイルを圧縮する

大きなロードファイルを圧縮するときは、gzip、lzop、bzip2、または Zstandard を使用してそれらを圧縮し、データを複数の小さなファイルに分割することをお勧めします。

ロードの前後におけるデータファイルの検証

必要なファイルがバケットにあることを確認する
S3 バケットにファイルをアップロードした後に、バケットの内容を一覧表示し、必要なすべてのファイルが揃っており、不必要なファイルがないことを確認します。

データが正しくロードされたことを確認する
ロード操作が完了したら、STL_LOAD_COMMITS システムテーブルにクエリし、ファイルが予定どおりロードされたことを確認します。

複数行の挿入の使用

COPY コマンドを選択できないときに SQL 挿入が必要な場合、可能であれば、複数行の挿入を使用します。

一括挿入の使用

テーブル間でデータまたはデータのサブセットを移動する必要があるとき、INSERT および CREATE TABLE AS コマンドを使用します。
例えば、次の INSERT ステートメントでは、CATEGORY テーブルからすべての行が選択され、CATEGORY_STAGE テーブルに挿入されます。
insert into category_stage (select * from category);

ソートキー順序でのデータのロード

ソートキー順序でデータをロードし、バキュームの必要性をなくします。
新しいデータの各バッチがテーブルの既存の行に続く場合、データはソート順序で適切に保存され、バキュームを実行する必要がありません。COPY により入ってくるデータの各バッチがロード時にソートされるため、各ロードの行を事前にソートする必要はありません。

順次ブロックでのデータのロード

ソート順序に基づいて順次ブロックでデータをロードすればバキュームの必要性がなくなります。
1 月、2 月などと、行をロードします。ロードが完了したとき、テーブルは完全にソートされています。バキュームを実行する必要はありません。

時系列テーブルの使用

(引用なし)

ステージングテーブルを使用したマージ（アップサート）の実行

データを最初にステージングテーブルにロードすることで、効率的に新しいデータを更新し、挿入できます。

merge ステートメント (update または insert、または upsert とも呼ばれる) をサポートしません。
ただし、実質的にマージ操作を実行できます。そのためには、データをステージングテーブルにロードし、UPDATE ステートメントおよび INSERT ステートメントのターゲットテーブルにステージングテーブルを結合します。

保守管理の時間枠を回避したスケジュール計画

大規模なデータロードや VACUUM 操作などの長時間実行される操作のスケジュールは、保守管理の時間枠を避けて設定します。

Amazon Redshift クエリの設計のベストプラクティス

(引用なし)

Amazon Redshift Advisor からのレコメンデーションの使用

Redshift Advisor は、Amazon Redshift クラスターを最適化してパフォーマンスを高め、運用コストを低減するための方法に関するレコメンデーションを提供します。

その他リファレンス

ショートクエリアクセラレーションを使用する

ショートクエリアクセラレーション (SQA) は、実行時間が短い一部のクエリを、実行時間が長いクエリよりも優先します。
実行時間が長いクエリをキューで待機するよう強制されません。

quick sight

e-statから年代別総人口をダウンロード
https://dashboard.e-stat.go.jp/timeSeriesResult?indicatorCode=0201010000000010000

QuickSight -> データセット -> ファイルアップロードで総人口のCSVをアップロード

視覚化する、をクリック

利用開始

サインアップ

エディション選択

自分のQuick Sightは一度Enterprizeを選択した影響でサインアップし直すときにStandardが表示されなくなったので(EnterprizeからStandardにするにはサブスクリプションの解除なるものが必要)、一覧についてはリファレンス参照

この辺使うにはEnterprizeが必要

閲覧者
行レベルのセキュリティ
SPICE データの 1 時間ごとのリフレッシュ
保管中のデータの安全な暗号化
Active Directory への接続
機械学習インサイト

アカウントの作成

認証方法
IAMとQuickSight管理ユーザを利用、IAMのみ、ActiveDirectoryから選択

QuickSightからアクセスするAWSサービスを選択

作成完了

データセットの作成

データセットを選択

「ファイルをアップロード」からCSVをアップロードする
SPICEにインポートする際の推定テーブルサイズ、SPICEの空き容量が表示される

「データの編集/プレビュー」をクリック
インポートする列の選択、列名の編集、データ型の変更などができる

視覚化を実行

SPICEへのインポートの成功が表示される

ビジュアルタイプを選択

送信先

OpenSearch, Redshift, S3, サードパーティアプリと連携できる
連携できないもの: Lambda, EMR, Kinesis Data Analyticsなど

ここからQuick Sightの各機能を見てく

データセット

連携元が豊富で、AWS内外のサービスと連携できる
salesforce, s3, athena, rds, redshift, auroraなどの各DB, open search(erastic search)
emrは連携できない

QuickSightの管理

メニューの以下を確認してく

ユーザーを管理

アクセス許可の管理

後述の「IAM ポリシーの割り当て」でQuickSightのユーザにIAMポリシーを割り当てることができるが、ここでQuickSightのざっくりとした権限を直接定義して割り当てることもできる

セキュリティとアクセス権限

QuickSight の AWS のサービスへのアクセス
デフォルトのリソースアクセス
個々のユーザーとグループのリソースへのアクセス
IP 制限
ダッシュボードへのパブリックアクセス

QuickSight の AWS のサービスへのアクセス

デフォルトのリソースアクセス

IAM ポリシーの割り当て

QuickSightのユーザにIAMポリシーを割り当てることができる

IP 制限

ダッシュボードへのパブリックアクセス

VPC 接続の管理

QuickSightにセキュリティグループを設定できる
(VPCに立てたRedShiftと連携するときに利用する)

KMSキー

デフォルトでAWS マネージドKMSキーで暗号化されているが、カスタマーマネージドKMSキーで暗号化もできる

マニフェストを利用してS3上のオブジェクトからデータセットを作成する、特定のS3バケットにアクセスするための権限を設定する

データセットの作成 -> S3を選択 -> S3に置いたマニフェストファイルのS3 URIを指定(直接アップロードも可) -> 権限エラーになる

QuickSightの管理 -> セキュリティとアクセス権限 -> 管理をクリックする

S3にチェックがついていないので

チェックをつけて、表示されるダイアログでS3バケットを指定する。「Athena Workgroup の書き込みアクセス許可」も有効にする

セキュリティとアクセス権限設定画面に戻ると、S3が表示されるようになった

データセットでS3を選択し、S3上に格納したマニフェストを読み込み、マニフェストに記載したS3上のcsvを読み込んでSPICEに追加できた

定期更新する

データセット(マニフェストファイルを利用してS3のオブジェクトを参照してるもの)を開く -> 新しいスケジュールの追加

スケジュールを入力し保存する
頻度は毎時/毎日/毎週/毎月から選択できる。細かい時刻の指定はできない

保存後、設定したスケジュールが更新される

IP制限

QuickSightの管理 -> セキュリティとアクセス権限

IP制限できる

セキュリティグループ

ユースケース: プライベートVPC上のEC2/RDS/Redshiftと連携する
Amazon QuickSight から Amazon Redshift クラスターまたはプライベートサブネットにある Amazon RDS DB インスタンスへのプライベート接続を作成する方法を教えてください。
ソリューション: VPC接続を作成すれば (VPC/サブネット/セキュリティグループを設定)、プライベートVPC上のリソースと通信できる

操作手順はこちらの記事が分かりやすい

4-2. Redshift用セキュリティグループの作成
4-3. Redshiftへのセキュリティグループ紐づけ
4-4. QuickSight用セキュリティグループの作成
4-5. Redshift接続用のVPC接続設定

暗号化

デフォルトで暗号化されている

デフォルトのデータ暗号化の詳細については、こちらを参照してください。

リンク先のリファレンス

Amazon QuickSight は Amazon QuickSight メタデータを安全に保存します。

Amazon QuickSight は Amazon QuickSight データをセキュアな方法で保存します。
SPICE 内で保管されているデータは、AWS マネージドキーによるハードウェアブロックレベルの暗号化を使用して暗号化されます。
SPICE 以外で保管されているデータは、Amazon マネージド KMS キーを使用して暗号化されます。SPICE 以外で保管されているデータは、Amazon マネージド KMS キーを使用して暗号化されます。これには以下が含まれます。
メールレポート、フィルターのサンプル値、クエリ結果キャッシュ。

カスタマーマネージドKMSキーを使うこともできる

Redshift Spectrum連携

ユースケース: Redshift SpectrumをQuickSightのデータソースとして利用する
ソリューション: AWS公式のデータレイクハンズオン

ストリームデータを Kinesis Data Firehose に送信後、 Amazon S3（以下、S3）に保存することで長期保存します。その後、 Amazon Redshift Spectrum（以降、Redshift Spectrum）を用いて、クエリを実行し、 QuickSight で可視化します。

行レベルのセキュリティ(RLS)

データセットを選択して、行レベルのセキュリティの設定をクリック

ユーザーベースとタグベースの設定がある

ユーザーベースのルールでは、あらかじめ見せたくないデータをcsvで定義しておいて、それをデータセットのルールとして適用する

タグベースのルールは、タグを設定して見せる行を制御する
タグベースのルールは、リーダーセッションキャパシティで使う
リーダーセッションキャパシティは、QuickSightアカウントがないユーザにQuickSightのグラフを公開する機能(匿名アクセス)

手順は以下が参考になる
Amazon QuickSightでデータセットへのアクセスを制限する
 Amazon QuickSight で RLS を有効化したデータセットから子データセットが作成出来るようになりました
 QuickSightのRLS(Row-Level Security) が匿名ユーザーのダッシュボードで使えるようになりました
 QuickSight でリーダーセッションキャパシティで使えるタグベースの RLS を使ってみた

Amazon QuickSight のビジュアルタイプ

問題集ででてきたものは以下
(リファレンスに画像があれば転記、なければ基本Google検索のリンクを書きます)

棒グラフ

単一測定棒グラフ
リージョンごとの収益目標です。

複数測定棒グラフ
収益目標とリージョンあたりのコストなどです。

折れ線グラフ

一定期間の測定値の変化を比較します。

円グラフ

パイチャート
ドーナツチャート, ドーナツグラフ

合計の割合を示す場合に最適です。

パイチャート、ドーナツチャートの違い(Google検索)

ファネルチャート (ファンネルチャート, ファネルグラフ)

ファネルグラフは、ボトルネックなど、各ステージの傾向や潜在的な問題領域を示すことができるため、ビジネスの環境で役立ちます。

Google検索

ヒートマップ

傾向と異常値を識別する場合はヒートマップを使用します。

KPI (主要業績評価メトリクス)

キー値とその目標値の比較を視覚化します。

ピボットテーブル

傾向と異常値を識別する場合はヒートマップを使用します。色を使用することでこれらの特定が容易になるためです。ビジュアル上でデータを分析するには、ピボットテーブルを使用します。

docs.krew.grapecity.com
が分かりやすかったです(他のグラフについても分かりやすいです。「じょうご」と記載されてるグラフはファネルチャートかと思います)

レーダーチャート

複数の観測値を 1 つのレーダーチャートにプロットして複数の多角形を表示できます。これにより、複数の観測値の範囲外の値をすばやく簡単に見つけることができます。

ツリーマップ

長方形のサイズ
暗い色は高い値を示し、明るい色は低い値を示しています。

Google検索

ワードクラウド

単語またはフレーズの頻度を表示することです。

Kinesis関連

Kinesis Data Streams

ストリームの作成

名前と容量モード(オンデマンド/プロビジョンド)を指定する

オンデマンド
プロデューサーからの書き込みは200MB & 20万レコード/s、
コンシューマーからの読み込みは400MB/s、デフォルトコンシューマーは2。

プロビジョンド
1シャードあたり、
プロデューサーからの書き込みは1MB & 1000レコード/s、
コンシューマーからの読み込みは2MB/s。

データ保持期間、サーバー側の暗号化、拡張メトリックのモニタリング中のデフォルトが表示される。
ストリーム作成後に編集できる

ストリームの詳細画面

作成されたストリームの設定を確認する

アプリケーションタブ
プロデューサー、コンシューマーのコードサンプルのリンクなどが表示される

モニタリングタブ
GetRecordsのレイテンシーが大きいときは、シャードの追加などを検討する

設定
容量、暗号化、データ保持期間、拡張(シャードレベル)メトリクス

追加の設定

データ保持期間、サーバー側の暗号化、拡張メトリックのモニタリング中のデフォルトが表示される。
ストリーム作成後に編集できる
を設定してみる

暗号化は、AWS管理のCMKか、カスタマー管理のCMKを選ぶ

データ保持期間はデフォルト1日で、最大1年

Amazon Kinesis Data Streams では、デフォルトでは 1 日 (24 時間) のデータが保存されます。1 日を超えて最大 365 日までのデータを保存することもできます。データが保存されている最初の 7 日間は、データ保持の延長料金が課金されます。その後、7 日を超える期間保存され、指定した保持期間までのデータに対して、GB/月の料金が課金されます。

拡張(シャードレベル)メトリクスは、CloudWatchメトリクスにシャードのメトリクスを追加できる

データビューワー
プロデューサーからデータ送信すると、ここでデータ見れる

CLIでデータ入れてみる

この辺のサイトを使って適当なjsonを作成
https://www.site24x7.com/ja/tools/json-generator.html
https://www.atatus.com/tools/json-generator

{
        "id": "63e6cee1263ca78f0d8bd5ad",
        "currentJob": {
                "title": "Developer",
                "salary": "mask;"
        },
        "jobs": [
                {
                        "title": "medic",
                        "salary": "R$ 4.839,90"
                },
                {
                        "title": "teacher",
                        "salary": "R$ 4.849,86"
                }
        ]
}

パーティションキーに1を指定
実行すると、シャードのIDと、シーケンスナンバーが返される

aws kinesis put-record --stream-name mystream --partition-key 1 --data file:///home/user/temporary-directory/test.json --cli-binary-format raw-in-base64-out
{
    "ShardId": "shardId-000000000000",
    "SequenceNumber": "49637910931783308630219956507133084672720790699213062146"
}

データビューワタブで
上記シャードIDを選んで
開始位置に水平トリム(レコードの先頭から見る)を選んでレコードを取得

パーティションキー、データ、おおよその到着タイムスタンプ、シーケンスナンバーが表示される。

CLIの場合はレコード取得の前にまずイテレーターを取得する

aws kinesis get-shard-iterator --shard-id shardId-000000000000 --shard-iterator-type TRIM_HORIZON --stream-name mystream
{
    "ShardIterator": "AAAAAAAAAAHDRFTnmIZK1OSWfUIP1gGXx3rHs/zbjw+LwUo8TLZWo7JH8l/UedHhWdHtfjxQUjZnOXH5Il3yuDW10+XoyLmuf2qH+RHNL9nIjnzhx/Pp4j6ZFMild9quHVwIRHfxrmIeJ3UIpF0W+7PQxHAAvpGjHH5p3PrSz832dp9QXQZQ3BBLhmN80IBGwcM6hg3WHS3ClT8lsCb58tc4vCgYEjg7wggP6Q40FNIiJSuROFtJHw=="

取得したイテレータを指定してレコードを取得する

aws kinesis get-records --shard-iterator "AAAAAAAAAAHDRFTnmIZK1OSWfUIP1gGXx3rHs/zbjw+LwUo8TLZWo7JH8l/UedHhWdHtfjxQUjZnOXH5Il3yuDW10+XoyLmuf2qH+RHNL9nIjnzhx/Pp4j6ZFMild9q
uHVwIRHfxrmIeJ3UIpF0W+7PQxHAAvpGjHH5p3PrSz832dp9QXQZQ3BBLhmN80IBGwcM6hg3WHS3ClT8lsCb58tc4vCgYEjg7wggP6Q40FNIiJSuROFtJHw=="
{
    "Records": [
        {
            "SequenceNumber": "49637910931783308630219956507133084672720790699213062146",
            "ApproximateArrivalTimestamp": "2023-02-11T17:14:50.970000+09:00",
            "Data": "ewoJImlkIjogIjYzZTZjZWUxMjYzY2E3OGYwZDhiZDVhZCIsCgkiY3VycmVudEpvYiI6IHsKCQkidGl0bGUiOiAiRGV2ZWxvcGVyIiwKCQkic2FsYXJ5IjogIm1hc2s7IgoJfSwKCSJqb2JzIjogWwoJCXsKCQkJInRpdGxlIjogIm1lZGljIiwKCQkJInNhbGFyeSI6ICJSJCA0LjgzOSw5MCIKCQl9LAoJCXsKCQkJInRpdGxlIjogInRlYWNoZXIiLAoJCQkic2FsYXJ5IjogIlIkIDQuODQ5LDg2IgoJCX0KCV0KfQo=",
            "PartitionKey": "1"
        }
    ],
    "NextShardIterator": "AAAAAAAAAAFwMTdN8qWVLXaz4Owaa52T9ENuBa/2RUIV0fNQ/N6vgGYEpWCwhmFBGpHbOqClOX48DVuyUdf4DsKkLTZG1LJEpXXKNbGo/Nnbrnv76cfgBkYmPJzYz2Vf/aBbeAAjaPaFTaQr6+E+9e/VBD3zMyQTjpPxGAYnZWMeRwALTrLYlaVJg+F+aMct3BiXiMYp9a3ElOFpEQ8XHl34W/ICiTt2367TQnRAJRST/IEzYLyCMQ==",
    "MillisBehindLatest": 0
}

"Data"にbase64エンコードされてデータが格納されてるので、デコードして表示する

echo "ewoJImlkIjogIjYzZTZjZWUxMjYzY2E3OGYwZDhiZDVhZCIsCgkiY3VycmVudEpvYiI6IHsKCQkidGl0bGUiOiAiRGV2ZWxvcGVyIiwKCQkic2FsYXJ5IjogIm1hc2s7IgoJfSwKCSJqb2JzIjogWwoJCXsKCQkJInR
pdGxlIjogIm1lZGljIiwKCQkJInNhbGFyeSI6ICJSJCA0LjgzOSw5MCIKCQl9LAoJCXsKCQkJInRpdGxlIjogInRlYWNoZXIiLAoJCQkic2FsYXJ5IjogIlIkIDQuODQ5LDg2IgoJCX0KCV0KfQo=", | base64 -d
{
        "id": "63e6cee1263ca78f0d8bd5ad",
        "currentJob": {
                "title": "Developer",
                "salary": "mask;"
        },
        "jobs": [
                {
                        "title": "medic",
                        "salary": "R$ 4.839,90"
                },
                {
                        "title": "teacher",
                        "salary": "R$ 4.849,86"
                }
        ]
}

プロデューサー

Kinesisエージェント/SDK/Kinesis Producer Library(KCL)

コンシューマー

Kinesis Data Analytics/Kinesis Data Firefose/Kinesis Client Library(KCL)
※S3に直接送信はできない

性能/クォータ

リファレンスよりDevelopersIOが分かりやすい

シャードあたりの書き込み制限は以下がありあます。
1000 records/second
1 MB/second
この制限に引っかかると、スロットルされ、ProvisionedThroughputExceededException エラーが発生します。

レコードについては以下の制限があります。

1 MB/record(base64エンコード前)
5 MB/transaction(PutRecords の場合)
500 records/transaction(PutRecords の場合)
レコードをシリアライズしたり、複数レコードをPutRecords API でまとめて送ることによって、より効率的に書き込めます。

読み込み制限
シャードあたりの読み込み制限は以下があります。

2 MB/second
この制限に引っかかると、スロットルされ、ProvisionedThroughputExceededException エラーが発生します。

レコードについては以下の制限があります。

1 MB/record
10000 records/transaction
10 MB/transaction

AWS資料

Kinesis Data Firehose

配信ストリームの作成

ソースと送信先を選択

ソースと送信先を選択する

ソース
Kinesis Data Stream
Direct Put (APIや、Kinesis Data Firehoseへの送信をサポートしてる機能を利用して送信する)

送信先
S3, Redshift, OpenSearch

送信先にS3を選択すると、「レコードを変換および転換 - オプション」が表示される

レコードを変換および転換 - オプション

Lambda でソースレコードを変換
レコード形式を転換

Lambda でソースレコードを変換

利点として、Kinesis Data Firehoseにデータが届いたら、リアルタイムにデータの変換、圧縮、暗号化を行える。
(別途、変換用のLambdaを呼び出すような仕組みを作らなくて良い)

以下を設定する

Lambda関数
バッファサイズ (最大3MB)
バッファ間隔 (最小60秒)

「関数を作成」から、Lambda ブループリント(=テンプレート)を利用してレコード変換のLambda関数を作れる

例えば「一般的な Kinesis Data Firehose の処理」のブループリントを選択するとワンクリックで以下Lambda関数が作成できる

console.log('Loading function');

exports.handler = async (event, context) => {
    /* Process the list of records and transform them */
    const output = event.records.map((record) => ({
        /* This transformation is the "identity" transformation, the data is left intact */
        recordId: record.recordId,
        result: 'Ok',
        data: record.data,
    }));
    console.log(`Processing completed.  Successful records ${output.length}.`);
    return { records: output };
};

レコード形式を転換

Parquet/ORCとして出力できる

Apache Parquet または Apache ORC 形式のデータは、通常、JSON よりも効率的にクエリを実行できます。
Kinesis Data Firehose は、AWS Glue で定義されているテーブルのスキーマを使用して、JSON 形式のソースレコードを転換できます。
JSON 形式ではないレコードについては、上記の「AWS Lambda でソースレコードを変換」セクションで、JSON に転換する Lambda 関数を作成します。

送信先の設定

送信先にS3を選択している場合、S3バケット/プレフィクスの他に、動的パーティショニングを有効にするか選択する

動的パーティショニングを有効にした場合の設定

パーティショニングキーに基づいてストリーミング S3 データをパーティショニングすることにより、ターゲットデータセットを作成できます。インライン解析や指定された AWS Lambda 関数を使用して、ソースデータをパーティショニングできます。

S3 バッファのヒント

Kinesis Data Firehose は、受信レコードを S3 バケットに配信する前にバッファリングします。
レコード配信は、指定されたバッファリングヒントのいずれかの値に達するとトリガーされます。

バッファサイズ、バッファ間隔(最小60秒)を指定する

S3圧縮と暗号化

Kinesis Data Firehose は、S3 バケットに配信する前にレコードを圧縮できます。圧縮されたレコードは、AWS Key Management Service (KMS) マスターキーを使用して S3 バケットで暗号化することもできます。

クォータ

base64-encoding の前に Kinesis Data Firehose に送信されるレコードの最大サイズは、1,000 KiB です。

バッファの間隔のヒントの範囲は、60～900 秒です。

JSON 形式ではないレコードについては、上記の「AWS Lambda でソースレコードを変換」セクションで、JSON に転換する Lambda 関数を作成します。

data analitics

センサーの異常検知に、Kinesis Data AnalyticsでRandom Cut Forestを利用する
https://dev.classmethod.jp/articles/kinesis-data-analytics-sql-rcf-trial/

PutRecordsはPutRecordの125倍速い

ウィンドウ

AWS資料

ストリーミングデータのように常時更新されている入力から結果セットを得るために、時間と行の条件で定義される「ウィンドウ」を使用してクエリをバインドする場合が多くあります。これをウィンドウクエリと呼びます。

Kinesis Data Analytics では以下、3 パターンのウィンドウタイプをサポートしています。

タンブリングウィンドウ
Stagger Windows（ずらしウィンドウ）
スライディングウィンドウ

タンブリングウィンドウ

スタッガーウィンドウ(ずらしウィンドウ)

一貫性のない時間に届くデータの分析に適している
例えば VPC フローログのようにキャプチャしてから届くまでに時間差のあるデータ
固定の時間間隔ではウィンドウは開かない
ウィンドウはイベントが届いた時点から経過時間を測定
ウィンドウで指定した時間ごとに結果を 1 回出力する
WINDOWED BY 句を使う

スライディングウィンドウ

ウィンドウが時間とともにスライドする
ウィンドウが重複する
ストリーム内の各レコードは複数のウィンドウの一部になる
アプリケーション内ストリームにイベントが追加される都度、結果が出力される
WIDOW 句を使う

DevelopersIOがわかりやすい(でもやっぱり難しい)

EMR

EMRコンソール/クラスタ作成画面など、新しいUI(コンソールエクスペリエンス)が提供されてますが、旧UIを載せています(試験対策記事のため)
一部新しいUIを載せてますが、新しいUIのライト/ダークモードは、マネジメントコンソールの設定に依存します(旧UIではダークモードが効かないのですが、新しいUIでは効くようになったようです。なので、新しいUIのキャプチャがダークモードになってますが、これは自分のマネジメントコンソールの設定によるものです)。

クラスタ作成画面(クイックオプション)

デフォルトはクイックオプションで、一画面の設定でクラスタを作成できる

一般設定
クラスタ名、ログ記録、起動モード

ソフトウェア設定
emrのバージョン、利用するアプリケーション、テーブルメタデータにGlue Data Catalogを使用する

ハードウェア構成
インスタンスタイプ、インスタンス数、Cluster scaling、自動終了

セキュリティとアクセス
EC2キーペア、EMRロール、EC2インスタンスプロファイル

クラスタ作成画面(詳細オプション)

次に詳細オプションに切り替えて設定項目見ていく

ステップ1: ソフトウェアおよびステップ

EMRバージョン、利用するアプリケーション
複数のマスターノード
Glue Data Catalogの設定
ソフトウェア設定
ステップの追加

ステップ2: ハードウェア

インスタンスグループ/インスタンスフリート
VPC/サブネット
ノードタイプごとのインスタンスタイプ、インスタンス数、オンデマンド/スポット
Cluster scaling
自動終了
EBSサイズ

ステップ3: クラスター全般設定

クラスター名、ログ記録、ログ暗号化、削除保護
タグ
EMRFSの整合性のあるビュー
AMI
ブートストラップアクション

ステップ4: セキュリティ

EC2キーペア
EMRロール、EC2インスタンスプロファイル、Auto Scalingロール
セキュリティ設定
セキュリティグループ

クラスター作成画面の各設定

詳細オプションの各設定項目を見ていく

ソフトウェア設定

EMRバージョン、利用するアプリケーションを選択

新しいUIの方が見やすい

複数のマスターノード

マスターノードを個別の基盤となるハードウェアに分散して関連する障害を減らすことにより、クラスターの可用性を向上させることができます。この機能を使用するには、このクラスターの起動に使用する EMR サービスロールに AWS 管理ポリシー AmazonElasticMapReducePlacementGroupPolicyをアタッチします。

AWS Glue Data Catalogの設定

AWS Glue Data Catalog を使用して、アプリケーション用の外部メタストアを提供します。

リファレンス

Hive のメタストア情報の記録先は、デフォルトでは、マスターノードのファイルシステムにある MySQL データベースです。
メタストアには、テーブルとテーブル構築の基となるデータ (パーティション名やデータタイプなど) が含まれています。
クラスターが終了すると、マスターノードも含めて、すべてのクラスターノードがシャットダウンされます。
この場合、ノードファイルシステムではエフェメラルストレージが使用されているため、ローカルデータが失われます。
メタストアを永続的に保存する場合は、クラスター外に外部メタストアを作成する必要があります。

外部メタストアとして 2 つのオプションがあります。
AWS Glue Data Catalog (Amazon EMR バージョン 5.8.0 以降のみ)。
Amazon RDS または Amazon Aurora。

ステップの追加

ステップは、EMR クラスターで実行されるアプリケーションに送信される作業のユニットです。EMR は、追加されたステップの実行に必要なアプリケーションをプログラムでインストールします

ステップタイプを以下から選択する

ストリーミングプログラム
Hiveプログラム
Pigプログラム
Sparkアプリケーション
カスタムJAR

新しいUIだと選択肢が異なっている

カスタムJAR
Sparkアプリケーション
シェルスクリプト

カスタムJAR/シェルスクリプトの場合は、格納先のS3オブジェクトのパスと、ステップが失敗したときのアクションを指定する。

Sparkアプリケーションの場合は、デプロイモードも指定する。

Cluster Composition

インスタンスグループ、インスタンスフリートから選ぶ
以下記事が分かりやすい

旧UIだとUniformインスタンスグループとなってるけど、新UIでは単にインスタンスグループとなってる
テキストでもUniformという単語はついてない

Cluster Nodes and Instances

マスター/コア/タスクそれぞれで、インスタンスタイプ/インスタンス数/購入オプション(オンデマンド/スポット)を選択する

ユースケース

コアノードにプロビジョニングのタイムアウトを備えたインスタンスフリートを利用し、タスクノードにスポットインスタンスを利用する

クラスタを作成するとき、インスタンスフリートを選択する

インスタンスフリートを選択するとプロビジョニングのタイムアウトを指定するオプションが表示される
プロビジョニングのタイムアウト(分指定)、タイムアウト時の動作(クラスターを終了/オンデマンドインスタンスに切り替え)を指定する
タスクノードのスポットユニット数を指定する

なおインスタンスグループを選択したときは以下のようにプロビジョニングのタイムアウトの項目はない。

Cluster scaling

「Enable Cluster Scaling」を選択し、「Use EMR-managed scaling」を選択する

自動終了

クラスターがアイドル状態になった後にクラスターを終了する時間を選択します。

起動モード

ユースケースとして、1日1回数時間動かすような場合に料金を節約する。
テキストでは「クラスタタイプで過渡的(一時的)を指定」などの表記

クイックオプションの場合、起動モードでステップ実行を指定する

ステップ実行では、EMR はクラスターを作成し、追加されたステップを実行し、完了時に終了します。

詳細オプションの場合、ステップの追加で、「After last step completes:」に「最後のステップが完了したらクラスターを自動的に終了します。」を選択する

クラスタ作成時のログの暗号化

全般オプションで「ログを暗号化」を有効化してKMSキーを入力する

ログ記録

クラスタを作成するとき、クイックオプションでは、ログ記録にチェックが入っている

詳細オプションでも、ログ記録にチェックがついてる。ログを暗号化、のチェックはついてない(チェックをつけると、KMSキーのARNの入力欄が表示される)。

CLIで作成してみる(必須の引数のみ指定して作成)

aws emr create-cluster --release-label emr-5.36.0 --instance-type m5.xlarge --use-default-roles
{
    "ClusterId": "j-2GWCEO1D1M4YU",
    "ClusterArn": "arn:aws:elasticmapreduce:ap-northeast-1:123456789012:cluster/j-2GWCEO1D1M4YU"

作成したクラスタの詳細 -> 構成の詳細 -> ログのURLが「-」となっている

コンソールから作成したときは、以下のようにログのURLにS3のURIが表示されるので、CLIで作成するとたしかに無効になっている

上記の通りCLIでクラスタ作成するとログ記録はデフォルト無効となっている。
(ログ記録を有効化する場合は「--log-uri」を指定すれば良いと思われる)

           create-cluster
          --release-label <value>   | --ami-version <value>
          --instance-fleets <value> | --instance-groups <value> | --instance-type <value> --instance-count <value>
          [--os-release-label <value>]
          [--auto-terminate | --no-auto-terminate]
          [--use-default-roles]
          [--service-role <value>]
          [--configurations <value>]
          [--name <value>]
          [--log-uri <value>] ★<-- これ
          [--log-encryption-kms-key-id <value>]

EMR 5.30.0以降のバージョンでは、S3のログをKMSキーで暗号化できる

クラスタを作成するとき、EMR 5.29を選択すると

ログ記録のとなりに暗号化の設定がない

クラスタを作成するとき、EMR 5.30.0を選択すると (なお検証時5系の最新は5.36.0。6系もあり、6系の最新は6.9.0)

ログの暗号化、の設定が表示される

カスタムAMIを指定する

クラスタを作成するときに、オペレーティングシステムのオプションで指定できる

なおクラスタからAMIを作成することはできないので、必要なソフトウェアをインストールしたAMIを利用したい場合は、EC2でそれを実施してAMIを作成し、EMRでカスタムAMIとして指定する

セキュリティグループ

マスターと、コアおよびタスク、の分類で、セキュリティグループを設定できる

EMRFS の整合性のあるビュー

S3 のファイルにおけるリストと書き込み後の読み取り（新しい PUT が対象）の整合性を監視します。

各設定の説明は以下。

メタデータストア

DynamoDB で使用または作成するメタデータストアを指定します。

再試行回数

S3 の不整合が検出された後、EMRFS が S3 を呼び出す再試行回数。

再試行間隔

最初の再試行を行うまでの時間。それ以降の再試行では、エクスポネンシャルパックオフが使用されます。

ブートストラップアクション

起動時にカスタムブートストラップアクションで、S3上のbashスクリプトを実行する

設定と追加をクリック

スクリプトの場所と引数(オプション)を指定する

ローカルディスク暗号化

プロバイダータイプ (KMS, カスタムキープロバイダー(S3上のJARをARNで指定する))と、
EBS暗号化/LUKS暗号化を選択する

Amazon EC2 インスタンスストアボリュームと、接続された Amazon Elastic Block Store (EBS) ストレージボリュームを Linux Unified Key Setup (LUKS) で暗号化します。または、AWS KMS をキープロバイダーとして使用する場合は、EBS 暗号化をオンにして EBS ルートデバイスとストレージボリュームを暗号化することを選択できます。 AWS KMS カスタマーマスターキー (CMK) には、EBS 暗号化用の追加のアクセス許可が必要です。

送信中のデータ暗号化
証明書を保存したS3のパスを指定する

EMRFSのIAMロール
IAMロールを指定する

承認

AWS Lake Formation/Apache Ranger
どちらと統合するか選択、ロールなどを入力する

Lake Formation

Apache Ranger

Apache Rangerとは: 公式のFAQより

Apache Rangerは、Hadoopおよび関連コンポーネント(Apache Hive、HBaseなど)に対するきめ細かなアクセス制御を管理するための集中型セキュリティフレームワークを提供します。Apache Ranger管理コンソールを使用すると、ユーザーは特定のユーザーやグループのリソース(ファイル、フォルダー、データベース、テーブル、列など)へのアクセスに関するポリシーを簡単に管理し、Hadoop内でポリシーを適用できます。

こちらがコンソール画面などがのっていて分かりやすい

セキュリティ設定

クラスタ作成より前に作成しておき、クラスタ作成のセキュリティ設定で作成したものを選択する
セキュリティ設定は主に暗号化とアクセス権限に関するもの。ネットワークアクセス制限ではない(ネットワークアクセス制限は、ブロックパブリックアクセスの設定画面で行う、ブロックパブリックアクセスとポートの許可設定)

暗号化
認証
EMRFS の IAM ロール
承認
EC2 インスタンスメタデータサービス

セキュリティ設定の各設定

S3暗号化

EMRFSデータ保存時の暗号化
perバケットの暗号化オーバーライド

どちらも以下暗号化モードを選択できる

SSE-S3
SSE-KMS
CSE-KMS
CSE-Custom

perバケットの暗号化オーバーライド

特定のバケットに対してオプションの暗号化オーバーライドを選択します。各バケットに異なる暗号化モードと暗号化マテリアルを指定できます

「S3でEMRFSデータ保存時の暗号化」を有効にし、さらにperバケット(バケットごと)の暗号化オーバーライドを設定する

他

isIdleメトリクス

クラスタ詳細のモニタリングタブ

CloudWatchで表示もできる

Zeppelin

Zeppelinとは: jupiterが分かればそれと同じと考えると分かりやすい。pythonでデータ分析できるノートブック。Webアプリ上でインタラクティブ(対話形式)にpythonで分析や可視化(グラフ作成)を実行できる。

画面や使った感じがのっていてこちらが分かりやすい

パブリックアクセスのブロック

リファレンス

Amazon EMR でブロックパブリックアクセス設定が導入され、EMR クラスターが誤ってネットワークに公開されることを防止できるようになりました。

その他

クラスタ作成後、クラスタを選択したときのアクション

詳細を表示
クローン
削除

ここにはログのON/OFFや暗号化に関する設定変更ボタンはない

詳細を表示すると、
まとめ、アプリケーションの履歴、モニタリングなどの設定をタブごとに表示できる
しかしここにもログのON/OFFや暗号化に関する設定変更ボタンはない

各タブを見ても設定変更ボタンはでてこない
唯一ハードウェアタブでCluster Scaling Policyと自動終了は変更できる

なので、たとえばEMRでログを有効化したり暗号化する、ルートボリュームなどを暗号化したい場合は、クラスタ作成後にはできないので、クラスタ作成時に行うか、すでに運用中であれば、クラスタを削除して再作成する必要がある。

hiveとprestoの違い

hiveはHiveQL
prestoは標準SQL互換、様々なデータソースからクエリを実行できる

pig

Javaとかに組み込んで使えるライブラリ。
pigコマンドや、Pig LatinというSQLに似た構文でHadoop上でデータを操作する。

Hadoop 上で稼動し、大規模なデータセットを複雑なコードを記述することなく Java などの低レベルコンピュータ言語で変換するのに使用できるスクリプト言語を提供します。このライブラリは、Pig Latin という言語で記述された SQL に似たコマンドを受け取り、

Pig は多様な形式の構造化データと非構造化データで機能します。

Pig コマンドは、インタラクティブに実行するか、バッチモードで実行できます。Pig をインタラクティブに使用するには、マスターノードへの SSH 接続を作成し、Grunt シェルを使用してコマンドを送信します。Pig をバッチモードで使用するには、Pig スクリプトを記述し、Amazon S3 にアップロードして、クラスターステップとして送信します。

Pig を使用して Amazon S3 の HCatalog テーブルに出力を書き込む場合は、mapred.output.direct.NativeS3FileSystem プロパティと mapred.output.direct.EmrFileSystem プロパティを false に設定して、Amazon EMR の直接書き込み機能を無効にしてください。

ganglia

いわゆる監視ツール。

リファレンス

ブラウザで Ganglia ウェブ UI を表示すると、クラスターの概要が表示されます。パフォーマンス、負荷、メモリ使用量、CPU使用率、およびネットワークの詳細を示すグラフクラスターのトラフィック。クラスター統計の下には、個々のサーバーのグラフがありますクラスター内。

HBaseとリードレプリカ

HBaseでリードレプリカが使える

(条件)
EMRバージョン5.7.0以上
ストレージにS3を利用

HBaseはThinkITが分かりやかったです

HBaseはこのHDFS上に構築するデータベースです。HBaseとHadoop（HDFS）の関係を図4に示します。なお、HBaseの構築にYARNとMapReduceは必須ではありませんが、MapReduceを使用するとHBaseのデータ格納/参照を高速に行えるため、YARNとMapReduceも同時にインストールすることを推奨します。

Glue

色々あるが、マネジメントコンソール上の分類のくくりはこう
データカタログの中に、データベース、テーブル、スキーマ、クローラ、カタログ設定(英語表示状態だと設定)がある。
ETL(英語表示状態だとData Intergration and ETL)の中に、Glue Studio、ジョブ、ノートブック、トリガー、ワークフロー (ワークフローの中にBlueprints) 、セキュリティ設定がある
(機能によって日本語で表示されるページと英語で表示されるページがあり、どちらかに遷移するとメニューの言語も切り替わるが、言語ごとに表記揺れがある)

データカタログ

クローラ

データソースに、S3/JDBC/DynamoDB/DocumentDB/MongoDB/DeltaLakeを選択できる

S3選択時。別のアカウントのS3を指定できる

カタログ設定

メタデータ暗号化、接続パスワード暗号化ができる
(AWSマネージドKMSキーしか使えなそう?)

データ統合とETL

ワークフロー

実行プロパティ、最大同時実行数を指定できる

このワークフローで許可される同時実行の最大数を設定します。このしきい値に達すると、エラーが返されます。デフォルトは無制限です。

ETL ジョブ、トリガー、およびクローラのオーケストレーションを実行するには、ワークフローを追加してください

ワークフロー作成後、トリガーを作成する
トリガーの起動タイミングとして、スケジュール/イベント/オンデマンド/EventBridge eventを選択できる

Blueprints

ワークフローのBlueprints

設計図は、組織の一般的な ETL ユースケースの AWS Glue ワークフローを生成するために使用します。

設計図はS3で作成する

Amazon S3 は、設計図と同じリージョンに存在する必要があります。

セキュリティ設定

「データ統合とETL」の中のセキュリティ設定だが、説明書きは「データカタログの暗号化と権限オプションを選びます」って書いてある..

S3暗号化(SSE-S3/SSE-KMS選べる)、CloudWatch logs暗号化、ジョブのブックマーク暗号化ができる

MSK

クイック作成

クラスタ名
クラスタータイプ
クラスターのスループット
クラスターストレージ

カスタム作成

ステップ1 クラスターの作成

ステップ2 ネットワーク

VPC
サブネット
セキュリティグループ

ステップ3 セキュリティ

アクセスコントロール方法
IAM ロールベースの認証

ステップ4 メトリクスとタグ

メトリクス
クラスタータグ

ステップ5 確認と作成

ベストプラクティス超要約

クラスターを適切なサイズにする:ブローカーのパーティション数

ブローカー = kafka上のインスタンスタイプ

kafka.t3.small = ブローカーあたりの最大パーティション数300
kafka.m5.large ~ xlarge = 1000
kafka.m5.2xlarge = 2000
kafka.m5.4xlarge以上 = 4000

t3.smallは300で、
m5はxlargeが1000でサイズが上がると倍、4xlarge以上は4000
largeはxlargeと同じ
と覚えると意外と簡単かも

ブローカごとのパーティション数が前の表で指定された最大値を超えると、クラスタ上で次の操作を実行することはできません。

クラスター設定を更新する
クラスターの Apache Kafka バージョンを更新します。
クラスターをより小さなブローカータイプに更新
AWS Secrets ManagerSASL/SCRAM認証を使用するクラスターにシークレットを関連付ける

パーティション数大事

クラスターを適切なサイズにする:クラスターあたりのブローカーの数

MSK クラスターに適切なブローカーの数を決定

高可用性クラスターの構築

3 つの AZ クラスターをセットアップします。

複製係数 (RF) が 3 以上であることを確認します。

最小同期レプリカ (minISR) を最大で RF - 1 に設定します。

クライアント接続文字列には、各アベイラビリティーゾーンのブローカーが少なくとも 1 つ含まれていることを確認します。

CPU 使用率をモニタリングする

60%以下に維持することを強く推奨しています。

オプション 1 (推奨): ブローカータイプを次に大きいタイプに更新します。例えば、現在のタイプが kafka.m5.large の場合、kafka.m5.xlarge

オプション 2: ラウンドロビン書き込みを使用するプロデューサーから取り込まれたすべてのメッセージを含むトピックがある場合 (つまり、メッセージはキー設定されておらず、順序付けはコンシューマーにとって重要ではありません)、ブローカーを追加してクラスターを拡張します。

オプション 3: ブローカーを追加してクラスターを拡張し、kafka-reassign-partitions.sh という名前のパーティション再割り当てツールを使用して既存のパーティションを再割り当てします。

ディスク容量のモニタリング

KafkaDataLogsDiskUsed

データ保持パラメータの調整

メッセージを消費しても、ログからは削除されません。定期的にディスク容量を解放するには、保持期間（メッセージをログに保持する期間）を明示的に指定できます。保存ログのサイズを指定することもできます。

アパッチカフカメモリーの監視

HeapMemoryAfterGC

MSK 以外のブローカーを追加しない

タイトルのとおり

転送中の暗号化を有効にする

タイトルのとおり

パーティションの再割り当て

kafka-reassign-partitions.sh

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

DASが終了するのでお蔵入りしてた記事を公開する

redshift

ノードの種類

エラスティックリサイズ

マルチAZ

制限設定

クロスリージョンスナップショット

パフォーマンスモニタリング系

テーブルの復元

監査ログの暗号化方式

監査ログの内容

暗号化

パラメータ

ワークロード管理

diststyle(分散スタイル)

ベストプラクティス 超要約

Amazon Redshift の概念実証の実施

Amazon Redshift テーブル設計のベストプラクティス

最良のソートキーの選択

最適な分散スタイルの選択

COPY による圧縮エンコードの選択

プライマリキーおよび外部キーの制約の定義

最小列サイズの使用

日付列での日時データ型の使用

データをロードするための Amazon Redshift のベストプラクティス

COPY コマンドを使用したデータのロード

単一の COPY コマンドを使用した複数のファイルからのロード

ロードデータの分割

データファイルを圧縮する

ロードの前後におけるデータファイルの検証

複数行の挿入の使用

一括挿入の使用

ソートキー順序でのデータのロード

順次ブロックでのデータのロード

時系列テーブルの使用

ステージングテーブルを使用したマージ（アップサート）の実行

保守管理の時間枠を回避したスケジュール計画

Amazon Redshift クエリの設計のベストプラクティス

Amazon Redshift Advisor からのレコメンデーションの使用

その他リファレンス

ショートクエリアクセラレーションを使用する

quick sight

利用開始

サインアップ

エディション選択

アカウントの作成

データセットの作成

データセットを選択

視覚化を実行

ビジュアルタイプを選択

送信先

データセット

QuickSightの管理

ユーザーを管理

アクセス許可の管理

セキュリティとアクセス権限

QuickSight の AWS のサービスへのアクセス

デフォルトのリソースアクセス

IAM ポリシーの割り当て

IP 制限

ダッシュボードへのパブリックアクセス

VPC 接続の管理

KMSキー

マニフェストを利用してS3上のオブジェクトからデータセットを作成する、特定のS3バケットにアクセスするための権限を設定する

定期更新する

IP制限

セキュリティグループ

暗号化

Redshift Spectrum連携

行レベルのセキュリティ(RLS)

棒グラフ

折れ線グラフ

円グラフ

ファネルチャート (ファンネルチャート, ファネルグラフ)

ヒートマップ

KPI (主要業績評価メトリクス)

ピボットテーブル

レーダーチャート

ツリーマップ

Kinesis関連

ベストプラクティス超要約