dbtを中心に据えた データ分析とプロダクト開発

Transcript

1. 1
   dbtを中心に据えた
   データ分析とプロダクト開発
   2022/11/11
   LayerX 須藤 欧佑
   データビジネスにおけるdbtの活用事例
   〜Ubie、LayerX、10X〜
   LayerX Inc.
   

   View Slide

2. 2
   CONFIDENTIAL: © LayerX Inc.
   自己紹介
   ● Osuke（須藤 欧佑）
   ● Privacy Tech事業部 リードエンジニア
   ● ソフトウェアエンジニアとしてプロダクト開
   発、データエンジニア兼アナリティクスエンジ
   ニアとしてデータ基盤の整備・運用あたりをメ
   インに取り組んでいます。
   

   View Slide

3. 3
   CONFIDENTIAL: © LayerX Inc.
   LayerXの事業紹介
   

   View Slide

4. 4
   CONFIDENTIAL: © LayerX Inc.
   ● LayerXにおけるプライバシー保護データマイニング技術のユースケースは、データ外部提供先でのプラ
   イバシーリスクを守るもの
   ● 攻撃者は、データ提供先の内部や、ハッキングや情報流出等での外部の人
   データ外部提供における問題設定
   生データ
   (保護対象)
   匿名化
   処理
   データオーナー データ利用者
   加工後
   データ
   攻撃者
   ？
   

   View Slide

5. 5
   CONFIDENTIAL: © LayerX Inc.
   平均年収：800万円
   平均年収：799.9万円
   Aさん在籍時の合計年収
   = 平均800万円 * 51人
   Aさん退職後の合計年収
   = 平均799.9万円 * 50人
   Aさんの年収
   = 800 * 51 - 799.9 * 50
   = 805万円
   Aさん在籍時
   (51名)
   Aさん退職後
   (50名)
   ・・・・・・・・・・・・・
   ・・・・・・・・・・・・・
   たった1000円分の平均年収の
   変化から、Aさんの給与がわ
   かってしまう
   プライバシー保護の難しさ
   ● 統計情報だけを提供しても、差分から特定個人のデータが炙りだされてしまう
   ● 1970年代（もしくはもっと前）から続く、長い研究の歴史
   ● 実際にはもっともっと色々なリスクがある！
   

   View Slide

6. 6
   CONFIDENTIAL: © LayerX Inc.
   例：差分プライバシー
   ● 機密なデータに基づく統計データに、プライバシーを保護するノイズを注入する
   ● 誤差が発生するが、統計的な分析では活用できる
   年齢 性別 住所 年収
   32 男性 東京都中央区 650万円
   24 女性 神奈川県横浜市 600万円
   56 男性 東京都中央区 1000万円
   44 女性 千葉県松戸市 950万円
   ノイズ付与後の
   平均年収: 810万円
   平均年収: 800万円
   （真の値）
   公開しない
   元のデータの
   復元困難
   元のパーソナルデータ
   差分プライバシー
   のアルゴリズム
   +10万円の
   ノイズを付与
   

   View Slide

7. 7
   CONFIDENTIAL: © LayerX Inc.
   分析基盤プロダクト
   

   View Slide

8. 8
   CONFIDENTIAL: © LayerX Inc.
   アジェンダ
   ● データ分析基盤超概要
   ● クエリの共通化
   ● テスト・品質担保
   

   View Slide

9. 9
   CONFIDENTIAL: © LayerX Inc.
   データ分析基盤
   

   View Slide

10. 10
    CONFIDENTIAL: © LayerX Inc.
    プライバシー保護のためのデータ分析
    ● BigQuery上にデータを集約し、dbtを用いてデータを整備
    ● そのデータを各種BIツールから社内のデータ分析者がデータ分析に利用
    例：位置データ
    社外 社内
    社内分析者
    

    View Slide

11. 11
    CONFIDENTIAL: © LayerX Inc.
    データモデリング概要
    ● プライバシー保護のためのデータ分析
    ○ そのデータセットに存在しうるユーザーのプライバシーを保護するために必要な加工により誤差率
    などの有用性指標がどの程度になるか、などをさまざまなディメンションや指標の軸で分析する
    st0
    データレイク
    st1
    前処理
    st2
    ファクトテーブ
    ル
    st3
    プライバシー保
    護前処理
    st4
    プライバシー保
    護・評価
    st5
    データマート
    例：位置データ
    社外 社内
    社内分析者
    

    View Slide

12. 12
    CONFIDENTIAL: © LayerX Inc.
    データアプリケーション
    ● ユーザーがユースケースに合わせて欲しい分析軸やパラメータを入力すると、それに合わせたプライバ
    シー保護評価の結果やプライバシー保護済みのデータが出力するWebアプリケーションを提供
    st0
    データレイク
    st1
    前処理
    st2
    ファクトテーブ
    ル
    st3
    プライバシー保
    護前処理
    st4
    プライバシー保
    護・評価
    st5
    データマート
    例：位置データ
    社外 社内
    社内分析者
    社外分析者 データアプリケーション
    

    View Slide

13. 13
    CONFIDENTIAL: © LayerX Inc.
    クエリの共通化
    

    View Slide

