| 粒度 | 手段 | 特徴 or ユースケース | |
|---|---|---|---|
| サービス | athena | 非構造化データ、半構造化データ、構造化データすべてが対象 データレイクから直でアドホックなSQLを実行したい場合 BIチームなどにも情報へ素早くアクセスしてほしい場合 例：アドホックな分析 |
|
| redshift | 構造化データに対するアナリティクスが対象 スケールとパフォーマンスを追求する場合、より本格的なワークロードを実行したい場合。 |
||
| テーブル作成 | parquetによるパフォーマンス最適化 | パーティション | モダンなクエリエンジンのストレージに対するプッシュダウンを活用してディスクの異なる領域にランダムにスキップすることなくデータをシークできるようにする |
| 辞書エンコーディング | 小数のカテゴライズされた列に対して各カテゴリを表す小数のビットでカテゴリを識別したいケース | ||
| 型圧縮 | (String,String)(Integer,Integer)のように効率的に保存 | ||
| ベクトル化集計 | 列指向フォーマットなのででぅすくコントローラがデータを1回だけ集計する。 | ||
| ENCODE属性の付与による列の圧縮を通じたパフォーマンス最適化 | zstd | 汎用圧縮アルゴ https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/zstd-encoding.html |
|
| az64 | Oct 8, 2019リリース。Amazon Redshift に保存されている数値および日付/時刻データの最適な解凍パフォーマンスが得られます。 | ||
| bytedict | 有限カテゴリに有効。https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_Byte_dictionary_encoding.html | ||
| SORTKEYによるパフォーマンス最適化 | よく参照するデータに応じてSORTKEYを設定 | ||
| DISTを使用したテーブル分散スタイル |
データの移動を最小限に抑える目的 https://docs.aws.amazon.com/ja_jp/redshift/latest/dg/c_choosing_dist_sort.html参照 |
||
| ALL 分散 | |||
| EVEN 分散 | |||
| KEY 分散 | |||
| レコード挿入時 | ETLタスクのテクニック | selectの結果をテーブルに取り込む | 例えばcast(year(date(hoge_date)) as INTEGER) as yearとして念を抽出した列を作成するなどすると手間は減る |
| コマンド | COPY | まだテーブルが存在しない時点で新たにS3等のデータソースからテーブルを作成する場合 | |
| INSERT INTO | データがすでにテーブルとして存在し、データのサブセットをロードする場合 |
備考:
- 46993975×16列の行挿入で約5分ほどかかったので、1億レコードを超える場合はParquetを使うべきか
- UNLOADは3929550×16列をParquet形式で保存するので8m 37.9sかかった