Db2 Warehouse Spark利用ガイドチュートリアル編

© 2017 IBM Corporation
Db2 Warehouse Spark利⽤ガイド
チュートリアル編
IBMシステムズ・エンジニアリング
2017/10/11

© 2017 IBM Corporation2
⽬次
§ Sparkアプリケーションの作成と実⾏
- チュートリアル
- Jupyter Notebookによる対話的開発の流れ
- Analytic Stored Proceduresの実⾏
§ 補⾜資料
- チュートリアルの実⾏例

Sparkアプリケーションの作成と実⾏

§ チュートリアル
§ RESTツールの準備
§ サンプルアプリケーションのロード
§ アプリケーションのデプロイ / 依存モジュールの管理
§ アプリケーションの実⾏
§ SparkのJob監視 / 停⽌
§ アプリケーションの実⾏結果・ログ参照
§ アプリケーションの削除
§ SQLによるSparkへの処理リクエスト
§ Jupyter Notebookによる対話的開発の流れ
§ Jupyter Notebook概要
§ Jupyter NotebookによるTornadoデモの実⾏
§ Jupyter Notebookからのデプロイ
§ Analytic Stored Proceduresの実⾏
§ TwoStep
§ GLM
Sparkアプリケーションの作成と実⾏

チュートリアル

チュートリアル概要説明
§ Db2 Warehouseに統合されたSpark環境を利⽤する場合のアプリケー
ションライフサイクルを、チュートリアルに従って学習する
§ RESTツールの準備
Db2 WarehouseにSparkで記述したアプリケーションを投⼊するためのspark-submit.shをセットアップします
spark-submit.shからDb2 WarehouseへのリクエストにはRESTが利⽤されます
§ サンプルアプリケーションのロード
チュートリアルで使⽤するアプリケーションをDb2 Warehouseにダウンロードします
§ アプリケーションのデプロイ / 依存モジュールの管理
アプリケーション、依存モジュールのデプロイをします
§ アプリケーションの実⾏
アプリケーション単体で実⾏、依存モジュールを呼び出して実⾏します
§ SparkのJob監視 / 停⽌
アプリケーションを実⾏した時のSparkの動きを確認します
§ アプリケーションの実⾏結果・ログ参照
アプリケーションの実⾏結果、出⼒ログを確認します
§ アプリケーションの削除
デプロイ済みのアプリケーション、依存モジュールを削除します

RESTツールの準備1
§ Sparkにリクエストするための準備
§ spark-submit.sh スクリプトとは
§ Db2 Warehouse(以降DWH)が提供しているコマンドラインツールスクリプト
§ DWHのSparkに対してアプリケーションのデプロイ、実行、ログ取得やJob監視などの
リクエストを送るためのインターフェースでRESTを使用する
§ このスクリプト内で ”curl“ を使用するため、cURLがインストールされていることが前提
§ spark-submit.shを使用する準備
§ 実行環境の構成
§ 当ガイドではspark-submit.shをクライアントPCから実行する手順を記載する
1. cURLがインストールされていることを確認
確認方法:
spark-submit.shを実行するマシンのコマンドラインインターフェースで「curl –v」を実行し、
バージョンが返却されることを確認する。curlがインストールされていない場合は、
環境に合わせてインストールする
*1
*1 DWHのSparkのインターフェースとして、spark-submit.sh, REST API, WebコンソールからのSQL実行の3パターンが用意されている。
Db2 WarehouseクライアントPC spark-submit.sh
*2
*2 クライアントPCがWindowsの場合はShell環境を準備するか、他のインターフェースによるリクエスト（補足資料）も可能。

