こんなデータマートは嫌だ。どんな？ / waiwai-data-meetup-202504

Transcript

1. こんなデータマートは嫌だ。どんな？ わいわいデータミートアップ 2025-04-10 高際 隼 @shun_tak
2. 高際 隼 / Shun Takagiwa 株式会社LayerX アナリティクスエンジニア ▸ 2020年〜現在 - バクラク事業を立ち上げ、AI-OCRの初期バージョンを開発 - 機械学習とデータ関連組織の立ち上げ、マネジメント - データ活用の推進に注力 (今) ▸ 2018〜2020年 - 株式会社LayerX 立ち上げ - ブロックチェーン事業 PM・TechLead 最近は Cline でのデータマート作りに挑戦中 結構いい感じになってきたかも 自己紹介 © LayerX Inc. 2
3. こんなデータマートは嫌だ。 どんな？
4. ドキュメントがない ▸ 誰が何のために作ったデータマートか分からない ▸ カラムの意味や、主キー (PK)・外部キー (FK) も不明瞭 ▸ でも意外と使われてる ▸ 「数字がズレてるんですけど」を直せない © LayerX Inc. 4
5. まじでドキュメント書こう ▸ シンプルでいいので書いてほしいものリスト - 目的・用途 - 想定する主な利用者 - 主キー (複合主キーなら組み合わせ) - 外部キーの参照先 - 日本語 (自然言語) のカラム定義 3か月後の自分のためにもなるし、作ったデータマートの利用者も増えると思うよ！ 特にLLMの時代はドキュメントが重要 © LayerX Inc. 5
6. 例 項目 具体例 目的 EC部門の月次報告用で使う商品カテゴリ別の売上推移 想定利用者 EC部門のデータアナリスト カラム定義 year_month: 対象年月（YYYY-MM形式）(PK) electronics_sales: 電化製品売上（円） fashion_sales: ファッション売上（円） food_sales: 食品売上（円） total_sales: 総売上（円） customer_count: 購入ユニークユーザー数 © LayerX Inc. 6
7. ドキュメントの下書き生成プロンプト (参考) 現時点では o3-mini など考えるモデルがオススメ。 {} は自分で編集する © LayerX Inc. 7
8. こんなデータマートは嫌だ。 どんな？
9. 汎用性が低い ▸ 月次で集計済み ▸ カテゴリーでピボット済み © LayerX Inc. 9
10. 月次で集計済み year_month total_sales customer_count 2025-01 10,500,000 3,240 2025-02 9,800,000 3,050 2025-03 11,200,000 3,420 ▸ 問題点 - 3月の売上急増の原因日（イベント日など）を特定できない - ある特定の週だけ売上が落ちていても月合計では気づけない - 「月初10日間」の前年同期比など、柔軟な分析ができない © LayerX Inc. 汎用性が低い 10
11. カテゴリーでピボット済み year_month total_sales electronics_sales fashion_sales food_sales 2025-01 10,500,000 5,200,000 3,800,000 1,500,000 2025-02 9,800,000 4,700,000 3,500,000 1,600,000 2025-03 11,200,000 5,500,000 4,100,000 1,600,000 ▸ 問題点 - 新カテゴリー「home_goods」追加時にカラム追加・スキーマ定義の変更が必要 - サブカテゴリー（スマホ、PC、AV機器など）の追加はどうする - 一つの商品が複数カテゴリーに所属する場合（電化製品かつギフト商品など）の対応が難しい © LayerX Inc. 汎用性が低い 11
12. 汎用性を上げるコツ ▸ 目的と用途を明確にし、言われた通りに作らない ▸ 用途の範囲内で粒度を最小に保つ ▸ ピボットしない (横持ちしない) © LayerX Inc. 12
13. 目的と用途を明確にし、言われた通りに作らない 「今度の経営会議で月次の売上推移を報告するので、データ出して」という要望を受けた場合 ▸ なぜ必要？ → 「マーケティング施策の効果を確認したい」 ▸ どう活用？ → 「カテゴリ別予算配分の意思決定に使う」 ▸ 意思決定の頻度は？ → 「経営会議は月次だけど、週次のマーケティング定例でも議論」 ▸ 他に見たい切り口は？ → 「新規・リピート別の効果も知りたい」 → 必要なのは日次または週次の商品カテゴリ別のデータで、顧客タイプ別の分析も可能なデータマート © LayerX Inc. 汎用性を上げるコツ 13
14. 用途の範囲内で粒度を最小に保つ 月次集計 日次（適切な粒度） 時間単位（必要な場合） year_month: 2025-03 total_sales: 11,200,000 date: 2025-03-15 total_sales: 384,000 timestamp: 2025-03-15 18:00 total_sales: 48,000 ▸ 用途に応じて粒度を選択 - 時間単位 → 特売セール開始直後の売上急増、終了前の駆け込み需要を把握 - 日次 → 平日/週末の傾向の違い、給料日効果などを分析 - 月次 → 日次データから集計可能 時間単位にするとレコード数が日次の24倍になり、コスト増加やパフォーマンス悪化の可能性 → 必要な場合のみ使用 © LayerX Inc. 汎用性を上げるコツ 14
15. ピボットしない (横持ちしない) date category sales 2025-03-01 electronics 180,000 2025-03-01 fashion 125,000 2025-03-01 food 52,000 ▸ 正規化形式 (縦持ち) のメリット - 新カテゴリー「home_goods」を追加してもスキーマ変更不要 - サブカテゴリーの追加が容易（categoryとsub_categoryの2列で表現可能） - 一つの商品が複数カテゴリに所属する場合も自然に表現できる - ピボットしたければBIツールで簡単にできる © LayerX Inc. 汎用性を上げるコツ 15
16. ディメンショナル・モデリング (発展編) ▸ 基本的な考え方 - 何を (Fact/指標) どのように (Dimension/軸) 見るかでモデリングする - Factテーブル : 測定値・集計対象となる指標 - 例 : 売上金額、数量など - 集計関数 (COUNT, SUM, AVG など) の対象になることが多い - Dimensionテーブル : 分析軸となる属性情報 - 例 : 契約日、商品、顧客など - グルーピング・フィルタリング (GROUP BY / WHERE) の対象になることが多い ▸ メリット - 分析時に理解しやすい構造 - 結合 (JOIN) を減らせる - 新しい軸を簡単に追加できる - BIツールとも相性が良い 参考 : 30分でわかる『アジャイルデータモデリング』 by ucchi-さん © LayerX Inc. 汎用性を上げるコツ 16
17. こんなデータマートは嫌だ。 どんな？
18. クエリがカオス ▸ クエリ全体がとにかく長く、サブクエリ多用 ▸ 分かりそうで分からない謎の名前 (amt_dlyとか) ▸ 異なる単位やタイムゾーンが混在 ▸ NULLの代わりに使われてそうな値の説明がない - -1 , 1970-01-01 , etc © LayerX Inc. 18
19. 理解しやすいクエリを書くコツ ▸ 読んで意味のわかる名前をつけよう ▸ サブクエリをCTEに分解しよう (WITH句を使う) © LayerX Inc. 19
20. 読んで意味のわかる名前をつけよう (1) ▸ 基本原則: 省略せず、明確に - amt → amount ▸ 一貫性を保つ (以下は例) - テーブル名: 複数形 ( orders , customers ) - ID列: テーブル名の単数形+ _id ( order_id , customer_id ) - 日付/時間: 接尾辞で型を明示 ( created_date , created_at ) - コードと名称を区別 ( category_code / category_name ) 余談 : 生き残り続ける tmp_sales_202311 みたいなのもやめよう © LayerX Inc. 理解しやすいクエリを書くコツ 20
21. 読んで意味のわかる名前をつけよう (2) 曖昧な名前 明確な名前 理由 price price_yen 通貨単位を明示 created_at created_at_jst タイムゾーンを明示 count number_of_orders 何をカウントしているか明示 sales total_sales 合計値であることを明示 conversion_rate orders_per_page_views_percent 分子・分母、単位を明示 特に rate の分子・分母、単位 (小数、百分率、一万分率など) は重要 © LayerX Inc. 理解しやすいクエリを書くコツ 21
22. サブクエリをCTEに分解しよう (WITH句を使う) ▸ 問題点 - 入れ子構造で読みづらく、クエリの意図が掴みにくい - 重複が発生し、非効率 - 実は意味のないサブクエリだったりする ( SELECT * FROM table してるだけとか) ▸ CTEに分解すると… - 可読性が高く、役割も明確になり、メンテナンスしやすくなる - 重複やバグに気付きやすくなる 参考 : 人間のためのリーダブルSQL by tenajimaさん © LayerX Inc. 理解しやすいクエリを書くコツ 22
23. さいごに ▸ ここまで聞いてくれた方はきっと 「今がベストじゃない」 「もっと良くできるはず」と考えているのでは？ ▸ あなたの作ったデータマートは、間違いなく事業を、組織を前に進めたと思います ▸ 「こんなデータマートは嫌だ」なんて言ってすみませんでした ▸ 今日のLTが少しでもあなたのお役に立てば幸いです © LayerX Inc. 23
24. [PR] LayerX ではデータの民を募集中！ データ基盤の土台 (Data warehouse, ETLなど) が整ってきました。 いよいよAI・データ分析での活用や、データマネジメントが楽しくなってくるフェーズです！ (今回の話が好きな人はちょうどいいフェーズかも) ▸ 正社員・副業も可 ▸ 募集職種 - データアナリスト - データサイエンティスト - 機械学習エンジニア - アナリティクスエンジニア - データエンジニア LayerX 採用情報 → jobs.layerx.co.jp © LayerX Inc. 24