[db tech showcase Tokyo 2017] D15: ビッグデータｘ機械学習の高速分析をVerticaで実現！by ヒューレット・パッカードエンタープライズ大林加奈子

ビッグデータ × 機械学習
の高速分析をVerticaで実現！
Kanako Obayashi, Micro Focus
Sep 5, 2017

本セッションの内容
1. はじめに
2. WHY Vertica＋機械学習？
3. 実装例①：Verticaで実装するPredictive Maintenance（予知保全）
4. WHY Vertica＋地理空間分析？
5. 実装例②：Verticaで実装する地理空間分析
6. まとめ
2

時代と共に高まる分析基盤への要求
3
データドリブン経営の分析基盤
• 定型レポーティング中心
• 実績を事前集計し、見える化
• 前日までのデータ分析
• 扱うデータ種類、量は少ない
• 分析対象期間は短い
• 部門内の少人数で利用
ビッグデータ分析基盤BI/DWH
• 非定型・複雑な分析中心
• 過去データから洞察を得る
• 数分・数時間前のデータを分析
• 扱うデータの多様化・肥大化
• 長期的なトレンドの把握
• 幅広いユーザー層で利用
• OLTP向けRDBMS
（行指向RDBMS）
• DWHアプライアンス
• OLAP向けRDBMS
（列指向RDBMS）
• Hadoopソリューション
• インメモリーソリューション
• クラウド型DWH
• 機械学習、AI技術を活用した分析
• 未来予測に活用
• リアルタイム分析
• IoT、位置情報、SNSデータ等
• より長期的なトレンドの把握
• プロアクティブ検知・自動化
• OLAP向けRDBMS
（列指向RDBMS）
• Hadoopソリューション
• インメモリーソリューション
• クラウド型DWH
• 専用ソリューション（AI, GIS等）
過去現在近い将来
分
析
要
件
対
応
技
術

時代と共に高まる分析基盤への要求
4
データドリブン経営の分析基盤
• 定型レポーティング中心
• 実績を事前集計し、見える化
• 前日までのデータ分析
• 扱うデータ種類、量は少ない
• 分析対象期間は短い
• 部門内の少人数で利用
ビッグデータ分析基盤BI/DWH
• 非定型・複雑な分析中心
• 過去データから洞察を得る
• 数分・数時間前のデータを分析
• 扱うデータの多様化・肥大化
• 長期的なトレンドの把握
• 幅広いユーザー層で利用
• 機械学習、AI技術を活用した分析
• 未来予測に活用
• リアルタイム分析
• IoT、位置情報、SNSデータ等
• より長期的なトレンドの把握
• プロアクティブ検知・自動化
過去現在近い将来
分
析
要
件
対
応
技
術
全ての領域をカバーするVerticaソリューション
初めは小さくスモールスタートで開始し
ビジネスの成長と共にリニアに拡張して行く事が可能
DWH
Modernization
Advanced
Analytics

Vertica（ヴァーティカ）のコアテクノロジーとは？
5
高度な圧縮
標準SQLイン
ターフェー
ス
列指向
自動データ
ベース設計
高可用性
MPP
（超並列処
理）
BI、ETL、
Hadoop/MapReduce等の
既に投資している環境
を活用
ディスクのI/Oボトル
ネックがなく、ロード
とクエリが高速に同時
実行可能
低コストのx86 Linuxノ
ードでのネイティブな
DBレベルでのクラスタ
リング
10個以上のアルゴリズ
ムを駆使して最大90％
のスペース削減
ツールを起動するの
みで自動データベー
ス最適化、最適化自
動検知
複数サーバー停止中も
継続運用可能とする全
てのノードがマスター
ノードとなる冗長性
 従来のRDBMSよりも
50倍〜1000倍高速
 業界標準のハード
ウェアにで、TBから
PBまで拡張可能
 既存のETLおよびBIソ
リューションとのシ
ンプルな統合
 SQL99準拠
 機械学習の関数など
も含む高度な分析関
数
 24時間365日、継続
ロード、クエリ実行
可能

大規模データに対する機械学習処理を高速に！
SQL機能を他の言語から
呼び出せるようにラッパーを提供
※GitHubにて提供
 Verticaのコアエンジンに組み込まれており、インストールやメンテナンス不要
ですぐに使用可能
 データ準備（前処理）、モデリング、評価、実装すべてをSQLで実行可能
 既にVertica内に格納されている大容量のデータをその場で分析可能（従来型製
品での機械学習アプローチのようなダウンサンプリングは不要）
 RやPythonで作成済みのロジックも再利用可能
 機械学習処理はVertica MPPクラスター内
で並列処理
 高速反復演算のためのインメモリー処理
 多くの同時セッションのリソース分離
7
Node 1 Node 2…. Node n

Vertica機械学習はSparkよりも高速で高拡張性
 アルゴリズム実行開始時に、テーブルデータをメモ
リーにキャッシュし、高速に反復演算を実行
 Verticaのコア機能として動作実証済の安定したワー
クロード管理機能により、使用メモリーや並行実行
数を完全制御
 各ノードで稼動する並列スレッド数の制御も可能
 処理対象データがメモリーに収まりきれなかった場
