Google Cloud を使ったデータプラットフォームへの変革と最新の活用状況について [Google Cloud Data Platform Day #2 フォローアップ記事]

Shinichiro Joya

Published in

DeNAデータ分析ブログ

31 min readSep 16, 2020

Google DataPlatform Day #2 の配信をご覧いただき誠にありがとうございました。

大分お時間が経ってしまいましたが、この記事では、登壇で頂いた質問やコメントに対するフォローアップ記事となります。

はじめに

こんにちは！DeNAデータエンジニアの Ryoji Hasegawa＆ Shinichiro Joyaです！

改めまして、 Google DataPlatform Day #2 の配信をご覧頂き、ありがとうございました。配信では、時間の都合上、すべてのご質問にお答え出来なかったこともありましたので、改めてお伝えさせて頂きます。同様のテーマで課題があったり、検討している方に役立てて頂ければ幸いです。

まだご覧になられていない方でご興味がある方は、是非ご覧ください。

本題

早速、本題に入らせていただきます。

本記事では、登壇時にご質問頂いた内容や、 Twitter の内容から以下のアジェンダでお送りさせて頂きます。

ワークフローエンジンとしてなぜ digdag を選定したか。その選定理由と使い方
次世代 BI ツールの Looker をなぜ選定したか
その他、当日ご質問頂いた内容への回答

digdag の選定理由および DeNA での使い方

登壇の中で、Google Cloud へ移行するにあたってワークフローエンジンとして、 digdag を選定し Google Kubernetes Engine（以降GKE) 上で稼働させていると説明しました。

有名な OSS である digdag ですが、なぜ DeNA で選定したのでしょうか。

また、 Google Cloud には、 Apache Airflow がデプロイされたマネージド・サービスである Cloud Composer が存在します。なぜ、そちらを選定しなかったのでしょうか。選定に至っては技術的／組織的な理由がありました。

保守性と習熟コストの両立
ワークフローエンジンを維持するためのコスト
カスタマイズ性

これらについて１つずつ詳細を深堀りしましょう。

保守性と習熟コストの両立

DeNAの中核事業であるゲーム事業においては、ゲームタイトル毎にデータパイプラインを開発しています。そのデータパイプラインは、事業運営においてKGI/KPIの提供や、データから導かられる示唆の提示など、重要な意思決定に利用されています。

しかし、ゲームタイトルやサービス毎にデータエンジニアをアサインできる程、人材や工数に余裕が無いため、運用の中で以下の様に事業側の状況に応じてサポートにグラデーションを効かせる形を取っています。

上記図にもある通り、アナリスト・データサイエンティストの工数が多く取れるサービスを中心に欲しいデータを中間の集計も含めて、実装いただく事で意思決定のスピードを高める狙いがあります。そのために、ワークフローを実装時に関わる学習コストを低くする必要がありました。[1]

digdag のワークフローは、YAML ( dig ファイル）にて、宣言的に依存関係を持ったワークフローを作る事が出来ます。YAMLで定義出来ることから、SQLのファイルと同じGitHubリポジトリでワークフロー定義を管理出来、保守性の向上に役立ちます。

timezone: "Asia/Tokyo"schedule:
  daily>: 10:00:00_export:
  date: ${moment(session_time).format("YYYYMMDD")}+workflow_1:
  _export:
    bq:
      dataset: dataset_A
    gcs_bucket: 'bucket-foo-bar'
    targes: [
      'table1',
      'table2',
      'table3'
    ]
  for_each>:
    targe: ${targes}
  _do:
    +gcs_wait:
      gcs_wait>: gs://${gcs_bucket}/${target}/${date}/_SUCCESS+bq_load:
      bq_load>: gs://${gcs_bucket}/${target}/${date}/*.tsv.gz
      destination_table: ${target}$${date}
      write_disposition: WRITE_TRUNCATE
      source_format: csv
      field_delimiter: "\\t"
      skip_leading_rows: 1+workflow_2:
  _export:
    table: 'foo_bar_table'
      
  +bq_query:
    bq>: ./update_${table}.sql
    dataset: dataset_B
    destination_table: ${table}$${date}
    write_disposition: WRITE_TRUNCATE

上記は、Google Cloud Storage（以降GCS) にアップロードされたファイルを JST10:00に BigQuery（以降BQ)に取り込み、その後 SQLによって加工するまでをイメージしたサンプルの dig ファイルです。この様に、変数などを上手く組み合わせる事で、ワークフローの水準を保ちつつも集計に関わるワークフローの開発スピードを高めています。

