【AWS学習】Kinesis Data Streamsの制限事項など

本日学習したことをメモします。

Kinesis Data Streamsの制限事項

docs.aws.amazon.com

Kinesis Data Streamsのシャードは一秒ごとに1000レコードか1MBの上限がある。

データ分析のバッチ処理に適したアーキテクチャ

IoTデバイスから取得したデータをバッチ処理で分析する場合は以下の形式が適している。

Iotデバイスからのデータ->Kinesis Data Firehose->S3-.Glue->S3のデータレイク->Athena->QuickSIght

リアルタイムでデータ分析を行う際のコストを抑えたアーキテクチャ

Iotデバイスからのデータをリアルタイムでデータ分析を行う際は以下のようなアーキテクチャが適している。
Iotデバイスからのデータ->AWS IoT->Kinesis Data Firehose->Lambda->Redshift->分析用のアプリ

Lambdaでデータの加工などを行う。

データ分析用のS3データレイクに書き込みを行う場合

データ分析用のS3データレイクに書き込みを行う場合は、Kinesis Data FirehoseからLambdaでデータを加工した後に再度Kinesis Data Firehoseにデータを送ってS3にデータを送る。
基本的にLambdaからS3には書き込まない。

AWS SCTを使う場合

DBの移行を行いつつ、DBスキーマの変換も行う場合は、AWS SCTを使ってスキーマの変換を行い、マイグレーションにはDMSを使う。

Glueトリガーについて

GlueトリガーでETLジョブを呼び出す際は、GlueクローラーがSUCCEEDED状態になることをトリガーにする。

at-least-onceデリバリーかつ処理の順番を保証する形式のサービス

at-least-onceデリバリーかつ処理の順番を保証する形式のサービスには、Kinesis Data StreamsとAWS MSKがある。

Kinesis Data FirehoseとSQS標準キューjはat-least-onceデリバリーだが、順番は保証されない。

SQS FIFOキューは確実に一回送る方式。

リアルタイム分析を行うアーキテクチャ

Kinesis Data Firehoseでデータを取得する->Kinesis Data Firehoseデータ変換機能でLambda関数を呼び出してKPLやGZIPデータをCSVやTSV、SALM形式に変換する

耐久性とパフォーマンスを重視した分析アーキテクチャ

耐久性とパフォーマンスを重視する場合は以下のようなアーキテクチャが考えられる。
IoTデバイスからのデータをKinesis Data StreamからKinesis Data Firehoseに送る->Kinesis Data FirehoseがパーティションされたORCファイルへデータを送り、データレイクにデータを書き込む。

Kinesis Data Firehoseは複数のAZに対応しているため耐久性が高い。
また、Kinesis Data FirehoseはデータをパーティションされたORCファイルに送ることが容易。
ORCファイルはSQLクエリ用に最適化され、データレイクからデータを取得する際のパフォーマンスが高くなる。

Dynamo DBの複合プライマリキー

docs.aws.amazon.com

DynamoDBの複合プライマリキーを使うことで、複雑なデータを取得する際にDynamoDBにクエリを投げやすくなりパフォーマンスが上がりやすい。