Vertica 9.0.0 新機能

1. Vertica 9.0.0 “Grader”
新機能のご紹介
Product Management
September, 2017

2. パフォーマンス向上
機械学習、及び、アドバンスドアナリティクス
マルチクラウド: 様々な環境にデプロイ
オープンソースインテグレーション、エコシステム
との連携強化
エンハンスメント

3. ハイライト
• AWS S3上のParquetフォーマットデータの外部テーブルとしてのクエリ処理
• 高いSLA向けにAWS S3上のParquetフォーマットデータを Verticaにロード
• Management Console (MC)からクラウド環境のプロビジョニング
• Google Cloud Platform マーケットプレースのサポート
• PowerBI – 高速化、及び、セキュリティの強化。マイクロソフト社認定取得。
• パフォーマンス、スケーラビリティ、メモリ利用の効率化、同時実行処理の改善
• UUID データタイプをサポート（ストレージの効率化）
• 機械学習モデルをVerticaクラスター間でインポート、エクスポート
• 機械学習向け、データ探索、及び、データ準備機能の強化
• ユーザーフレンドリーなライセンス管理方法（テンポラリーライセンスは不要）
• Beta. Rapid elasticity, and simpler operations, from separation of compute and storage on AWS

4. マルチクラウド: 様々な環境
にデプロイ

5. • 課題: 増加するデータは、すべてが常に重要なデータでない場合があります
いくつかのデータは、少数のユーザーにより稀に分析する機会しかありませ
ん。その一方、同時に多くのユーザーがインタラクティブにダッシュボード
で分析するデータもあります。複数のアプリケーションがある環境では、ク
ラウドストレージが、始めにデータをストアする場所として利用されるよう
になっています。これまでVerticaはAWS S3と接続する機能を提供していまし
たが、ビックデータ分析で利用されるParquetフォーマットのデータに直接ク
エリ実行することができませんでした。
• 解決策: AWS S3上のParquetデータに Verticaは、外部テーブルとしてアクセス
することが可能です。S3への接続性が強化されました。
• 利点:
• 迅速にその場でデータ探索を実行できます。（In place）
• Verticaのアドバンスド分析をスケーラブルに実行することができます。（At scale）
その他のS３用クエリエンジン比較し、同時実行性などの優位性を提供します。
データ変換・再フォーマット無しでクラウドデータレイク上のデータをその場で分析
S3 bucket with
customer data
ロード無しでク
エリ実行
例: CREATE external TABLE t1 ( a int,b int,c varchar, d varchar) as COPY
from 's3://AWS_VER-55549/partition1/e=1/*' PARQUET;
select * from t1;

6. データレイクの新ライセンス計算方法・外部テーブル専用ライセンス
Vertica Add-On for External Data
 外部テーブル専用ライセンスを保持しない場合、 Premium Editionのライセンスとしてテーブル全体のサイズ（物理サイズ）に対して
ライセンス課金し、 1/4のライセンス料金のディスカウントは適用されません。 （データ圧縮してる場合、物理サイズは圧縮済み
データサイズを指します。）
 外部テーブル専用ライセンス型番（SKU）でパーペチュアル、及び、タームライセンスで購入する必要があります。
 以下の条件を満たすデータは、外部テーブル専用ライセンスで利用でき、Premium Editionのライセンス 1/4のライセンス料金で計算
します。（Premium Edition購入の際の同じ値引き率が適用されます）
 Vertica Premium Edition/Expressのライセンスをすでに購入済み、もしく同時に購入する必要があります。単体の購入はできません。
 Vertica version 8.1.1以上のバージョンで外部テーブル専用ライセンスを利用可能です。
 AWS S3、HDFS、 もしくは、外部ロケーションのデータサイズ（物理サイズ）が計算対象となります。
 Parquet及び、 ORCフォーマット(ビックデータフォーマット) を外部テーブルとして利用した場合がライセンス課金対象となります。
