Realize tokyo 20191010の発表資料です Verticaの活用事例を話しています

1. © YRGLM Inc.
400億件のリアルタイム分析の実現と運用の実態
2019.09.27 株式会社イルグルム

2. © YRGLM Inc. 2
0. 紹介
1. 広告効果測定とは？
2. ヒト軸分析をどうやって実現したのか？
• ヒト軸分析を実現するための要素
• ヒト軸分析を実現するための 「分析」基盤/インフラ課題
• 全てを満たすことができた 「分析」基盤/インフラ
3. 導入から3年しての運用の実態
• 増え続けるデータとニーズ
• 運用課題
4. Veritica Eonモードの導入
・広告効果測定/アドテク？
・マーケティングの今とシステム課題
・自己紹介
・会社紹介
・アドエビスとは
アジェンダ

3. © YRGLM Inc. 3
その他
上原 賢也
2006年 日本発ECオープンプラットフォーム「EC-CUBE」の開発
2009年 広告運用「THREe」のインフラ基盤の設計・構築
2012年 全社の品質管理・インフラの導入・運用をメインで実施
2015年 ベトナム子会社へ出向し、オフショア開発拠点の立ち上げ
2019年 日本に帰国し、主にインフラ面から基盤戦略全般を担当
業務の傍らロックオフというエンジニアのたまり場を運営
ベトナム渡航中は大学の講師も務める
基本的に何でも屋さんです
略歴
自己紹介
UEHARA Katsuya

4. © YRGLM Inc. 4
株式会社イルグルム
YRGLM Inc.
【大阪本社】 大阪府大阪市北区梅田2-4-9 ブリーゼタワー13F
【東京本社】 東京都千代田区有楽町2-2-1 X-PRESS有楽町12F
【KYOTO BASE】 京都市下京区新町通松原下ル富永町107番地1 4F
【子会社】 株式会社イーシーキューブ
【子会社】 YRGLM MARKETING OF U.S.A. inc.（米国カリフォルニア州）
【子会社】 YRGLM VIETNAM COMPANY LIMITED（ベトナム社会主義共和国）
設立 2001年6月4日
代表者 代表取締役 岩田 進
事業内容 マーケティングロボットの提供
・マーケティング効果測定プラットフォーム「アドエビス」
・運用型広告レポート自動作成ツール「アドレポ」
・商流プラットフォーム「EC-CUBE」
東京証券取引所マザーズ上場（3690）
会社概要

5. © YRGLM Inc. 5
称号を変更しました
株式会社イルグルム

6. © YRGLM Inc. 6

7. © YRGLM Inc. 7

8. © YRGLM Inc. 8
アドエビスは導入実績累計1万件以上！
マーケティング効果測定
プラットフォームとして
信頼の導入実績 1万件!!
※出典：「ITR Market View：メール／Webマーケティング市場2019」 広告効果測定市場：ベンダー別売上金額推移およびシェア（2016～2018年度予測）
2016年度 2017年度 2018年度（予測値）
広告効果測定市場において
売上シェアNo.1!!※
4000
4500
5000
5500
6000
6500
7000
7500
8000
8500
9000
9500
10000
2011年度 2012年度 2013年度 2014年度 2015年度 2016年度 2017年度 2018年度 2019年度
2004年
AD EBiS
発売開始
2019年
1万件突破!!

9. © YRGLM Inc. 9
広告効果測定？
アドテク?

10. © YRGLM Inc. 10
アドテクノロジー
メディア
広告を表示する領域を提供
広告配信
メディアに、場合によってはあるロジック
に従って広告を配信
効果計測
配信された広告がどの程度の効果、収益を
上げたのかを評価
略称
アドテク、アドテック、など

11. © YRGLM Inc. 11
アドテクとは？
アドテク業界で生き残るためには
最新の技術が必要とされる
アドエビスも常に新たな技術を
取り入れていかないといけない

12. © YRGLM Inc. 12
アドエビスとは
マーケティングの今

