-
Notifications
You must be signed in to change notification settings - Fork 1
Architecture
Prism Streamは前処理済みのオブジェクトをParquet形式の "Small Object" に変換する。 そしてパーティションの最初のSmall Objectが作成された時点で、 そのパーティションのマージジョブがスケジューリングされる。
そのスケジュールに従ってPrism Mergeが起動し、 対象となるパーティションのSmall ObjectをまとめたParquetファイルを作成する。 こちらを "Merged Object" と呼ぶ。
アプリのログなどは実際のイベント発生時刻からかなり遅れて到着する場合があるので これに加えて遅延ログの処理が発生するが、それはややこしくなるので後述する。
Small Object とは、Prism Stream が書き出す細切れのデータオブジェクトのことである。 Small Object は Live Object と Delayed Object の2種類に分かれている。
Live Object は後述の「締め」に間に合ったもの、Delayed Object は間に合わなかったものである。
Live Object は <テーブル名>/live/dt=<日付>/
以下に、Delayed Object は <テーブル名>/delayed/dt=<日付>/
以下に、それぞれ保存されている。
Redshift は Live Object または、後述の Merged Object を参照している。 新しいパーティションは必ず Live Object を参照するようになっている。 Prism Stream は Live Object を順次書き出すため、新しいパーティションにおいては書き出したものから順次読めるようになる、という仕組みである。 ただし、後述の「締め」や「切替」処理を経て、Merged Object を参照するようになる。
Prismはクエリの実行速度を最適化するため「マージ」という処理を行う。 これは多数のSmall Objectを同じ内容を保ったまま(ソートはするが)、より少数のデータオブジェクトに書き直すという処理である。
この「マージ」処理は Prism Merge が担当している。
「マージ」処理で書き出されたデータオブジェクトを Merge Object と呼ぶ。
Merge Object は <テーブル名>/merged/dt=<日付>/
以下に保存されている。
日付が変わると、前日分のパーティションは「締め」られる。 「締め」られたパーティションへ Live Object の新規書き込みは禁止され、「締め」以降に到着したデータはすべて Delayed Object となる。 この「締め」処理は Prism Batch の CatalogCmd が担当している。
Redshift からリアルタイムに読めるデータはこの「締め」に間に合った分のデータ(=Live Object)だけである。 たとえば、10/5 に到着した 10/4 分のデータはすぐには読めない。
Delayed Object の内容が読めるようになるには、「マージ」と「切替」という2つの操作が完了するまで待たなければならない。
パーティション内のすべての Live Object がマージされ、Merged Object となると、当該パーティションに対して「切替」という処理が行われる。
「切替」が行われると、Redshift は <テーブル名>/merged/dt=<日付>/
以下のデータ(= Merged Object)を参照するようになる。
この「切替」処理は Prism Batch の CatalogCmd が担当している。
この「切替」が行われたあとは、当該パーティションへのクエリの高速化が期待できる。
また、「切替」後は「締め」に間に合わなかったデータ(= Delayed Object)が徐々に読めるようになる。 どこまでの Delayed Object が読めるかは「マージ」の進捗と CatalogCmd の実行タイミングに依存する。 CatalogCmd 実行時点までに「マージ」が完了している分については、CatalogCmd の実行により読めるようになる。