[レポート]ハンズオン/LookerとRを連携したデータサイエンス – Looker：JOIN 2019 at San Francisco #looker #JOINdata

Lookerにとっての…『R』……

「カスタマーストーリー」を支えるツール特集

#レポート

#イベントレポート

#ビジネス・アナリティクス

#ビッグデータ

たまちゃん

2019.12.02

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

現地時間2019年11月05日〜07日の期間、米国サンフランシスコで開催されているLookerの年次カンファレンスイベント『JOIN 2019』。今年2019年のイベントは、弊社から3名のメンバーが現地参戦しました。

参加レポート各種については下記シリーズをご参照ください。

当エントリでは、その中から『Hands-on Lab: Data Science in Action with Looker & R (LookerとRを連携したデータサイエンス)』の内容について参加レポートをお届けします。

セッション概要

セッションの概要は以下の通りです。

[登壇者情報]：
Shingai Samudzi氏（Looker社 Consultant）

[セッション情報]：
Hands-on Lab: Data Science in Action with Looker & R
(# LookerとRを連携したデータサイエンス)

Looker can be used as a powerful transformation layer within a data science-oriented pipeline. This lab will focus on Looker with R and give you an opportunity to get hands-on with the workflows and analysis that this architecture enables. Come see how Looker and R can be combined to support driving accurate predictions using your historical data.
(Lookerは、データサイエンス指向パイプライン内の強力な変換レイヤーとして使用できます。このハンズオンでは、Rを使用したLookerに焦点を当て、このアーキテクチャによって実現されるワークフローと分析を実践する機会を提供します。LookerとRを組み合わせて、過去のデータを使った正確な予測をサポートする方法をご覧ください。)

セッションレポート

イントロダクション

Lookerを使用すると、データサイエンスのワークフローを上記のように回すことができます。

これで大丈夫か？
- すべてのデータは、接続されていないさまざまなExcelスプレッドシートやデータベースに格納されている
私たちはそれを追跡できているか？
- Lookerがすべてのデータをモデル化し、真の単一データソースとなるためのクリーンなデータパイプラインを構築することで、実際に追跡/測定されているものとその方法を可視化できる
それが意味する事は？
- シンプルな統計モデルは、データから導き出す良い結論と悪い結論の図式を作成するのに役立つ
「明日」はどうなる？
- エラーを最小限に抑えた強力なモデリングにより、予測分析が可能

そもそも、データサイエンスとは一体何なのでしょうか。

ソフトウェア×統計×大規模なデータセット
ソフトウェアを使用して、大規模なデータセットへの統計モデルとテストの適用を拡張
ETLを介して実際の分析に適した形式にオリジナルデータを取り込むデータエンジニアリングを含めることも可能

LookerとR

LookerとRを連携させた時のアーキテクチャは上記のような形となります。RからLooker APIを叩くことで、Lookerで定義されたデータを直接Rに取り込むことできます。R上で予測した結果をDBに書き戻し、そのDBをLookerダッシュボードで確認することで、LookerとRによるデータサイエンスを実現します。　

ユースケース

デモグラに基づいて新規顧客が購買に何を選ぶかを予測
過去のデータに基づいて、顧客が新製品にどのように対応するかを予測
数百万件の顧客取引におけるクレジットカード詐欺の特定
時系列データからの在庫予測、財務予測またはイベント予測の作成
…など

ハンズオンやってみた

想定するビジネスケース

ユーザーが販売可能な不動産を探して購入できるマーケットプレイスを運営する不動産スタートアップを想像します。最もよく使われている機能の一つが「今すぐ購入するか、後で購入するか」サービスで、これはユーザーが物件を今買うべきか、来年中に価格が下がるのを待つべきかを決めるのに役立つサービスです。これのレコメンドを行うには、郵便番号のように狭い地域での住宅価格の上昇（HPIのホーム・プライス・インデックスを通じて）を予測できる必要があります。

小規模なデータサイエンスチームはRに習熟しており、データウェアハウスも利用できます。このデータウェアハウスは、クリーニング済みのテーブルや変換済みのテーブルを国勢調査データとともに提供しています。このハンズオンの目標は、LookerをデータサイエンスETLワークフローの重要な部分として使用する方法を説明し、次にLookerを使用してモデルからのビジネスに関連する結果を表示することです。

ハンズオンの流れ

Looker APIを使用して、事前にモデリングされたデータをLookerからインポートする
Rで単純多変量回帰を行う
多変量回帰により予測する
Lookerに予測データを表示する

Google Colaboratoryの準備

ハンズオン用に提供されているスクリプトを、自分の環境にコピーしてやっていきます。

ライブラリのインストール

ハンズオン用に提供された4つのファイルをダウンロードし、Google Colaboratory環境に配置します。例にならって、/home/scriptsに置きました（scripitsディレクトリはなかったので作成）。

ライブラリファイルを配置したら、それをインストールしていきます（結構時間がかかる…）。

source(file="/home/scripts/predictiveR2.R")
source(file="/home/scripts/crossvalidation.R")


install.packages("plyr")
install.packages("dplyr")
install.packages("quantmod")
install.packages("purrr")
install.packages("data.table")
install.packages("tidyr")
install.packages("MVLM")
install.packages("car")
install.packages("GGally")
install.packages("scatterplot3d")
install.packages("rrr")
install.packages("caret")
install.packages("leaps")
install.packages("ggpairs")

library (plyr)
library(dplyr)
library(quantmod)
library(purrr)
library(data.table)
library(tidyr)
library(MVLM)
library(car)
library(GGally)
library(scatterplot3d)
library(caret)
library(leaps)

Looker APIへ接続する

R用のLooker APIクライアントSDKを実行します…が、Google Colaboratoryには制限があるため、ちょっとした回避策を講じる必要があります。

先程配置したLooker.iniを使って、lookrというライブラリをインストールします。

devtools::install_github("looker/lookr", ref = "dev", force=TRUE)
library(lookr)

sdk <- LookerSDK$new(configFile = "/home/scripts/looker.ini")

Lookerで定義されたモデル（データ）をRにもってくる

これで、RからLooker APIを叩けるようになったので、実際にデータを持ってきます。今回のハンズオンで使用するモデルは、既に用意されていました（既に表形式のLookとして用意されていました）。

ですので、このLookをRから呼び出す必要があります。Look ID（今回の場合は86）をメモしておきます（URLの末尾でわかります）。API経由でこのLookを呼び出す場合は、この番号が必要になります。

data <- sdk$runLook(lookId = 86)

headers <- c("zipcode","city","state","x.median_income","x.median_home_value","x.Five_yr_unit_growth_rate","x.total_units","x.Three_yr_HPI_percent_change","x.Ten_yr_HPI_percent_change","x.percent_usable_land","x.median_net_wealth","x.percent_of_households_renters","y.HPI","x.new_units_per_capita_over_Five_yrs","x.One_yr_HPI_percent_change","x.One_yr_pop_change","x.Three_yr_pop_change","x.Five_yr_pop_change")
names(data) <- headers
data_df <- na.omit(select(data,-1,-2,-3))
data_df <- mutate_all(data_df, function(x) as.numeric(as.character(x)))

str(data_df)

dataにLookのデータを入れ、別途ヘッダーを定義し、データフレームに出力しています。中をみるとこんな感じになっています。

探索的データ分析と仮説の作成

今回のやるのは多変量回帰モデルを作成することでです。HPIが目的変数であり、他は説明変数です。

このプロセスの最初のステップは、簡単なデータ探索です。下記のggpairsは、モデル内の変数の総数を減らすために、相関の高い予測変数を見つける良い方法です。

model_plot <- ggpairs(data=data_df, columns=1:11, title="Real Estate Demand Variables", progress=NULL)

#予測変数間の相関を評価する変数分析の第2の形式

model_x <- data_df %>%
    select(starts_with("x"))

model_y <- data_df %>%
    select(starts_with("y"))


GGally::ggcorr(model_x)

下記のプロットが表示されます。

上記の結果、相関係数が0.985の場合、Five_yr_unit_growth_rateとnew_units_per_citper_over_Five_yrsはモデルに影響を及ぼすことなく、一つを除外できることを示唆しています。また、median_income とmedian_net_wealth、median_incomとmedian_home_valueの間にも強い相関があります。つまり、これらの変数も削除することができます。

model_x2 <- na.omit(select(model_x,-2,-3,-4,-8))

この時点で、回帰モデリングによってテストできる仮説を導き出すのに十分な情報が得られました。

仮説0（帰無仮説）
- HPIとこれらの変数のいずれかとの間に予測関係はない
仮説1
- HPIはランダムではなく、HPIの変動を説明できる予測変数がある

最適な多変量回帰モデルを見つける

予測変数の最適な組み合わせをプログラムで識別するために使用できるツールの1つは、ベストサブセット回帰です。これは、データセットで最大の分散を予測する変数の組み合わせを見つけるのに役立ちます。

model_x3 <- na.omit(select(data_df,-12))

var_subset <- regsubsets(y.HPI~., data = model_x3, nvmax = 10)
res_subset<-summary(var_subset)
res_sum<-data.frame(
  Adj.R2 = which.max(res_subset$adjr2),
  CP = which.min(res_subset$cp),
  BIC = which.min(res_subset$bic)
)
res_sum

三つの測定基準のうち二つは、「変数は10個」が最も良い予測を提供することを示唆しています。それでは、クロスバリデーションを行って、10個の変数を使用したモデルとトレーニングデータとの比較を見てみましょう。

model.ids <- 1:10
cv.errors <-  map(model.ids, get_model_formula, var_subset, "y.HPI") %>%
  map(get_cv_error, data = model_x3) %>%
  unlist()
cv.errors

a <- which.min(cv.errors)

#目的変数と、クロスバリデーションエラーが最小の数に基づいて最適な変数セットを選択します
get_model_formula(10, var_subset, "y.HPI")

予測を生成する

クロスバリデーションを十分に行うモデルができました（~88%の精度）。実際の予測をデータセットに組み込んでみましょう。

model1 <- lm((get_model_formula(a, var_subset, "y.HPI")), data=data_df)
model1

data_df$predicted.HPI <- model1$fitted.values
head(data_df)

予測した値と実際の値が一致するようになったので、回帰の適合度をプロットして、予測が既存のデータセットにどの程度適合するかを確認できます。

# 適合した値と実際のHPIをプロットする

plot(x = data_df$y.HPI,                          # 実際の値をX軸へ
     y = data_df$predicted.HPI,               # 適合した値をY軸へ
     xlab = "True Values",
     ylab = "Model Fitted Values",
     main = "Regression fits of zip code-level HPI")

abline(b = 1, a = 0)

初期の統計的検定は、単純回帰が分散を予測する有意な能力を有することを示唆しますが、回帰適合は、使用すべきより良い機械学習モデルがあるかもしれないことを示唆します。そうは言っても、これはひどいことではないし、（私たちの）特定のデータセットに過度に適合する危険性もありません。これは、HPIがどのように変化するかについての大まかなアイデアを構築するのには十分ですが、実際の投資戦略を構築するには不十分でしょう。

いずれにしても、このデータをLookerに戻し、チームの他のメンバーと一緒にモデリングの結果を表示しましょう。

データをDWHにエクスポートする

dplyrライブラリとそのSnowflakeコネクタを使用して、Snowflakeにデータをdata_dfというテーブルに送り返すことができます（今回のハンズオンでは、DWHにSnowflakeを使用していることが前提）。

copy_to(sf_connect, data_df, name = deparse(substitute(data_df)), overwrite = FALSE)

このテーブルを使用して、モデルが予測する「どの郵便番号が最も成長するか」について、同僚と共有するための有用なビジュアライズを生成できます。

今回のビジネスケースは下記の通りです。

ユーザーが販売可能な不動産を探して購入できるマーケットプレイスを運営する不動産スタートアップを想像します。最もよく使われている機能の一つが「今すぐ購入するか、後で購入するか」サービスで、これはユーザーが物件を今買うべきか、来年中に価格が下がるのを待つべきかを決めるのに役立つサービスです。これのレコメンドを行うには、郵便番号のように狭い地域での住宅価格の上昇（HPIのホーム・プライス・インデックスを通じて）を予測できる必要があります。

このダッシュボードをみることで、住宅価格の上昇について、郵便番号単位の狭いエリアレベルで予測した結果をひと目で確認することができます。

補足

今回はSnowflakeでしたが、BigqueryやRedshift用のコネクタもあります。

ハンズオンを受講して

データサイエンスのワークフローがシームレスになる

今回のハンズオン、実は、Rでやっていることは、ごく普通のデータ分析に過ぎません。このハンズオンの肝は、Looker APIをRから直接叩くことで、Looker内で定義したデータを直接持ってこれることにあります。LookerはLookMLでデータを定義することで、非エンジニアでもわかりやすくデータを整理することができます。その整理整頓されたデータを、データサイエンティストが直接アクセスできるというところが、Lookerならではの機能ではないでしょうか。

しかも、結果をDBに返すことで、結果のビジュアライズもLookerで行えます。Lookerは、ビジュアライズをSlack等のサービスに簡単に通知することができるので、Rで行った予測結果のビジュアライズを、関係者に簡単に共有することができます。また、ビジュアライズの他サイトへの埋め込みも簡単です。

つまり、LookerとRを連携させることで、データ→データサイエンス→ビジュアライズ→結果のシェア…という流れをシームレスに行うことができます。従来、この一連のワークフローで手間取り、本来の「結果を吟味して次のビジネスアクションにつなげる」というところに時間を割くことができませんでしたが、LookerとRでこの問題を解決できることがわかりました。個人的にここは非常に大きいです。