2. spark-submit.shの取得
1. DWHのWebコンソール ( https://<host>:8443/ ) にログイン
2. 画面左のメニューバーの「Analytics」 > 「Spark Analytics」を選択
3. 画面右の項目から「Download spark-submit.sh」をクリック
3. spark-submit.shを使用するターミナルで環境変数定義
n <password>はbluuser1に設定したパスワードを指定
メニューがなければ
ここをクリック
RESTツールの準備2
export DASHDBURL=https://<host>:8443
export DASHDBUSER=bluuser1
export DASHDBPASS=<password>

サンプルアプリケーションのロード
§ DWHにサンプルアプリケーションを配置する
1. DWHの ”/mnt/clusterfs/home/bluuser1/spark/apps/” (以降spark/apps)に
サンプルアプリケーションをロードする
（bluuser1のホームに”spark/apps”がない場合は自動生成される）
2. “spark/apps”以下のアプリケーションを確認する
（任意） “spark/apps”以下のサンプルアプリケーションをクライアントPCに
ダウンロードしたい場合 (保存先はクライアントのカレントディレクトリ)
./spark-submit.sh --load-samples
./spark-submit.sh --list-files apps
./spark-submit.sh --download-file apps <application>
./spark-submit.sh --downloadfile apps ReadExample.py
ex.) サンプルアプリケーションのダウンロード
*2
*1当ガイドでは”ReadExample.py”を使用した場合のガイドを記載する。
*2 ファイルは1つずつ指定する必要があり、 * は使用できない
*1
ReadExample.py：
1、Db2に接続し、”SPARK_TEST_DATA”テーブルからデータを取得
2、行数を標準出力に出力（spark/log/submission_<submission_id>/submission.outに出力確認方法の詳細はp.16）
3、”ID”列でソートした結果を標準出力に出力
*1

アプリケーションのデプロイ / 依存モジュールの管理1
n Sparkアプリケーションをデプロイする
n アプリケーションのデプロイ先は”spark/apps”
（<myDir>はクライアントPCのディレクトリ）
n 依存モジュールをデプロイする
n アプリケーションに依存関係がある場合、管理者ユーザーでモジュール
(jar, zip, py, egg) を配置可能
n 特定のアプリケーションの依存ファイルの場合
配置先は”/mnt/clusterfs/home/bluuser1/spark/defaultlibs/”に配置される
n DWHユーザー間で共有する依存ファイルの場合
配置先は”/mnt/clusterfs/global/”
./spark-submit.sh --upload-file <myDir>/<application>
./spark-submit.sh --upload-file defaultlibs <dependencyFile>
./spark-submit.sh --upload-file globallibs <dependencyFile>
* 共有依存ファイルのアップロードのコマンドオプションは”globallibs”だが、作成されるディレクトリ名はglobalになる
*

n 依存モジュール管理
n 依存モジュールディレクトリはSparkドライバーとexecutorプロセスがアクセス可能
n jar : executorプロセスとSparkドライバーのJavaクラスパスに追加
n py / zip / egg ： PySparkのsearchパスに追加
n アプリケーション毎の依存解決
n 複数種類の依存モジュールを使用する場合は、依存モジュールをサブディレクトリに分け、
アプリケーション実行時に、サブディレクトリのモジュールを指定可能
n 作成するディレクトリは”spark/apps”以下でも良く、実行時は”spark/apps”からの
相対パスで指定でき、カンマ区切りで複数のモジュールを扱うことができる
n “spark/apps”ディレクトリ以下で依存モジュールを管理する場合
n 依存モジュール用のサブディレクトリは手動で作成する必要がある
n spark-submit.shでのデプロイは”spark/apps”以下にのみ配置可能なため
依存モジュールをappsから手動でサブディレクトリに移動する必要がある
n 実行手順を次ページに記載

n DWHサーバーで”apps”以下のサブディレクトリで依存モジュールを管理する
1. dockerコンテナーに入らずに依存モジュールのディレクトリを作成する
DWHのDocker稼動環境にログインして以下を実行する
2. bluuser1の“apps”ディレクトリに移動する
3. 依存モジュール管理用サブディレクトリを作成する
4. bluuser1のユーザーIDとグループIDを取得する
5. 3で作成したサブディレクトリの所有者を 4 で確認したユーザーIDと
グループIDに変更する
6. “apps”ディレクトリにある依存モジュールを作成したディレクトリに移動する
cd /mnt/clusterfs/home/bluuser1/spark/apps
mkdir <dirName>
docker exec -t dashDB id -u bluuser1
docker exec -t dashDB id -g bluuser1
chown <uid>:<gid> <dirName>
mv ./<dependencyFile> ./<dirName>/
Dockerの稼働環境にはbluuser1がいないため、
所有者をUID / GIDで指定する必要がある

