Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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年代(もしくはもっと前)から続く、長い研究の歴史 ● 実際にはもっともっと色々なリスクがある!

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

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

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

19 CONFIDENTIAL: © LayerX Inc. テスト

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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 ユニットテスト (クエリテスト) インテグレーションテスト (データテスト)

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

24 CONFIDENTIAL: © LayerX Inc.