この習熟コストについては、 Cloud Composer も同様の事が言えるかと思います。Cloud Composer は Python を利用して宣言的にワークフローを記載する事が可能です。さらには、github による変更管理も可能です。どちらも、習熟コストを抑えつつ、構成管理が可能な手段ですが DeNA でdigdag を選定した理由としては、次に紹介するコストが大きく絡みます。

ワークフローエンジンを維持するためのコスト

DeNAがオンプレのデータプラットフォームから Google Cloud へ移行するあたって大きく構成が変わった点の一つに、バッチやワークフローの実行環境を中央集約のスタイルから、サービス・ゲームタイトル毎に Google Cloudのプロジェクトを作成し、プロジェクト毎にワークフロー実行環境を分散するという物でした。

これらの話は、 DeNA Techconでより詳細な検討が決まるまでの流れを説明しています。ご興味がある方はご覧ください。

https://engineer.dena.com/posts/2020.03/techcon_2020_live/

分散型で、環境を開発することでサービスやゲームタイトル毎に疎結合となり、他方の変更による影響が少なくなる事で、より柔軟かつ自由度の高い構成になった一方で、管理する環境自体は非常に多くなってしまいました。インフラの構成管理およびプロビジョニングは Terraform を使う事で、自動化を図っていましたが、コストに関してはサービス・ゲームタイトルが増える毎に用意する必要があるため、ワークフローの実行環境を維持するコストも考えなければなりませんでした。

上記比較表は、digdag と Cloud Composer で GKE の最小構成で動作させた場合のランニングコストを表したものです。digdag 環境も Cloud IAP 、 Cloud SQLを利用していますが、そこにはコスト差が無いため GKE のみの比較となっています。勿論、処理によってはワーカーノードはスケールするため、実際の費用は上記比較より高くなる場合があります。 Cloud Cloud Composer はマネージドでワークフロー環境を利用できるメリットがありますが、ワーカーノードが最低３つ。つまり、最低３つの GCE インスタンスを起動する必要があります。前述の通り、 DeNA のデータプラットフォームではサービス毎に分析環境を分離するアーキテクチャから考えると、1環境あたりの月額コスト差が140$ は大きなコストメリットが発生します。そのため、 GKE を保守するコストは掛かりますが、digdag によるワークフロー提供の方が有利であると判断しました。[2]

カスタマイズ性

マネージドサービスは、運用保守の面では非常に優位性があります。しかし、全社に展開し長く運用していくことを考えた場合に、マネージドサービスでは叶え辛いカスタマイズ・追加機能開発や、不具合の暫定的な対応などが考えられました。そのため、OSSなど内部構造を理解でき場合によっては、内製による開発により問題を回避することが出来るのが望ましいと考えました。

また、digdag のコンテナは自前で build しているため、公開もしくは内製のツールやコマンドなどをコンテナに含め、配布すると言った事も行っています。

digdagの利用状況と今後

以上が、digdagをワークフローエンジンとして選定した理由です。

現在は、ゲームタイトルやサービスで合わせて数十のdigdag環境が動作しています。

構築・運用についても、手順、Iaasのコードも揃って来ており、新たなサービスが立ち上がった場合にも、比較的クイックにワークフロー環境を構築出来る様になりました。更にはワークフローの実装においてもデータエンジニア・アナリストにもナレッジが溜まってきたので、今後もDeNAデータプラットフォームにおけるワークフローエンジンの中心になる事と考えています。

しかし、クラウド全盛期において、過度な前例踏襲や塩漬けはリスクが高いと考えます。最新情報をキャッチアップし、場合によってはワークフローの入れ替えといったレベルでのアップデートを行うなど、常によりよいデータプラットフォームとして改善を行って行くのが、エンジニア冥利に尽きると考えます。