アプリケーションの実行
n DWHにデプロイ済みのアプリケーションを実行する場合
n コマンドオプションに”--loc host”を指定（デフォルト値のため、指定しなくても良い）
n 依存モジュールがある場合はオプション”--py-files”の後に依存モジュールを指定
（カンマ区切りで複数指定可能）
n ”apps”以下にある場合
n ”defaultlibs”以下にある場合
n クライアントPC上のアプリケーションをテスト実行する場合
n コマンドオプションに”--loc client”を指定すると、クライアントPC上のアプリケーショ
ンを”apps/temp/”以下に配置して、テスト可能（”apps/temp”がなければ自動生成）
./spark-submit.sh <app>.py --py-files <dependencyDir>/<dependencyFile>
./spark-submit.sh ReadExample.py --py-files example_utilities.egg
ex.) サンプルアプリケーションの実行
./spark-submit.sh <localApplication> --py-files
<dependencyDir>/<dependencyFile> --loc client
* 依存モジュールがある場合は、あらかじめDWHにデプロイしておく必要がある。
--loc clientで同じ名前を指定してデプロイした場合、DWH上のアプリケーションは上書きされる。
*
./spark-submit.sh <app>.py --py-files ../defaultilibs/<dependencyFile>

SparkのJob監視 / 停止1
n 稼働中のアプリケーションのクラスターの動きを確認することができる
n DWHのWebコンソールから確認する
1. “https://<host>:8443/”でログイン
2. 画面左のメニューから「Monitor」 > 「Workloads」をクリック
3. 中央エリアの左上「概説」 > 「Spark」をクリックし、対象ユーザーをクリックする
1、
2、
3、

n 稼働中のアプリケーションのクラスターの動きを確認することができる
n SparkのWebコンソールから確認する
n “https://<host>:8443/”でDWHのWebコンソールにログイン
稼働中のアプリケーションの”Name”をクリックすると
クラスターの処理がモニターできる
処理が全て完了すると”Completed Applications”の欄に追加
される。
クラスターが行なっているJobの状態を確認することができる

n 稼働中のアプリケーションやクラスターの稼働状態を確認することができる
n spark-submit.shで確認する
n クラスターの状態を確認する
n アプリケーションの状態を確認する
n 特定のアプリケーションの状態を確認する
./spark-submit.sh --cluster-status
./spark-submit.sh --list-apps
./spark-submit.sh --app-status <submission_id>

n 稼働中のアプリケーションを停止する
n SparkのWebUIからJobを停止する
1. 「SparkのJob監視 / 停止1」の手順と同様にSparkのWebコンソールを開く
2. 「Running Applications」の「(kill)」をクリックする
3. 「Completed Applications」で停止した「Application ID」を持つアプリケーションが
「KILLED」になっていることを確認する

n 稼働中のアプリケーションを停止する
n spark-submit.shで停止する
1. 停止対象のアプリケーションを調べる（SparkのJob監視 / 停止3参照）
2. 「Running」になっている停止対象のアプリケーションの「SubmissionID」を引数に
以下のコマンドを実行する
3. 対象のアプリケーションが停止していることを確認する
./spark-submit.sh --kill <submission_id>
./spark-submit.sh --list-apps
SubmissionIDの確認
アプリケーションの停止
停止状態になっている