CSVなどのその他のフォーマットのデータを外部テーブルとしてアクセスする場合はライセンス課金対象外となります。
 処理ノード数、CPU数、利用ユーザー数の制限はありません。
 Non-production use category Class 3が適用されるため、本番環境以外で使用する場合、ライセンスを別途購入する必要があります。
 外部テーブル上で利用しないレコードがあった場合でも、テーブル全体のサイズ（物理サイズ）に対してライセンス課金します。

7. ライセンス課金例
Data Lake (HDFS or S3)
5 PB of
Data
20 TB
“Raw Data”
（非圧縮サイズ）
Vertica
Tables
100 TB
External
Tables
（圧縮されたファ
イルサイズ）
20 TB Premium
Edition License
100 TB External Data
Add-On License
（Premiumライセン
スの1/4価格）

8. 多くのインタラクティブな分析必要なダッシュボードなどの用途に最適化
クラウドデータレイクからVerticaにデータロード可能（SLAが高い場合）
• 課題：古いUDSourceは、AWSの認証情報（アクセスID、秘密鍵）を利用す
る必要があり、セキュアなアクセスができませんでした。
• 解決策：AWS S3上のParquetデータをVerticaのCopyコマンドを使用して、並
列処理で高速にロードすることも可能です。また、Copyコマンドを使用する
ことで高速にセキュアにS3と接続することができます。 新しいUDFileSystem
は、並列処理のApportioned Loadができ、AWS IAM認証を利用することがで
きます。
• 利点:
– グロブパターンをサポート（例、*.datのようなワイルドカード）
– AWS IAM認証を用いたシンプルなデータロードプロセス
– 優れたパフォーマンスとスケーラビリティ（右のグラフは、 8.x (UDS) vs.
9.x (UDFS)のロードパフォーマンス比較）
S3 bucket with
customer data
load
Load generates optimized
Vertica storage format for
fast analytics
例: CREATE TABLE t1 ( a int,b int,c varchar, d varchar);
COPY t1 from 's3://AWS_VER-55549/partition1/e=1/*' PARQUET;
select * from t1;
ROS
ROS
ROS

9. Google Cloudマーケットプレイス Vertica用“Launcher”
• 課題: 分析担当者は一つのクラウドに制限されたく
ないという課題がありました。
• 解決策: 定期的にVertica用テンプレートイメージを
Google Cloudマーケットプレイスで提供します。テ
ンプレートは、プロビジョニングプロセスを起動
し、Verticaサービスを起動することができます。
• 利点: Verticaユーザーは、AWS、Azure、オンプレ環
境に限らずVerticaを実行できます。クラウド独自で
提供するサービスに制限されることなく、統一し
たVertica環境を通じてデータ連携し、分析できます。

10. PowerBIとの接続 がマイクロソフト認定 – 高速に、セキュアに。
This is a rolling (up to 3 year) roadmap and is subject to change without notice
• 課題: MS PowerBIユーザーは、対象データを一度ローカルに
ダウンロードし、分析する必要がありました。大容量デー
タのハンドリングやパフォーマンスに課題がありました。
• 解決策: PowerBIは、新しいDirectConnectを使用してVerticaに
接続することができるようになりました。 Microsoft社と技
術協力し、PowerBIのコードをVerticaに最適な変更をしてい
ます。
• 利点: 高速に、セキュアに、スケーラブルな分析を実現しま
す。

11. クラウド環境で簡単に環境準備できるようにMCをデザイン変更
• 課題: プロビジョニングツールやスクリプトを作成するなど経験者でなければ難しいという課題があり
ました。（特に、ノードのクラスタリング、データベース作成など）
• 解決策: Cloud Service Provider (CSP) スクリプトツールと連携することで、 ユーザーフレンドリーなウィ
ザードを通じて設定できます。GUIベースのコンソールは、新規ユーザーにVerticaセットアップ後の利
用手順（データロードやクエリ実行方法など） を提供します。
• 利点: 簡単に複数のクラウド環境でセットアップでき、作業時間の短縮をすることができます。
Example: launch Vertica from
a cloud marketplace
After configuration, wizard guides you
through loading and querying data

12. Scalability
users, workloads, metadata, & data
Performance and Stability
Monitoring and Manageability
パフォーマンス向上
Compliance and Security