14. 14
    CONFIDENTIAL: © LayerX Inc.
    クエリの共通化
    ● どちらもコアロジックとなるプライバシー保護関連の処理は「ほとんど」同じロジック
    ● 管理するクエリは最小限にした方が品質担保的にも運用的にもメリットが大きい
    例：位置データ Data App
    分析 dbt model dbt model dbt model
    SQL SQL
    dbt model dbt model dbt model
    SQL SQL
    例：位置データ Data App
    分析 dbt model dbt model dbt model
    SQL
    dbt model dbt model dbt model
    SQL
    

    View Slide

15. 15
    CONFIDENTIAL: © LayerX Inc.
    クエリの共通化
    ● SQLは”関数”としてdbtのmacroで定義
    ● 参照するdbt modelやパイプラインごとの差分は引数で設定可能なようにする
    Macros in Jinja are pieces of code that can be reused
    multiple times – they are analogous to "functions" in
    other programming languages, and are extremely
    useful if you find yourself repeating code across
    multiple models.
    https://docs.getdbt.com/docs/build/jinja-macros
    

    View Slide

16. 16
    CONFIDENTIAL: © LayerX Inc.
    クエリの共通化
    analysis_
    fact
    app_fact
    analysis_
    agg
    app_agg
    

    View Slide

17. 17
    CONFIDENTIAL: © LayerX Inc.
    ● ただし、トレードオフとして、可読性が低下してしまう
    ● とはいえ、可読性が低下してしまうことよりも処理を共通化できることの方が品質担保やクエ
    リ開発コストの点からメリットの方が大きいと判断（慣れれば読める）
    ● dbt Wizardなどエディタ上でのリアルタイムコンパイルやlinterの力を借りてコンパイル後の
    クエリを見ながら開発できるようにもなってきている
    トレードオフ
    

    View Slide

18. 18
    CONFIDENTIAL: © LayerX Inc.
    複数データソース
    ● 実際には、さらにさまざまな企業からさまざまな種類のソースデータが存在
    ● 同様に、単一のmacroを利用しコアロジックは共通化
    位置データ
    Data App
    分析 dbt
    model
    dbt
    model
    dbt
    model
    dbt
    model
    dbt
    model
    dbt
    model
    決済データ
    Data App
    分析 dbt
    model
    dbt
    model
    dbt
    model
    dbt
    model
    dbt
    model
    dbt
    model
    SQL
    医療データ
    Data App
    分析 dbt
    model
    dbt
    model
    dbt
    model
    dbt
    model
    dbt
    model
    dbt
    model
    SQL
    

    View Slide

19. 19
    CONFIDENTIAL: © LayerX Inc.
    テスト
    

    View Slide

20. 20
    CONFIDENTIAL: © LayerX Inc.
    テスト
    ● 外部に分析したデータや加工データを提供するので、「データ」自体が商品であり、そこにデータの欠
    陥・分析ミス・プライバシー保護加工のミスなどが含まれることはあってはならない。
    ● １ファイルで長いクエリはテストがしにくいので、ephemeralなどを使って細かくファイルは分けてお
    く。
    ユニットテスト
    （クエリテスト）
    インテグレーションテスト
    （データテスト）
    クエリにより生成されたデータ自体に対するテスト。
    その（継続的に変化しうる）データがその時点で意図
    した必要条件を満たしているかテスト。
    例：
    - ソースデータの欠損: nullが入るべきではないカラ
    ムの値がnullになっていないか
    - データの分布: 正規分布に従う乱数（ノイズ）を
    加えた際、そのノイズの平均が0であることのz検
    定
    クエリ自体のロジックに対するテスト。
    あるテーブルに対して実行したクエリが意図したデー
    タを出力しているか。
    いわゆる、expectedとactualが一致していることをテ
    スト
    例：
    - 単価1,000円以上の商品の購入数を集計する処理
    で、1,000円という境界付近のレコードがある場
    合・ない場合で意図した集計結果になるかテスト
    

    View Slide

21. 21
    CONFIDENTIAL: © LayerX Inc.
    テスト
    dbt seed
    etc.
    test
    case
    actual
    user area value
    a c 10
    b d 20
    SQL
    expected
    requirements
    SQL
    app_agg
    app_fact
    ユニットテスト
    （クエリテスト）
    インテグレーションテスト
    （データテスト）
    

    View Slide

22. 22
    CONFIDENTIAL: © LayerX Inc.
    テスト
    ユニットテスト
    （クエリテスト）
    インテグレーションテスト
    （データテスト）
    https://github.com/mjirv/dbt-datamocktool でもOK
    

    View Slide

23. 23
    CONFIDENTIAL: © LayerX Inc.
    ● ただし、以下のようなトレードオフもある。
    ○ テストも含めたクエリ開発自体にかなり工数が取られる
    ○ データサイズが膨大になるとテストクエリの実行にコストがかかる
    ○ 細かくテストを定義しすぎるとクエリ自体の変更が大変になる
    ● とはいえ、データの品質担保はデータビジネスにおいて最重要であるのでテストテスト
    トレードオフ
    

    View Slide

24. 24
    CONFIDENTIAL: © LayerX Inc.
    

    View Slide