アプリケーションの実行結果・ログ参照1
n Sparkアプリケーションの実行ログは以下のようなディレクトリ構造で
”/mnt/clusterfs/home/bluuser1/spark/log”に出力される
spark/log
cluster_<cluster_id>
master.err
master.out
worker_<hostname>.err
worker_<hostname>.out
workers
<hostname>
app-<application_id>
<executor_id>
Invoker.py
stderr
stdout
submission_<submission_id>
app-<application_id>
submission.err
submission.info
submission.out
latest
SparkのMasterとWorkerからで出力されたログを格納する
masterノードの標準エラー出力
masterノードの標準出力
<ホスト名の>workerノードの標準エラー出力
<ホスト名の>workerノードの標準出力
アプリケーションに紐付くExecutorのログを格納
Sparkアプリケーションの出力したログを格納する
Sparkアプリケーションの実行情報を持つJSON
アプリケーションの標準エラー出力
アプリケーションの最終結果、full stack traceを含むログ
アプリケーションの標準出力
直近のアプリケーション実行ログ（リンク）

アプリケーションの実行結果・ログ参照2
n 実行ログの確認方法は2種類
n ログファイルのダウンロード（ダウンロード先はカレントディレクトリ）
n クラスター
n アプリケーション（<submission_id>を指定しなければ”latest”を取得）
n CLIからログファイルの閲覧（CLIのエディターが開く）
n クラスター
n アプリケーション
./spark-submit.sh --download-app-logs <submission_id>
./spark-submit.sh --download-cluster-logs
./spark-submit.sh --display-cluster-log <err|out> <master|worker> <host-ip>
./spark-submit.sh --display-app-log <err|out|app|info> <submission_id>

アプリケーションの削除
n DWHにデプロイしたアプリケーション、依存モジュールを削除する
n アプリケーションの削除
n “apps”以下にデプロイされているアプリケーションの場合
n “apps/temp/”のテスト時にデプロイしたアプリケーションの場合
n “apps”以下に作成したサブディレクトリの依存モジュールの場合
n 特定アプリケーションの依存モジュールの削除
n “$HOME/spark/defaultlibs/”からの削除
n DWH内のユーザーで共有する依存モジュールの削除
n “/global/”からの削除
./spark-submit.sh --delete-file apps <application>
./spark-submit.sh --delete-file apps temp/<application>
./spark-submit.sh --delete-file defaultlibs <dependencyFile>
./spark-submit.sh --delete-file globallibs <dependencyFile>
./spark-submit.sh --delete-file apps <subDir>/<dependencyFile>

SQLによるSparkへの処理リクエスト
n SQL実行でSparkに対してリクエストできる
n Stored ProcedureをDWHのWebコンソールから呼び出すことでsubmit-spark.shと
同様にSparkに対して、アプリケーション実行やJob監視などが可能
1. DWHのWebコンソールにログインし、メニューから「Run SQL」をクリック
2. アプリケーションの実行
(./spark-submit.sh ReadExample.py --py-files dependencies/example_utilities.egg と同様)
n オプションをパイプ（｜）で指定する
CALL IDAX.SPARK_SUBMIT(?, 'appResource=ReadExample.py |
sparkSubmitPyFiles=dependencies/example_utilities.egg');

n オプションをJSONで指定する
3. Job監視
n Job一覧の取得
(./spark-submit.sh --list-appsと同様)
CALL IDAX.SPARK_SUBMIT(?, '{"appResource":"ReadExample.py",
"sparkProperties":{"sparkSubmitPyFiles":"dependencies/example_utilities.egg"}}');
CALL IDAX.APP_STATUS(‘all’);

n 特定Jobの状態確認
(./spark-submit.sh --app-status <submission_id>と同様)
4. Jobの中止
n 稼働中の最新のJobを中止する
CALL IDAX.APP_STATUS('20170929102323152000');
*1 <submission_id>を指定しない場合は、最新のJob状態を取得する。 Ex.) IDAX.APP_STATUS();
*1
*2
*2 <submission_id>を指定可能。 Ex.) IDAX.CANCEL_APP(<submission_id>);
CALL IDAX.CANCEL_APP();