合は、自動的にDisk上の処理へと移行
（Sparkで必要となる、煩雑なメモリーパラメーター
チューニング、Out of memoryを回避するための試行
錯誤は不要）
 右図はVertica8.1.0とSpark2.1.0 MLibでのパフォーマン
ステスト結果となるが、Sparkでの結果はHDFSからメ
モリーにデータをロードする時間は含まれていない
8

Vertica上での機械学習アルゴリズムの処理概要
9
blobsメモリの
作成
UDX1呼び出
し
UDX2呼び出
し
サマライズ
マスター
（イニシエーターノード）
UDX1
UDX2
モデル
トレーニン
グデータ
ワーカー
Blobs

実際のSQL実行例
10
SELECT logistic_reg('public.fasttrack',
'PREDICTIVEMAINT.readings', '"asset_status"',
'temperature, powerfactor, airflow, pressure, vibration'
);

自動で最適化された一連の処理が実行される
11
select logistic_reg( 'fasttrack', 'PREDICTIVEMAINT.readingssample', 'asset_status', 'temperature, powerfactor,
airflow, pressure, vibration' ) ;
SELECT table_to_blob("asset_status","temperature","powerfactor","airflow","pressure","vibration" USING
PARAMETERS blob_name='fasttrack') OVER(PARTITION BEST) FROM (SELECT * FROM (SELECT *
FROM (SELECT "asset_status","temperature","powerfactor","airflow","pressure","vibration" FROM
PREDICTIVEMAINT.readingssample WHERE (NOT "asset_status" IS NULL AND NOT "temperature" IS NULL AND NOT
"powerfactor" IS NULL AND NOT "airflow" IS NULL AND NOT "pressure" IS NULL AND NOT "vibration" IS NULL) AND
("asset_status"=0 OR "asset_status"=1)) as filtered1 WHERE NOT "temperature"='inf' AND NOT "powerfactor"='inf'
AND NOT "airflow"='inf' AND NOT "pressure"='inf' AND NOT "vibration"='inf') as filtered2 WHERE NOT
"temperature"='-inf' AND NOT "powerfactor"='-inf' AND NOT "airflow"='-inf' AND NOT "pressure"='-inf' AND NOT
"vibration"='-inf') as filtered3;
（略）
SELECT public.reg_final_newton(xTransAz, xTransAx, deviance USING PARAMETERS
model_name='fasttrack', family=2, epsilon=1e-06, theLastIteration='false',
iterationNumber=-1, dimension=6) OVER() FROM (SELECT
public.reg_transition_newton( USING PARAMETERS model_name='fasttrack', family=2,
iterationNumber=-1, dimension=6, nodes='"v_testdrive_node0001";8')) AS udctf1;
（略）
SELECT public.reg_write_model('temperature','powerfactor','airflow','pressure','vibration' USING PARAMETERS
model_name='fasttrack', family=2, dimension=6, iterations=21, skippedRows=71,
processedRows=982, call='logistic_reg(''fasttrack'', ''PREDICTIVEMAINT.readingssample'', ''"asset_status"'',
''temperature, powerfactor, airflow, pressure, vibration''
SELECT remove_blob(USING PARAMETERS blob_name='fasttrack');
手動実行SQL
自動実行SQL

データ準備～高度な分析を支える豊富なツール
 Copy
 Flex Tables
 External Tables
 パーサー: Avro, CEF, CSV,
Delim, JSON, RegEX
 Kafka統合を含むスト
リーミングユーティリ
ティ
 S3 & ABS
 ORC, Parquet, HIVE, Spark
RDD & DF
 シェープファイル & ス
ペーシャルデータ
12
キャプチャ＆エンリッチ測定 & 準備モデル & デプロイ
 1000個を超える関数
 タイムシリーズ (GFI,
Interpolation, Slicing,
TSA)
 Sessionize
 パターンマッチング
 イベントシリーズ結合
 高度な集計
 日時の代数
 ウインドウ & パーティ
ション
 統計 & 数学
 文字列
 シークエンス
 地理空間、結合、変換
 バランシング
 サンプリング
 外れ値検出
 正規化
 欠損値の補完
 線形回帰
 ロジスティック回帰
 K-Means
 ナイーブベイズ
 SVM（サポートベクターマ
シン）
 ランダムフォレスト
 モデル評価 & 可視化
 モデル管理
 UDX 関数
 テキスト分析
ANSI SQL標準 - MPP実行のために開発されたアルゴリズム - PBスケールでのリレーショナル構造

13
シンプルなSQLで
機械学習を取り入れた
高速分析システム
を構築可能！

実装例①：Verticaで実装する
Predictive Maintenance（予知保全）
～冷却塔の予知保全～

Predictive Maintenance（予知保全）とは？
機器に取り付けたセンサーから取得した
データを継続的に監視し、故障が発生する
前に発生しうる故障を予測、検知し、メン
テナンス実施
機器の稼働率の増加、メンテナンスコスト
の削減、適切なメンテナンスの実施などに
寄与
15

冷却塔？
 ビル空調や地域冷暖房設備である冷凍機の冷却水を冷却するために用い
られる
16

ロジスティック回帰とは？
 最も基本的で一般的な二項分類（true/false, pass/fail, yes/no, 1/0）
 独立変数のセット（予測変数）の値に基づいて結果（バイナリ応答）の確率を計算
 予測変数とバイナリ応答の関係の強さを調査
17
η = c0 + c1 x1 + c2 x2 + c3 x3 + … + cn xn
y = logit -1(η) * logit -1(α) = 1/(1+e –α)
y: 応答変数
xi: 予測変数
ci: 係数
c0: 切片
本日ご紹介する実装例では、ロジスティック回帰分析を使用し、装
置からの定期的なセンサーの測定値に基づいて、故障する可能性が
ある冷却塔を予測

デモシステム概要（初期状態）
18
冷却塔の
センサーデータ
（測定値）
初期データロード
機械学習をベース
としたSQLクエリで
モデルを作成
HTTPD＆PHPを使用し、Web画
面上に冷却塔のステータス表示
としたSQLクエリで、
予測
テーブル作成

デモシステム概要（シミュレーター作動後）
19
冷却塔の
センサーデータ
（測定値）
追加データロード
※いったん初期データ
は削除後、ロード開始
一定間隔で、機械学
習をベースとした
SQLクエリで最新
データをサンプリン
グしたデータを用い、
モデルを最適化
HTTPD＆PHPを使用し、Web画
面上に冷却塔のステータス表示
としたSQLクエリで、
オリジナルのモデ
ルを用い予測
ニアリアルタイム表示
追加センサーデータ生成

デモンストレーション
20
サマリー情報
タワーマップ
ステータスチャート

事前準備：テーブル作成
1. テーブルを作成する。
21
=> i create_predictivemaint_schema_ddl.sql
create table PREDICTIVEMAINT.initial_readings (
reading_id identity(1, 1),
asset_id varchar(32),
unixtimestamp int,
asset_status int,
temperature_sensor varchar(16),
temperature float,
powerfactor_sensor varchar(16),
powerfactor float,
airflow_sensor varchar(16),
airflow float,
pressure_sensor varchar(16),
pressure float,
vibration_sensor varchar(16),
vibration float,
maintenance int,
batch_id int );
例：create_predictivemaint_schema_ddl.sqlの内容
下記いずれかの方法で、標準SQLでテーブルを作成
• Vertica専用のvsqlクライアントツール or マネージ
メントコンソール
• ODBC/JDBC接続などで接続する一般的な開発ツー
ル

事前準備：データロード
2. データをロードする。
22
=> i load_initial_predictivemaint_data.sql
copy PREDICTIVEMAINT.asset (
asset_id,
asset_tag,
description,
asset_tp_cd,
model,
manufacturer,
serial_no,
parent_asset_id,
valid_from,
valid_to,
cd filler varchar(20),
lud filler varchar(20),
last_update_by,
last_update_txid
)
from '/home/dbadmin/TestDrive/PredictiveMaint/ASSET.csv' delimiter ',' null '';
例： load_initial_predictivemaint_data.sqlの内容
COPYステートメントを使用し、データロード

事前準備：モデル作成と初期データ格納
3. ロジスティック回帰分析を使ってモデルを作成し、結果を格納する。
23
=> i create_model_logisticReg_ins_riskscores.sql
select logistic_reg('public.fasttrack', 'PREDICTIVEMAINT.readings', 'asset_status', 'temperature,
powerfactor, airflow, pressure, vibration');
insert into PREDICTIVEMAINT.riskscores (
reading_id,
asset_id,
･･･
riskscore
) select
reading_id,
asset_id,
predict_logistic_reg( temperature, powerfactor, airflow, pressure, vibration
using parameters model_name=‘fasttrack’, type='probability'
) as riskscore from PREDICTIVEMAINT.readings;
commit;
例： load_initial_predictivemaint_data.sqlの内容
LOGISTIC_REG関数を用い、ロジスティック
関数のモデルを作成
PREDICT_LOGISTIC_REG関数を用い、作成したロジス
ティック関数のモデルを用い予測した結果を
riskscoresテーブルに挿入

LOGISTIC_REG関数
24
SELECT logistic_reg('public.fasttrack',
'PREDICTIVEMAINT.readings', '"asset_status"',
USING PARAMETERS optimizer='newton', epsilon=1e-06,
max_iterations=100)
モデル名
入力テーブル
応答因子カラム
予測因子カラム
デフォルトパラメーター

PREDICT_LOGISTIC_REG関数
25
predict_logistic_reg
( temperature, powerfactor, airflow, pressure, vibration
using parameters model_name=‘fasttrack’,
type='probability'
) as riskscore
･･･
from PREDICTIVEMAINT.readings
モデル名
カラム指定
確率で出力

初回実行時に作成されたモデル
26
coeff names : {Intercept, temperature, powerfactor, airflow, pressure,
vibration}
coeffecients: {45.99255759, 0.06847892311, -47.53683713, -28.53484928,
0.03093668099, 67.59858138}
std_err: {0.734, 0.0005564, 0.3212, 0.688, 0.0002042, 0.4199}
z_value: {62.66, 123.1, -148, -41.48, 151.5, 161}
p_value: {< 1e-20, < 1e-20, < 1e-20, < 1e-20, < 1e-20, < 1e-20}
Number of iterations: 13, Number of skipped samples: 0, Number of processed
samples: 9999034
Call:
logistic_reg('public.fasttrack', 'PREDICTIVEMAINT.readings', '"asset_status"',
USING PARAMETERS optimizer='newton', epsilon=1e-06, max_iterations=100)
モデル作成時実行コマンド
係数の値
予測変数
標準誤差
z値と p値

最適化されたモデル例
27
coeff names : {Intercept, temperature, powerfactor, airflow, pressure,
vibration}
coeffecients: {13.22423646, 0.01734242756, -52.3965672, 11.60618362,
0.03421253392, 77.54870382}
std_err: {40.63, 0.0388, 23.66, 37.8, 0.0124, 31.77}
z_value: {0.3254, 0.447, -2.215, 0.3071, 2.759, 2.441}
p_value: {0.7448, 0.6549, 0.02676, 0.7588, 0.00579, 0.01466}
Number of iterations: 12, Number of skipped samples: 44, Number of processed
samples: 1022
Call:
logistic_reg('fasttrack_1504516602', 'PREDICTIVEMAINT.readingssample',
'"asset_status"', 'temperature, powerfactor, airflow, pressure, vibration'
USING PARAMETERS optimizer='newton', epsilon=1e-06, max_iterations=100)
モデル作成時実行コマンド

画面概要（サマリー情報）
 実行中の冷却塔の数とその状態を表示
 3つの状態は、「実行中」、「リスクがある」（予測モデルに基づく）、また
は「停止中」のいずれか
28

サマリー情報表示SQL
29
=> SELECT CASE
WHEN asset_status = 1
THEN 'DOWN'
WHEN asset_status = 0
AND r.riskscore > 0.1
THEN 'ATRISK'
ELSE 'OK'
END AS STATUS
,COUNT(*)
FROM PREDICTIVEMAINT.riskscores r
WHERE r.unixtimestamp = (
SELECT unixtimestamp
FROM PREDICTIVEMAINT.riskscores
GROUP BY unixtimestamp
ORDER BY unixtimestamp DESC
offset 1 limit 1
)
GROUP BY STATUS;
status | COUNT
--------+-------
OK | 19926
ATRISK | 33
DOWN | 41
(3 rows)

画面概要（タワーマップ）
 マップ上に表示されている点は、米国内に広が
る冷却塔の位置を表示
 「赤」の点は、塔がダウンしている意
 ダッシュボードページ上で小さな地図をクリッ
クすると、地図がフルスクリーンで表示される
 フルスクリーンモードにすると、地図上の点を
クリックしてその場所にあるすべての塔を見る
ことで、ある場所にドリルスルーする可能
 マップの右側のバーに、Vertica上のクエリ実行
時間を表示
30

タワーマップ情報表示SQL
31
SELECT ROUND(a.latitude_degrees, 1) AS latitude
,ROUND(a.longitude_degrees, 1) AS longitude
,r.asset_status
,a.city_name AS city
,a.prov_state_tp_cd AS stateprov
,COUNT(*) AS tooltip_content
,TO_CHAR(MAX(CASE
WHEN
r.asset_status = 1
THEN
1.0
ELSE r.riskscore
END), 'FM0.0999')
AS riskvalue
FROM PREDICTIVEMAINT.riskscores r
LEFT JOIN PREDICTIVEMAINT.assetlocation al ON al.asset_id
= r.asset_id
LEFT JOIN PREDICTIVEMAINT.orgname o ON o.org_name_id =
al.asset_owner
LEFT JOIN PREDICTIVEMAINT.address a ON a.address_id =
o.address_id
WHERE (
(
a.latitude_degrees BETWEEN 25
AND 49
AND a.longitude_degrees
BETWEEN - 125
AND - 67
)
OR a.prov_state_tp_cd IN (
'AK'
,'HI'
)
)
AND r.unixtimestamp = (
SELECT unixtimestamp
FROM PREDICTIVEMAINT.riskscores
GROUP BY unixtimestamp
ORDER BY unixtimestamp DESC offset 1
limit 1
)
GROUP BY latitude
,longitude
,r.asset_status
,a.city_name
,a.prov_state_tp_cd
ORDER BY riskvalue DESC;

タワーマップ情報表示SQL
32
latitude | longitude | asset_status | city | stateprov | tooltip_content | riskvalue
----------+-----------+--------------+-----------------------+-----------+-----------------+-----------
34 | -118.5 | 1 | LOS ANGELES | CA | 1 | 1.0
36 | -86.8 | 1 | BRENTWOOD | TN | 1 | 1.0
34 | -84.2 | 1 | NORCROSS | GA | 1 | 1.0
41.2 | -96.1 | 1 | OMAHA | NE | 1 | 1.0
41.1 | -85.1 | 1 | FORT WAYNE | IN | 1 | 1.0
40.7 | -74 | 1 | NEW YORK | NY | 2 | 1.0
40 | -83.1 | 1 | COLUMBUS | OH | 1 | 1.0
39.7 | -75.6 | 1 | NEW CASTLE | DE | 1 | 1.0
45 | -93.3 | 1 | MINNEAPOLIS | MN | 1 | 1.0
40.3 | -74.1 | 1 | RED BANK | NJ | 1 | 1.0
45.5 | -122.7 | 1 | PORTLAND | OR | 1 | 1.0
37.4 | -121.9 | 1 | SAN JOSE | CA | 1 | 1.0
41.6 | -85.8 | 1 | GOSHEN | IN | 1 | 1.0
40.8 | -74 | 1 | NEW YORK | NY | 2 | 1.0
40 | -75.4 | 1 | RADNOR | PA | 1 | 1.0
43 | -85.7 | 1 | GRAND RAPIDS | MI | 1 | 1.0
41.1 | -76.2 | 1 | BERWICK | PA | 1 | 1.0
39.6 | -104.9 | 1 | GREENWOOD VILLAGE | CO | 1 | 1.0
25.8 | -80.2 | 1 | MIAMI | FL | 1 | 1.0
47.6 | -122.3 | 1 | SEATTLE | WA | 1 | 1.0
40.7 | -73.9 | 1 | NEWARK | NJ | 1 | 1.0
・・・

画面概要（ステータスチャート）
 タワーの状態が、OK、At-RiskあるいはDownで
あることの時系列情報をパーセンテージで表
示
 100％で開始
 時間の経過と共にシミュレーションを表示す
るため、チャートは数日間スケールのもの
 グラフをクリックすると大きく表示可能
33

画面概要（実行統計情報と最新のモデル係数）
 実行の統計情報および最新のモデルの係数を表示
 実行の統計情報については、センサー読み取り値の合計
数および全体の実行時間を表示
34

画面概要（冷却塔の詳細情報）
 サマリーボタンの1つをクリックすると詳細を表示
35
At Riskをクリックし、リスクが
ある冷却塔の詳細情報を表示

シミュレーター概要
パラメーター概要
冷却塔数
Towers to launch
冷却塔の数を指定。タワーが多いほど、繰り返しの度にVerticaが取り込むデータを多
くするシミュレーションが可能。例えば、タワーごとに5つのセンサーを使用して5万
のタワーを打ち上げると、繰り返しごとに25万回の読み取りが行われる
測定値データの取り込み間隔（実際の秒数）
Real seconds between readings
タワーの測定値がどれくらいの間隔で取得されるかを制御。シミュレーションでは日、
週、および月にスケールアウトされた結果が表示される
シミュレーション終了前の測定値読み取り数
Readings to take before quitting
シミュレーション中に実行される反復回数。たとえば、3秒ごとに測定値を取り込む
とすると、この値を1,200とすると、シミュレーションは1時間実行される
タワー故障の確率
Probability of a tower failure
冷却塔の動作が不安定となり、最終的に故障するまでの傾向を制御。数値が大きい
ほど、タワーが劣化し始める可能性が高くなる
自動メンテナンスの遅延
Automatic maintenance delay
タワーが不安定になり始めると、ランダムな間隔で自動でトリガーされるメンテナン
スイベントをコントロール。これがいつ発生するかは正確には制御できないが、係数
を高い値に設定すると、メンテナンスイベントまでに時間がかかることになり、よっ
て、より多くのタワーが壊れることになる。これを低い値に設定すると、メンテナン
スイベントが平均してより速く発生する
一定の読み取り数ごとのモデルのリフレッシュ間
隔
Model refresh after every # of readings
FastTrackシミュレーターが実行されている間、ロジスティック回帰（予測）モデル
は、ここで指定した読み取りレコード数ごとに更新される
表示リフレッシュ間隔（秒）
Display refresh (in seconds)
指定された間隔でデータのページリフレッシュを制御
36

今すぐ実際に動かせます！
 下記ページより、4時間以内であれば自由に使用可能なテストドライブ
にアクセス可能！
https://aws.amazon.com/jp/testdrive/hpe/
37

WHY Vertica＋地理空間分析？

大規模データに対する地理空間分析を高速に！
 Verticaのコアエンジンに組み込まれており、インストールやメンテナンス不要
ですぐに使用可能
 使い慣れたSQLインターフェースで、様々な業界標準フォーマットやツールと
シームレスに連携可能
 地理空間分析を実行するために、他の製品へデータを受け渡す必要はなく、既
にVertica内に格納されている大容量のデータをその場で分析可能
（従来のアプローチでは、多くのデータポイントを処理することは困難であり、分析者は小さなデータ
セットでの分析を余儀なくされていた）
 MPPアーキテクチャーとの高い親和性 –
Geospatial機能は数十、数百台のVertica
クラスターでパラレルに実行可能
 多くの同時に実行されるクエリーセッ
ションのリソースを分離することが可能
39
Node 1 Node 2…. Node n

Image from support.esri.com
空間インデックス
 一般的な地理空間操作の1つは、ポイントと
ポリゴンの交点を割り出す空間結合処理
 「ジオフェンシング」のようなユースケー
スでは、どのポイントがどのポリゴン内に
あるか、素早く識別する方法が必要
 この操作を高速化するため、Verticaは空間
インデックス機構を採用
 ユーザーはSTV_Create_Index関数を呼び出し
てポリゴンを格納する列にインデックスを
作成し、STV_Intersectを呼び出して別の列
に格納されているポイント間をインデック
スで交差させることが可能
40
ポイント
ポリゴン

41
 各ポイントを既知の地域に素早く分類
 その仕組み
- ジオメトリから空間インデックスを作成
- 各ノードで毎秒数百万ポイントを分類
 使用例
- ある時間帯における、ある小売店に滞在した
顧客数を計算
- 各地域の携帯電話による通話の密度を計算し、
新しい携帯電話塔をどこに設立すべきか分析
- ジオフェンシング – 各ポイントがどの地域内
にあったかを記録し、移動先ポイントの地域
を新たに計算し、アラートリストを生成
SELECT STV_Intersect(location
USING PARAMETERS
index=‘/dat/states.idx’),
COUNT(*)
FROM calls
GROUP BY 1;
地域分類

42
地理空間分析を取り入れた
高速分析システム
を構築可能！

実装例②：
Verticaで実装する地理空間分析
～ボストン市街の道路の「穴」～

ボストン市街の道路の「穴」を分析
 ボストン市によって報告され、修正された穴の場所を特定
 それぞれの穴は点とし、各領域は多角形
 穴の各点の位置とそれが発生する領域との交差点を分析（ポ
リゴンの交差点）
44
ボストン周辺では、道路に穴が空いてい
ることは珍しくない
補修すべき穴がたくさん
あるところはどこか？

ボストン市街の道路の「穴」の分析フロー
1. ボストン市街の穴の位置に関する情報、
ボストン市街の道路情報、ボストン市
街のブロック情報をVerticaにロード
2. 米国国勢調査のブロックに対して空間
インデックスを作成
3. すべてのブロックと交差する道路セグ
メントの数をカウントし、すべてのブ
ロックの道路セグメントあたりの穴の
数をSQLで分析
4. R Studioを使ってヒートマップ表示
45

ボストン市街の道路の「穴」
Block Pothole Density:
各ブロックの穴の密度を計算
46
potholes ph blocks_idx roads rd
Spatial Join
[ph.id, block_id]
Spatial Join
[rd.id, block_id]
Group By
[block_id, count(ph.id)]
Group By
[block_id, count(rd.id)]
Join
[block_id, count(ph.id)/count(rd.id)]
Query Result
x
x
x
x pothole road
Block Pothole Density = 3/2
# potholes
# roads
補修すべきボストン市街の道路を分析する

ボストン市街の道路の「穴」
下記の情報をVertica Databaseに格納して分析
1. ボストン市街の穴の位置に関する情報
2. ボストン市街の道路情報（シェープファイル）
3. ボストン市街のブロック情報（シェープファイル）
GitHub：
https://github.com/vertica/Vertica-Geospatial
※本資料で示すサンプルの環境：Vertica 8.1 on CentOS 6.8
47

事前準備：シェープファイルをWGS84系に変換
 ogr2ogr コマンドを使用し、一般配布されているシェープファイルを
WGS84フォーマットに変換する必要あり（VerticaはWGS84をサポー
ト）
 ogr2ogr コマンドを使用するために、以下のパッケージをインストール
しておく
- gdal
- geos
- proj
48
$ sudo yum install epel-release //EPELリポジトリのインストール
$ sudo yum install gdal geos proj //gdal, geos, projのインストール

事前準備：シェープファイルをWGS84系に変換
1. ボストン市街の道路情報用シェープファイル
https://www.census.gov/cgi-bin/geo/shapefiles2013/main
からシェープファイル（eotroads_35.shp）を取得し、以下の
コマンドで変換
2. ボストン市街のブロック用シェープファイル
http://www.mass.gov/anf/research-and-tech/it-serv-and-support/application-
serv/office-of-geographic-information-massgis/datalayers/ftpeotroads.html
からシェープファイル（tl_2013_25_tabblock.shp）を取得し、
以下のコマンドで変換
49
$ ogr2ogr -f "ESRI Shapefile"
roads_wgs84 eotroads_35.shp -s_srs
EPSG:26986 -t_srs EPSG:4326
$ ogr2ogr -f "ESRI Shapefile"
blocks_wgs84 tl_2013_25_tabblock.shp -
s_srs EPSG:4269 -t_srs EPSG:4326
SRID = 4326

1-1. ボストン市街の穴の位置情報をロード
テーブル作成とデータロード（フレックステーブル活用の例）
CREATE TABLE
Rows Loaded
-------------
27459
(1 row)
50
=> CREATE flex table boston_potholes_raw();
=> COPY boston_potholes_raw
FROM '/home/dbadmin/BOS/potholes/Closed_Pothole_Cases.csv'
PARSER public.FDelimitedParser (delimiter=',');

フレックステーブルに格納されたデータの内容確認
MAPTOSTRING
-------------------------------------------------------------------------------
{
"CASE_ENQUIRY_ID" : "101000328358",
"CASE_STATUS" : "Closed",
:
:
"ucol29" : "-71.0728)"",
"ward" : "Ward 4"
}
(1 row)
51
=> SELECT MAPTOSTRING(__raw__) FROM boston_potholes_raw LIMIT 1;

確認した定義を元に、必要な列を持つカラムナーテーブルを作成
CREATE TABLE
OUTPUT
--------
27459
(1 row)
COMMIT
52
=> CREATE TABLE boston_potholes(gid identity, case_enquiry_id varchar(100), lat
float, lon float, geom geometry(100)) SEGMENTED BY hash(gid) all nodes;
=> INSERT /*+direct*/ INTO boston_potholes(case_enquiry_id, lat, lon, geom)
SELECT case_enquiry_id::varchar(100), latitutde, longitude,
ST_GeomFromText('POINT('||longitude||' '||latitude||')', 4326) FROM
boston_potholes_raw; COMMIT;

1-2. ボストン市街の道路情報をロード
シェープファイルからDDLを出力
create_table
----------------------------------
CREATE TABLE eotroads_35(
gid IDENTITY(64) PRIMARY KEY,
CLASS INT8,
:
geom GEOMETRY(7785)
);
(99 rows)
53
出力されたDDLを実行してテーブルを作成
=> SELECT STV_ShpCreateTable(using parameters
file='/home/dbadmin/BOS/shapefiles/roads_wgs84/eotroads_35.shp') OVER();

1-2. ボストン市街の道路情報をロード
シェープファイルをテーブルへロード
Rows Loaded
-------------
20224
(1 row)
54
シェープファイルの構造
を読み取ってロードする
ネイティブパーサー
=> COPY eotroads_35 WITH SOURCE
STV_ShpSource(file='/home/dbadmin/BOS/shapefiles/roads_wgs84/eotroads_35.shp',
srid=4326) PARSER STV_ShpParser() DIRECT;

1-3. ボストン市街のブロック情報をロード
シェープファイルからDDLを出力
create_table
-----------------------------------
CREATE TABLE tl_2013_25_tabblock(
gid IDENTITY(64) PRIMARY KEY,
STATEFP VARCHAR(2),
:
geom GEOMETRY(41501)
);
(21 rows)
55
出力されたDDLを実行してテーブルを作成
=> SELECT STV_ShpCreateTable(using parameters
file='/home/dbadmin/BOS/shapefiles/blocks_wgs84/tl_2013_25_tabblock.shp')
OVER();

シェープファイルをテーブルへロード
Rows Loaded
-------------
157534
(1 row)
56
=> COPY tl_2013_25_tabblock WITH SOURCE
STV_ShpSource(file='/home/dbadmin/BOS/shapefiles/blocks_wgs84/tl_2013_25_tabbloc
k.shp', srid=4326) PARSER STV_ShpParser() DIRECT;

内容確認（空間オブジェクトの種別と数）
ST_GeometryType | count
-----------------+--------
ST_Polygon | 157409
ST_MultiPolygon | 125
(2 rows)
57
=> SELECT ST_GeometryType(geom), count(geom) FROM tl_2013_25_tabblock GROUP BY
ST_GeometryType(geom);
Polygon MultiPolygon

gid | ST_AsText
-----+---------------------------------------------------------------------------------------------------------------
1 | POLYGON ((-70.562918 41.434951, -70.562863 41.435121, -70.562621 41.43551, -70.562364 41.435888, -70.562267
41.436043, -70.562181 41.436121, -70.561973 41.436197, -70.561963 41.436224, -70.562043 41.436332, -70.562035
41.43635, -70.561586 41.436695, -70.561437 41.436824, -70.56133 41.436947, -70.561271 41.437096, -70.561264 41.43741,
-70.561227 41.437582, -70.561194 41.437653, -70.561038 41.437806, -70.56095 41.437866, -70.560847 41.437913, -
70.560661 41.437989, -70.560504 41.438102, -70.56025 41.438397, -70.560094 41.438514, -70.560007 41.438563, -
70.559819 41.438634, -70.559606 41.438673, -70.559491 41.43867, -70.559294 41.438631, -70.558909 41.438528, -
70.558641 41.438414, -70.558477 41.438307, -70.558282 41.438098, -70.558203 41.437941, -70.558047 41.437556, -
70.557997 41.437483, -70.557928 41.437427, -70.557842 41.437385, -70.557737 41.43736, -70.557625 41.43735, -70.557089
41.437334, -70.557126 41.437082, -70.557119 41.436643, -70.55709 41.436135, -70.557073 41.435826, -70.557041 41.4354,
-70.556994 41.434965, -70.556982 41.434887, -70.556641 41.433212, -70.556577 41.432898, -70.557493 41.432822, -
70.557463 41.433014, -70.557456 41.433113, -70.557434 41.433223, -70.557412 41.433266, -70.5575 41.433442, -70.557529
41.433519, -70.557558 41.433563, -70.557595 41.433601, -70.557624 41.4337, -70.557704 41.433782, -70.557733
41.433843, -70.557777 41.433914, -70.557792 41.433958, -70.557872 41.43404, -70.557989 41.434194, -70.558076
41.434266, -70.558149 41.434337, -70.5582 41.434419, -70.558302 41.434502, -70.558368 41.434595, -70.558492
41.434672, -70.558572 41.434732, -70.558645 41.434804, -70.558842 41.434924, -70.559046 41.435089, -70.559294
41.435199, -70.559688 41.435298, -70.560162 41.435314, -70.560425 41.435276, -70.560848 41.435182, -70.560965
41.43516, -70.561162 41.435084, -70.561403 41.434941, -70.561548 41.434864, -70.561672 41.434809, -70.561811
41.434738, -70.562045 41.434661, -70.56219 41.434655, -70.562315 41.434661, -70.562621 41.434633, -70.562966
41.434599, -70.562918 41.434951))
58
=> SELECT gid, ST_AsText(geom) FROM tl_2013_25_tabblock LIMIT 1;
ジオメトリをテキスト形式で表現
内容確認（グリッドID＋空間オブジェクトの内容）

3. SQLを実行
結果をテキストに出力し、ツールにInput
-- Final query to find the number of potholes per road segment in every block
SELECT ph.block_gid, round(ph.potholes/rd.road_segs, 2.0) ph_per_rseg
FROM
-- Potholes per block
(SELECT block_gid, count(ph_gid) potholes
FROM (SELECT stv_intersect(gid, geom using parameters index=‘blocks_idx’)
OVER(PARTITION BEST) AS (ph_gid, block_gid) FROM boston_potholes) t
GROUP BY block_gid) ph,
-- Road segments per block
(SELECT block_gid, count(distinct road_gid) road_segs
FROM (SELECT stv_intersect(road_gid, road_pt using parameters
index='blocks_idx')
OVER(partition by road_gid) AS (road_gid, block_gid)
FROM (SELECT gid road_gid, stv_linestringpoint(geom)
over(partition by gid) AS road_pt FROM eotroads_35) t) t
GROUP BY block_gid) rd
WHERE ph.block_gid = rd.block_gid
ORDER BY ph_per_rseg DESC;
60

4. SQL実行結果をR Studioで表示
https://www.rstudio.com/
61

1. パッケージggplot2, ggmapをインストールし、パッケージを使用
> install.packages("ggplot2")
> install.packages("ggmap")
> library(ggplot2)
> library(ggmap)
2. SQL実行結果ファイルを読み込み
> new_potholes = read.csv("heatmap.dat")
3. 地図情報を読み込み
> metro <- get_map(location = "Boston, MA", zoom = 11, maptype='toner-hybrid')
> downtown <- get_map(location = "Boston, MA", zoom = 15, maptype='toner-hybrid')

4. ヒートマップの作成
> heatMapMetro <- ggmap(metro) +
geom_polygon(data = new_potholes, aes(y = Longitude, x = Latitude,
group = gid, fill = Ratio), alpha = .7) +
scale_fill_gradient(low = "light yellow", high = "red", guide = "legend",
na.value="light yellow", limits = c(0,5), breaks = c(0:5))
> heatMapDowntown <- ggmap(downtown) +
geom_polygon(data = new_potholes, aes(y = Longitude, x = Latitude,
group = gid, fill = Ratio), alpha = .7) +
scale_fill_gradient(low = "light yellow", high = "red", guide = "legend",
na.value="light yellow", limits = c(0,5), breaks = c(0:5))

4. ヒートマップの表示
> heatMapMetro
64

4. ヒートマップの表示
> heatMapDowntown
65

69
Vertica Community Edition
データ量1TB/3ノード構成まで
無期限でお試しいただけます
 Vertica Geospatialを含む、全ての機能をお使いいただけます
 Community Edition用のインストールガイド（日本語）もご用意しています
 Let’s download! ==> www.hpe.com/jp/vertica

まとめ
Simple
Fast
Scalable
71
機械学習や地理空間分析も実装可能
データを別システムに移動させるこ
となく、従来のコアテクノロジー＋α
により高速実行可能
数十、数百台のVerticaクラスターで
パラレルに実行可能

参考情報
 Machine learning meets massively parallel processing – ビデオ
 Unlock machine learning for the new speed and scale of business – ホワイト
ペーパー
 関連ブログ英語サイト/日本語サイト
- https://my.vertica.com/blog/machine-learning-series-linear-regression/ ※日本語版はこちら
- https://my.vertica.com/blog/vertica-machine-learning-series-logistic-regression/ ※日本語版はこちら
- https://my.vertica.com/blog/vertica-machine-learning-series-k-means/ ※日本語版はこちら
- https://my.vertica.com/blog/category/machine-learning/
Analytic functions Aggregate functions
Grouping functions Mathematical functions
Machine learning functions （データ準備、モデルトレーニング、評価、スコアリング等を含む）
Working with unstructured data
※日本語版はこちらよりDL可能

Thank you
https://software.microfocus.com/en-us/contact

[db tech showcase Tokyo 2017] D15: ビッグデータｘ機械学習の高速分析をVerticaで実現！by ヒューレット・パッカードエンタープライズ大林加奈子

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to [db tech showcase Tokyo 2017] D15: ビッグデータｘ機械学習の高速分析をVerticaで実現！by ヒューレット・パッカードエンタープライズ大林加奈子

Similar to [db tech showcase Tokyo 2017] D15: ビッグデータｘ機械学習の高速分析をVerticaで実現！by ヒューレット・パッカードエンタープライズ大林加奈子 (20)

More from Insight Technology, Inc.

More from Insight Technology, Inc. (20)

Recently uploaded

Recently uploaded (8)