13. © YRGLM Inc. 13
計測
広告効果測定 アクセス解析
View計測 LPOクリック計測/SEO計測 経路分析
動画広告
記事広告
ディスプレイ
広告
コンテンツ
マーケティング
純広告
自然検索
アフィリエイト
広告
リスティング
広告
リターゲティン
グ広告
ダイレクト
SNS
LP TOP
コンテンツ
デジタルマーケティングに必要な”あらゆる機能”をワンパッケージで提供
CV
活用
外部連携
BI/レポーティング
MR/CRM/SFA
広告配信/運用管理
リサーチ/モニター
3rd Party Data
EC/通販支援ツール
TV/オフライン施策
分析
レポーティング
施
策
軸
ユ
ー
ザ
ー
軸 デモグラフィック
カスタマージャーニー
分析
チャネル別集計
アトリビューション
分析
アドエビスはあらゆるマーケティングの効果をメディア・デバイス・代理店を横断して測定、
マーケティング活動の成果最大化をサポートするサービスです。
「アドエビス」が提供する３つのソリューション

14. © YRGLM Inc. 14
これまでとこれからの施策評価

15. © YRGLM Inc. 15
60%
40%
スマートフォンの普及によるマルチデバイス化
クロスデバイス
コンバージョン
単一デバイスで
コンバージョン
（出典） criteo「2016年度下期クロスデバイス・コマースレポート」
クロスデバイス

16. © YRGLM Inc. 16
不明ユーザー
同一ユーザー
IDで特定
それぞれのデバイスでログインしていれば、
同一人物だとシステム上扱える
これまでのクロスデバイス分析
クロスデバイス

17. © YRGLM Inc. 17
不明ユーザー
同一ユーザー
IDで特定
それぞれのデバイスでログインしていれば、
同一人物だとシステム上扱える
これまでのクロスデバイス分析
クロスデバイス
しかし、複数デバイスで確実に
ログインしてくれるようなサイトは少ない

18. © YRGLM Inc. 18
不明ユーザー
同一ユーザー
同一ユーザー 機械学習で
同一ユーザーを類推
アドエビスのクロスデバイス分析
クロスデバイス

19. © YRGLM Inc. 19
データ×組み合わせ
爆発

20. © YRGLM Inc. 20
媒体軸分析 ヒト軸分析
軸の件数 媒体の数
※広告の場合、約150万程度
行動パターン
※組み合わせ爆発発生
データ量 10万件～1000万件程度
※１日単位の事前集計済データ
100億件〜
※事前集計無しの全行動履歴
要求される
処理速度
数秒〜数十秒
新たな課題 - 媒体軸とヒト軸のデータの違い

21. © YRGLM Inc. 21
全行動履歴を
ヒト軸で
リアルタイムに
どのように実現したか？

22. © YRGLM Inc. 22
1.行動パターンに合致する「ヒト」の抽出
（軸の件数）
2.全行動履歴のリアルタイム集計
（データ量）
3.リニアなスケーラビリティ
（処理速度）

23. © YRGLM Inc. 23
一致したヒト
2/3 が購入
という行動パターンに一致した/しないヒトは？
広告A
閲覧
広告B
クリック
検索流入
広告B
クリック
検索流入
購入
購入
広告A
閲覧
検索流入 購入
広告A
閲覧
広告B
クリック
検索流入
広告A
閲覧
広告B
クリック
一致しなかったヒト
1/3 が購入
広告A閲覧 検索流入→
計測対象ユーザー
広告A
閲覧
1.行動パターンに合致する「ヒト」の抽出

24. © YRGLM Inc. 24
• 媒体軸：事前に集計可能
• ヒト軸：事前に集計不可能
– 全行動履歴データは 年間 数百億レコード
– 全行動履歴データを 行動パターンに起こすと、何倍にもデータが膨れ上がる
– 事前に集計するためには、時間、リソースの両方が足りない
ヒト軸分析を実現するための 「分析」基盤/インフラ課題
ログ
ファイル
計測
サーバ
全行動履歴データ
リアルタイム分析・
閲覧用
※数百億レコード
全行動履歴データ
検査/加工/集計
※数百億レコード
ログ
ファイル
計測
サーバ
…
全行動履歴取得
※広告閲覧/広告クリック/検索流入/
サイト閲覧/コンバージョンetc…
計測対象ユーザー
計測対象ユーザー
？？？
Hadoop
Postgre
SQL
集計データ閲覧用
※数百万レコード
※集計データ
アドエビス
管理画面
アドエビス
ご契約者様
2.全行動履歴のリアルタイム集計