【参考】Spark History Serverによるイベントログの閲覧1
n Sparkのイベントログの確認
n Sparkの履歴サーバーで過去のSparkイベントログを参照できる
n イベントログでSparkのJob、Stageにかかっている時間や実行された順番、
RDDが使用しているメモリ数などを確認できる
n 通常SparkのWebUIからSparkのイベントログはRunning状態でしか確認できないが
履歴サーバーを使用することで、完了したイベントログをWebUIから確認できる
n 履歴サーバーはDockerコンテナーから起動する必要があり、
イベントログは1アプリケーションごとに起動して確認する
1. DWHサーバにログインし、DWHのDockerコンテナーにログインする
2. 履歴サーバー起動Shell、対象アプリケーションログの検索
3. 起動Shellの引数に閲覧対象のアプリケーションログのディレクトリのパスを渡して実行
4. SparkのWebUI(https://<host>:18080/)にログイン
docker exec -it dashDB bash
<ShellDir>/sbin/start-history-server.sh <applicationLogDir>
find / -name "start-history-server.sh”
find / -name “latest” -type l -user bluuser1
次ページに起動例を記載

【参考】 Spark History Serverによるイベントログの閲覧2
n Sparkのイベントログの確認例
Jobの実行順やかかった時間を
視覚的に把握できる
ex.) 完了した最新のSparkアプリケーションログを確認する
1, dockerコンテナーにログイン
[root@node1i:/root]# docker exec -it dashDB bash
[root@node1i - dashDB /]#
2, 履歴サーバー起動シェル、ログディレクトリの検索
[root@node1i - dashDB /]# find / -name "start-history-server.sh"
/opt/ibm/dashdb_spark/spark/sbin/start-history-server.sh
[root@node1i - dashDB /]# find / -name "latest" -type l -user bluuser1
/mnt/bludata0/home/bluuser1/spark/log/latest
/mnt/blumeta0/home/bluuser1/spark/log/latest
3, 最新ログディレクトリのパスを引数に履歴サーバーの起動
[root@node1i - dashDB ~]# /opt/ibm/dashdb_spark/spark/sbin/start-history-server.sh
/mnt/bludata0/home/bluuser1/spark/log/latest/
starting org.apache.spark.deploy.history.HistoryServer, logging to
/opt/ibm/dashdb_spark/spark/logs/spark-root-
org.apache.spark.deploy.history.HistoryServer-1-node1i.jp.ibm.com.out
[root@node1i - dashDB ~]#
4, http://<host>:18080にアクセス（右図）
5, 履歴サーバーの停止
[root@node1i - dashDB ~]# /opt/ibm/dashdb_spark/spark/sbin/stop-history-server.sh
stopping org.apache.spark.deploy.history.HistoryServer
[root@node1i - dashDB ~]#
Jobの実行順序
実行経過時間

Jupyter Notebookによる対話的開発の流れ

Jupyter Notebook概要1
概要
Db2 Warehouseのホストサーバー上にJupyterを稼働するコンテナを
追加し、ブラウザでアクセスして開発を⾏う
ホストサーバー
Linux OS
Docker engine
Db2
Db2 Warehouseコンテナー
DSM DWH
Console
ファイルシステム
Jupyter Notebook環境のセットアップは「Jupyter Notebook(対話的開発環
境)の導⼊」を参照のこと
Jupyter
コンテナー
Jupyter
Notebook
MLlib
Scala Python

Jupyter Notebook概要2
n Jupyter NotebookによるTornadoデモの実行
n Notebookで対話的に開発する流れをTornadoデモで学習する
n サンプルを実行する準備
1. サンプルのNotebookをGithubから取得してJupyter Notebookにアップロード
2. サンプルデータの取得とロード
3. Jupyter Notebookでサンプルアプリケーションを実行