また、宣伝となりますが、 digdag のワークフローにおいて、BQテーブル間のwait処理を行う plugin である、 bq_wait も公開し社内でも活用しています。是非、利用や参考ください。

https://github.com/DeNA/digdag-operator-bq-wait

次世代 BI ツールの Looker をなぜ選定したか

現行BIツール（Argus）の課題

2014年頃からDeNAではArgusと呼ばれる内製のBIツールを活用しています。これによりSQLベースでのデータ抽出が可能になり、データの活用を一気に進める事ができました。それにより、アナリストやデータ利用者は、BQやオンプレのDWH(vertica)から素早く必要なデータを得ることが可能になりました。

しかし、データ活用が全社的に進む事で、以下の課題が顕在化しました。

集計データの品質・ロジックが属人的になった
大量のダッシュボード・レポートの管理負荷が高くなった
柔軟なアクセスコントロール・データ提供を求められる様になった

これらの課題を解決し、さらなるデータ利活用を推進する事を目的に今回DeNAではLookerを導入することになりました。

集計データの品質・ロジックが属人的になった

DeNAのデータプラットフォームの特徴としては、先のワークフロー選定理由のセクションでもお伝えしたとおり、アナリストやデータ利用者が自らパイプラインを開発し、集計・可視化する体制や仕組みを構築しており、それにより欲しいデータをなるべく早く得られる形を取っています。

そのため、目的に特化したデータマートを作るケースが少なく、汎用性が高かったり、都度データをスキャンするにはデータ量が多いといった場合に、事前に中間集計を行う事でアナリストが効率よくデータを利用出来る環境を作るに留めています。

各自が Rawデータもしくは中間集計したテーブルから、好きにSQLを作り集計することで、データマートのパイプラインが少なく抑えられるなどのガバナンスにメリットがある一方で、同じ様な集計でも担当するアナリストやエンジニアによって、集計のロジックが異なるといった問題が発生しました。更には、当時実装したアナリストが異動・退職した後に引き継いだメンバーはロジックの細部まで理解することが出来ず、そのまま利用したり別のレポートにロジックをコピーしたりといった問題が発生しました。

これは、SQLによる集計が手続き型言語と比べて手軽な一方で、サブクエリや相関サブクエリクエリなどを多様してしまうと、途中経過の集計結果が見えづらく仕様の理解が伝わり辛いのが原因の一つと考えています。

大量のダッシュボード・レポートの管理負荷が高くなった

この問題はBIツールによらないと考えますが、利用が促進されることで、数百、数千のレポートが生まれました。中には利用が全くされていないのに毎日レポートが更新されると言った問題も発生していました。BQを活用している場合、こういった問題を放置する事は、クラウド利用料にも影響を与えるので、なるべく避けなければなりません。

柔軟なアクセスコントロール・データ提供を求められる様になった

登壇でも触れましたがArgusがリリースされた当初、利用は主に社内。しかも、モバゲーサービスに関するログ・DB Snapshotを可視化、分析するためのBIツールでした。そのため、アクセスコントロールはシンプルで基本的にArgusにアクセス出来るメンバー＝全テーブルアクセス可能といった形で実装されていました。[3]

そんな中、DeNAのビジネス環境も変化していき、必ずしも社内の同じ事業のメンバーだけでは無く、他の事業や社外のステークホルダーにもデータプラットフォームを通じてデータの提供[4]を行う様になっていきました。

更には、メールによるデータの提供を行う場合、これまでは要件毎にバッチを開発し、運用・保守する必要も出てきました。少ない要件であれば問題有りませんが、要件が増えてくると工数も逼迫し、結果新たな要望に対しての提供自体がが遅れてしまうと言った問題も発生していました。また、近年では、Slackなどのチャットツールへのデータ提供の需要も高まっていました。

これらの課題に対してLookerでどう解決を図っているか

以上の課題に対して、Lookerの機能を有効に活用することで解決を図っています。

LookML の活用 → 属人化／BIレポートの管理負荷を解決
LookMLプロジェクト毎のアクセスコントロール → 柔軟なアクセスコントロール・データ提供
Looker Action Hub によるビジネスサイドからのデータ提供 → 柔軟なアクセスコントロール・データ提供

LookML の活用

