VOC分析を支えるデータ基盤とモダンデータスタックの取り組み【DeNA TechCon 2023】

youtube：https://youtu.be/fokewbBeRvo

概要：
DeNAのカスタマーサポートやマーケティング業務では、数多くのサービスに対する反響の分析やリスク管理などを目的に、日々蓄積されるDeNAのあらゆるサービスのユーザーのご意見やレビューデータなど活用したVOC(Voice Of Customer)分析およびソーシャルリスニングが積極的に行われています。

これらデータの活用を進めるためGoogle Cloudでデータ基盤を構築・提供してきましたが、ツール保守などの運用コスト面やデータ品質の課題などが顕著となってきました。

そこで、データエンジニアリング界隈でトレンドとなっているモダンデータスタックに着目しつつ、どう課題を解決してきたか、また現在どういったことに取り組んでいるかをご紹介します。

登壇内でのリンク集：
p2, https://engineering.dena.com/team/data/dataengineering/
p10, https://dena.ai/works/nlp/
p21, https://cloud.google.com/bigquery/docs/column-data-masking-intro?hl=ja
p22, https://cloud.google.com/analytics-hub?hl=ja

◆ チャンネル登録はこちら↓
https://youtube.com/c/denatech?sub_confirmation=1

◆ Twitter
https://twitter.com/DeNAxTech

◆ DeNA Engineering
https://engineering.dena.com/

◆ DeNA Engineer Blog
https://engineering.dena.com/blog/

◆ DeNA TechCon 2023 公式サイト
https://techcon2023.dena.dev/

Transcript