Jupyter NotebookによるTornadoデモの実行1
1. サンプルのNotebookファイルを取得
n 「Jupyter Notebookの導入」の手順に従って“git clone”した場合は、該当のディレク
トリから”Tornado_Clustering.ipynb“を取得
n クライアントPCで”git clone”をしていない場合はこのURLから取得
n wgetやリンク先のページをコピーペーストして ”Tornado_Clustering.ipynb” ファイルを作成する
2. Jupyter Notebookにアップロード
3. サンプルデータの取得とロード
n Tornadoデモのサンプルデータの実行手順はこちらを参照
クリックしてファイル選択
「Upload」をクリック
ファイルアップロード完了

n Tornadoデモ概要（データの確認と探索）
サンプル表を元にデモ用
TORNADOテーブルを生成
TORNADOテーブルのデータ取得
TORNADO表の緯度経度を元に
地図に描画
density(州ごとのトルネード発生数)
ごとに色を指定して、地図に描画
（左）取得したデータをそのまま表示
（右）州ごとのトルネード発生数を計算し、
densityに代入＋データ表示

n Tornadoデモ概要（機械学習ライブラリーの利用）
発生数が多いテキサス州にデータを絞って、発生傾向を分類する
発生箇所の緯度経度を使用して
KMeansでクラスター数を5つに設定して
クラスタリングモデルを生成する。
発生傾向の違いを分類した各クラスターの
重心を算出して、地図に描画する
テキサスのトルネードの発生データを
クラスターに割り当て、各クラスターに
属するデータ件数を取得してランク付けする

n Tornadoデモ概要（予測分析）
テキサスの不動産保険加入者のリスクをクラスターごとにスコアリングする
テキサスの保険加入者データを読み
込んでデータを確認し、地図に表示
モデルを適用し、保険加入者がどのクラスターに属すかを予測し、
結果をTEXUS_CUSTOMERS_SCOREDに保存
クラスタリングIDを元に地図に
保険加入者をマッピング
保険加入者が属する
リスククラスはクラスタ
リングIDで決まる

Jupyter Notebookからのデプロイ
§ デモモジュールをJupyter Notebookからデプロイ
アプリケーションからリアルタイムスコアリングするためにDWHにデプロイ
§ Jupyter Notebookからデプロイされたアプリケーションの実行
画面上部の「File」 > 「Deploy
as」 > 「Deploy to dashDB
Spark」をクリック
別タブが開かれ、デプロイ結果が出力される
spark-submit.sh / Stored Procedureで呼び
出すためのコマンドが出力される
実行結果は spark-submit.sh からログを取得して確認できる。

Analytic Stored Procedures

Analytic Stored Procedures
n DWHはSparkを使ったデータ分析用の関数を用意している
n Generated Linear Models ：一般化線形モデル
n 入力されたデータに基づく結果を分類するための統計手法
n 線形回帰モデルを拡張し、予測値と実測値の差異を最小限に抑えている
n TwoStep： TwoStepクラスタリング
n 大規模データセット用のデータマイニングアルゴリズム
n CF（Clustering Feature）ツリーに保存する前のデータセットのスキャンが1度だけなので、
従来の方法に比べて高速に行うことができる
n 実行するインターフェースはDWHのWebコンソール
1. DWHのWebコンソールにログインする
2. メニューから「Run SQL」を選択する
*
* GLMとTwoStepはSparkを使用する実装になっているので、
DWHのSparkが利用可能になっていることが前提。

サンプルデータの準備
1. サンプルテーブルの作成
1. DWHのWebコンソールで「Run SQL」を選択する
2. 添付ファイル”cre_tbl.sql”のADULTテーブル部分をコピーペーストして実行
3. メニューから「Load」 > 「Load from File」を選択する
（当資料に同梱されているファイルを使用する）
「Client」を選択して
ファイルを選択
「No」を選択して
「Preview」をクリック
データを確認したら「Next」
Schemaは「BLUUSER1」
「ADULT」テーブルを選択
「32561」件のデータが
入ったことを確認
「既存表にLoadする」で
「Next」

