データプラットフォームグループの松原です。 弊社各サービスのデータ分析基盤であるLivesense Analytics（以降LA）の開発、運用を行っています。
今回はLAで行っているELT/ETL処理について紹介したいと思います。
LAでのELT/ETL処理概要
そもそもELT/ETLとは
ETLとはデータを整形してからDWH/データマートへ取り込む処理のことで、Extract(抽出) -> Transform(変換) -> Load(読み込み) の順で処理を行うためETLと呼ばれています。
ELTとはデータをDWH/データマートへ取り込んだのちに変換を行う処理のことで、Extract(抽出) -> Load(読み込み) -> Transform(変換) の順で処理を行うためELTと呼ばれています。
LAでのELT/ETL処理概要
LAではEMRを利用するまでは、ELTを中心に行っていましたが、EMRを利用してからはELT/ETLを両方行うようになりました。
LAでは大まかには以下のような構成でELT/ETL処理を行っています。
LAでは主に3つELT/ETL処理があり概要は以下のようになっています。
- Redshiftで実行するSQLバッチによるELT
LAの運用初期からあり、利用者向けのテーブルの作成などを行っています。 - EMR Sparkを利用したETL
SQLでは実現しづらい複雑な処理（セッションの集計処理など）を実施しています。 - GlueによるELT/ETL
コールドデータ（利用頻度の低いデータ）等をRedshift Spectrumで利用しやすいようにデータフォマットの変換などを実施しています。
LAでのELT/ETL処理
ワークフローエンジン
LAではETLのためのワークフローエンジンとしてAirflowを利用しスケジュール実行しています。
ちょうど導入を検討したタイミングで用途に合っていたから導入したという消極的な採用理由ですが、1.8にアップグレードしてからは1.7で不満があった以下の2点の不満も解消され運用しやすくなりました。
- DAG単位でCatchup設定が可能になり、Taskが詰まった際に過去のTaskを実行する必要がなくなった。
- Celery Backendを利用した際に、頻繁に実行されるヘルスチェック系のタスクを登録した際のCPU負荷が下がった。
Redshiftで実行するSQLバッチによるELT
LA運用初期からあるELT処理で、Redshiftに格納済みのデータから利用者向けのテーブルの生成や、分析者向けのテーブルの生成を主に行っています。
ここで生成している主要なデータは以下のようなものになります。
- RAWデータを加工し利用しやすくしたサマリーテーブル。
- 特定期間のみのデータを保持し、インターリーブソートキーを付けた利用者向けテーブル。
- 分析者向けのテーブル。
構成としては以下のようになります。
EMR Sparkを利用したETL
主に以下の2点の理由で昨年ぐらいから、主要なサービスについてはSQLバッチから置き換えを行っています。
- ストリーム＋SQLでデータを処理しづらいケースに対応する。
- 過去データのデータ定義の変更をRAWデータから再生成しやすくする。
将来的には 、サマリーテーブルのデータ定義の修正などで全データを再生成する際にRedshift上で再生成する運用コストが高い*1のでその辺りもEMRで処理をしたいと考えています。 ただし、SQLバッチによるELT処理も引き続き利用していくつもりです。
構成としては以下のようになります。
現状はストリームで処理は行っておらず定期バッチ処理が中心なためEMRは常時起動するのではなく、必要な時にAiflow経由で起動・停止させるという運用をしています。
Glueバッチ
昨年リリースされたGlueについても、Redshift Spectrumを利用してRedshiftのディスクを節約するために利用しています。
利用用途として以下の2つで、EMRを立てるほどでもないけどというような処理で利用しています。
- 終了してしまったサービスのデータをRedshiftからS3に移しParquetに変換を行う。
- コールドデータや、Redshiftに投入するにはデータ量が多すぎるものについては最初からRedshift Spectrumで利用できるようにParquetに変換を行いS3に保管する。
EMRの処理を置き換えることは現時点では想定しておらず、上記のようなデータフォーマットの変換という限定的な使い方をしています。
上記の構成は利用用途の2番目の用途で利用しており、GlueのTrigger機能は利用せずにAirflowでGlue Jobの実行、異常検知を行っています。
1番目の用途については割と雑にGlue Scriptを書いて手動で実行しています。
まとめ
今回はLivesense AnalyticでのETL / ELT処理について紹介しました。
リブセンスのデータ分析基盤の全貌の資料公開から比べると比較的変更があり、紹介しきれていなかった部分も紹介できたかと思います。
今回紹介したELT / ELT処理や、前回紹介したエンコードタイプの変更の他にも色々な施策に取り組んでおります。それらについても別の機会にご紹介できればと思います
*1:ディスクの空き状況によっては別Redshiftクラスタを立ち上げ処理する必要がでたりするので、費用面よりも運用の手間という意味合いが強いです。