25. © YRGLM Inc. 25
日々増加する計測対象ユーザー
• ご契約者数
• ご契約者様の計測対象ユーザー
日々増加する計測ポイント
• 顕在層→潜在層 への計測拡大
近い将来、リソースが限界に
全リニア（直線的）にスケール
アウトする仕組みが必要
ex) ・サーバ1台で10.0秒
・サーバ2台で 5.0秒
・サーバ3台で 3.3秒
2015/11/28
2015/12/8
2015/12/18
2015/12/28
2016/1/7
2016/1/17
2016/1/27
2016/2/6
2016/2/16
2016/2/26
2016/3/7
2016/3/17
2016/3/27
2016/4/6
2016/4/16
2016/4/26
2016/5/6
2016/5/16
2016/5/26
2016/6/5
2016/6/15
2016/6/25
2016/7/5
2016/7/15
広告クリック数
3.リニアなスケーラビリティ

26. © YRGLM Inc. 26
1.行動パターンに合致する
「ヒト」の抽出 × ○ △ ×
2.全行動履歴のリアルタイム
集計 × △ △ ○
3.リニアなスケーラビリティ × ○ ○ ○
ヒト軸分析を実現するための 「分析」基盤/インフラ課題
社内にあったデータ分析基盤では全てを解決できない

27. © YRGLM Inc. 27
全てを満たすことができた 「分析」基盤/インフラ

28. © YRGLM Inc. 28
1.行動パターンに合致する「ヒト」の抽出
Match関数
2.全行動履歴のリアルタイム集計
高スループット/低レイテンシ性
3.リニアなスケーラビリティ
シェアードナッシング方式による超並列アーキテクチャー

29. © YRGLM Inc. 29
SELECT
ユーザID, アクセス時間,
アクション, 広告ID
FROM
all_log
MATCH
(PARTITION BY ユーザID ORDER BY アクセス時間
DEFINE
広告A閲覧 AS アクション = ‘広告閲覧' AND 広告ID = 'A',
検索流入 AS アクション = '検索流入‘
その他 AS …
PATTERN
P AS (広告A閲覧 (広告A閲覧|検索流入|その他)*? 検索流入)
ROWS MATCH FIRST EVENT);
ユーザID アクセス時間 アクション 広告ID
ユーザ1 2016-07-26 12:00 広告閲覧 A
ユーザ1 2016-07-26 12:02 検索流入
ユーザ1 2016-07-26 12:03 購入
ユーザ2 2016-07-26 12:00 広告閲覧 A
ユーザ2 2016-07-26 12:01 広告クリック B
という行動パターンに一致したヒトの抽出広告A閲覧 検索流入→

30. © YRGLM Inc. 30
テーブル レコード件数(億) 所要時間(ms)
全行動履歴(半年分) 55.80 380.042
ご契約者様 レコード件数(億) 所要時間(ms)
A様 5.58
12,034.691
B様 4.81
C様 2.88
D様 2.15
E様 1.83
各テーブル別の
レコード件数
ご契約者様別の
全行動履歴テーブル
レコード件数
（上位５件）
ex) SELECT ご契約者様, count(ご契約者様) FROM 全行動履歴
GROUP BY ご契約者様 ORDER BY 2 DESC limit 5;
ex) SELECT count(ご契約者様) FROM 全行動履歴;
RDBでは捌ききれなかった大量データも高速に集計可能

31. © YRGLM Inc. 31
※約80億レコードの実データを投入
※クエリ種別、データ容量を変え25パターンのクエリを使用
※3ノード、5ノード、10ノードにて検証
3
課題を解決してくれたVerticaの特長 – 超並列アーキテクチャー
（参考）導入前の検証結果

32. © YRGLM Inc. 32
ログ
ファイル
計測
サーバ
全行動履歴データ
リアルタイム分析・
閲覧用
※数百億レコード
全行動履歴データ
検査/加工/集計
※数百億レコード
ログ
ファイル
計測
サーバ
…
全行動履歴取得
※広告閲覧/広告クリック/検索流入/
サイト閲覧/コンバージョンetc…
計測対象ユーザー
計測対象ユーザー
Vertica
Hadoop
Postgre
SQL
集計データ閲覧用
※数百万レコード
※集計データ
アドエビス
管理画面
アドエビス
ご契約者様
Vertica を導入することで、ヒト軸分析を行えるようになった！
行動パターンに合致す
る「ヒト」の抽出
全行動履歴のリアルタ
イム集計
リニアな
スケーラビリティ

33. © YRGLM Inc. 33
導入から3年

34. © YRGLM Inc. 34
増え続けるデータ
増え続ける利用ニーズ
膨れ上がる運用コスト
性能の維持・・