LookMLとは、簡単に言うとLooker が提供する参照したいテーブルの構造や、テーブル間のリレーションをYAML形式で記載するものです。

引用: https://docs.looker.com/data-modeling/learning-lookml/what-is-lookml

これにより以下のメリットを受けられます。

LookML自体をgit管理下における( LookerのGUIでgit操作も可能）
データエンジニアは、model および view を予め定義しておくことで、各テーブルの dimension(集計の切り口) / measure(指標）を事前に定義・共通化し、更にはテーブル間のリレーションを定義する事で、人によって集計値が異なるといった問題を排除できる
SQLが書くことが出来なかったビジネスユーザも自ら、複数のテーブル間で正しいリレーションを保った形でデータ抽出が可能になる。そのため、データエンジニアはBIツール向けに 大福帳 の様な、ユーザ毎、日毎✕ユーザ毎といった形で、目的に特化したデータマートをなるべく作らなくて済むようになる。

LookML の model, view について少し深堀ましょう。

LookML の model, view とは

view

view とは単純にお伝えするのであれば、１つのテーブルもしくはクエリの実行結果に対して抽出対象のカラムや条件を指定した上で、集計の切り口（ dimension）や集計する指標（ measure）を yaml 形式で記載し、ビジネス側に提供する表形式の構造体を定義するものと考えています。

以下のサンプルでは、BQ上に存在する取引ログをLookMLのviewで定義したものです。dimension には、transaction_idなどの PrimaryKey や考えうる集計の切り口（user_id、product_id)などを記載します。これを定義することで、このテーブルは、PrimaryKeyが transaction_id で一意であり、集計する切り口としては、 user_id と product_id と transaction_time が選択し得る事が分かります。

view: 取引ログ

view: transaction {
  
  # 参照するテーブル名を定義
  sql_table_name: project_a.logs.transaction_log ;;
  
  # 参照するテーブルから必要となるカラムを定義する
  dimension: transaction_id {
    primary_key: yes # 主Keyであること表す
    hidden: yes # 主Keyはビジネス側には見せないので隠す
    description: "取引ID"
    type: string
    sql: ${TABLE}.transaction_id ;;
  }
  
  dimension: user_id {
     description: "会員ID"
     type: string
     sql: ${TABLE}.user_id ;;
  }
  
  dimension: product_id {
    description: "商品ID"
    type: string
    sql: ${TABLE}.product_id ;;
  }
  
  dimension_group: transaction_time {
    description: "取引時間"
    type: time
    timeframes: [hour, date, week, month, raw]
    # 時間、日、週、月、元のtimestampで集計軸を設定する
    sql: ${TABLE}.transaction_time ;;
  }
  
  dimension: amount {
    description: "購入金額"
    hidden: yes # 集計前の購入金額は、ビジネス側には見せないので隠す
    type: number
    sql: ${TABLE}.amount ;;
  }
  
  # テーブルから抽出したカラムから集計・加工などを定義する
  measure: sum_amount {
    description: "合計購入金額"
    type: sum
    sql: ${amount} ;;
  }
  
  measure: avg_amount {
    description: "平均購入金額"
    type: average
    sql: ${amount} ;;
  }
}

以下は、月と product_id(商品ID）毎に合計の売上を抽出する際に、Looker上で自動で生成するSQLです。view上で予め dimension や measure を定義しておくことで、利用者はSQLを意識する事無くdimension やmeasure を選択し利用することができます。

SELECT
 FORMAT_TIMESTAMP('%Y-%m', TIMESTAMP(FORMAT_TIMESTAMP('%F %H:%M:%E*S', transaction.transaction_time , 'Asia/Tokyo'))) AS transaction_transaction_time_month,
 transaction.product_id  AS transaction_product_id,
 COALESCE(SUM(transaction.amount ), 0) AS transaction_amount_sum_amount
FROM project_a.logs.transaction_log AS transactionGROUP BY 1,2
ORDER BY 1 DESC

model

model とは、複数のテーブル間でリレーションを組み、仮想的な非正規化を行う定義です。誤解を恐れずお伝えするのであれば、ER図（実態関連モデル）を定義するようなものと考えていただくのが良いかと思います。

実際に modelで定義したものが、ビジネスサイドやデータ利用者に提供するインタフェース(Explore)になります。

先程の、商品の取引ログに加えて、商品のマスタを定義するview を作成しつつ、先程の月と product_id(商品ID）毎では無く、月と product_name (商品名) 毎の合計売上を実現してみましょう。

view: 商品マスタ

view: product_master {
  
  # 参照するテーブル名を定義
  sql_table_name: project_a.master.product ;;
  
  # 参照するテーブルから必要となるカラムを定義する
  dimension: product_id {
    primary_key: yes # 主Keyであること表す
    hidden: yes # 主Keyはビジネス側には見せないので隠す
    description: "商品ID"
    type: string
    sql: ${TABLE}.product_id ;;
  }
  
  dimension: product_name{
     description: "商品名"
     type: string
     sql: ${TABLE}.product_name ;;
  }
  
  dimension: product_unit_price {
    description: "商品単価"
    type: number
    sql: ${TABLE}.product_unit_price ;;
  }
  
  dimension: sale_start_date{
    description: "販売開始日"
    type:date
    sql: ${TABLE}.sale_start_date ;;
  }
}

model: 取引管理

# explore として、transaction のview の名前を使う
explore: transaction {
  label: "取引管理"
  
  # product_master(商品マスタ）と結合する
  join: product_master {
    # transaction と product_masterでは N対1 の関係
    relationship: many_to_one_to_one 
    # product_id で join する
    sql_on: ${transaction.product_id} = ${product_master.product_id};; 
  }
}

上記、複数のテーブルを組み合わせたmodelを作ることで、以下の様に動的にJOINを行うSQLを生成してくれます。そのため、従来のBIツールでは難しかった、ビジネスユーザなどSQLを書けないユーザによる複数のテーブルテーブルにまたがったデータ抽出を可能にします。[4]

SELECT
 FORMAT_TIMESTAMP('%Y-%m', TIMESTAMP(FORMAT_TIMESTAMP('%F %H:%M:%E*S', transaction.transaction_time , 'Asia/Tokyo'))) AS transaction_transaction_time_month,
 product_master.product_name  AS product_master_product_name,
 COALESCE(SUM(transaction.amount ), 0) AS transaction_amount_sum_amount
FROM project_a.logs.transaction_log AS transaction
LEFT JOIN project_a.master.product AS product_master
ON transaction.product_id = product_master.product_idGROUP BY 1,2
ORDER BY 1 DESC

LookMLプロジェクト毎のアクセスコントロール

Looker には権限の管理を含む、Lookerに関連する一連のファイルを管理する概念として、LookMLプロジェクトと呼ばれるものがあります。LookMLプロジェクト単位で、誰がどの権限でアクセスすることが可能か管理する事が出来ます。

引用: https://docs.looker.com/ja/data-modeling/learning-lookml/lookml-terms-and-concepts

更には、LookMLプロジェクト毎に、実際のデータへのアクセス先（DeNAの場合は、Google Cloudのプロジェクト）を Database Connection として管理できるため、LookMLプロジェクトとGCPプロジェクトの関係性が疎になり、柔軟なアクセスコントロールを実現することが出来ます。

LookML プロジェクトAは、 GCP Project X, Y, Zにアクセス可能
LookML プロジェクトBは、 GCP Project Yのみアクセス可能
LookML プロジェクトCは、 GCP Project Y, Zにアクセス可能

また、Lookerへの認証と各 LookML プロジェクトへの認可は、SSOと連携しているため、SSO側のグルーブ設定で個人のアクセス権限を設定することが出来るようになっています。

Looker Action Hub によるビジネスサイドからのデータ提供

Looker には、Action Hub と呼ばれる Explore や Dashboard から抽出した結果を画像・PDFなどのレポート形式もしくは、表のRawデータを使って後続のAction を随時もしくは定期的に実行する事が出来ます。

代表的な物を挙げると、以下の様なActionが可能であり、多様な要件が産まれやすいデータの利用（出口）部分で大きな効果が期待出来ます。

Explore や Dashboardを日次でEmail、Slackの宛先に送る
表データを毎月１日のAM10:00 に Google Sheets を更新する
MAの対象情報を随時 Marketo に送る
機械学習の学習／予測用のデータを Looker Exploreで作り、DataRobotやAmazon SageMakerに送信する

Lookerを利用した次世代BIの現在地点

以上が、現行のBIが抱えている課題を踏まえた上で、DeNAがLookerを導入した経緯を記載いたしました。

現在、現行のBIツールであるArgusからLookerへの移行を各ゲームタイトルい・サービスで実施しています。まだまだ移行の過渡期ですが、幾つか課題も出てきています。

LookMLでテーブル間の関係性・構造をコードで定義出来る一方で学習コストが高く、DeNAのベストプラクティスが定義出来ていない
Argusやこれまでの分析のすべてを代替・移行するために、アナリストやデータの利用者に対してより細部のヒアリングと方式検討が必要

１点目については、LookMLによる管理によって集計ロジックが排除できる一方で、LookMLの実装に慣れが必要であったり、機能の多さから、LookMLの実装自体に属人的な要素が発生する可能性が考えられます。機能を制限する訳ではありませんが、社内のベスト・プラクティスのマニュアル整備を近々行う必要があります。

２点目については、特にアナリスト・サイエンティストの方など表のデータとして、Sheet形式であったり、RやPythonなどで探索的にデータを利用する場合において方式・ツール・プロセスの定義が必要と考えています。Lookerはガバナンスを効かせたデータ活用を行う場合に、非常に強力なツールではありますが、あくまでも目的はデータから導かれたインサイトを得たり、データに基づき社内で意思決定を手助けすることにあります。次世代BI検討のスコープとしては、フラットに利用者側のニーズをキャッチアップし、最適な方法を導く必要があります。

その他、当日ご質問頂いた内容への回答

当日ご質問頂いた中で、回答出来なかったものに関しまして、以下に回答致します。

なお、ご質問内容は配信上にコメント頂いたものから回答致します。

https://cloudonair.withgoogle.com/events/jp-data-platform-day

Q1. 発表ありがとうございます！非常に興味深い内容でした。オンプレからBigQueryへのデータ移行には結構コストがかかると思いますが、コストを抑えるために工夫した点などがありましたら教えてください。

ご質問ありがとうございます！以下に回答させて頂きます。

ご質問頂いている通り、クラウド移行を進めていく中で分析で利用している Google Cloud 全体のコストが非常に高くなっている課題感がありました。分析を行うと、概ね以下の問題に当てはめる事が出来ました。[6]

BQ においてクエリのスキャン量が多いもしくは不必要にクエリを実行ししてしまい、クエリスキャンの料金が高くなっている
BQ および GCS において、不必要なデータを保管しストレージの料金が高くなっている

これらの問題に対して、DeNAでは以下の様なアプローチを取っています。

BQ 警察活動
BQ ドクター活動

BQ警察の活動については、不必要なクエリスキャンを監視したり、テーブルの構成がベストプラクティスに沿っていないなどの、治安（コスト）維持の側面で活動していました。

BQドクターの活動については、BQ警察の活動の一歩先の活動として、より健全にデータプラットフォームを利用いただくための活動として、コストのモニタリング以外にも、テーブルの利用状況や、クエリの実行状況などより深く広い可視化を行い、最適な状態を維持するための活動を行っています。

弊社 kazumasa.iwao が記載している記事やリンク先の登壇内容に詳しく触れています。併せてご確認ください。

[DeNA TechCon 2020 ライブ配信] DeNA データプラットフォームにおける自由と統制のバランス

DeNA TechCon 2020 ライブ配信をご覧いただき誠にありがとうございました。この記事では DeNA TechCon 2020 ライブ配信（「DeNA…

medium.com

Q2. 学習や予測のパイプラインにkubeflowを利用することは検討候補に挙がりましたか？

ご質問ありがとうございます！以下に回答させて頂きます。

こちらのご質問は、AutoML Tableを使ったパイプラインに関するご質問と想定し回答させて頂きます。機械学習のパイプライン構築にkubeflowを利用するケースは増えていますが、今回のケースですとkubeflowは検討の候補に挙がりませんでした。今改めて考え直しますと、以下の観点でdigdagを選定する可能性が高いかと思います。

使い慣れているdigdagの方が、提供までのスピードと学習コストで優位性があった
機械学習の学習／予測までのパイプラインが比較的シンプルであった

今回の事例では、あくまでも社内の利用に関して機械学習を使った場合の実績です。仮に、本番システムに複雑な機械学習モデル・パイプラインを実装する場合は、積極的にkubeflowなどMLのパイプラインを実現するソフトウェアの検証・導入を進めるかも知れません。

Q3： NLP APIのポジネガ分析の妥当性ってどう検証するんでしょうか？

ご質問ありがとうございます！以下に回答させて頂きます。

妥当性検証にあたっては、実際にTwitter本文を確認し、人間が見た定性的な評価と感情分析結果をサンプリングで比較しました。

本来はネガティブな単語も、前後の文脈と合わせて文章総合としては、ポジティブに判定するなどある程度の精度が出ていると判断し利用しています。

また感情分析については、score,magnitude の２つの指標があります。ユースケースや業務特性ごとに、scoreとmagnitudeの値をルールベースで判定するロジックを整理する必要があると考えています。詳細は以下のGoogle Cloudが提供しているドキュメントを参照下さい。

Natural Language API Basics | Cloud Natural Language API

Send feedback This document provides a guide to the basics of using the Cloud Natural Language API. This conceptual…

cloud.google.com

終わりに

改めまして、資料をご覧頂きありがとうございました。DeNAのデータプラットフォームでは、日々新たな要望や変化・問題がが起きています。こういった変化・問題に対して日夜戦っていますが、得られた経験値については、また登壇やBlogなどで皆様に情報を発信出来ればと思いますので、楽しみに頂ければと思います。

ありがとうございました。

Notes

[1]: アナリストが所属していないサービスについては、データエンジニアがサポートする場合もあれば、サービス側に所属するエンジニアがアドホックにサポートすると言ったケースがあります。

[2]: digdagのコスト比較については、DeNAではSQLによる集計・加工が中心で有った点や、サービス毎にGCPプロジェクトを分ける事で、分離性を高めるなどのクラウド移行後のアーキテクチャが前提にあり、GKE上でdigdagを運用することにコストメリットがあると判断しました。仮にPython、Javaなどのプログラムが主体の加工や、GCPプロジェクトを中央集約するなど、アーキテクチャによってコストやその他メリット・デメリットは変わりますので、ご注意ください。

[3]: 主にオンプレ時代の Hadoop の事を言います。もちろん Google Cloud では IAM 設定で柔軟な権限設定が可能です。ですが、同じ GCP プロジェクトにおいて、アクセスコントロールを行う場合は、サービスアカウントを分けて発行するなどの手間もありました。

[4]: 協業先や社外のステークホルダーに、メールないしArgusにてKPI情報を提供するなど

[5]: 要件・データの状況によっては、データエンジニアによるパイプラインでの集計・加工が必要になる場合があります。また、PDT(Persistent Derived Tables) というLooker の機能を利用することで、viewで定義している実行結果の取得に時間が掛かる物をBQなどのDWHの実テーブルとして保管し、キャッシュとして利用することも可能です。

[6]: DeNAのデータプラットフォームでは、Google Compute Engine や Google Cloud Dataflow などの利用時間で料金が発生するサービスを利用している箇所は限定的であったため、上記２つの問題に収束していました。

Google Cloud を使ったデータプラットフォームへの変革と最新の活用状況について [Google Cloud Data Platform Day #2 フォローアップ記事]

はじめに

本題

digdag の選定理由および DeNA での使い方

次世代 BI ツールの Looker をなぜ選定したか

その他、当日ご質問頂いた内容への回答

[DeNA TechCon 2020 ライブ配信] DeNA データプラットフォームにおける自由と統制のバランス

DeNA TechCon 2020 ライブ配信をご覧いただき誠にありがとうございました。この記事では DeNA TechCon 2020 ライブ配信（「DeNA…

Natural Language API Basics | Cloud Natural Language API

Send feedback This document provides a guide to the basics of using the Cloud Natural Language API. This conceptual…

終わりに

Notes

Written by Shinichiro Joya