Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ネットスーパーにおける商品在庫データのアプリケーション構築事例

10xinc
November 11, 2022

 ネットスーパーにおける商品在庫データのアプリケーション構築事例

10xinc

November 11, 2022
Tweet

More Decks by 10xinc

Other Decks in Programming

Transcript

  1. ©10X, Inc. All Rights Reserved. 自己紹介
 3 所属: 株式会社10X
 氏名: 瀧本 晋也


    職種: データプロダクトエンジニア
 居住: 山梨
 Twitter: @takimo
 最近はTokyo dbt Meetupのオーガナイザーを やってます

  2. ©10X, Inc. All Rights Reserved. なぜ商品在庫データを作る必要があるのか?
 7 
 通常EC
 店舗型ネットスーパー

    
 品揃え
 数十〜数百
 数万点
 在庫数の 管理
 倉庫の入庫数と販売数で管理が可 能
 基本的に日次での残在庫数等は数値管 理していない場合が多い(生鮮系や賞味 期限が短いものは売り切りが基本) 
 金額
 あまり変わることはない 
 チラシ価格や特売等、日単位で同一商品 で変化する
 • 日々変化する「金額」と取り扱う「商品数の多さ」から厳密な在庫数確認が困難で、人的な対応も限界 がある
 • Stailerでは店頭在庫数を自動で推定し、ネットスーパーの在庫データとして提供している 

  3. ©10X, Inc. All Rights Reserved. 2021年前半 爆誕期
 • 社内ではDWHの構築のためにdbtの導入が進んでおり、 dbtを使える人が増加
 •

    外部パートナーから提供されるデータから商品在庫データを生成する必要性が出る 
 • データ内容の理解の難しさや変換処理の設計難易度 、プロダクトエンジニアのリソース的な観 点もあり、「データ変換処理」をdbtで実装するためのチーム が組成された
 • ファーストリリースがされる🎉
 10 商品在庫データの歴史
  4. ©10X, Inc. All Rights Reserved. 2021年後半 拡大期
 • 嬉しいことに様々なパートナーにお声をかけて頂き、 dbtを使った商品在庫データの生成 パイプ

    ラインは増えた
 • パートナーごとに保有しているデータ仕様が異なりがあったが、開発ガイドライン(初期)を策定 し、一定の変換対応ができればサービスを提供できるようになっていた 
 • dbtを採用した事により開発に携われる人の採用職種の幅を出すことができ、機動的に開発 チームを増員していくことが出来た 
 11 商品在庫データの歴史
  5. ©10X, Inc. All Rights Reserved. 2022年前半 戦乱期
 • 個社毎に作ったパイプラインにも問題がで始める 🔥
 •

    複雑に入り組むリネージ
 • 同じような処理ロジックが様々なところに&下流に様々なロジックが混在しやすくなってしまって いた
 • また属人的に開発をする必要が高く、キャッチアップコストも高い状態に 
 • 修正をしたりする開発難易度や品質確認のためのQA工数も高くなってしまった 
 ◦ リネージが複雑でデータの流れを追うのが大変だったり、抽象度が荒いので様々なテーブルの確認が必要等
 12 商品在庫データの歴史
  6. ©10X, Inc. All Rights Reserved. どういうモデリング、アーキテクチャにすべきか検討
 • DRY(SSOT)を実現し、計算ロジックをテスト出来る状態にすることが必要命題 
 •

    様々な開発手法のアプローチやモデリングを検討した 
 ◦ dbtのベスプラ(staging, mart)
 ◦ ディメンジョンモデリング(fact, dimension)
 ◦ 他の開発手法であるMVCやDDD(ドメイン駆動設計)等
 • 最終的にドメイン駆動設計の思考に近いアプローチが良さそうだと判断 
 19 アーキテクチャの共通化
  7. ©10X, Inc. All Rights Reserved. ドメイン駆動設計とは?
 • このスライドだけではぱっと説明するのは自分には無理だなと感じつつ。。 
 •

    以下のようなアプローチで解決をしようとするものです 
 ◦ 解決したい関心事(ビジネスや業務)を「ドメイン」という粒度で捉える
 ◦ ただし「ドメイン」を整理するためにはドメインの深い知識と理解が必要
 ◦ 「ドメイン」同士の複雑性をオブジェクト指向や制約でコントロールする
 • 詳しく勉強したい人は書籍を!
 20 アーキテクチャの共通化
  8. ©10X, Inc. All Rights Reserved. なぜドメイン駆動設計が良いと思ったのか
 • 大まかな設計方針として「データを一定の粒度に一度まとめる(SSOT)」、その後利用する といった考えは持っていた
 •

    DDDの中でドメイン(モデル)をまたぐ複雑な処理(今回の実装でいうと計算処理)はドメイ ンサービスとして切り出すような思想になっている 
 • 実際のパイプラインでもこの計算処理の部分が複雑になりやすく、この処理を切り出し、テ ストできるようにしたかったのでやりたいことと思想がマッチした 
 23 アーキテクチャの共通化
  9. ©10X, Inc. All Rights Reserved. 5つのレイヤリングに役割を区分しテストで品質を保証
 24 アーキテクチャの共通化 ソースデータ
 


    ・このデータを様々な ところから利用しない 
 ゲートウェイ
 
 ・ソースデータをクレン ジングする処理層 
 ・データレイクとの入り 口を意識した名前 
 
 
 ドメインモデル
 
 ・ビジネスドメインを一 定の粒度で集約する 
 ・ドメインモデル同士 は依存させない 
 
 
 ドメインサービス 
 
 ・ドメインモデル同士 を利用して複雑な処 理をするための処理 層
 ・必ず実装する必要 はない
 
 
 アプリケーション 
 
 ・最終的なユースケー スに沿った結合処理 等を行う
 
 

  10. ©10X, Inc. All Rights Reserved. not_emptyテスト
 • ソースデータが日付シャーディングで保存されているようなデータに対して 
 •

    実行日に所定のシャーディングがあるのか簡単にチェックできるカスタムジェネリックテスト 
 26 テストによる責務や品質の保証をする
  11. ©10X, Inc. All Rights Reserved. スキーマテスト(ジェネリックテスト)
 • dbt標準で提供されているnot_nullや uniqueを利用
 •

    追加で内包されているデータ型をチェック するための型チェック用のカスタムテスト も実装
 27 テストによる責務や品質の保証をする
  12. ©10X, Inc. All Rights Reserved. まだまだ道半ばです
 • ネットスーパーを運営するためにはまだまだ様々なことが必要です 
 •

    今日はその難しさの中の一部分を紹介させてもらいました 
 • 本日は技術方面の話が中心でしたが、実際は先方と仕様を調整したり、データプロダクトの企 画や仕様策定といった業務をリードする データプロダクトマネージャーと一緒に仕事をしていま す
 • 是非ご興味ある方はカジュアル面談等お気軽にお尋ねください 
 32 まとめ