13. 階層的なパーティション管理でスケーラビリティ向上
• 課題: パーティションを利用することで、Vertica
は関連するストレージコンテナのみにアクセスし、
実行時間を大幅に改善することができます。しか
し、これまでのVerticaは１つのパーティションし
か、設定できず、大容量データのハンドリングに
は不便なことがありました。
頻繁に利用するクエリには細かなパーティション
設定し、利用頻度が低いクエリには粗いパーティ
ション設定をしたいという要求がありました。
• 解決策: 利用者はパーティション構造を階層的に
カスタマイズして作成することが可能です。
• 利点: カタログサイズとROSコンテナの削減できま
す。
• 例: Geography: City -> State -> Country
Time: Hour -> Day ->Month -> Year, as
shown on right

14. ユースケース：直近3ヶ月は日単位、それ以前は月単位とする
2017-07
2017-08
2017-09
2017-10
2017-11
年月でパーティション
（9.0まで）
2017-07
2017-08
2017-09-01
2017-09-30
2017-10-01
2017-10-31
2017-11-01
2017-11…
･･･
･･･
･･･
階層パーティション
（9.0から）
ALTER TABLE で、
パーティション
設定変更可能

15. ユースケース：直近3ヶ月は日単位、それ以前は月単位とする
設定変更例①：CALENDAR_HIERARCHY_DAY関数を使用する場合
1. 変更前のテーブルの設定を確認する。
2. パーティションの設定を変更する。
=> select export_objects(‘’,’sales_fact’);
------------------------------------------------
CREATE TABLE public.sales_fact
(
sales_date date NOT NULL,
area varchar(10),
sales int
)
PARTITION BY (concat((date_part('year', sales_fact.sales_date))::varchar, (date_part('month',
sales_fact.sales_date))::varchar));
・・・
=> ALTER TABLE sales_fact PARTITION BY sales_date
GROUP BY (CALENDAR_HIERARCHY_DAY(sales_date, 3));
直近3ヶ月以内は、sales_date（日単位）
でパーティションし、それ以前は、月単
位でパーティションする
参考：
https://my.vertica.com/docs/9.0.x/HTML/index.htm#Authoring/SQLReferenceManual/Functions/VerticaFun
ctions/PartitionManagement/CALENDAR_HIERARCHY_DAY.htm

16. ユースケース：直近3ヶ月は日単位、それ以前は月単位とする
設定変更例①：CALENDAR_HIERARCHY_DAY関数を使用する場合
3. 変更内容を適用するために、再編成を実施する。
4. パーティションされている状況を確認する。
=> ALTER TABLE public.sales_fact REORGANIZE;
=> SELECT DUMP_TABLE_PARTITION_KEYS('sales_fact');
---------------------------------------------------------
Partition keys on node v_vmart_node0001
Projection 'sales_fact_b0'
Storage [ROS container]
No of partition keys: 13
Partition keys: 2017-07-03 2017-07-05 2017-07-06 2017-07-09 2017-07-12 2017-07-13 2017-07-
14 2017-07-16 2017-07-17 2017-07-18 2017-07-24 2017-07-25 2017-07-26
Storage [ROS container]
No of partition keys: 10
Partition keys: 2017-08-01 2017-08-03 2017-08-04 2017-08-05 2017-08-10 2017-08-16 2017-08-
18 2017-08-27 2017-08-28 2017-08-30
Storage [ROS container]
No of partition keys: 1
Partition keys: 2017-09-01
・・・
直近3ヶ月以内は、日ご
とにコンテナが作成さ
れていることがわかる
3ヶ月より前は、月ごと
にコンテナが作成され
ていることがわかる

17. ユースケース：直近3ヶ月は日単位、それ以前は月単位とする
設定変更例②：一般的な関数を使用して指定する場合
1. 変更前のテーブルの設定を確認する。
2. パーティションの設定を変更する。
=> select export_objects(‘’,’sales_fact’);
------------------------------------------------
CREATE TABLE public.sales_fact
(
sales_date date NOT NULL,
area varchar(10),
sales int
)
PARTITION BY (concat((date_part('year', sales_fact.sales_date))::varchar, (date_part('month',
sales_fact.sales_date))::varchar));
・・・
=> ALTER TABLE sales_fact PARTITION BY sales_date
GROUP BY (
CASE
WHEN DATEDIFF('month', sales_date, CURRENT_TIMESTAMP::DATE) >= 3
THEN DATE_TRUNC('month', sales_date)::DATE
ELSE sales_date
END
);
直近3ヶ月以内は、sales_date
（日単位）でパーティショ
ンし、それ以前は、月単位
でパーティションする

