estie データマネジメントグループのソフトウェアエンジニアの和田です。
この記事の内容
さーて、今回の estie inside blog は
- Snowflake の導入
- estie のデータマネジメントの過去の課題・今の課題
- データプラットフォームエンジニア募集中
となっております。それでは本編どうぞ！
estie におけるデータの重要性
estieは商業用不動産業界のデジタルシフトを推進するスタートアップ企業です。
様々な経路 (PDF ファイルの共有、FAX、電話、飲み会、etc…) でやり取りされている業界内の情報を集め、それらの情報を統合した高品質な不動産データセットを作り、それをプロダクトとして展開することで不動産業界へ貢献しようとしています。
会社が目指している構想については過去の記事をご覧ください。
また、実際のプロダクトについては「初公開！estieの主力サービスを解剖してみた」をご覧ください。
集めてきたデータを統合するデータ加工プロセスそのものがビジネスの根幹を担っているという点が、個人的には面白いポイントだと感じています！
Snowflake 導入前のデータ課題
estie が持つデータは所謂 3 層構造（レイク・ウェアハウス・マート）のような形態をとっており、各層をまたぐ部分で加工を行うパイプラインを構築しています。
各層のデータストアはMySQLが採用され、層をまたぐ加工は Python プログラムで実行されています。中身を確認したいときは Redash で接続するような運用になっていましたが、データソースの増加に伴っていくつか課題感が出てきました。
- 分析の課題
- 複数のデータソースを一つに統合したデータがプロダクトに提供されるため、処理の入出力を確認することの重要性が高いが、Redash の Query Results 機能で DB をまたいだ分析を行うコストが高くなっていた
- アクセスコントロールの課題
- 様々なデータソースやプロダクトが増えるにしたがって「このデータソースはこのプロダクトだけから参照したい」「このデータソースに対して、この社内ユーザはアクセスしてはいけない」というような要件が増加してきた
上記はデータ加工を行うパイプラインの課題ですが、これに加えて「全社的にデータ活用を活性化させたい」という社内課題も存在し、
- プロダクトのログのようなデータも統合的に扱いたい
- 各プロダクトチームがデータを活用したい時に、データマネジメントグループが作業しないと進まないようなシーンを減らしたい
というような期待も、データ基盤に求められていました。
Snowflake の導入
estie では、データ加工のプロセスを実行するための基盤と、社内のデータ分析の実行基盤との両方を兼ねることを期待して Snowflake を導入しました。
プロダクトで使うデータを生成するための基盤と社内データ活用の基盤を同じにしてしまうかどうかに関しては様々議論があったのですが、以下の理由で一緒にしてしまう意思決定をしました。
- 現状 estie が収集しているデータにはリアルタイム性の高いものは多くなく、バッチでデータの加工処理を実行しているため、Snowflake 上でデータ加工を行っても遅延がクリティカルな問題にはならないであろうという予想
- データが Snowflake の中だけで完結するようにすれば、Snowflake 内のロールだけでデータのアクセス権限が管理できるのではないかという期待
- Snowpark や dbt Python model などが利用できるようになり、既存の処理を更に効率的に開発・運用できるのではないかという期待（モダンなツールに対してのやや銀の弾的な期待であることは否めませんｗ）
このブログを書いている時点では、これまで MySQL のテーブルだった部分を Snowflake のテーブルに置き換えるような移行が概ね完了したような状態です。既に稼働しているプロダクトへの影響を最小限にするべく、入出力を MySQL から Snowflake に切り替えるだけに留めることを優先したため、Snowflake だからできることという恩恵はまだ受けていない状態にはなっています。
改善されたこと
Snowflake だからこそできることはまだ多くはないのですが、導入前の課題はある程度解決されました。
- 分析の課題
- 処理の前後のデータの比較はやりやすくなったと感じます。実際に、データを統合する処理の入出力に期待と異なるケースがあることが発見・修正され、データ品質の向上につながるケースがありました
- アクセスコントロールの課題
- 明確にロールが設定されました。デフォルト非公開で、必要に応じて公開するという基本方針を定めてロール設計をしたため、利用者が意図せずデータを不正に公開してしまうようなリスクが低減しました。「保存していいのか良くわからないから保存しないでおこう」から「公開のコントロールを後で考えればいいから一旦保存しておこう」に変わったのは、データ基盤としては大きな進歩だと思っています
- 社内データ活用の活性化
- Snowflake のリソースは Terraform で管理する方針にしたため、各プロダクトチームが必要なリソースを自分で用意しやすくなりました。実際に、ほとんどデータマネジメントグループの手を借りずにプロダクトのログの取り込み設定が完了したケースもあります
次に見えてきた課題
Snowflake に移行したことでメリットもありますが、新たに見えてきた課題もあります。
- データ加工基盤としての課題
- Python プログラムの入出力が Snowflake に置き換わっただけで、まだまだ Snowflake の機能を活用しきれていない
- MySQL から Snowflake に移行したことで、テーブル間のリレーションが効かなくなりました（Snowflake ではリレーションを設定することはできますが、それに背いてもエラーにはならない）データを正規化する必要がある場合に、実際にリレーションがあることを担保するような仕組みが欲しい
- dbt の導入でテストできないか？を検討中
- 収集したデータを統合するパイプラインは常に改善されているため、データの入出力の定義をきちんとメタデータとして管理したい
- データ分析基盤としての課題
- 分析結果を共有したり分析のための仕組みを共有するための整理がなされていない
- 共通的に使いたいデータ加工の定義や、汎用的な UDF の管理など
- 分析結果を共有したり分析のための仕組みを共有するための整理がなされていない
Help!
今回の記事では、estie が Snowflake を導入したことやその背景を説明させていただきました。
モダンなツールを導入したこと自体は、いちエンジニアとしては面白い環境ではあるものの、正直なところデータ基盤の構築はかなり手探りな状態です。自分の前職はデータアナリスト兼検索エンジニアですし、チームメンバーもデータエンジニアリングを経験豊富というわけではないため、日々勉強しつつデータエンジニアリングに挑んでいるような状態です。
このような状況の estie のデータ基盤を、ビジネスの基盤として昇華させることに興味を持たれたデータエンジニアの方、ぜひカジュアルにお話させていただけると嬉しいです！お力をお貸しください！
