Reverse ETLでSnowflakeにある集計済みデータを使おう！！
データインフラチームの渡部です。
note社内では分析用のデータをETLしてSnowflakeに寄せていっています。
今回はnote社内でReverse ETLの仕組みを実装・導入したので、そちらについて書かせていただきたいと思います。
そもそもETLとは？
Reverse ETLの前にETLについて知っていると分かりやすいので、そもそもETLとはなんなのかということについて最初に書いていきます。
ETLはデータ系の用語でデータの抽出・加工・格納の一連の流れのことを表します。
Extract = 抽出
Transform = 加工
Load = 格納
データインフラではこの図のようなアーキテクチャを使って各所でETL処理を行い、ログ系のデータなどをSnowflakeにまとめていきます。
データの流れとしては、左から右にいくようになっています。
ETLの例として、このアーキテクチャ図の中でETLが目立つ箇所として2箇所ほど紹介します。
1箇所目がRDBやFirebaseからデータをETL(抽出・加工・格納)している箇所です。
Digdag + Embulkを使って、各データソースからS3にデータをETLしていっています。
※ Digdag = cronのようにスケジュールに従ってタスクを実行するもの
2箇所目がSnowflakeに集約したデータを改めてETL(抽出・加工・格納)しているところです。
このETLではSnowflake内のデータをより分析しやすい形に加工して、別なDBスキーマのテーブルにデータを格納していっています。
ここでは、DigdagからSnowflake内に書いた自前のコード(Snowpark)を定期的に起動することでETLしています。
ETLをする理由
ETLを行う理由としては、以下の3つが挙げられると思います。
あらかじめデータを加工しておくことで、データを理解しやすく、分析に適した形で置いておける
大きいテーブルに対して重いクエリを実行する必要がなくなる
各データベースに散らばっているデータを連携しやすくする(データのサイロ化を防ぐ)
Reverse ETL
ここからは本題であるReverse ETLについてです。
ETLの説明ができたので、Reverse ETLの説明はそれほど長くならないで済みます。なぜなら、Reverse ETLとはその字面の通り、ETLを逆方向に行うことを指すからです。
今回導入したReverse ETLについて見ていくと、分析用データはデータウェアハウスの Snowflake に ETL されていっているので、逆にReverse ETLはデータウェアハウスSnowflakeからアプリケーション側にデータをETL(抽出・加工・格納)することを言います。
noteでのReverse ETLを簡単に説明すると、「SnowflakeからRDBへのテーブルのコピーが行えるようになった」と言えるでしょう。
Reverse ETLをする理由
なぜ一度ETLを行ってデータウェアハウスのSnowflakeに寄せたデータを、わざわざ逆方向にETLをするのか？
以下のような動機・理由がありました。
Snowflakeに入っているデータを活用した機能を作れるようにするため
Snowflakeにデータの集計処理を寄せるため
Snowflakeでデータの集計処理を行い、それをRDBにコピーすれば集計済みデータが手に入る
つまり、Snowflake以外の場所で集計処理を書かなくて良い！
noteではWEBアプリケーション側はRuby on Railsで実装されていますが、Rails側からはSnowflakeのデータを直接SQLで見たりすることはできないようになっています。
Reverse ETLを定期的に行えば、間接的にSnowflakeのデータを見ることができるようになり、分析データのことを気にせずアプリに必要なデータの処理に集中できます。
Reverse ETLの事例紹介
最後にReverse ETLの活用事例があるのでそれらを紹介して終わりにしようかと思います。
事例1. アクティブなユーザーを対象にメール施策
一つ目が”アクティブ”なユーザーを対象にメールを打つ施策を行うためにReverse ETLが活用されています。
アクティブなユーザーの定義は、最後に行動した時間を元に決めているようです。
Reverse ETLで、Snowflakeにあるユーザーの最後に行動した時間が記録されたテーブルを定期的にRDBにETLしています。
これらのテーブルをRails側から利用することで、アクティブなユーザーに向けてメールを送付することができるようになりました。
事例2. メンバーシップのオーナー向けのメールに数字を載せる
二つ目は、メンバーシップのオーナー向けのメールに数字を載せるためにReverse ETLを活用した事例です。
このメールはオーナーの方向けに月初に数値載せており、自分のやってることを俯瞰して見るためという目的のために送信されています。
これらの数値はSnowflakeで集計を行い、データを保存するためのテーブルを作成しました。
Reverse ETLでそのテーブルを含めていくつかのテーブルを定期的にRDBにETLしています。
事例3. アナリティックスβに、「読者へのお知らせ」の imp 数と click 数を表示
最後は、アナリテックスβに「読者へのお知らせ」のインプレッション数とクリック数を載せるためにReverse ETLした事例です。
※ アナリティクスβ＝note proで利用できるアナリティクス機能
imp数とclick数をデイリーでSnowflakeで集計を行い、テーブルに集約するようにしました。
Reverse ETLで作成したテーブルを定期的にRDBにETLしています。
Snowflakeにあるデータの活用
Snowflakeには日々分析のデータが集計され貯まっていっています。
Reverse ETLで、既に作成済みのテーブルをコピーしたり、もしくは新たにRails側で活用しやすい形で集計して作成したテーブルをコピーしたりできるようになりました。
現在noteでは、集計されたテーブルがすでに60〜70ほどSnowflakeで作られており、新たに集計を依頼するのもSlackの申請フォームから簡単にできるようになっています。
Snowflakeにあるデータを活用すれば、Rails側では以下のように様々なアイデアが実現できるようになると思います。
ユーザビリティの改善
パーソナライゼーション
ターゲティング広告
マーケティングの半自動化
顧客サポートの改善
ダッシュボードの作成
今回のReverse ETLの実装によって、Snowflakeにあるデータの利活用が進み、noteがもっと面白いサービスになっていけば良いと思いました。
▼noteの技術記事がもっと読みたい方はこちら
▼noteで働くことに興味ある方はこちら