GLM (Generated Linear Model)のフロー
ADULT
ADULT_TEST ADULT_TRAIN
ADULT_MDL_GLM_SCORE
学習用データとテストデータに分割
学習用データを元にAGE列を予測する
予測分析モデルを生成する
予測分析モデルを元にテストデータの
AGE列を予測したテーブルを生成
ADULT_MDL_GLM_SCOREのPRED列
（ADULT_TESTのAGE列の予測値）と
ADULT_TESTのAGE列の値を比較ADULT_MDL_GLM_SCORE ADULT_TEST
ADULT_MDL_GLM

GLM (Generated Linear Model)1
2. モデル作成用(adult_train)と評価確認用(adult_test)データに分割
3. テーブルが生成され、データが分割されていることを確認
CALL IDAX.SPLIT_DATA('intable=adult, traintable=adult_train,
testtable=adult_test, id=id, fraction=0.35');

4. “adult_train”テーブルを元にAGE列を予測する”adult_mdl_glm”モデル
を生成
n
CALL IDAX.GLM('model=adult_mdl_glm, intable=adult_train, id=id,
target=age, link=identity, family=gaussian');

5. 生成されたモデルを確認
1. メニューから「Analytics」 > 「In-Database Analytics Models」を選択
2. 作成された”ADULT_MDL_GLM”をクリックし、モデルの情報を確認
1、
2、

6. “adult_mdl_glm”を使用して、”adult_test”のAGE列の値を予測し、
”adult_mdl_glm_score”テーブルを生成する
CALL IDAX.PREDICT_GLM('model= adult_mdl_glm, intable=adult_test,
id=id, outtable=adult_mdl_glm_score');

7. 最初に分割した”adult_test”のAGE列と、”adult_mdl_glm”を使用して
予測した”adult_mdl_glm_score”の予測値を比べる
SELECT s.id, s.pred, i.age from adult_test i, adult_mdl_glm_score s where
i.id=s.id;
モデルを使用して作成した
ADULT_TESTのAGE列の予測値
ADULT_TESTのAGE列

TwoStepのフロー
ADULT
ADULT_TEST ADULT_TRAIN
ADULT_MDL_GLM_SCORE
学習用データとテストデータに分割（済）
学習用データを元にデータをクラスタリング
するを予測分析モデルを生成する
予測分析モデルを元にテストデータを
クラスタリングしたテーブルを生成
ADULT_MDL_TWOSTEP

TwoStep1
1. “サンプルデータのロード”と”データの分割”は”GLM(Generated Linear
Model)1”を参照
2. “adult_train”テーブルを元に”adult_mdl_twostep”モデルを生成
CALL IDAX.TWOSTEP('model=adult_mdl_twostep, intable=adult_train,
id=id');

TwoStep2
3. メニューから「Analytics」 > 「In-Database Analytics Models」を選択し、
作成された”ADULT_MDL_TWOSTEP”をクリックし、モデルの情報を確認

TwoStep3
4. “adult_mdl_twostep”に従って、各行にクラスターIDを付与する
CALL IDAX.PREDICT_TWOSTEP('model= adult_mdl_twostep,
intable=adult_test, id=id, outtable=adult_mdl_twostep_score');

TwoStep4
5. “adult_mdl_twostep_score”テーブルのデータを確認する
1. メニューから「Administer」 > 「Tables」を選択
2. 「Filter by Name」に”adult_mdl_twostep_score”を入力し、テーブルを選択
3. 「Generate SQL」をクリックし、表示されたダイアログで
「SELECT statement」を選択して「OK」

TwoStep4
4. 自動生成されたSQLを実行する
モデルを使用して作成した
ADULT_TESTのクラスターID
元のADULT_TESTのID列

補⾜資料
§ チュートリアルの実⾏例
§ 添付ファイル「チュートリアル実⾏ログ.xlsx」を参照

Db2 Warehouse Spark利用ガイドチュートリアル編

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Db2 Warehouse Spark利用ガイドチュートリアル編

Similaire à Db2 Warehouse Spark利用ガイドチュートリアル編 (20)

Plus de IBM Analytics Japan

Plus de IBM Analytics Japan (20)

Dernier

Dernier (12)