18. ユースケース：直近3ヶ月は日単位、それ以前は月単位とする
設定変更例②：一般的な関数を使用して指定する場合
3. 変更内容を適用するために、再編成を実施する。
4. パーティションされている状況を確認する。
=> ALTER TABLE public.sales_fact REORGANIZE;
=> SELECT DUMP_TABLE_PARTITION_KEYS('sales_fact');
---------------------------------------------------------
Partition keys on node v_vmart_node0001
Projection 'sales_fact_b0'
Storage [ROS container]
No of partition keys: 1
Partition keys: 2017-11-07
Storage [ROS container]
No of partition keys: 1
Partition keys: 2017-11-03
・・・
Storage [ROS container]
No of partition keys: 13
Partition keys: 2017-07-03 2017-07-05 2017-07-06 2017-07-09 2017-07-12 2017-07-13 2017-07-
14 2017-07-16 2017-07-17 2017-07-18 2017-07-24 2017-07-25 2017-07-26
・・・
直近3ヶ月以内は、日ご
とにコンテナが作成さ
れていることがわかる 3ヶ月より前は、月ごと
にコンテナが作成され
ていることがわかる

19. データ型Universally Unique Identifier (UUID) をサポート
• 課題: UUID形式のデータをテキスト形式で管理するより、ストレージ
の観点で効率的なデータ形式を使用したいという要求がありました。
• 解決策: Python, ODBC, JDBC ,ADO.NET, 及び、 vsqlクライアントで
新しいデータストレージスペースの効率化形式をサポートします。
• 利点: ストレージ容量の削減、及び、パフォーマンス向上します。
• 例: テキスト形式で管理すると6bbf0744-74b4-46b9-bb05-
53905d4538e7 は、36バイト VARCHAR(36)必要であったが、新し
いUUID形式で管理すると 16 バイトで管理することができます。
CREATE TABLE document (id UUID, title VARCHAR(100));
INSERT INTO document (‘6bbf0744-74b4-46b9-bb05-53905d4538e7’, ‘Vertica in the Valley’);
INSERT INTO document SELECT uuid_generate(), ‘Vertica in Europe’);
COPY document FROM STDIN
88888888-4444-4444-4444-121212121212 | Vertica Boston
.
SELECT * FROM document;
id | title
-------------------------------------|---------------------------------------------------
6bbf0744-74b4-46b9-bb05-53905d4538e7 | Vertica in the Valley
56g3f62d-bde4-75ef-a6f2-61e5dab39149 | Vertica in Europe
88888888-4444-4444-4444-121212121212 | Vertica Boston

20. Live Aggregateプロジェクション（LAP）の更新高速化
不連続データを新しくデータロードする際に最適化
• リフレッシュ処理の高速化できます。
• ノードリカバリ中のLAP対するすべてリフレッシュは不要です。古いLAPのデータ対してのみ
リフレッシュ処理を実行することで、リカバリスピード、及び、パフォーマンスの改善でき
ます。
Number of aggregates defined in LAP
Duration(seconds)
Vertica 8
Vertica 9
LAP Refresh Duration

21. ELT向けの強化 – テーブル作成、削除時のメモリリソース効率化
Large growth in use of memory with Vertica 8, but not with Vertica 9

22. オープンソースインテグレーション、
エコシステムとの連携強化
Hadoop
Kafka
Spark

23. Hadoop

24. Hadoop Sentry サービスとのセキュリティポリシー連携
 課題: Verticaは、HDFSにアクセスする際、Hadoopユーザー名を使用する代わりにユーザーセッションを
