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

Google Cloud を使ったデータプラットフォームへの変革と 最新の活用状況について

Google Cloud を使ったデータプラットフォームへの変革と 最新の活用状況について

2020-03-31 の

2020/03/31 に開催された「Google Cloud Data Platform Day #2」での

・システム本部分析推進部データプラットフォームグループ 長谷川 了示
・ゲーム・エンターテインメント事業本部ゲーム事業部 Publish 統括部 分析部 データエンジニアリンググループ 城谷 信一郎

の登壇資料です。

DeNA_Tech

March 15, 2023
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. Google Cloud を使ったデータプラットフォームへの変革と
    最新の活用状況について
    株式会社ディー・エヌ・エー
    長谷川 了示
    システム本部分析推進部データプラットフォームグループ
    城谷 信一郎
    ゲーム・エンターテインメント事業本部ゲーム事業部 Publish 統括部 分析部
    データエンジニアリンググループ

    View Slide

  2. 長谷川 了示(Ryoji Hasegawa)
    ● 新卒 -> ITコンサルティング
    ● 製品開発@分析系SaaS ベンダ
    ● 2016年9月 DeNA 入社
    ○ 全社データプラットフォームの企画・構築・運用
    ○ 今回のテーマであるデータプラットフォーム刷新を立
    ち上げからリード
    2
    Speakers

    View Slide

  3. 3
    本日お話する内容
    1
    2
    データ プラットフォームの刷新 なぜGoogle Cloud を選んだのか?
    新データ プラットフォームの全貌 設計思想と実装
    3
    4 Google Cloud をフル活用した事例
    新データ プラットフォームへ効率の良い移行方法

    View Slide

  4. Section 1
    データ プラットフォームの刷新
    なぜGoogle Cloud を選んだのか?

    View Slide

  5. このSection でお話すること
    5
    ● 旧データ プラットフォームとその課題
    ● データ プラットフォーム刷新プロジェクト「ポリモフ」
    ● なぜGoogle Cloud を選んだのか?

    View Slide

  6. DeNA On-Premises
    • 怪盗ロワイヤルに代表されるモバイルゲームの大ヒットを背景に、大規模データプラット
    フォームを整備
    • 2010年から、Hadoop の運用を開始。
    • ちなみに ”Hadoop: The Definitive Guide” (象本)の初版出版が2009年
    • 現在の総データ量: 2.5PB+
    • 大部分はオンプレミス( 2015年頃からBigQuery を利用)
    6
    旧データ プラットフォームの全体像
    Service Env Data Platform
    Service A
    Hadoop
    Argus
    Batch Server
    BigQuery
    App Server
    DB Server
    app logs
    snapshot
    Jenkins
    Hue
    batch job management
    Service B
    Service C

    View Slide

  7. 7
    旧データ プラットフォームの特徴
    ● 多種多様な利用者
    ● 高いレベルの自由度
    ● マルチテナント

    View Slide

  8. DeNA グループ全社員の4割強
    旧データ プラットフォームの特徴: 多種多様な利用者
    8
    ゲーム以外の
    サービス
    5 +
    ゲームタイトル
    15 +
    BIツールの
    Monthly Active
    User
    1,000 -
    アナリスト(データ分析担当者)から企画、経営層まで幅広い利用者

    View Slide

  9. • SQL クエリ作成
    • レポート作成
    Argus (内製BI ツール)
    Jenkins
    Batch Server
    • 集計・分析スクリプト作成
    • アドホック分析
    • ssh でログインして作業
    • バッチジョブ設定
    • エラー対応
    アナリスト等一部の利用者は、GUI を使った分析・レポーティングだけでなく、バッチジョブ管理や、バッチサーバへ
    ssh でログインした上でのスクリプト作成まで行っている
    利用者が行う作業
    旧データ プラットフォームの特徴: 高いレベルの自由度
    9

    View Slide

  10. 同一のクラスタ、サーバを様々なサービスの分析で共用
    ● 初期の分析対象はMobage とMobage 上のゲーム
    ○ 全員が全てのデータにアクセスできる環境であった
    ● 事業の多様化に伴い、サービス毎の権限管理を導入
    旧データ プラットフォームの特徴: マルチテナント
    Hadoop Cluster
    Service B
    のログ
    Service C
    のログ
    Vertica Cluster
    Service A
    のデータ
    Service B
    のデータ
    Service C
    のデータ
    Service A
    のログ
    10
    Batch Server
    Service A
    のアナリスト
    Service B
    のアナリスト
    Service C
    のアナリスト

    … …

    View Slide

  11. 10年の歳月を経てさまざまな課題が顕在化してきた
    中でもDeNA 固有の課題は「モノリス化」であると考えている
    旧データ プラットフォームの課題: モノリス
    11
    様々な事業・利用者が一つの環境に同
    居し、システムリソースを共有
    ● 特定の事業に合わせた環境の カスタマイズ
    が難しい
    ● 影響範囲が広く計画停止するのも一苦労、 ス
    ピーディーな改善が難しい
    ● ただでさえコンポーネントが多く複雑な
    システムが、権限管理等の要件により
    更に複雑化
    On-Premises
    Service A
    Service B
    Service C


    Service A
    Service B
    Service C

    View Slide

  12. 課題の背景: 進化・多様化する分析ニーズ
    12
    新しい技術・ツールへのニーズの盛り上がり
    • Twitter でソーシャル リスニングを行うために、最新のクライアントライ
    ブラリを使いたい
    • 予測モデルを開発するために Jupyter Notebook と最新のpythonライ
    ブラリを使いたい
    • ディープ ラーニングを活用したいのでGPU マシンが必要
    etc...
    ただし、技術要件は事業/案件毎に異なる
    ● 目的に応じて最適な技術を取り入れたい!
    しかしモノリスでは機敏かつ柔軟に対応できない...

    View Slide

  13. モノリス化を解決するために、データプラットフォームの刷新プロジェクト
    「polymorph(ポリモフ)」を2018年に始動。
    polymorph: 多形
    1. 化学の用語で、同じ組成の化学物質に、多くの結晶形が存在すること。
    2. 生物学の用語で、同じ種の生物に、多くの形態、形質の個体が存在す
    ること。
    2020年度中にはポリモフへの移行を完了する予定。
    データプラットフォームの刷新: モノリスからポリモフへ
    13

    View Slide

  14. • サービス毎に環境分離
    • ワークロード毎にリソース分離
    これらを実現するためにはパブリッククラ
    ウドへの移行が必要であった
    オンプレの仕組みをクラウド上に再現す
    るのではなく、ゼロベースで再設計
    -> Section 2 にて詳細に解説
    ポリモフの設計方針
    14
    On-Premises
    Service A
    Service B
    Service C


    Service A
    Service B
    Service C
    … …
    Service A
    Service B
    Service C

    View Slide

  15. BigQuery は2015年頃から実戦投入し、既存の分散DB 製品に対
    する優位性を確認できていた
    コスト
    • 既存製品より桁一つ安い
    スケーラビリティ
    • 既存製品は独自ノウハウが必要
    • BigQuery は Google が スケーラビリティを 担保
    チューニングフリー
    • DeNA は利用者が幅広く、かつ、自由度が高いため、チューニ
    ングの徹底が困難
    • BigQuery は 特別なチューニングなしで一定の性能を発揮
    Google Cloud を選んだ理由: BigQuery
    15

    View Slide

  16. • BigQuery と他のコンポーネントとの連携が容易
    • アカウント・権限の一元管理が可能
    • コストの一元把握が可能
    • システム間連携の認証鍵(サービスアカウントの鍵)を自前
    で管理する必要がなくセキュア
    • クラウドでは鍵の漏洩が即、情報漏洩につながる場合があ
    る!
    BigQuery を使うなら、全てGoogle Cloud に寄せるのが吉
    16

    View Slide

  17. このSection のまとめ
    ● 早い時期からHadoop 等の技術を取り入れ、大規模データを分析できる環境を
    築いていたが、徐々に「モノリス化」していった
    ● モノリス化の課題を解決するために、データ プラットフォーム刷新プロジェクト「

    リモフ」を始動した
    ● Google Cloud を選んだ決めてはBigQuery がDeNA のユースケースに最適で
    あったため
    17

    View Slide

  18. Section 2
    新データ プラットフォーム「ポリモフ」
    設計思想と実装

    View Slide

  19. このSection でお話すること
    19
    ● ポリモフの全体構成
    ● ポリモフの設計方針: サービス毎に環境分離
    ● ポリモフの設計方針: ワークロード毎にリソース分離

    View Slide

  20. • サービス毎に環境分離
    • ワークロード毎にリソース分離
    ポリモフの設計方針(再掲)
    20

    View Slide

  21. BI Tools
    ポリモフの全体構成
    21
    Service A
    Service Env
    App Server
    DB Server
    Data Platform
    Service A
    BigQuery
    Cloud
    Storage
    GKE
    digdag batch
    web
    app
    Argus
    app logs
    snapshot
    Service B
    Service C
    Service B
    Service C
    ・・・
    ・・・
    サービス毎に環境分離
    ワークロード毎にリ
    ソース分離

    View Slide

  22. 分析対象サービス毎に異なる Google Cloud プロジェクトを利用している
    コスト管理上のメリット
    ● プロジェクト別に請求が来る
    ● BigQuery にエクスポートして分析可能
    ● 「どのサービスで何にいくら使ったか 」が明
    確に
    ポリモフの設計方針: サービス毎に環境分離
    権限管理上のメリット
    ● 権限管理(IAM)が
    プロジェクト毎 = サービス毎
    に明確に分離される
    ● 誤って不要な権限を付けてしまう リス
    クが低い
    22

    Service A
    Service B
    Service C

    View Slide

  23. バッチ処理やWeb アプリをそれぞれ別のコンテナとして
    GKE (Google Kubernetes Engine) 上で稼働させている
    ポリモフの設計方針: ワークロード毎にリソース分離
    23
    GKE
    web app
    batch
    digdag

    View Slide

  24. • 事業、案件毎に特化した可視化ツール等
    • SQL では書けない処理を python 等、好きな言語で記述
    • 大きなリソースを必要とする処理
    • digdag から実行
    GKE 上で稼働させているワークロード
    • バッチジョブの管理
    • 集計SQL の実行
    • batch ワークロードの実行
    24
    batch, web app のコンテナは、利用者側で作成・実行
    利用者側のカスタマイズの影響をコンテナ内に閉じ込めることで、高い自由
    度を与えつつ、環境を管理可能に保つことができる
    digdag
    web app
    batch

    View Slide

  25. • digdag (それ自体がGKE上で稼働している)が kubernetes のAPIを呼
    び出し、batch ワークロードをGKE 上に deploy する
    • digdag で処理の流れ制御しつつ、実際の処理は個別のコンテナ上で
    実行させることが可能
    batch ワークロードは digdag から実行している
    25
    GKE
    batch
    digdag
    apiVersion: batch/v1
    kind: Job
    metadata:
    name: some-job
    ...
    kube-
    apiserver
    kubectl apply create

    View Slide

  26. • Cloud IAP で社内 G Suite アカウントによる認証を設定
    個別のアプリで認証機能を実装する必要がない
    • Cloud Armor で社外からのアクセスをシャットアウト
    web app は Cloud IAP、 Cloud Armor でセキュアに
    26
    Cloud Load
    Balancing
    DeNA office
    Cloud Armor
    Identity-Aware
    Proxy
    GKE
    接続元アドレス制限 ユーザ認証
    Google Cloud の機能を活用することで、社内システムをセキュアかつ手軽
    に構築
    web app

    View Slide

  27. GKE
    Node Pool with High Memory
    「このbatch ではGPU を使いたい」
    様々なリソース要求
    GKE の仕組みを活用し様々なリソース要求に効率的に対応
    27
    Node Pool with GPU
    「このweb app は大きめのメモリが必要」 …

    ・・・
    ● ノードプール(同じ構成のノード群)を複数種類用意
    ● オートスケールにより、必要な時に必要なノードが自動で起動

    View Slide

  28. このSection のまとめ
    28
    ● 分析対象のサービス毎に Google Cloud プロジェクトを分離することで、権限とコ
    ストを明確に管理できる
    ● コンテナ技術を活用し、ワークロード毎にリソースを分離することで、利用者の

    由度を高めつつ、環境を管理可能に保つ
    ことができる
    ● Google Cloud の機能を活用することで、更に手軽かつセキュアに様々な要求に
    応えることができる

    View Slide

  29. 城谷 信一郎(Shinichiro Joya)
    ● 2019年9月 DeNA 入社
    ● ゲーム事業のデータエンジニアとして従事
    ○ パイプライン開発
    ○ クラウド移行
    ○ データ プラットフォームの最適化
    29
    Speakers

    View Slide

  30. Section 3
    新データ プラットフォームへ
    効率の良い移行方法

    View Slide

  31. ● Google Cloud へ移行する際に求められたこと
    ● 求めに対し、どういう工夫をして移行を実施しているか
    このSection でお話すること
    31

    View Slide

  32. 32
    本題に入る前に分析環境の
    クラウド移行をおさらい

    View Slide

  33. ゲーム以外の
    サービス
    5 +
    33
    DeNA で移行が必要なサービス
    ゲームタイトル
    15 +
    移行候補テーブル数
    5000+

    View Slide

  34. 34
    周辺も同時に移行が必要
    データ
    保管
    データ
    収集
    データ
    分析
    データ
    加工
    内製開発
    内製開発
    Hadoop Vertica
    Cloud
    Storage
    BigQuery
    jenkins
    Embulk
    vSQL,Java,
    Pig,etc
    digdag
    BQ SQL,Ruby,
    Python,etc
    Argus
    Argus
    Looker

    View Slide

  35. 35
    Google Cloud へ移行する際に求められたこと
    1. 移行前と移行後のデータの差分を最小限にする
    • 環境の違うデータを比較するには?
    2. 移行を効率化する仕組みを提供する
    • アナリストが自ら移行できる仕掛けとは?

    View Slide

  36. 36
    BigQuery を使ったデータの差分確認環境
    サービス環境 オンプレ環境 Google Cloud Platform
    Cloud
    Storage
    Service B
    LOG
    DB
    Service A
    LOG
    DB
    ...
    現データ
    収集機能
    新データ
    収集機能
    Hadoop
    Vertica
    BigQuery
    RAW Data
    Mart
    RAW
    Data
    Mart

    View Slide

  37. 37
    差分確認はSQL で実施
    WITH
    table1 as (
    SELECT col1, col2, col3 FROM foo.bar1
    ),
    table2 as (
    SELECT col1, col2, col3 FROM foo.bar2
    ),
    except_table as (
    SELECT “comp_dist”, * FROM (SELECT * FROM table1 EXCEPT
    DISTINCT SELECT * FROM table2)
    UNION ALL
    SELECT “comp_source”,* FROM (SELECT * FROM table2 EXCEPT
    DISTINCT SELECT * FROM table1)
    )
    SELECT * FROM except_table
    差分が一目瞭然
    オンプレテーブル
    クラウドテーブル

    View Slide

  38. 38
    自動化することで差分確認の効率を上げる
    アナリスト
    BigQuery
    オンプレ
    テーブル
    クラウド
    テーブル
    オンプレ
    テーブル
    クラウド
    テーブル
    対象TBL (TSV)
    対象TBL を更新
    git push & merge
    自動Deploy
    対象TBL のSchema を取得し、
    差分確認用SQL を動的生成
    bq show --schema --format=prettyjson \
    ${project_id}:${dataset}.${table}
    日次で差分確認を
    自動で実施
    差分発生時にAlert
    確認対象が増えた時の
    対応はコレだけ

    View Slide

  39. 39
    実際にあった差分
    オンプレ 2019-10-24 10:31:44※実態はJST
    クラウド 2019-10-24 10:31:44 UTC
    ● データソースのTimestamp にtime zone の
    指定が無いためBigQuery 側がUTC を付与
    データにtime zone を明記させる
    or
    String 型で取り込む

    View Slide

  40. 40
    BigQuery を使ったデータの差分確認環境
    サービス環境 オンプレ環境 Google Cloud Platform
    Cloud
    Storage
    Service B
    LOG
    DB
    Service A
    LOG
    DB
    ...
    現データ
    収集機能
    新データ
    収集機能
    Hadoop
    Vertica
    BigQuery
    RAW Data
    Mart
    RAW
    Data
    Mart

    BulkLoad を
    どう実現する?

    View Slide

  41. 41
    Medjed という内製のツールでデータの取り込みを支援
    Medjed の設定画面
    Google Sheets
    Web 操作し、スケジュール、
    トリガーを設定
    Google Sheets の
    URLを登録
    取り込みたい
    テーブル、スキーマを
    入力
    アナリスト

    View Slide

  42. 42
    オンプレ / クラウドからのデータ取り込みを効率化
    データ
    収集機能
    Cloud
    Storage
    Table A
    Table B
    BigQuery
    現データ
    収集機能
    Table A
    Table B
    Table C
    Table A
    Table B
    Table C
    Table A
    Table B
    BigQuery
    Table C
    Table C
    Medjed
    Hadoop
    Vertica
    アナリスト

    View Slide

  43. 43
    データ取り込みを支援するCloud Data Fusion
    https://cloud.google.com/data-fusion/plugins

    View Slide

  44. このSection のまとめ
    44
    大規模なクラウド移行を実現するために
    1. 移行前と移行後のデータの差分を最小限にする
    ● オンプレデータもBigQuery に取り込み
    差分を効率良く確認出来る状態に
    2. 移行を効率化する仕組みを提供する
    ● 差分の確認を自動化することで効率化
    ● データの取り込みツールを利用者にて提供する事で効率化

    View Slide

  45. Section 4
    Google Cloud をフル活用した
    データ プラットフォームの使い方

    View Slide

  46. ● Google Cloud Platform をフルに活用した事例の紹介
    a. SNS データを使った取り組み
    b. Cloud AutoML を使ったデジタルマーケティング施策
    このSection でお話すること
    46

    View Slide

  47. ● Google Cloud Platform をフルに活用した事例の紹介
    a. SNS データを使った取り組み
    b. Cloud AutoML を使ったデジタルマーケティング施策
    47

    View Slide

  48. 48
    DeNA のSNS データを使ったコミュニティーとの関わり
    SNS データを活用した施策の検討
    ● 施策検討
    ● コンテンツ提供
    ● 外部発信
    ユーザ
    ● サービスに
    対する投稿

    View Slide

  49. 膨大なTweet に対して分析は相応の時間を要していた
    49
    SNS データからの高い分類・分析コスト
    …....
    ….....
    …....
    …...
    ......
    ......
    ユーザはどう反応
    しているのか...






    Tweet の件数が多すぎて
    収集に時間が掛かる...

    View Slide

  50. 50
    Twitter データとNLP API によるユーザの分析
    Tweetデータ
    BigQuery
    Cloud
    Storage
    Cloud Natural
    Language API
    感情分析データ
    BigQuery
    Tweetラベリングデータ
    BigQuery
    Twitter
    API
    analytics
    Container
    Twitter
    Crawler
    Container
    digdag
    Container
    WorkFlow
    50

    View Slide

  51. 51
    Looker を使いダッシュボードで可視化
    ● NLP API を導入することでこれまで人間の目で
    判断していたTweet の内容を機械学習の力で効率化

    View Slide

  52. 52
    Looker を使いダッシュボードで可視化
    ポジティブなTweet の
    部分をクリック!
    具体的なTweet にドリルダウン

    View Slide

  53. 53
    効果と今後について
    1. 定性的なデータの定量化・可視化が可能に
    • 自動化によりデータ収集、分析を効率化
    • バイアスを排除した分析が可能に
    2. 今後はデータの種類と取得先を増やしていく
    • Twitter 以外のSNS データを取得
    • Twitter データを活かしたより高度な分析

    View Slide

  54. ● Google Cloud Platform をフルに活用した事例の紹介
    a. SNS データを使った取り組み
    b. Cloud AutoML を使ったデジタルマーケティング施策
    54

    View Slide

  55. LTV の高い事が予想されるユーザに対してゲーム復帰を促す広告施策
    55
    デジタル マーケティング施策について
    log
    DB
    学習/予測
    Model
    広告 再びゲームに
    戻ってもらう
    広告識別子
    高LTV予想
    ユーザ
    LTV:顧客生涯価値(Life Time Value)

    View Slide

  56. LTV の高い事が予想されるユーザに対してゲーム復帰を促す広告施策
    56
    POCの結果 特定のゲームタイトルで効果が出た
    log
    DB
    学習/予測
    Model
    広告 再びゲームに
    戻ってもらう
    広告識別子
    高LTV予想
    ユーザ
    LTV:顧客生涯価値(Life Time Value)
    ・実際の平均LTV の上昇

    View Slide

  57. タイトルA
    57
    システム化し横展開する上での課題



    タイトルB
    タイトルC
    ● 少人数で複数タイトルのパイプラインを開発・維持
    ● 機械学習の学習モデルのメンテナンス、パラメータチューニ
    ングの問題
    ● 広告識別子(IDFA)を扱うのでセキュアに提供する必要

    View Slide

  58. 58
    AutoMLを使った学習・予測基盤の構築
    Source Data
    BigQuery
    LTV学習用テーブル
    BigQuery
    LTV予測モデル
    AutoML Tables
    Kubernetes Engine
    digdag
    Container
    Python
    Container
    JupyterLab
    Container
    復帰学習用テーブル
    BigQuery
    復帰予測モデル
    AutoML Tables
    広告配信マスタ
    BigQuery External
    Table
    Input Data Train Data Training
    bq operator
    AutoMLAPI で学習の実行
    学習パイプライン
    モデル精度監視
    Stackdriver
    コンテナレジストリ
    Container Registry
    実行時にコンテナ起動

    View Slide

  59. 59
    AutoMLを使った学習・予測基盤の構築
    Source Data
    BigQuery
    LTV予測用テーブル
    BigQuery
    LTV予測モデル
    AutoML Tables
    Kubernetes Engine
    digdag
    Container
    Python
    Container
    JupyterLab
    Container
    復帰予測用テーブル
    BigQuery
    復帰予測モデル
    AutoML Tables
    Input Data Prediction Data Prediction
    bq operator
    予測パイプライン
    予測結果(IDFA+予測値)
    BigQuery
    Output Data
    コンテナレジストリ
    Container Registry
    予測結果への
    アクセス
    Authentication
    実行時にコンテナ起動
    AutoMLAPI で予測の実行
    デジマ担当者

    View Slide

  60. 60
    現在開発中だが期待出来る効果として
    1. 開発・メンテナンスの効率向上
    • BigQuery , digdag など学習コストを抑える仕組み
    • Cloud AutoML 側に任せる事でモデル開発・メンテの難易度が低下
    • GKE 上の JupyterLab から広告識別子を取得するためセキュアに
    2. ML Ops の礎として複数用途に展開可能
    • 多用途、多サービス展開が可能なプラットフォームへ

    View Slide

  61. このSection のまとめ
    61
    ● Google Cloud Platform をフルに活用した事例の紹介
    ○ NL API やAuto ML などサーバレスの機械学習サービスを利用
    ■ より高度なデータ活用を実現
    ○ WorkFlow, 実行環境は使い慣れたサービスを利用
    ■ 低い学習コストで効率の良い開発

    View Slide

  62. まとめ

    View Slide

  63. 63
    本日話した内容
    1
    2
    3
    4
    多様化したニーズに対して、 モノリス化したオンプレが足枷 に
    適切な分離性を持つ 事で、自由で統制の取れたプラットフォームに
    BigQuery のフル活用と内製の仕組みを組み合わせ 、効率良く移行
    GCP のサービスを組み合わせ 、自由で高度なデータ活用
    データプラットフォームの刷新 なぜGoogle Cloud を選んだのか?
    新データ プラットフォーム「ポリモフ」 設計思想と実装
    Google Cloud をフル活用した事例
    新データプラットフォームへ効率の良い移行方法
    Google Cloud を中心としたプラットフォームで課題の解決を図る

    View Slide

  64. • BigQuery の利用におけるコスト最適化戦略
    • Google Cloud Next '19 in Tokyo で発表済み(2019/08/01)
    • BigQuery を使い倒せ!DeNA データエンジニアの取り組み事例
    • https://cloud.withgoogle.com/next/19/tokyo/sessions?session=D2-2-S09
    • DeNA データ プラットフォームにおける運用の詳細
    • DeNa TechCon 2020でオンライン配信
    • DeNA データ プラットフォームにおける自由と統制のバランス
    • https://www.youtube.com/watch?v=S3jUEl9pEmM (1:49:55 〜)
    • DeNA が Looker を採用した経緯
    • Looker Game Night で発表予定(時期未定)
    • https://discover.looker.com/Q1Y2020JPNGameEvent.html
    64
    本日話さなかった内容

    View Slide

  65. 65
    今後Google Cloud に期待すること
    ● 安全安心なデータ プラットフォームの提供に期待
    ○ データガバナンス :データカタログ、データリネージ
    ○ セキュリティ :ゼロトラスト、PII データの検知・削除
    ● Google の他サービスとの心地よい連携に期待

    View Slide

  66. 本日話しきれなかった内容/質問への回答は後日Mediam に投稿予定
    DeNA Analytics Blog
    66

    View Slide