35. © YRGLM Inc. 35
データ量増加 100億件→700億件(顧客分析データのみ)
100億
300億
700億
2017年 2018年 2019年

36. © YRGLM Inc. 36
倍々でデータ量
増えてるんですけど

37. © YRGLM Inc. 37
ログ
ファイル
計測
サーバ
全行動履歴データ
リアルタイム分析・
閲覧用
※数百億レコード
全行動履歴データ
検査/加工/集計
※数百億レコード
ログ
ファイル
計測
サーバ
…
全行動履歴取得
※広告閲覧/広告クリック/検索流入/
サイト閲覧/コンバージョンetc…
計測対象
ユーザー
計測対象
ユーザー
Vertica
Hadoop
Postgre
SQL
集計データ閲覧用
※数百万レコード
※集計データ
アドエビス
管理画面
アドエビス
ご契約者様
APIデータ
提供
外部データ
取り込み
全アクセス
の横断分析
不正アクセ
ス傾向分析
調査基盤
もっと早く
柔軟に
成果を上げたい
利用ニーズ増大

38. © YRGLM Inc. 38
なんでもできる
魔法のハコ
じゃないんだよ

39. © YRGLM Inc. 39
リソースプール検討の話
並列数や、CPU/メモリ等で制御はしてみたがコントロールは簡単ではない
サービス毎にスケールアウト戦略がとりづらい・・・
USER A（CPU25%）
ロングクエリ実行
USER B（CPU25%）
ロード実行
一般User
ショートクエリ
General Pool
パラレルプロセス数Memory
同時実行可能数CPU 50%
Pool for USER A
パラレルプロセス数Memory
同時実行可能数CPU 25%
Pool for USER B
パラレルプロセス数Memory
同時実行可能数CPU 25%

40. © YRGLM Inc. 40
プロジェクション
増やしたくても
DISK容量
足りない・・
データ量増、CPU/メモ
リに余裕があっても
ノードを追加しないと
いけない事態に・・
ノード１
CPU
/メモリ
DISK
処理
リソース
拡張
ノード2
CPU
/メモリ
DISK
CPU
/メモリ
DISK
ノード4
ついでに
電源容量
が・・
ノード3
CPU
/メモリ
DISK
スケールアウトの課題

41. © YRGLM Inc. 41
データ増による性能劣化の課題
プロジェクション見直し

42. © YRGLM Inc. 42
機能毎に必要な要件を整理
NO 提供I/F 機能名 CRUD データ更新頻度 並列事項数 実行タイミング サービス・機能例 対象サブクラスタ
C R U D
01 画面 アドホック検索 － 〇 － － 90分内(ニアリアル) N 常時 A 画面検索用
Subcluster 1
02 レポート＋フィルタ － 〇 － － 前日 M 常時 B 画面検索用
Subcluster 1
03 レポート － － － － 前日 N 常時 C,D (不要)
04 マスタ管理 〇 〇 〇 〇 － N 常時 E 画面更新処理用
Subcluster 4
05 バッチ 処理系バッチ(ニアリアル) 〇 〇 〇 〇 － 設定数 定時 F バッチ用
Subcluster 3
処理系バッチ(日時) 〇 〇 〇 〇 － 設定数 定時 G バッチ用
Subcluster 3
06 READ系バッチ － 〇 － － － 設定数 定時 H バッチ用
Subcluster 3
07 レポート生成 － 〇 － － － 設定数 定時 I カスタムレポート用
Subcluster 2
08 API 単一テーブルAPI － 〇 － － 90分内(ニアリアル) N 常時 K API用
Subcluster 5
09 集計データAPI － 〇 － － 前日 N 常時 API用
Subcluster 5
10 ローデータAPI － － － － 前日 N 常時 － (不要)

43. © YRGLM Inc. 43
対象データ開始日
(何日前)
指定期間
日数
1ヶ月
2ヶ月
3ヶ月
4ヶ月
5ヶ月
6ヶ月
7ヶ月
8ヶ月
9ヶ月
10ヶ月
11ヶ月
12ヶ月
1年前 2年前
未来を含む期間指定
のアクセス
1年前と比較
※ 件数をヒートマップで表示
データの参照期間、操作履歴を分析

44. © YRGLM Inc. 44
• 事業の伸長に合わせた拡張設計は大事
• でも、運用しないと分からないことが多い
• 利用状況は調査できるようにしておこう！
SQLのログやアクセスログだけでは不十分
まとめ

