過去2回、自社データ分析基盤の構築に関わってきましたが、3回目にしてかなりシンプルで高性能なデータ分析基盤を作ることができたので、記事として公開します。
1社目のデータ分析基盤 2013年頃
こちらは私が考えたものではなく、メンバーとしてプロジェクトに参加させて頂いたものです。
- ソース：Oracle（売上データ）
- DWH：SQLserver（オンプレミス）
- ETL：自作のVBSをDWHサーバ上でスケジュール実行
- BI：QlikView
課題など
QlikViewがインメモリ型であった為、列指向DBは使用せず、使い慣れたSQLserverで構築。取り込むデータが増えるほどにQlikViewのパフォーマンス劣化が顕著に。QlikViewサーバのスケールアップで凌ぐのも限界を感じていたところで退職。
2社目のデータ分析基盤（2019年頃）
メンバーは私ひとりだったので、構築も運用もすべて自分で実施。基盤自体は2016年からビルド&スクラップを繰り返しており、最終的な構成がこちら。
- ソース：Oracle（売上データ）、SQLserver（社内マスタデータ）
- DWH：Snowflake
- 歴史：SQLserver → Snowflakeへ変更
- ETL：Talendで作成したバッチをタスク管理サーバでスケジュール実行
- 歴史：VBSを自作 → Talendへ変更(VBSも一部併用)
- BI：Metabase
- 歴史：PowerBI → QuickSight → Metabase と変遷。
課題など
Talend採用によって異なるDBを直接接続（Oracle → Snowflake、SQLserver → Snowflake）することが容易にできた。しかし、Talendだけでデータ整形は終わらない為、Snowflake上でのデータ整形の棲み分けも必要となり、バッチ数が増えるごとに管理が煩雑になった。
Snowflakeの採用とMetabaseの採用によって安価で高性能なデータ分析基盤構築が構築できたが、ETL部分の煩雑さが運用負荷となってしまった。
3社目のデータ分析基盤（2023年）
Snowflakeの外部ステージ、Snowpipe、task、Streamという機能を活用して、非常にシンプルな基盤を構築。
- ソース：CSV（売上データ、コストデータ、外部データ）
- データレイク：S3
- DWH：Snowflake
- ETL：S3にCSVを置くとSnowpipeを通じて即時に取り込みとデータ整形taskが実行される
- BI：PowerBI
課題など
前回導入したTalendが、データ連携を容易にした部分と作業を煩雑にした両面があったので、今回も使うかどうかで非常に悩んだ。PythonでETLを自作するようにしようと考えたが、「Snowflakeに取り込んでから整形する」＝ELTという思考に変更すれば、Pythonも不要ということに気づいて方針を転換。S3に置いたCSVをSnowPipeで取り込むことを基本としたことで、サーバレス実行できるようになった。
3社目のデータ分析基盤（2023年）について詳しく書きます。
前回は「サーバレスでデータ分析基盤作る」ということができなかったので、今回はここに力を入れました。
その為、最初は以下のようにLambdaで動作するPythonプログラムでデータを整形してから取り込みを実行していましたが、SnowflakeのSnowPipe、Stream、Taskの機能を組み合わせることで、Lambda（Python）も使うことなくデータ分析基盤が構築できるようになりました。「データを整形してから取り込む」から「データを取り込んでから整形する」に思考を変えることが重要なポイントでした。
また、エンジニア採用が困難な昨今、クラウドの知識は必要ですが、SQLが分かれば大半のことができる仕組みにできたことは、人件費といった側面からも大きな効果があったと感じています。
メリット
- マネージドサービスの組み合わせなので、データマネジメント業務に集中できる
- S3にデータを置くと自動でSnowflakeに取り込まれ、データ整形も実行される
- Snowflake（とAWS）の知識があれば構築できる
- SQLのみでデータ整形ができるので、人材採用のハードルも下がる。
今回作成したデータ分析基盤の構成図
SQSやSNSなどのAWSの機能も利用していますが、非常に簡単なものとなっております。
詳しい構築方法については、機会があれば記事にしたいと思います。