偽装してアクセスしていました。大規模でHadoopを運用環境では、ユーザー権限の管理を集中管理し
たいという要望がありました。
 解決策: Verticaは、Apache Sentryと連携することで、Clouderaユーザー名に連携したアクセス権限を
Verticaでコントロールできるようになりました。
 利点:セキュリティポリシーを集中管理することで管理コストの軽減を
 例:

25. セキュリティレルム利用したHadoop上の複数グループのアクセスコントロール
• 課題: Hadoop のセキュリティはラージエンタープライズでは重要になっています。 例えば、
セキュリティレルムを異なるグループに適切にクリックストリームのデータからファイナン
スデータまで適用する必要がありました。そして、 Hadoopの管理者は、マーケティング部に
ファイナンスデータにアクセスさせたくないという課題がありました。
• 解決策: Kerberos Realmsと連携することで、様々なグループのアクセスポリシーでデータアク
セスの管理をすることが可能です。
• 利点: 異なるビジネスユニットに対してアクセスコントロールを実現し、セキュリティ向上す
ることができます。
• 例:

26. 機械学習、及び、アドバン
スドアナリティクス
Machine Learning for
predictive analytics
Geospatial for location
based analytics

27. 機械学習 予兆分析
Machine Learning for
predictive analytics

28. カテゴリデータを数値データに任意で自動変換
OneHotエンコーディングで分析したいカテゴリデータを数値変換
• 課題: カテゴリーデータ（ state = CA など）を分析する課題ありました。しかし、いくつかの
アルゴリズムを使用するにあたり、手動でカテゴリデータを数値データに変換する必要があ
りました。
• 解決策: 自動的に指定したVertica上のカラムをOneHotエンコーディング、もしくは、ダミー変
数で数値変換するファンクションを提供します。
• 利点: 手動の作業を簡略化。例えば、今までif-then-else句などの変換クエリで対応していた処
理が簡略化できます。
• 例: 過去の購入履歴の顧客データ（性別を含む）を線形回帰アルゴリズムで分析したい場合、
GenderカラムをOneHotエンコーディングで処理します。
ID Gender
1 Female
2 Male
3 Not specified
4 Female
5 Not specified
ID Female Male Not specified
1 1 0 0
2 0 1 0
3 0 0 1
4 1 0 0
5 0 0 1
One-hot
encoding

29. Vertica ML モデルの選択 – 適切なアルゴリズムを発見
クロスバリデーション機能を使用してモデルを作成し、評価段階で比較
• 課題: データサイエンティストは、いくつかのアルゴリズムのパフォーマンス比較し、ハイ
パーパラメータを調査する手間のかかる作業がありました。複数のモデルでパフォーマンス
を比較する機能が求められていました。
• 解決策: Verticaは、交差検証（cross-validation）機能を追加し、データサイエンティストのモ
デル選択のプロセスを支援します。様々なデータセットをモデルをトレーニングすることで、
より正確なモデルのパフォーマンスを得ることができます。 オリジナルデータをランダムに
K Subsetに分割し、その分割したサブセットを検証、テストとして利用します。K-1サブセッ
ト以外は、トレーニング用として利用します。この処理は、異なるテストデータにも繰り返
し処理します。
• 利点: 様々なモデルを比較することができます。また、過剰適合（Overfitting）や各モデルの
パフォーマンスレポートを得ることができます。 Training and testing data sets shown for k value of 5
Iteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5
例: 顧客分析をする際、クロスバリデーション
機能を利用することで、ロジスティック回帰や
SVMでどちらのパフォーマンスが良いか比較で
きます。

30. 機械学習モデルをVerticaクラスター間でインポート、エクスポート
• 課題: 複数のVerticaクラスターを運用している環境、もしくは、開発、本番システムを分けて
いる環境にて、トレーニングした機械学習モデルを別のクラスターに移行したいというニー
ズがありました。.
• 解決策: 機械学習モデルをVerticaクラスター間でコピーする機能を提供します。バイナリファ
イルをエクスポート、インポートする手順となります。
• 利点:Verticaクラスターで機械学習モデルを作成、トレーニングし、他のVerticaクラスターに
エクスポートすることができ、作業工数の削減、及び、移植性が向上しました。
• 例: myschemaスキーマ配下にあるすべての機械学習モデルをディスクにエクスポートします。
SELECT EXPORT_MODELS('/home/user1', 'myschema.*');

