https://ozaki25.hatenadiary.jp/entry/2025/02/04/205349

マルチデータプロダクト開発・運用に耐えるためのデータ組織の遷移

2022年頃までチームごとにデータ担当を持っていた
- スピードは維持しやすかったが車輪の再開発なども起きてきた
- 横のつながりのためプラットフォームチームに変更
  - Snowflake x dbt x Terraformの基盤
- 主体はストリームアラインドチームとして動く
その後データとプロダクトが増え続けている
- データソース20くらい
- ストリームアラインドチームごとのドメイン知識の共有が難しくなる
  - データを組み合わせるところがビジネス価値
- データ固有の名寄せなどはサイロ化
- ビジネスメンバーもデータにアクセスする機会が増える
- プラットフォームの充実化へ
- OpenMetadata導入でデータを発見しやすいように
  - メタデータは人が入れないといけないので運用の仕組み作り
dbtからDataContractへ
- dbtでは不十分なケースが出てきた
- DataContractを導入へ
  - OpenAPIのようなスキーマの定義

株式会社estie Ryosuke Lin さん

データパートナーによって仕様が様々
- 同じようなカラムでも内容が異なっていたり
- 自由記述になっててスラッシュ区切りで複数値入ってるとか
- データの更新頻度
- データの仕様が変わることも
- これらを組み合わせることでデータを充実させていく
データを名寄せする難しさ
- 表記揺れやパートナーの入力ミスもある
- 同じ名前の建物が隣にあったりということもあるのでちゃんと確認しないと分からない
- 自動化が難しく人の目を入れないとどうにもならないところも多い
- 自動化と手動をものによって使い分けて対処
データクレンジングパイプライン
- 表記揺れのある重複データを名寄せ
- データパートナーの追加/削除対応
- Snowflake上で管理
- 毎日パイプラインを回してincremental modelで対応
- 過去データの追加や削除の場合はfull refreshが必要
  - 手動入力や名寄せ結果は壊れないように対象から分離
自動名寄せ
- pythonで実装
- APIとして提供しSnowflake上から叩いて利用
手動名寄せ
- Streamlit in SnowflakeでSnowflake上で完結させる

株式会社アイスタイル tsudash0 さん