Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Db2 Warehouse Spark利用ガイド チュートリアル編

111 views

Published on

Db2 Warehouseは分析用途に最適化されたDockerコンテナで提供されるDWHソフトウェアアプライアンスです。Db2 Warehouseコンテナ内にはSparkが統合されており、Spark上でPythonやScalaを使用した分析アプリケーションの実行が可能です。本ガイドはDb2 Warehouse, Spark, Jupyter Notebookによる機械学習プログラムの始め方、利用ガイドを紹介しています。

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Db2 Warehouse Spark利用ガイド チュートリアル編

  1. 1. © 2017 IBM Corporation Db2 Warehouse Spark利⽤ガイド チュートリアル編 IBMシステムズ・エンジニアリング 2017/10/11
  2. 2. © 2017 IBM Corporation2 ⽬次 § Sparkアプリケーションの作成と実⾏ - チュートリアル - Jupyter Notebookによる対話的開発の流れ - Analytic Stored Proceduresの実⾏ § 補⾜資料 - チュートリアルの実⾏例
  3. 3. © 2017 IBM Corporation3 Sparkアプリケーションの作成と実⾏
  4. 4. © 2017 IBM Corporation4 § チュートリアル § RESTツールの準備 § サンプルアプリケーションのロード § アプリケーションのデプロイ / 依存モジュールの管理 § アプリケーションの実⾏ § SparkのJob監視 / 停⽌ § アプリケーションの実⾏結果・ログ参照 § アプリケーションの削除 § SQLによるSparkへの処理リクエスト § Jupyter Notebookによる対話的開発の流れ § Jupyter Notebook概要 § Jupyter NotebookによるTornadoデモの実⾏ § Jupyter Notebookからのデプロイ § Analytic Stored Proceduresの実⾏ § TwoStep § GLM Sparkアプリケーションの作成と実⾏
  5. 5. © 2017 IBM Corporation5 チュートリアル
  6. 6. © 2017 IBM Corporation6 チュートリアル概要説明 § Db2 Warehouseに統合されたSpark環境を利⽤する場合のアプリケー ションライフサイクルを、チュートリアルに従って学習する § RESTツールの準備 Db2 WarehouseにSparkで記述したアプリケーションを投⼊するためのspark-submit.shをセットアップします spark-submit.shからDb2 WarehouseへのリクエストにはRESTが利⽤されます § サンプルアプリケーションのロード チュートリアルで使⽤するアプリケーションをDb2 Warehouseにダウンロードします § アプリケーションのデプロイ / 依存モジュールの管理 アプリケーション、依存モジュールのデプロイをします § アプリケーションの実⾏ アプリケーション単体で実⾏、依存モジュールを呼び出して実⾏します § SparkのJob監視 / 停⽌ アプリケーションを実⾏した時のSparkの動きを確認します § アプリケーションの実⾏結果・ログ参照 アプリケーションの実⾏結果、出⼒ログを確認します § アプリケーションの削除 デプロイ済みのアプリケーション、依存モジュールを削除します
  7. 7. © 2017 IBM Corporation7 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環境を準備するか、他のインターフェースによるリクエスト(補足資料)も可能。
  8. 8. © 2017 IBM Corporation8 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>
  9. 9. © 2017 IBM Corporation9 サンプルアプリケーションのロード § 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
  10. 10. © 2017 IBM Corporation10 アプリケーションのデプロイ / 依存モジュールの管理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になる *
  11. 11. © 2017 IBM Corporation11 アプリケーションのデプロイ / 依存モジュールの管理2 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 実行手順を次ページに記載
  12. 12. © 2017 IBM Corporation12 アプリケーションのデプロイ / 依存モジュールの管理3 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で指定する必要がある
  13. 13. © 2017 IBM Corporation13 アプリケーションの実行 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>
  14. 14. © 2017 IBM Corporation14 SparkのJob監視 / 停止1 n 稼働中のアプリケーションのクラスターの動きを確認することができる n DWHのWebコンソールから確認する 1. “https://<host>:8443/”でログイン 2. 画面左のメニューから「Monitor」 > 「Workloads」 をクリック 3. 中央エリアの左上「概説」 > 「Spark」をクリックし、対象ユーザーをクリックする 1、 2、 3、
  15. 15. © 2017 IBM Corporation15 SparkのJob監視 / 停止2 n 稼働中のアプリケーションのクラスターの動きを確認することができる n SparkのWebコンソールから確認する n “https://<host>:8443/”でDWHのWebコンソールにログイン 稼働中のアプリケーションの”Name”をクリックすると クラスターの処理がモニターできる 処理が全て完了すると”Completed Applications”の欄に追加 される。 クラスターが行なっているJobの状態を確認することができる
  16. 16. © 2017 IBM Corporation16 SparkのJob監視 / 停止3 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>
  17. 17. © 2017 IBM Corporation17 SparkのJob監視 / 停止4 n 稼働中のアプリケーションを停止する n SparkのWebUIからJobを停止する 1. 「SparkのJob監視 / 停止1」の手順と同様にSparkのWebコンソールを開く 2. 「Running Applications」の「(kill)」をクリックする 3. 「Completed Applications」で停止した「Application ID」を持つアプリケーションが 「KILLED」になっていることを確認する
  18. 18. © 2017 IBM Corporation18 SparkのJob監視 / 停止5 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の確認 アプリケーションの停止 停止状態になっている
  19. 19. © 2017 IBM Corporation19 アプリケーションの実行結果・ログ参照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を含むログ アプリケーションの標準出力 直近のアプリケーション実行ログ(リンク)
  20. 20. © 2017 IBM Corporation20 アプリケーションの実行結果・ログ参照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>
  21. 21. © 2017 IBM Corporation21 アプリケーションの削除 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>
  22. 22. © 2017 IBM Corporation22 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');
  23. 23. © 2017 IBM Corporation23 SQLによるSparkへの処理リクエスト 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’);
  24. 24. © 2017 IBM Corporation24 SQLによるSparkへの処理リクエスト 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();
  25. 25. © 2017 IBM Corporation25 【参考】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 次ページに起動例を記載
  26. 26. © 2017 IBM Corporation26 【参考】 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 /]# [root@node1i - dashDB /]# find / -name "latest" -type l -user bluuser1 /mnt/bludata0/home/bluuser1/spark/log/latest /mnt/blumeta0/home/bluuser1/spark/log/latest [root@node1i - dashDB /]# 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の実行順序 実行経過時間
  27. 27. © 2017 IBM Corporation27 Jupyter Notebookによる対話的開発の流れ
  28. 28. © 2017 IBM Corporation28 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
  29. 29. © 2017 IBM Corporation29 Jupyter Notebook概要2 n Jupyter NotebookによるTornadoデモの実行 n Notebookで対話的に開発する流れをTornadoデモで学習する n サンプルを実行する準備 1. サンプルのNotebookをGithubから取得してJupyter Notebookにアップロード 2. サンプルデータの取得とロード 3. Jupyter Notebookでサンプルアプリケーションを実行
  30. 30. © 2017 IBM Corporation30 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」をクリック ファイルアップロード完了
  31. 31. © 2017 IBM Corporation31 Jupyter NotebookによるTornadoデモの実行2 n Tornadoデモ概要(データの確認と探索) サンプル表を元にデモ用 TORNADOテーブルを生成 TORNADOテーブルのデータ取得 TORNADO表の緯度経度を元に 地図に描画 density(州ごとのトルネード発生数) ごとに色を指定して、地図に描画 (左)取得したデータをそのまま表示 (右)州ごとのトルネード発生数を計算し、 densityに代入+データ表示
  32. 32. © 2017 IBM Corporation32 Jupyter NotebookによるTornadoデモの実行3 n Tornadoデモ概要(機械学習ライブラリーの利用) 発生数が多いテキサス州にデータを絞って、発生傾向を分類する 発生箇所の緯度経度を使用して KMeansでクラスター数を5つに設定して クラスタリングモデルを生成する。 発生傾向の違いを分類した各クラスターの 重心を算出して、地図に描画する テキサスのトルネードの発生データを クラスターに割り当て、各クラスターに 属するデータ件数を取得してランク付けする
  33. 33. © 2017 IBM Corporation33 Jupyter NotebookによるTornadoデモの実行4 n Tornadoデモ概要(予測分析) テキサスの不動産保険加入者のリスクをクラスターごとにスコアリングする テキサスの保険加入者データを読み 込んでデータを確認し、地図に表示 モデルを適用し、保険加入者がどのクラスターに属すかを予測し、 結果をTEXUS_CUSTOMERS_SCOREDに保存 クラスタリングIDを元に地図に 保険加入者をマッピング 保険加入者が属する リスククラスはクラスタ リングIDで決まる
  34. 34. © 2017 IBM Corporation34 Jupyter Notebookからのデプロイ § デモモジュールをJupyter Notebookからデプロイ アプリケーションからリアルタイムスコアリングするためにDWHにデプロイ § Jupyter Notebookからデプロイされたアプリケーションの実行 画面上部の「File」 > 「Deploy as」 > 「Deploy to dashDB Spark」をクリック 別タブが開かれ、デプロイ結果が出力される spark-submit.sh / Stored Procedureで呼び 出すためのコマンドが出力される 実行結果は spark-submit.sh からログを取得して確認できる。
  35. 35. © 2017 IBM Corporation35 Analytic Stored Procedures
  36. 36. © 2017 IBM Corporation36 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が利用可能になっていることが前提。
  37. 37. © 2017 IBM Corporation37 サンプルデータの準備 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」
  38. 38. © 2017 IBM Corporation38 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
  39. 39. © 2017 IBM Corporation39 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');
  40. 40. © 2017 IBM Corporation40 GLM (Generated Linear Model)2 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');
  41. 41. © 2017 IBM Corporation41 GLM (Generated Linear Model)3 5. 生成されたモデルを確認 1. メニューから「Analytics」 > 「In-Database Analytics Models」を選択 2. 作成された”ADULT_MDL_GLM”をクリックし、モデルの情報を確認 1、 2、
  42. 42. © 2017 IBM Corporation42 GLM (Generated Linear Model)4 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');
  43. 43. © 2017 IBM Corporation43 GLM (Generated Linear Model)5 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列
  44. 44. © 2017 IBM Corporation44 TwoStepのフロー ADULT ADULT_TEST ADULT_TRAIN ADULT_MDL_GLM_SCORE 学習用データとテストデータに分割(済) 学習用データを元にデータをクラスタリング するを予測分析モデルを生成する 予測分析モデルを元にテストデータを クラスタリングしたテーブルを生成 ADULT_MDL_TWOSTEP
  45. 45. © 2017 IBM Corporation45 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');
  46. 46. © 2017 IBM Corporation46 TwoStep2 3. メニューから「Analytics」 > 「In-Database Analytics Models」を選択し、 作成された”ADULT_MDL_TWOSTEP”をクリックし、モデルの情報を確認
  47. 47. © 2017 IBM Corporation47 TwoStep3 4. “adult_mdl_twostep”に従って、各行にクラスターIDを付与する CALL IDAX.PREDICT_TWOSTEP('model= adult_mdl_twostep, intable=adult_test, id=id, outtable=adult_mdl_twostep_score');
  48. 48. © 2017 IBM Corporation48 TwoStep4 5. “adult_mdl_twostep_score”テーブルのデータを確認する 1. メニューから「Administer」 > 「Tables」 を選択 2. 「Filter by Name」に”adult_mdl_twostep_score”を入力し、テーブルを選択 3. 「Generate SQL」をクリックし、表示されたダイアログで 「SELECT statement」を選択して「OK」
  49. 49. © 2017 IBM Corporation49 TwoStep4 4. 自動生成されたSQLを実行する モデルを使用して作成した ADULT_TESTのクラスターID 元のADULT_TESTのID列
  50. 50. © 2017 IBM Corporation50 補⾜資料 § チュートリアルの実⾏例 § 添付ファイル「チュートリアル実⾏ログ.xlsx」を参照

×