過去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の機能も利用していますが、非常に簡単なものとなっております。
詳しい構築方法については、機会があれば記事にしたいと思います。