45. © YRGLM Inc. 45
• メンテナンス制約との闘い。しかし止められないシステム
• アクセスバーストによる負荷増、サービス間での影響
• データ量依存によるクラスタ増（コンピュートとストレージが一体）
• ライセンス（初期データ設計のミスで過剰データ量）
• ファシリティ電源容量足りへん問題
• データ構造の再設計にかかる時間と容量が足りない・・・
これらの課題いくつかは運用でカバーしてきたが
そろそろ疲れてきたのである
長く運用してくると出てくる課題達

46. © YRGLM Inc. 46
これら課題を解決するため
基盤リプレースを検討！

47. © YRGLM Inc. 47
次の基盤を比較、調査検証した結果、AWS上で稼働する「Vertica EONモード」を採用します。
比較検討基盤
(1) オンプレミス Vertica Enterpriseモード
(2) RDBMS
(3) AWS Vertica EONモード
(4) AWS Vertica Enterpriseモード
(5) DWH
(6) Mapreduce
NO 基盤名 a b c d e f g 備考
1 オンプレミス Vertica Enterpriseモード △ 〇 ✖ ✖ 〇 △ ✖ リソースを分割できず。
2 オンプレミス RDB ✖ 要件をクリアできず
3 クラウド Vertica EONモード 〇 ◎ ◎ ◎ △ 〇 〇 採用。
4 クラウド Vertica Enterpriseモード 〇 〇 〇 〇 〇 △ ✖ リソースを分割できず。
5 クラウド（DWH） 〇 ✖ インスタンス費が高額。
6 クラウド（MapReduceソリューション） ✖ 処理速度に不安。クロデバ分析利用。
調査検証内容
(a) 要件クリア
(b) イニシャル・ランニング費用
(c) 環境構築コスト
(d) スケールアウト/イン/アップ/ダウン
(e) 単一/並列稼働時の性能
(f) 運用/対障害時のオペレーション
(g) 将来的なシステム拡張性
上記課題を解決するソリューションを模索

48. © YRGLM Inc. 48
やっぱりVertica手放せない
Eonモードがいけてそう

49. © YRGLM Inc. 49
アーキテクチャー比較 Enterpriseモード vs. Eonモード
ノード2 ノード3ノード1
ノード１
EC2 EC2
with
Storage
Cache
■Enterpriseモード（従来アーキテクチャー）
計算ノードとストレージの役割をセットでノード構成。構成単位
のノードを追加することでスケールアウトを実現。
EBS
ROS用
ローカル
ボリューム
ノード2
EC2
EBS
ROS用
ローカル
ボリューム
ノード3
EC2
EBS
ROS用
ローカル
ボリューム
EC2
EBS
ROS用
ローカル
ボリューム
EC2
EBS
ROS用
ローカル
ボリューム
ノード4 ノード5
EC2
with
Storage
Cache
EC2
with
Storage
Cache処理
リソース
拡張
EC2
with
Storage
Cache
EC2
with
Storage
Cache
ノード4 ノード5
処理
リソース
拡張
■Eonモード（新アーキテクチャー）
計算ノードとストレージを分離し、計算ノードのみ追加でス
ケールアウトを実現。
特徴
• 繁忙期などの需要増加に合わせて、迅速に計算ノードを追加可能（クラウ
ドコストを削減 ）
• 計算ノードを追加時のデータリバランスは不要
• サブクラスタ機能（計算ノードグループ）を利用することでSLAに合わせた
設計が可能
• 同時実行処理を更に強化したクランチスケーリング機能
• 安価なAWS S3を利用することでストレージ費用を削減
• 高速分析処理が必要なデータ用にインテリジェントキャッシュ機能を提供
（S3への処理遅延を補完）
特徴
• 様々なインフラ環境にデプロイ可能（オンプレ、仮想環境、クラウド環境）
※Eonモードは、AWS環境とPure Storage環境（オンプレ）のみサポート（2019年9
月現在）
• 常に高いSLAを必要とする要件に最適なアーキテクチャー（繁忙期と閑散期の切れ
目がないユースケースに最適）
• 広範囲の対象データを高速処理する必要がある要件に最適なアーキテクチャー
（すべてのデータを高速ストレージにストアするため）
AWS S3
ROS用ボリューム

50. © YRGLM Inc. 50
新しいレベルでのワークロードの分離と柔軟性