1. VOC分析を支えるデータ基盤と モダンデータスタックの取り組み データ本部データ基盤部 深瀬 充範
2. 自己紹介 深瀬 充範 (Mitsunori Fukase) • データ本部データ基盤部 @ DeNA (2020/02 ~ ) ◦ Data Engineer / Data Architect ▪ HR / CS / 経営企画などのデータ活用推進を担当 ◦ Engineering Manager（グループマネージャー） ▪ 部門全体への技術支援グループ ▪ インフラ・全社横断データエンジニアグループ • DeNAデータエンジニア組織について ◦ https://engineering.dena.com/ team/data/dataengineering/ 2 実家の猫
3. Table of Contents ・VOC分析を支えるデータ基盤の紹介 • VOC分析について • 現在のデータアーキテクチャと取り組みの紹介 • 運用上の課題 3 ・データ基盤の課題を解決するためのモダンデータスタックの取り組み • 新たなデータアーキテクチャ構想 • Airbyte / dbt によるELTパイプライン • Analytics Hubの活用
4. Table of Contents ・VOC分析を支えるデータ基盤の紹介 • VOC分析について • 現在のデータアーキテクチャと取り組みの紹介 • 運用上の課題 4 ・データ基盤の課題を解決するためのモダンデータスタックの取り組み • 新たなデータアーキテクチャ構想 • Airbyte / dbt によるELTパイプライン • Analytics Hubの活用
5. VOC分析について • VOCとは「Voice of Customer」の略 ◦ ご意見やお問い合わせなどユーザーの声を分析することで、サービス品質向上・改善施策などに利用される • DeNAにおけるビジネス上の課題 ◦ カスタマーサポートでは、VOCテキストデータをサービスに活用するためにレポーティング業務を行っているが、 １サービスに対して、数十時間もの作業工数が発生していた状況 ◦ キャンペーンやアップデートなどで反響に比例してデータが増加するため、重要なお客様の声が見えづらくなる • カスタマーサポートとの協力体制の立ち上げ ＆ VOC分析データ利活用プロジェクトを開始 ◦ VOCデータ収集基盤の構築から、Lookerを駆使した分析ダッシュボード提供まで一気通貫して推進 ◦ 定形レポートを自動で作成できるようになり、更にダッシュボードを駆使して重要な声を ピックアップすることでサービス改善に活かせる状態になった 5 ユーザーの生の声 カスタマーサポート VOC分析・サービス改善
6. SNSデータ・ストアレビューデータ収集基盤（マーケティング向け既存） 現在のVOC分析データ基盤のアーキテクチャ 6 ご意見・お問い合わせデータ収集基盤（VOC分析向け新規） CRM (self-hosting) RDB連携 SNSデータ (Streaming) Opinions BigQuery サービス用プロジェクト A Linked Dataset BigQuery Authorized View BigQuery サービス用プロジェクト B Authorized View BigQuery Stream BigQuery Collector Batch Trigger Workflows SNSデータ Inquiries BigQuery SNSデータ ETLツール Appレビュー ETLツール Appレビュー SNS BigQuery Zendesk ETLツール push event Reviews BigQuery Lookerでの ダッシュボード提供 ML Project（自然言語処理） Prediction Vertex AI Pipeline Sentiment Analysis Natural Language API ・・・ Zendesk
7. Lookerによる分析ダッシュボードの提供 • 2019年より、データの民主化・データガバナンスの強化を目的にLooker導入・浸透の活動を行っている ◦ これまでデータ分析といえばデータエンジニア・アナリストが主体だったが、データの民主化を推進しており カスタマーサポートメンバーを含むビジネスユーザーも自発的にダッシュボードを作成できる状態へ • ビジネスニーズに対応した、ご意見・お問い合わせ分析の定形ダッシュボードをLookerで構築 ◦ イベントカレンダーとの連携、ユーザー属性情報の可視化など分析を強化 • 併せて、サービス分析・マーケティングでの活用のためにソーシャルリスニング機能も提供 ◦ Google, Appleといったアプリストア上のレビュー情報の活用 ◦ SNSデータを用いた反響分析などにもカバー 7 例：アプリストア上のレーティング・レビュー情報のポジネガ分析 例：ご意見ダッシュボード
8. データ提供元プロジェクトデータ Lookerの活用 : Remote Dependencyを利用したモデルの共通化 • 利用プロジェクト・サービスごとにGCP環境＆Lookerプロジェクトを準備 • 各プロジェクトに対して新規に定形ダッシュボード・LookML（Lookerで定義するモデル）を準備するのは非効率 → Remote Dependency 機能で共通化されたモデルを配布する方式を採択 8 VOC分析 中央Lookerプロジェクト サービスA Lookerプロジェクト explore: opinions { description: "ご意見データ" } view: opinions { sql_table_name: common.opinions ;; dimension: id { primary_key: yes type: string sql: ${TABLE}.id ;; } } id: 2, service: B, text: … id: 3, service: C, text: … gi t push id: 1, service: A, text: ... explore: opinions { description: "ご意見データ" } view: opinions { ... } Refinement view: +opinions { measure: uu { type: number sql: xxxxxxx ;; } } 必要に応じ、サービス毎で必要な 指標を追加して利用する updat e re m o te _ d e p e n d e n cy サービスA GCPプロジェクト LookML・定形ダッシュボードを モデル化してGitHub:e上で管理 select * from `voc_project.common.opinions` where project = "A" [View] common.opinions LookeMLで定義された 同名のビューを参照 承認済みビューでの参照 サービスAプロジェクトのビューから 参照されることを明示的に承認する [Table] common.opinions
9. 自然言語処理データの提供 • 課題として、ソーシャルリスニングの需要増により取り扱うデータ量に比例して運用コストが膨らみ始めた ◦ 2022年頭からNLP内製化プロジェクトを発足。内製AIモデル開発・Vertex AI Pipelineを用いたMLパイプラインの導入 により運用容易性や精度を落とすことなく、ランニングコストを90%以上削減に成功 10 データ基盤におけるエンジニア主導の低コストな自然言語処理パイプライン構築 | DeNA×AI WORKS • 自然言語処理APIを活用したポジネガ分析・形態素解析による分析ダッシュボードも提供 ◦ サービスに対するSNS上の反響分析や、ご意見・お問い合わせに対する分析・分類などに活用される
10. データ基盤の運用から見えてきた課題 • ETLツールの運用コスト増加 ◦ ツール毎に実行環境・開発言語の差異が発生している ◦ APIの仕様変更やユーザー要望のたびに新規ツール開発や改修が発生 ▪ ETLツールのため、収集・変換・格納のいずれのステップ改修のためにツール全体の改修が発生する ◦ 生のデータが残されていないため、必要なカラムを取得するためにデータ収集からやり直すケースも ▪ データの再取得・テーブル再生成など運用コストの増加につながる • データ品質・データガバナンス上の課題 ◦ 特定期間のデータが欠損している・想定していないデータが含まれている状態 ▪ ユーザー申告で気付くケースが多く、データ品質上の課題が残るまま ◦ 利用プロジェクトの増加に比例して、承認済みビューやLookerでのデータ提供作業が生じる ▪ どこに承認済みビューを設置しているか、利用されているかの管理ができていない 11
11. データ基盤の運用から見えてきた課題 • ETLツールの運用コスト増加 ◦ ツール毎に実行環境・開発言語の差異が発生している ◦ APIの仕様変更やユーザー要望のたびに新規ツール開発や改修が発生 ▪ ETLツールのため、収集・変換・格納のいずれのステップ改修のためにツール全体の改修が発生する ◦ 生のデータが残されていないため、必要なカラムを取得するためにデータ収集からやり直すケースも ▪ データの再取得・テーブル再生成など運用コストの増加につながる • データ品質・データガバナンス上の課題 ◦ 特定期間のデータが欠損している・想定していないデータが含まれている状態 ▪ ユーザー申告で気付くケースが多く、データ品質上の課題が残るまま ◦ 利用プロジェクトの増加に比例して、承認済みビューやLookerでのデータ提供作業が生じる ▪ どこに承認済みビューを設置しているか、利用されているかの管理ができていない 12 • モダンデータスタックの活用：ELTパイプラインの導入・運用保守の簡易化 • モダンデータスタックの活用：データ品質チェックの強化 • Analytics Hubの導入
12. Table of Contents ・VOC分析を支えるデータ基盤の紹介 • VOC分析について • 現在のデータアーキテクチャと取り組みの紹介 • 運用上の課題 13 ・データ基盤の課題を解決するためのモダンデータスタックの取り組み • 新たなデータアーキテクチャ構想 • Airbyte / dbt によるELTパイプライン • Analytics Hubの活用
13. モダンデータスタックの活用 14 • モダンデータスタック（Modern Data Stack）とは ◦ 最近のデータ活用・管理で用いられているサービス・ツール群を総称したもの ◦ バズワードであるため明確な定義は存在しないが、クラウドDWHを中心にしたマネージドサービスが主流 ◦ エンジニアだけでなく、ビジネスユーザーも想定したサービスも多くある Data Integration Workflow Orchestration Data Warehouse Business Intelligence Modelling & Transformation Reverse ETL 各種サービスの データ統合のための ETL・ELTツール ex) Airbyte / Fivetran Event Tracking ニアリアルタイムでの イベント追跡などで利 用されるサービス ex) Firebase データの集中管理サービス 変換前後データの保管から 活用のためのデータ提供 ex) BigQuery / Snowflake データの可視化など でビジネス上の意思 決定を支援する ex) Looker, Tableau DWH上にある 加工・処理済データを各種 Appへ連携するサービス ex) Rudderstack データモデルから適切な形式に 変換するプロセスを提供する ex) dbt / Dataform スケジューリングやトリガー、ステップ・ワークフロー間の依存関係の解決、監視・警告・リトライなど あらゆるプロセスの構成や状態管理などを担うサービス ex) Airflow, Prefect, Dagster
14. Data Integration Project (SNS) Data Integration Project (VOC) モダンデータスタックを取り入れた新データアーキテクチャ構想 15 CRM (self-hosting) RDB連携 dbt SNSデータ Airbyte Raw Data BigQuery Transformed BigQuery Analytics Hub ML Project Appレビュー Data Consumer Project A Data Consumer Project B Linked Dataset BigQuery Predicted Data BigQuery Prediction Vertex AI Pipeline Collector Batch Anonymizing Cloud DLP Processed BigQuery dbt Raw Data BigQuery Transformed BigQuery dbt runner Batch Authorized View BigQuery Other Projects Trigger Workflows Linked Dataset BigQuery Zendesk Zendesk
15. Data Integration Project (SNS) Data Integration Project (VOC) モダンデータスタックを取り入れた新データアーキテクチャ構想 16 CRM (self-hosting) RDB連携 dbt SNSデータ Airbyte Raw Data BigQuery Transformed BigQuery Analytics Hub ML Project Appレビュー Data Consumer Project A Data Consumer Project B Linked Dataset BigQuery Predicted Data BigQuery Prediction Vertex AI Pipeline Collector Batch Anonymizing Cloud DLP Processed BigQuery dbt Raw Data BigQuery Transformed BigQuery dbt runner Batch Authorized View BigQuery Other Projects Trigger Workflows Linked Dataset BigQuery Zendesk Zendesk データ収集ドメイン （データプロバイダー） サービス・ユーザードメイン （データコンシューマー） MLドメイン （データコンシューマー ＆ データプロバイダー）
16. Airbyte & dbt によるELTパイプラインの簡易的実現 • ETLツール中心からELTパイプラインへシフト ◦ どうしてELT？ ▪ あらゆる種類のデータを格納できるクラウドストレージとの相性が非常に良い • GCPでは BigQuery / Cloud Storage が主流 ▪ 収集したデータの仕様変更・スキーマへの柔軟な対応が可能 • すべての生データが保持される状態となるため、変換処理だけに注力できる ▪ ELTパイプラインを実現するためにモダンデータスタックと呼ばれる Airbyte & dbt を導入する方針へ ◦ Airbyte, dbt での検証を進める ▪ いずれもOSS版・SaaS版が存在しており、手元での検証が容易に行えるのが大きい • dbt競合のDataformはGCPマネージドで利用可能だが、現時点ではPreview版なので 検証の候補から除外している 17
17. Airbyte & dbt によるELTパイプラインの簡易的実現 • Airbyteは、Source / Destination と呼ばれるコネクタを組み合わせるだけでデータ抽出パイプラインを構築できるELTに おける Extract と Load に特化したサービス • コネクタはAirbyte社やOSSで開発・管理されており、バージョンアップの仕組みもあるためAPIの仕様変更などに容易 に追従できる ◦ 現在抱えているツール改修などの運用コスト解決に寄与できる可能性が非常に高い • 上記で対応していないコネクタでも独自にPython SDKを用いた実装が可能 ◦ 開発手法・実行環境を統一させ、ツール開発のガバナンスも効かせられる 18 データ取得元(Source)の コネクタ・接続設定 データ保存先(Destination)の コネクタ・接続設定 Source / Destinationを組み合わせるだけで 簡易にELTパイプラインが実現可能 [source] Zendesk Support username : xxxxxxxxxxxxx token: ••••••••• [destination] BigQuery project: xxxxxxxxxxxxxxx dataset: xxxxxxxxxxxxxx token: ••••••••• 事前に接続情報を定義したコネクタを準備 Extract Load / Transform 対象 サービス
18. Airbyte & dbt によるELTパイプラインの簡易的実現 • ELTサービスなので、Source コネクタが取得した生データがすべて保持される ◦ 同時にID・取り込み時刻といったメタデータも保持するため取得履歴管理＆テーブルの差分更新も対応 • BigQueryコネクタ内部には dbt(後述) が組み込まれており、扱いやすい形式への変換まで簡易に実現できる ◦ 生データの格納だけでなく、生データからすぐに取り扱うことができるテーブルへの変換までサポート 19 id subject … 910cf69f-54f1- 4fec-a7ab- 2238e0745f06 AAAAAAAAAAA … 7bd82192-857d- 4600-959e- 3dfg165fd52b BBBBBBBBBBB … c1es97c9-c43b- 4d3e-8g72- 94b614a93ea6 CCCCCCCCCCC … 対象サービス API _airbyte_ab_id _airbyte_emitted_at _airbyte_data 910cf69f-54f1-4fec- a7ab-2238e0745f06 2023-03-01 00:43:39.763000 UTC {"subject":"AAAAAAAAAAA", … } 7bd82192-857d-4600- 959e-3dfg165fd52b 2023-03-01 00:43:26.229000 UTC {"subject":"BBBBBBBBBBB", … } c1es97c9-c43b-4d3e- 8g72-94b614a93ea6 2023-01-19 00:43:42.210000 UTC {"subject":"CCCCCCCCCCC", … } Extract / Load APIから取得した生データを BigQuery上に格納 Transform 生データを簡易に扱える形式の テーブルへ変換して格納(dbtが担う)
19. • dbt は ELT の Transform に特化したサービス ◦ データ変換のためのモデルをSQLで定義できるため、既存の集計パイプラインからの移植性が高い ◦ 参照するテーブルをref関数で定義することで、dbtが依存関係を解釈 ▪ クエリ実行順序の担保だけでなく、データリネージュの生成もサポート • データ品質チェック機能が利用できる ◦ 指定のカラムに対するテストの実施 (dbt test) ◦ Airbyteなどで準備したソースデータに対する更新状態(鮮度)の監視 (dbt source freshness) ▪ YAMLで定義するだけで簡単に導入可能 ⇒ データ品質管理に注力できるメリット • 従来は個別にチェック用SQLを準備し、 追加でワークフローの準備の必要があった Airbyte & dbt によるELTパイプラインの簡易的実現 20 select * from {{ ref('customers') }} union all select * from {{ ref('products') }} models/orders.sql customers products orders dbt source generate models: - name: orders columns: - name: order_id tests: - unique - not_null - name: status tests: - accepted_values: values: ['placed', 'shipped',... ] カラム `order_id` に対する テストケースの指定 カラム `status` 内に 含まれる値のチェック
20. ELTパイプラインでの懸念点と対策 • VOCデータは個人情報を含む場合が多く、データの取り扱いをETLより強く意識する必要がある ◦ ETLではツール内で不要データを drop するが、ELTでは生データを格納するため個人情報の保持が発生しうる ▪ ガイドライン・プライバシーポリシーに沿った適切なデータの格納・処理プロセスを整備する必要がある ▪ 生データに対する匿名加工処理の必要性も生じる可能性があるため、事前のパイプライン設計が重要 ◦ 意図せず個人情報を共有しないよう、dbt でのデータ変換に加えてCloud DLPを活用したリスク検出も準備する ▪ 自由投稿文上に個人情報・関連情報が入力されているケースもある ◦ 個人情報に関わるデータを扱う必要が生じる場合、ポリシータグを用いて動的にデータマスキングを設定すること ▪ GCPプロジェクトレベルではLoggingによるセキュリティアラートを設置している 21 Data Integration Project for VOC Analysis dbt Airbyte Raw Data BigQuery Transformed BigQuery Anonymizing Cloud DLP Processed BigQuery https://cloud.google.com/bigquery/docs/column-data-masking-intro Cloud Data Loss Prevention 機密性の高いデータの検出・分類・保護を 行うためのGCPのフルマネージドサービス
21. Analytics Hubの活用 • 組織・プロジェクト間で効率的にBigQueryデータセットを共有するためのデータシェアリングサービス ◦ 組織内や会社間でのデータ共有や、企業発のオープンデータの一般公開などに適用するサービス • Analytics Hubの機能紹介 ◦ データ提供側（データプロバイダー）= パブリッシャー ▪ 公開したいBigQueryデータセットをAnalytics Hub上のデータ交換 (エクスチェンジ) 上へ登録する ◦ データ利用側（データコンシューマー）= サブスクライバー ▪ Analytics Hub上で 共有されたデータセット (リスティング) を検索して購読をする ▪ Linked Datasets と呼ばれるデータセットのシンボリックリンクがプロジェクト上に生成され、 読み取り専用のデータセットとして任意にクエリが可能 22 Analytics Hub | データ交換とデータ共有 | Google Cloud データアーキテクチャ構想上でもAnalytics Hubを経由したデータ交換に
22. Analytics Hub活用のメリット • データガバナンスをより効かせられる ◦ Analytics Hubを利用したデータ購読を基本方針へ整備 ▪ VOC分析データ基盤に限らず、今後様々なドメインで活用を広げていく ◦ セキュリティの担保も可能 ▪ 承認済みビューと同様に、利用者のIAMユーザーを中央プロジェクトに権限付与する必要がない ▪ エクスチェンジに対する権限設定が出来るため、不必要なデータ購読設定を抑制できる ▪ データ購読状況を一元的に管理・可視化できる • 運用・コスト面の効率化 ◦ データ提供のプロセスを簡略化 ▪ 承認済みビューでは、Viewを作成したあとに提供側の承認ステップの手間が生じる ▪ Analytics Hubでは利用者環境上でリスティングを検索・購読するだけで利用可能 ◦ 従来のビュー提供と変わらないコスト体系 ▪ 利用者はクエリコストだけ負担し、ストレージコストは不要のまま ▪ Analytics Hubは無料で利用可能 23 VOC分析用のデータプロバイダーとして複数プロジェクトへデータ提供を行うため、 Analytics Hubとの相性が非常に高いと判断し、積極的に導入を進めている
23. まとめ 24 • VOC分析のデータ基盤はあらゆるサービス・プロダクトに関わっている ◦ サービスごとにデータ提供しており、Lookerプロジェクトが存在する ▪ ビジネスユーザーも自発的に活用しており、データの民主化が進んでいる ◦ 運用効率化のため、Lookerモデルとデータ共有は中央的に管理している ▪ 今後はAnalytics Hubを駆使してよりガバナンスを効かせていく • 独自ツールからモダンデータスタックへシフトし運用コストを抑制させる ◦ モダンデータスタックを活用した新アーキテクチャ化の検証・導入に挑戦中 ▪ AirbyteによるELTパイプラインの簡易化 ▪ dbt を活用したデータ品質管理 ◦ ただし、個人情報・関連情報の取り扱いをより意識する必要がある