31. 簡単になったデータ探索
数値カラムの統計サマリー機能
• 課題: データサイエンティストは、機械学習プロセスの一連の流れとして、データ探索をしな
ければなりません。主要な統計情報を数値データから取得するために複数のファンクション
を使用する必要がありました。
• 解決策: 数値カラムに対する統計サマリー機能を追加しました。このファンクションを実行す
ることで、特定のカラム、もしくは、複数のカラムに対して、一括で主要な統計情報を所得
可能です。
• 利点: Mean/Mode, Min/Max, 標準偏差の算出のために複数のSQLクエリを毎回実行する必要が
なくなり、作業を軽減することができます。
• 例:
SELECT SUMMARIZE_NUMCOL(age) OVER() FROM customer_data_table;

32. 関連性の高い特長のあるデータを選択
Lasso回帰 （L1正則化特徴選択）
• 課題: 大規模データは、多くの特長が含まれますが、すべてのデータが有益とは限りません。
関連性の高い特長のあるデータを使用して、精度の高いモデルを作成する課題がありました。
• 解決策: 線形回帰向けにLasso回帰 （L1正則化特徴選択）が追加されました。特徴的なデータ
を選択し、処理することが可能です。
• 利点: L1正則化を利用して関連性の高いデータでモデルをトレーニングできます。関連性の低
いデータは、Lamdaの閾値（変更可能）を変更することで指定することができます。係数0を
設定した場合、データはモデルへの反映はされません。
• 例:
SELECT LINEAR_REG(
‘sales_forecast_model', ‘sales_table', ‘sales_revenue', ‘*' USING
PARAMETERS optimizer='CGD', epsilon=1e-6, max_iterations=100,
regularization='L1', lambda=1)

33. Platform support
Platform support

34. • RHEL, CentOS, and compatible OEL 6.9
• SUSE 12SP2
• Cloudera CDH 5.11
• Hortonworks HDP 2.6
Platform Support – 追加

35. • Ubuntu 12.04
Platform Support – EoL, サポート外

36. • Kafka 0.8
Platform Support –EoL予定

37. Beta Version
Platform support

38. • Computeノードとストレージノード
を独立して構成することで需要に応
じてスケースアウトすることができ
ます。利用していない場合は停止し
コスト削減できます。
• AWS EBSを使用する代わりに安価な
AWS S3を使用することでコストを削
減できます。
• データローカリティ – Depotは、ハ
イパフォーマンスクエリ用にインテ
リジェントキャッシュ機能を提供し
ます。
Beta Eon mode.
AWS環境でのコンピュートノード、及び、ストレージノードのリソース弾性
最適化
Node
Optimizer
Execution Engine
Depot
Shared storage, e.g.
AWS S3
Node
Optimizer
Execution Engine
Depot
Node
Optimizer
Execution Engine
Depot
オプションで“Eon mode”が追加 – AWS S3 共有ストレージでVertica ROSファイル(ネイティブ
フォーマット)を管理

39. Beta Eon mode.
Vertica Eon mode on AWSのアドバンテージ
• 高いSLAで大容量のデータセットにも対応 Verticaの内部テーブルにロードすることで外部テーブルよ
り高速で最適化した処理を実現することができます。各ノードに内部ストレージを持たず、ストレージ
共有することでストレージの最適化を実現し、より多くのデータをロードすることが可能です。
• 迅速なプロビジョニング、シンプルなオペレーション
• 迅速なリカバリ インフラの不具合でノードを入れ替えする必要がある場合、オンラインで迅速に準備
することが可能です。
• AWSストレージコストの削減 高価なEBSボリュームを利用することなく、安価なストレージサービス
S3サービスで運用することが可能です。
• AWSサーバーインフラコストの削減 ワークロードが少ない場合は、Verticaノード数を減らし、コスト
の削減ができます。
• デザスターリカバリ リプリケーション

40. Thank you