本日学習したことをメモします。
Kinesis Data Streamsの制限事項
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の複合プライマリキー
DynamoDBの複合プライマリキーを使うことで、複雑なデータを取得する際にDynamoDBにクエリを投げやすくなりパフォーマンスが上がりやすい。