51. © YRGLM Inc. 51
初回キャッシュ作成時は、Vertica Enterpriseモードより約179％性能劣化、
DEPOTキャッシュ構築後は、2.61％性能向上でクエリを処理。
DEPOTキャッシュ後のキャッシュヒット率は100％となり、Enterpriseと同性能を実現。
Shared Strage
S3
Node1
Node2
Node3
Node4
B A
C D
DEPOT キャッシュ
必要なデータ
キャッシング
4 Shard の場合
Shard A 利用
Shard B 利用
Shard C 利用
Shard D 利用

52. © YRGLM Inc. 52
シャード/ノード数を変え、単実行で実施した結果
DEPOTキャシュの動きと単実行速度を確認。
⇒ DEPOTキャッシュ構築時は179％性能劣化が見られる。初回のみキャッシュ構築時。
⇒ DEPOTキャッシュ構築後にデータの整理が実施。その間にアクセスが発生した場合はさらに性能が劣化290％の劣化が見られる。
⇒ DEPOTキャッシュ構築後は2.61％性能向上が見られる。
DC内オンプレミス環境
レポートクエリ実施
Vertica EONモード環境
レポートクエリ実施
キャッシュ無し(構築)
キャッシュ構築後整理中
キャッシュ有り
42.2s / トランザクション 118s / トランザクション
165s / トランザクション
41.1s / トランザクション
⇒ ノード追加時DEPOTキャッシュ作成。オーバーヘッドを0にする！

53. © YRGLM Inc. 53
耐障害性
⇒ EONは同一ラック
に格納を前提で設計！
物理データの再配置
⇒不要に！キャッシュ
のクリアとウォーム
アップは必要
柔軟なスケールアップ、
アウト
⇒ノード半分落とした
らクラスタ落ちるのが
難点
リソースの分離
更新処理と運用が楽に
ファシリティ地獄か
らは解放
コスト
⇒必要な時に必要な
分へ
？

54. © YRGLM Inc. 54
求められるニーズに着実に
答えようとする
Verticaの進化はありがたい。
VerticaEonモードは直近で実践投入予定
最後に・・・

55. © YRGLM Inc. 55
ご清聴
ありがとうございました

56. © YRGLM Inc.

57. © YRGLM Inc. 57
Appendix

58. © YRGLM Inc. 58
5
Verticaを導入してよかったこと

59. © YRGLM Inc. 59
選定ポイント Vertica Appliance N Service R
行動パターンに合致する「ヒト」
の抽出 ○ × ×
全行動履歴のリアルタイム集計 ○ ○ △
リニアなスケーラビリティ ○ × ○
同時接続数 ◯ △ △
運用コスト ○ ○ △
学習コスト ○ △ △
5
製品の選定ポイントと比較

60. © YRGLM Inc. 60
・耐障害性を考えるときもシンプル
・同じ構成のサーバを並べるだけなので、
障害時やスケール必要な場合の準備もシンプル
6
運用コスト
全てがマスタノード！
・データ初期投入後に一度だけプロジェクションを作れば殆どの場合は十分
・使用頻度高の処理がある場合、クエリに特化したチューニングも簡単
チューニングは最小限！

61. © YRGLM Inc. 61
6
学習コスト
・ANSI SQL-99準拠
・初日から違和感なく利用
・ベトナムオフショアも問題なく利用
・サービス運用担当エンジニアも、ほぼ教育なし
PostgreSQLエンジニアが違和感なく利用できる
・導入決定前の検証期間は2週間！
・「ヒト軸分析」機能は2.5か月でリリース！
・環境構築が容易
開発効率がよい！

62. © YRGLM Inc. 62
6
学習コスト
・コマンドも似ているのが地味に良い
※psql / vsql
➢ psql –h db_host –U db_user db_name
➢ vsql –h db_host –U db_user db_name
その他もメリットが！

63. © YRGLM Inc. 63
6
まとめ
想定外に良かった点として、
導入時に絡んでいなかったエンジニアが
初めて使ったときに凄く喜んだ
速度が速い！ 学習コストが低い！

64. © YRGLM Inc. 64
6
さいごに
Verticaという基盤を導入することで、
全行動履歴を使ったヒト軸分析が実現し、
ユーザの動きを深く知ることができました。
これからは、潜在層（遠い顧客）を顕在層（近い顧客）へと育
成するマーケティングを更に精度高く実現できるようになって
いきます。