HP Vertica培训-基础篇

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.
HP Vertica 培训
基础篇
HP Bigdata & Vertica Real-time Analytics Platform
3/10/2014

© Copyright 2012 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice.2
重要特点:数据量大、增长迅速、变化多样性、复杂
大数据分析的能力需求
匹配分析
模型
多目标
导向与互动
上下文
关系
BIG DATA
社交媒体
视频
音频
电子邮件
文本
移动电话
交易数据
设备数据
文档
收索引擎
图片
• 快速收集
• 海量存储
• 深度挖掘
• 实时分析
大数据给传统分析平台带来巨大挑战

大数据分析关键技术
Column
MPP
大数据分析系统主流优化技术
列式存储和计算内存计算并行计算
核心是并行计算和降低I/O
Column
Column
有效解决单机
“天花板”问题
有效解决I/O
瓶颈问题
计算速度快

高速、可扩展、开放与低成本
Vertica – 专为大数据架构的实时分析平台
新一代自动优化和管理工具
真正的列式数据库
原生支持高可用并能更好地优化性能
无共享MPP架构
列式存储
和计算
主动压缩
并行装载
和查询
弹性集群
高可用
实时分析
融合存储
SQL标准
高级分析
用户自
定义分
析扩展
半结构化
数据快速
探索
HADOOP
无缝集成
X86工业化标准服务器
> 快速
50x – 1000x性能提升
> 高可扩展(Scalability)
TBs~10PBs间在线扩展
> 简单(Simplicity)
> 高压缩率
压缩率一般为10:1，节约
90%的存储空间

列式存储大幅降低磁盘I/O
Vertica为什么能这么快？
范例：计算1天中某支股票的平均价格
SELECT AVG(price)
FROM tickstore
WHERE
symbol = ‘AAPL’ AND date =
‘5/06/09’
AAPL NYASE NYAASE NYSE NYASE NGGYSE NYGGGSE NYSE NYSE NYSE 143.74 NYSE NYSE NYSE 5/05/09
AAPL NYASE NYAASE NYSE NYASE NGGYSE NYGGGSE NYSE NYSE NYSE 143.74 NYSE NYSE NYSE 5/06/09
BBY NYASE NYAASE NYSE NYASE NGGYSE NYGGGSE NYSE NYSE NYSE 37.03 NYSE NYSE NYSE 5/05/09
BBY NYASE NYAASE NYSE NYASE NGGYSE NYGGGSE NYSE NYSE NYSE 37.13 NYSE NYSE NYSE 5/06/09
列式数据库- 读取3列
行式数据库- 读取所有列
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
NYSE
NYSE
NYSE
NQDS
AAPL
AAPL
BBY
BBY
143.74
143.75
37.03
37.13
5/05/09
5/06/09
5/05/09
5/06/09
…

不仅仅是列存储，存储为查询优化
1256678
1254038
1278858
1230807
学生ID
1210466
1249290
1244262
1252490
1267170
1248100
1243483
1230382
1240224
1222781
1231806
1246648
Cappiello, Emilia
Dalal, Alana
Orner, Katy
Frigo, Avis
姓名
Stober, Saundra
Borba, Milagros
Sosnowski, Hillary
Nibert, Emilia
Popovic, Tanisha
Schreckengost, Max
Porcelli, Darren
Sinko, Erik
Tarvin, Julio
Lessig, Elnora
Thon, Max
Trembley, Allyson
F
F
F
M
性别
F
F
F
F
F
M
M
M
M
F
M
F
Sophomore
Senior
Junior
Senior
班级
Junior
Freshman
Junior
Sophomore
Freshman
Senior
Junior
Freshman
Sophomore
Junior
Sophomore
Junior
62
92
76
64
成绩
90
96
68
59
95
76
67
91
85
63
82
100
D
A
C
D
级别
A
A
D
F
A
C
D
A
B
D
B
A
查询范例: select avg( score ) from example where
class = ‘Junior’ and gender = ‘F’ and grade = ‘A’
1256678Cappiello, EmiliaF Sophomore 62D
1254038Dalal, AlanaF Senior 92A
1278858Orner, KatyF Junior 76C
1230807Frigo, AvisM Senior 64D
1210466Stober, SaundraF Junior 90A
1249290Borba, MilagrosF Freshman 96A
1244262Sosnowski, HillaryF Junior 68D
1252490Nibert, EmiliaF Sophomore 59F
1267170Popovic, TanishaF Freshman 95A
1248100Schreckengost, MaxM Senior 76C
1243483Porcelli, DarrenM Junior 67D
1230382Sinko, ErikM Freshman 91A
1240224Tarvin, JulioM Sophomore 85B
1222781Lessig, ElnoraF Junior 63D
1231806Thon, MaxM Sophomore 82B
1246648Trembley, AllysonF Junior 100A
谓词中使用的列按照前置列数值进行排
序的相关数值
学生_ID姓名成绩班级性别级别
A
D
B
A
Junior
Senior
Freshman
Junior
Sophomore
Sophomore
Junior
Junior
F
F
F
M
F
F
F
F
M
M
M
F
M
F
1256678Cappiello, EmiliaSophomore 62D
1254038Dalal, AlanaSenior 92A
1278858Orner, Katy76C
1230807Frigo, Avis64D
1210466Stober, SaundraJunior 90
1249290Borba, Milagros96
1244262Sosnowski, Hillary68
1252490Nibert, Emilia59F
1267170Popovic, TanishaF Freshman 95A
1248100Schreckengost, MaxSenior 76C
1243483Porcelli, DarrenJunior 67D
1230382Sinko, ErikM Freshman 91A
1240224Tarvin, Julio85
1222781Lessig, Elnora63D
1231806Thon, MaxSophomore 82B
1246648Trembley, Allyson100
学生_ID姓名成绩班级性别级别
AF Junior
Junior
Junior
Junior
Junior
A
A
90
100
1st I/O
读取整个列
2nd I/O 3rd I/O 4th I/O

强大的数据主动压缩
根据数据类型、基数、排序自动进行数据压缩，支持12+压缩算法
压缩比通常可达10:1以上
支持直接访问编码数据的数据值，大大节省在数据查询期间的CPU开销
Encoding Mechanism Just-In-Time Decoding
Engine:
Encoded
blocks
Buffer Pool:
De-compress
only
Network:
Encoded
blocks
+ Optional LZO
Transaction Date Customer ID Trade
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
5/05/2009
0000001
0000001
0000003
0000003
0000005
0000011
0000011
0000020
0000026
0000050
0000051
0000052
Few values
sorted
5/05/2009, 16
RLE
0000001
0
2
2
4
10
10
19
25
49
DeltaVal
Many values
integer
Raw Data Compressed Data
Disk:
Encoding +
Compression
Many Others…
Results
100.25
302.43
991.23
73.45
134.09
843.11
208.13
114.29
83.07
43.98
229.76
Many distinct
values
LZO
ÞìÃp:±æ+©>
Hì&ì¥YÛ¡×¥
©éa½?50ÓJ

无共享大规模并行处理(MPP)架构
Vertica怎么能支持大数据分析？
100% 对等
–无需专有节点
–所有节点都参与数据装载/查询
–线性扩展
• 更多的节点数=更多的数据容量 & 更高
的计算能力
集
群
网
络
客
户
端
网
络
原
生
支
持
负
载
均
衡

原生支持高可用性
Vertica怎么能支持大数据分析？
• 数据库内类似RAID的功能
• Smart K-安全性
• 加载/查询持续可用
• “活”的冗余：服务于更
多的查询
Segment 1
集
群
网
络
客
户
端
网
络
Segment 2
Segment N-1
Segment N
Segment N
Segment 3
Segment 2
Segment 1
原
生
支
持
负
载
均
衡

读写分离的混合存储架构
Vertica如何支持实时分析？
小数据量频繁
加载/修改
异步数据移动
数据移动
• 磁盘式
• 已排序/已压缩
• 已分段
•大量数据直接装载
写优化存储 (WOS)
•在内存中
•已分段
•低延时/少量快速插入
读优化存储 (ROS)
APX 60.19 7,100 1/15/2013
MSFT 60.53 12,500 1/15/2013
NFLX 78.29 25,000 1/16/2013
APX 60.25 10,000 1/15/2013
大数据量批量
加载/修改
APX,2
MSFT,1
NFLX,1
60.19
60.25
60.53
78.29
10,000
7,100
12,500
25,000
1/15/2013,3
1/16/2013,1
APX,1
MSFT,2
NFLX,1
60.25
60.29
60.53
78.29
10,000
11,000
13,500
25,000
1/15/2013,2
1/16/2013,2
APX,1
MSFT,2
NFLX,1
60.25
60.29
60.53
78.29
10,000
11,000
13,500
25,000
1/15/2013,2
1/16/2013,2
异步数据和并
数据移动
APX,3
MSFT,3
NFLX,2
60.19
60.25,2
60.29
60.53,2
78.29,2
7,100
10,000,2
11,000
12,500
13,500
25,000,2
1/15/2013,5
1/16/2013,3
APX,3
MSFT,3
NFLX,2
60.19
60.25,2
60.29
60.53,2
78.29,2
7,100
10,000,2
11,000
12,500
13,500
25,000,2
1/15/2013,5
1/16/2013,3
避免修改数据文件：
• Insert=追加
• Delete=标记删除
• Update=Delete+Insert

SQL高级分析、与分布式R无缝集成
原生SQL高级分析算法
• Statistical functions（统计分析）
• Time series gap filing and interpolation（时序插值、聚合和关联）
• Event-based window functions and sessionization （事件窗口功能及点击
流分析）
• Pattern matching（模式匹配，用户行为分析）
• Geospatial functions（地理分析）
• ……
R分布式计算扩展，并与Vertica无缝集成
• K-Means Clustering（ K-Means聚类，基于地理位置和购买方式等细分客户）
• Page Rank（佩奇排名，识别有影响力的客户）
• K-Nearest Neighbor Classification（ K-最近邻分类）
• Naïve Bayes Classification（朴素贝叶斯分类）
• Classification and Regression Trees（分类与回归树）
• ……
Vertica

快速探索和管理半结构化数据, KV/Map方式存储
Vertica FlexZone
Table
Flexible Table Data
A B C D
Table
Flexible Table Data
A B C DCA

结构和半结构化融合分析
支持JSON/XML半结构化分析
易于与Hadoop集成：
• SQL on Hadoop
• Hadoop Connector
• HDFS Connector

标准开放的关系数据库
> 与现有BI以及ETL工具轻松无缝地整合
 Vertica 数据库支持SQL、ODBC、JDBC、ADO.NET和主流ETL以及BI展现工具等产品
> 提升现有投资价值同时降低TCO
SQL, ODBC,
JDBC, ADO.net
批量与微量加载
ETL、复制与数据质量分析、报告

内置资
源管理
器
可配置
的资源
池
限定用
户/角
色
CRM 应用
工作负载管理
业务分析
移动/网络用户处理流水线
队列

自动性能调节
最优数据布局 (物理模式)  最优性能
用户提供
• 逻辑模式
• 范例数据集
• 典型查询
数据库设计器（DBD）生成数据布局建议:
• 优化查询性能
• 优化数据读取吞吐量
• 最小化存储空间
负载分析器
基于Data Collector系统收集的历史负载情况，提供优化建议

表
模式
分级存储和信息生命周期管理
存储位置和自定义存储
• 多存储位置，SSD/FusionIO、
SAS/SATA、External SAN/NAS
• 支持HDFS等自定义存储
多级存储策略，区分冷、热数据
• Schema表分区
快速分区交换分区
存
储
策
略
自
定
义
存
储
性
能
单位成本

灵活的备份与恢复
灵活的备份节点映射
• 可灵活配置 Vertica节点到备份服务器的映射
热备份
• 在线备份时无锁竞争
• 对系统性能影响小
全量与增量备份相结合
• 快速获取快照
• 只需备份增量的数据（文件）
• 可保留多个恢复点
对象级别的备份与恢复
• 配置按应用、用户、Schema级别的备份策略，满足各种不同SLA的需求

监控与管理
图形化管理控制台
• HTML5标准，无需客户端安装
• 支持多个集群的管理和监控
集群/数据库的安装/创建和日常管理
• 包括性能诊断和自动优化
实时状态监控
• 集群健康状态、各种资源的使用情况，数据库活动
历史运行情况
• 详细的历史活动和资源消耗情况资料，可用作对比分
析、调优和审计
关键事件告警
• 支持SNMP trap与外部监控应用集成
Cluster 1 Cluster 2 Cluster 3
Vertica
Management
Console
Browser
Access

创造性的Projection组织列数据，表变为逻辑层
Vertica的列式存储
按列分开存储，性能提升10x
查询可跳过无关列
按列主动排序和压缩，性能再
提升10x
大幅降低I/O开销
节约大量存储空间
不影响数据量模型
立即获得性能大幅提升
Table
Projections
Files
Containers
customer
A B C
customer_p1 customer_p2 customer_p3
ACCCA AB B
通常50x – 1000x性能提升
100
200
300
400
500
600
700
800
900
…
Rows

Projection是MPP和高可用的关键
MPP架构和高可用
00034892 trial results
00034892 ABC's storm
01734984 rt Javier
01734984 This week
08092845 Go Broncos!
08092845 Pats-onside
分段Projection 00034892 trial results
01734984 rt Javier
01734984 This week
01734984 rt Javier
01734984 This week
伙伴分段Projection
事实表
Node1 Node2 Node3
维度表
00034892 Carol
01734984 Jim
08092845 Kim
00034892 Carol
01734984 Jimmy
08092845 Kim
00034892 Carol
01734984 Jimmy
08092845 Kim
00034892 Carol
01734984 Jimmy
08092845 Kim
复制Projection
K-safe
1

INITIATOR
分析查询执行过程
select count(*) from fact;
EXECUTOR EXECUTOR
10
3
3
4
原生支持负载均衡

原生支持负载均衡
INITIATOR
明细查询执行过程
select * from fact where key=… [and …];
EXECUTOR
…
…

Projection DDL和要素
Base Query
(Joins allowed)
Segmentation
and K-safety
Column List
and Encodings
Sort Order
SEGMENTED BY hash ( host, interface,
time, metric ) ALL NODES OFFSET 0;
CREATE projection snmp_p1 (
host encoding rle,
interface encoding rle,
time encoding commondelta_comp,
metric encoding rle,
value encoding deltaval
) as
ORDER BY host, interface, metric, time
SELECT
host,
interface,
time,
metric,
value
FROM snmp

表的所有Projection是对等的
Projection分类
Superprojection
包含表的所有列
有数据的表至少有1个Superprojection
Query-specific projection
包含表的部分列
针对特定类型查询优化产生的
Pre-Join projection
直接存储事实表与维度表的join结果
Buddy projection
包含的列以及segment方式相同，但offset
用于支持高和用

Segment vs Partition
Segment是Projection的属性，用于分布数据到多个节点
Partition是表的属性，用于加速删除数据和查询
Partition是按照表达式来定义的（通常基于某个列）
CREATE TABLE…PARTITION BY TDATE
ALTER TABLE…PARTITION BY TDATE
表的所有Projection的数据都会按照Partition策略分区存储
Source Data
Node1 Node2 Node3
3/25/2013
3/24/2013
3/23/2013
3/25/2013
3/24/2013
3/23/2013
3/25/2013
3/24/2013
3/24/2013
Date Partitions:
3/23/2013

In adminTools
The Database Designer
选择 adminTools 的 Configuration 菜单

In Management Console
The Database Designer

DBD会推荐些什么？
RECORD_ID
24897507245
28347590724
28347590456
28347590724
12345957678
28347590724
19456376456
28347590724
57895895895
28347590724
09803856676
28347590724
98724567345
48347590724
53867367367
78347590724
02895672525
88347590724
09298456873
00028974587
28347590724
28347590724
00978587766
11122789045
28347590724
99825763565
99839856333
98724567345
48347590724
53867367367
78347590724
02895672525
88347590724
09298456873
00028974587
28347590724
SEX
M
F
M
M
M
M
F
F
M
F
M
M
F
M
M
M
M
F
F
M
F
M
M
F
M
M
M
M
F
F
M
F
M
F
F
F
PAIN_TYPE
4
5
7
1
2
3
4
3
6
7
3
4
5
6
1
2
4
3
1
3
4
6
7
3
1
4
4
3
2
2
1
1
6
6
7
4
BLOOD_PRESSURE
130.0
124.0
160.0
112.0
156.0
134.0
125.0
138.0
170.0
173.0
110.0
109.0
113.0
115.0
134.0
145.0
170.0
164.0
112.0
164.0
113.0
179.0
138.0
132.0
164.0
113.0
115.0
134.0
145.0
170.0
164.0
112.0
164.0
113.0
179.0
138.0
CHOLESTEROL
322.0
260.0
199.0
432.0
134.0
125.0
138.0
170.0
260.0
199.0
432.0
134.0
125.0
260.0
199.0
432.0
134.0
125.0
260.0
199.0
432.0
134.0
125.0
260.0
199.0
432.0
134.0
125.0
170.0
388.0
295.0
228.0
234.0
303.0
322.0
138.0
ECG
0
2
0
2
0
2
2
2
2
0
0
0
0
0
2
2
0
2
2
0
2
0
0
0
0
2
2
2
2
0
2
2
0
2
2
0
AGE
24.6
8.2
97.3
34.0
12.1
34.5
56.7
42.7
95.5
43.8
12.0
3.9
9.3
23.3
95.3
36.3
84.3
75.3
53.3
23.4
24.5
23.6
67.7
74.9
3.0
9.0
82.0
52.1
45.2
12.4
17.6
78.8
82.0
8.9
42.3
1.4
HEART_RATE
109.0
124.0
160.0
112.0
156.0
134.0
125.0
138.0
170.0
173.0
110.0
109.0
113.0
115.0
134.0
145.0
170.0
164.0
112.0
164.0
113.0
179.0
138.0
132.0
164.0
113.0
115.0
134.0
145.0
170.0
164.0
112.0
164.0
113.0
179.0
138.0
判断每个列的
Encoding方式
定义包含
的数据
选择排序列，以
优化特定查询
数据分布方
式
| | | | | | |
指定K-safety
CREATE projection vitals_p1 (
record_id encoding rle,
age encoding rle,
sex encoding commondelta_comp,
blood_pressure encoding rle,
heart_rate encoding deltaval ) as
SELECTrecord_id
age
sex
blood_pressure
heart_rate
FROM vitals
ORDER BY heart_rate, blood_pressure, age, sex
SEGMENTED BY hash (heart_rate, blood_pressure, age, sex)
ALL NODES KSAFE;
age encoding rle,
SELECTrecord_id
age
sex
blood_pressure
heart_rate
FROM vitals
ALL NODES KSAFE;
age encoding rle,
SELECTrecord_id
age
sex
blood_pressure
heart_rate
FROM vitals
ALL NODES KSAFE;
Queries
未优化的Super Projection

Database Designer (1 of 3)
1. 准备运行DBD
创建数据模型（库、模式和表）
装载样例数据：样例数据一定要有代表性。如果时间允许，尽量用完整数据。
收集样例查询：重要的查询，尤其是性能不满意的。放在一个文件中。
2. 运行DBD
Comprehensive mode：优化所有表的superprojections，尽可能优化指定的查询
Incremental mode：优化指定的查询。会保留原来的设计。

优化目标
Optimize for query performance: 查询性能优先
根据专家知识为每个表生成一些候选的projections
通过数据库优化器来判断不同projection的查询成本，选择成本最小的
Optimize storage footprint：存储空间（压缩）优先
根据每个列的数据特征，尝试可能的压缩算法
选择压缩效果最好的设计
Balanced design：平衡查询性能和存储空间

3. 审核DBD的输出（可选）
[design name]_params.txt ——设计参数
[design name]_design.sql ——设计结果
[design name]_deploy.sql ——部署脚本，包含设计结果和删除无用projections操作
designer.log ——设计器日志，可以查看详细的设计过程（可用于排错）
4. 部署，优化projections
在审核DBD设计结果 [design name]_deploy.sql后，手工部署
或者在DBD向导中是选择了“自动部署”选项，DBD在设计完成后会自动部署设计结果

数据装载到WOS或ROS
• Trickle Load：小量数据频繁装载
– INSERT
– UPDATE
– DELETE
– COPY
• Bulk Load：大批量数据装载
– INSERT /*+DIRECT*/
– UPDATE /*+DIRECT*/
– DELETE /*+DIRECT*/
– COPY DIRECT
Write Optimized
Store
(WOS)
In-Memory
Read Optimized
Store
(ROS)
On Disk
AUTO
(Default)

COPY 命令选项
用表达计算
COPY Retail.Dim (num, name, store, date as SYSDATE)
FROM '/home/dbadmin/dim.txt' DELIMITER '|';
根据其他列的值（当前行）计算
COPY Retail.Dim (num, name, store, joined FILLER TIMESTAMP,
joined_mth AS DATE_PART('month',joined),
joined_year AS DATE_PART('year',joined))
FROM '/home/dbadmin/dim3.txt' DELIMITER '|';
表达式可以使用大部分SQL函数, 操作符, 产量, NULL
表达式不能用聚合函数（group by）和分析函数（over, 窗口函数）

COPY 拒绝信息
每个节点会创建2个日志文件
Exceptions：拒绝原因
Rejected Data：被拒绝的数据
拒绝日志文件缺省在 <catalog directory>/CopyErrorLogs
可以在COPY命令中指定拒绝日志文件路径
COPY <table> '/home/user/data/*' EXCEPTIONS <path>
REJECTED DATA <path>;
可以用表来存放拒绝日志
COPY … REJECTED DATA AS TABLE "rejected_table_name";
SELECT * FROM "rejected_table_name";

多文件 COPY
COPY … ON ANY NODE
COPY t FROM
'/data/1.dat' ON ANY NODE,
'/data/4.dat' ON ANY NODE;
OR
'/data/*.dat' ON ANY NODE;
1.dat 2.dat
3.dat 4.dat
Optimally distributed among all
nodes
Weighted by file size
Node_A Node_B Node_C Node_D
Stored on a
shared NFS
mount;
accessible
from all nodes

客户端装载
允许装载存放在客户机上的文件
不需要特殊权限
异常信息存放在客户端
COPY <table> from LOCAL '/home/user/data/*' EXCEPTIONS
<path> REJECTED DATA <path>;

监控数据加载过程
监控系统表 load_streams
Rows accepted (parsed), rejected, bytes read, % complete
每个COPY命令1行记录
拒绝日志文件
<catalog-dir>/CopyErrorLogs/<table-name>-<input-filename>-copy-from-exceptions
• 拒绝原因，每行数据一条
<catalog-dir>/CopyErrorLogs/<table-name>-<input-filename>-copy-from-rejected-data
• 被拒绝的数据
COPY命令中可以指定拒绝信息存放路径

数据删除
删除的数据不会立即被清除
删除记录被标注为“deleted”
删除数据列表——DV（Delete vectors），由一系列代表被删除数据行的(position, epoch)
组成
当TM(TupleMover)把数据从内存moveout到磁盘时，DV也按数据文件区分存放到磁
盘中
查询时，执行引擎会排除DV中的行
当TM(TupleMover)进行碎片文件mergeout时，DV以及相关的数据会被真正丢弃
手动执行Purge操作， DV以及相关的数据也会被真正丢弃

数据删除
Table
Projection
CAB
A B C
.fdb fiIes
POSITION EPOCH…
2 1092
4 1092
9 1093
Delete VectorSTORAGE_ID SYS_ID
897503545 ;fjl[q05om
523nj66890 qt0-23er
2475345907 .np48905
287535956 0345 [09op
283473024 a[07a0rgvd
194563456 05omagsbv
283472924 wlue[0pos
578953955 [0-8563p4j
523nj66890 qt0-23er
2475345907 .np48905
287535956 0345 [09op
STORAGE_ID SYSTEM
8975045 auaeokbfb
24753724 hetnmw,.
2870456 0f[0c89q; djg
2890724 ajvam 45jkag
1234678 789v d[09op
280724 a df-98q34kd
19456324 s[q0magsbv
283424 wk voaiue[0-4
578958255 lkvoiow[0-8
283475907 60ojqt0-23er
2890724 alkjv 45jkag
STORAGE_ID COMMENTS
89750545 kojkl
244590724 hakljf
28753596 ;alsdjg -9
28340724 45jkag
12343457 v d[09op
2834734 ;lkrgvd
19424456 ijafbv
4725924 pojpos
57895855 -8563p4jo
2839070 t0-23er
89750545 kojkl
X
X
X

删除性能优化
删除性能取决于projection的设计
所有的projections都应该针对删除操作优化
表的所有projections都应该保护删除语句的条件列
尽量选择选择性好的列放在Projection的ORDER BY列表后面，便于定位要删除的记录
检查表是否有潜在的删除性能问题
SELECT evaluate_delete_performance('table');

Partition主要用于加速删除数据和查询
分区
分区和数据文件（ROS containers）
数据装载时会自动创建分区
数据库内部操作（包含Moveout，Mergeout，refresh，recovery）会确保不同分区分会存
放到不同的数据文件
分区裁剪
当查询条件中包含分区列时，会只读相关的数据文件
谨慎选择分区表达式，建议最多不要超过700个分区
如果按日期：相当于保存2年数据
如果按月份：相当于保存58年数据
注意：分区表达式不能用非幂等函数
例如，不能用 timestamp with time zone (value depends on user timezone)

删除分区
SELECT drop_partition('<table>', '<partition_value>');
SELECT drop_partition ('fact', 2012);
SELECT drop_partition ('fact', extract ('year' FROM '2012-01-
01'::date));
删除分区时，会强制把数据从内存moveout到磁盘
因为WOS不分区

更新统计信息
数据统计信息被写入catalog，被查询优化器用于评估查询成本。收集时机：
初始数据装载后
数据大幅度被修改， > 50%
查询性能发生变化(stale statistics)
收集统计信息的方法：
-- Reads a fixed 10% of data， Use '' for all tables
SELECT analyze_statistics ('table-name');
-- 查看列的统计信息
SELECT * FROM projection_columns WHERE table_name =
'table-name';
负载分析器会建议收集统计信息

Projection DDL和要素
Base Query
(Joins allowed)
Segmentation
and K-safety
Column List
and Encodings
Sort Order
SEGMENTED BY hash ( host, interface,
time, metric ) ALL NODES OFFSET 0;
CREATE projection snmp_p1 (
host encoding rle,
interface encoding rle,
time encoding commondelta_comp,
metric encoding rle,
value encoding deltaval
) as
ORDER BY host, interface, metric, time
SELECT
host,
interface,
time,
metric,
value
FROM snmp

Projection应该包含哪些列
包含查询要访问的所有列
包括delete语句的条件
可能只包含表的一部分列
执行查询是，优化器一次只会选择表的其中一个projection来响应查询请求

通过ORDER BY 子句定义
决定 Projection 的排序
1. 查询条件（谓词）列放在最前面
• 按基数由小到大（或按选择性由低到高）排列
• RLE编码的列
2. 包含GROUP BY 子句的列
• 按基数由小到大（或按选择性由低到高）排列
3. 排序列表增加到每个分组内平均行数到10s时停止
SELECT count(*)
FROM students
GROUP BY gender, class, pass;
4. 考虑其他因素
• 关联（Join）优化
• 一致分片Projections（Identically Segmented Projections, ISP）
• 分组（Group by）优化

优化关联(Join)
让优化器选择理想的关联操作方式
针对Hash Join(HJ)或Merge Join（BJ）来创建Projection
尽可能减少网络操作
按关联键来分布projection，让关联只需要在节点内部的数据上执行——也称作本地关联
彻底避免查询时关联
逆范式设计——胖表
采用 pre-join projection

Hash Join 操作
最常见的关联操作，不需要特殊优化
基于 inner table（小表）创建 Hash 表
扫描 Outer table（大表）, 匹配的行就输出到结果集合
C
B
D
E
A
E
B
A
D
B
C
A
Unsorted column
(from outer table)
Unsorted column
(from inner table)
Value
D
B
C
A
Hash Table
(In Memory)
Build Hash Table
Found a match
Output tuple
No match

Hash Join– 关联溢出
关联溢出：如果Inner Table太大，导致 Hash 表无法完整地放在内存中，执行引
擎只能采用频繁地在内存与磁盘中交换需要访问的部分。
Veritca会先尝试只在内存中Hash关联，如果失败，再采用磁盘Hash关联
如果事先知道查询会溢出，可以在查询中添加 Hint 来避免尝试内存 Hash关联
SELECT /*+add_vertica_options(EE,ENABLE_JOIN_SPILL)*/ …
判断Vertica是否曾经尝试过内存 Hash关联：
可以 PROFILE 查询语句来判断内存是否足够，或者检查 vertica.log

Merge Join 操作
对于 inner table 大于内存中的关联，推荐采用流式的 merge join，速度会更快
因为只需要少量内存，不需要磁盘
A
B
C
D
Sorted column (from outer table) Sorted column
(from inner table)A
B
B
C
D
D
E
E
A =
A
Output Tuple
B ≠
A
B =
B
C ≠
B
C =
C
D ≠
C
D =
D
E ≠
D
No more values. Join completed.

Merge Join 的必要条件
关联左右的数据都必须按关联列排序
表有含按关联列排序的 projection
或者用带 ORDER BY 子句的子查询来替代表
优化器会首先执行等式谓词（过滤），以减少要关联的数据量
等式谓词应只能是单值过滤，且列正好在 projection ORDER BY 子句中位于关联列前面
如果 Outer table 的 projection 是按关联列排序的，尽管 Inner table 的数据
不是按关联列排序的，优化器也可能采用 Merge Join
但会先对 Inner table 进行动态排序，这叫 Sort Merge Join (SMJ)

为 Merge Join 设计
按关联列排序 Fact 和 Dimension 表的 projections
范例查询
SELECT * FROM Fact F, Dim D WHERE F.id = D.id;
范例 projections
CREATE PROJECTION Fact_p
(
a ENCODING RLE,
b ENCODING RLE,
c,
id ENCODING RLE
) AS
SELECT a, b, c, id FROM Fact
ORDER BY id, b
SEGMENTED BY HASH(c) ALL NODES;
CREATE PROJECTION Dim_p
(
x ENCODING RLE,
y ENCODING RLE,
z,
id ENCODING RLE
) AS
SELECT x, y, z,id FROM Dim
ORDER BY id, x, y
UNSEGMENTED ALL NODES;

带谓词下推(Pushdown) 的 Merge Join
首先按谓词中过滤条件列排序 fact 表的 projection
然后按关联列排序 Fact 和 Dimension 表的 projection
范例查询
SELECT * FROM Fact F, Dim D WHERE F.id = D.id AND f.a = 10;
范例 projections
CREATE PROJECTION Fact_p
(
a ENCODING RLE,
b ENCODING RLE,
c,
id ENCODING RLE
) AS
SELECT a, b, c, id FROM Fact
ORDER BY a,id, b
SEGMENTED BY HASH(c) ALL NODES;
CREATE PROJECTION Dim_p
(
x ENCODING RLE,
y ENCODING RLE,
z,
id ENCODING RLE
) AS
SELECT x, y, z,id FROM Dim
ORDER BY id, x, y

识别关联操作类型
从查询执行计划中查找
JOIN HASH
JOIN MERGEJOIN
– 如果 inner projection 不是有序的，关注 SORT ON JOIN KEY
在 vertica.log 中查找
如果 hash table 太大放不进内存, 关注 vertica.log 中带 ENABLE_JOIN_SPILL 的查询重试

优化关联 – 网络操作
本地关联(Local Join)的要求
匹配 fact 和 dimension 表关联的数据必须在相同的节点上
fact 表采用分布，小的 dimension 表采用复制
Fact: SEGMENTED BY HASH (id) ALL NODES;
Dimension: UNSEGMENTED ALL NODES;
一致分布 Projections，Identically Segmented Projections
关联的两个 projections 按关联列分布
查询结果在 initiator node 上聚合

为 Local Joins 设计
• 复制小的 dimension projections，分布大的 fact projections
01734984 rt Javier
01734984 This week
Segmented Projection 00034892 trial results
01734984 rt Javier
01734984 This week
Fact Data
Node1 Node2 Node3
Dimension Data
00034892 Carol
01734984 Jim
08092845 Kim
00034892 Carol
01734984 Jimmy
08092845 Kim
00034892 Carol
01734984 Jimmy
08092845 Kim
00034892 Carol
01734984 Jimmy
08092845 Kim
Replicated/Unsegmented
Projection

分布和复制 Projections
复制小的 dimension projections，分布大的 fact projections
范例查询
SELECT * FROM fact F
JOIN dim D ON F.id = D.id;
范例 projections
CREATE PROJECTION fact_p
(
a ENCODING RLE,
b ENCODING RLE,
c ENCODING RLE,
id
) AS
SELECT a, b, c, id FROM fact
ORDER BY id, a, b, c
SEGMENTED BY HASH(id) ALL
NODES;
CREATE PROJECTION dim_p
(
x ENCODING RLE,
y ENCODING RLE,
z,
id
) AS
SELECT x, y, z,id FROM dim
ORDER BY id, x, y

一致分布 (ISP)
单 fact 和 dimension 表都较大时, 关联的两个 projections 按关联列分布, 匹配
关联的数据都在相同的节点上
01734984 rt Javier
01734984 This week
Large Fact
segmented by hash (FK)
01734984 rt Javier
01734984 This week
Large Dimension
segmented by hash (PK)
Large Dimension Large Fact
Node1 Node2 Node3
00034892 Carol
01734984 Jim
08092845 Kim
01734984 Jim00034892 Carol 08092845 Kim

一致分布设计范例
关联的两个 projections 按关联列分布
范例查询
SELECT * FROM fact F
JOIN dim D ON F.id = D.id;
范例 projections
CREATE PROJECTION fact_p
(
a ENCODING RLE,
b ENCODING RLE,
c ENCODING RLE,
id
) AS
SELECT a, b, c, id FROM fact
ORDER BY id, a, b, c
NODES;
CREATE PROJECTION dim_p
(
x ENCODING RLE,
y ENCODING RLE,
z,
id
) AS
SELECT x, y, z,id FROM dim
ORDER BY id, x, y
NODES;

识别网络操作类型
• 如果要关联的数据在不在本地，必须动态分布数据，这就需要网络操作
• 在执行计划中查找网络操作：广播(BROADCAST)和重分段(RESEGMENT)
• Look for these network operators in the Explain Plan
– BROADCAST (sends temporary full copy of data to each node)
Access Path:
+-JOIN HASH [LeftOuter] [Cost: 40K, Rows: 10K (NO STATISTICS)] (PATH ID: 1)
Inner (BROADCAST)
| Join Filter: (T1.a > T2.y)
| Materialize at Output: T1.b
| Execute on: All Nodes
– RESEGMENT (sends temporary ISP segments to each node)
Access Path:
+-JOIN HASH [Cost: 639, Rows: 10K (NO STATISTICS)] (PATH ID: 1) Inner
(RESEGMENT)
| Join Cond: (T1.a = T2.y)
| Materialize at Output: T1.b | Execute on: All Nodes

优化分组(Group By)
针对不同的分组操作设计
Group By Pipe：流式分组
Group By Hash：按 Hash 分组
针对本地分组(Local Group By)设计
数据分布方式确保每个分组只在一个节点上

Group By Hash
SELECT count(*) FROM cust GROUP BY cust.state;
在结果输出前，Hash 表必须能全部放在内存中（与Hash Join相似）
CA
MA
AL
CA
DE
AL
MA
DE
Value Count
Hash Map (Stored In Memory)cust.state (Unsorted)
CA 12
MA
AL
DE
1
1
1
2
2
2
Return to User

Group By Pipe
SELECT count(*) FROM cust GROUP BY cust.state;
需要很少的内存，数据量大时远快于 Group By Hash（与 Merge Join相似）
cust.state (Sorted)
C 12BCount( ) = Return to User
AL
AL
CA
CA
DE
DE
MA
MA

Group By Pipe
Group by Pipe 对聚合存在大量分组的数据，是非常关键的
可以流式处理无限制行数据
分组数量不重要
如果存在过滤条件，也可以优化它，因为等值谓词会在 Group by Pipe 之前执行
Group by Pipe 的输出结果也是有序的
在执行计划中可以识别分组操作类型
GROUP BY HASH 或 GROUP BY PIPELINED

为 Group By Pipe 设计
所有的分组列必须在projection 的 Order By 子句最前面
注：前面还可以放等值过滤条件列
范例查询
SELECT count(*) FROM cust GROUP BY a, b, c;
范例 projection
CREATE PROJECTION cust_p
(
a ENCODING RLE,
b ENCODING RLE,
c ENCODING RLE,
d,
e
) AS
SELECT a, b, c, d, e FROM cust
ORDER BY a, b, c
SEGMENTED BY HASH(d) ALL NODES;

分布式分组
如果数据“随机”分布在多个节点上，那么完成分组之前必须对数据动态分段
按分组列动态分段(RESEGMENT)
如果每个分组已经只存放在一个节点上会呢?
按分组列分段来设计Projection
在查询执行计划中识别分布式分组
显示为 RESEGMENT GROUP

为本地分组设计
分组列来分布Projection
范例查询
SELECT count(*) FROM cust GROUP BY a, b, c;
范例 projection
CREATE PROJECTION cust_p
(
a ENCODING RLE,
b ENCODING RLE,
c ENCODING RLE,
d, e
) AS
SELECT a, b, c, d, e FROM cust
ORDER BY a, b, c
SEGMENTED BY HASH(a, b, c) ALL NODES;

分组的动态分段
如果 projection SEGMENTED BY HASH(a,b) ALL NODES，查询分组按照：
– GROUP BY a
• 需要动态分段，因为其他的分段列(b)不在分组列中
– GROUP BY a,b
• 不需要动态分段
– GROUP BY a,b,c
• 不需要动态分段
– GROUP BY a+1,b
• 需要动态分段，优化器还没有“聪明”到这个地步（就像传统数据库选择索引一样）

为什么需要资源管理器?
Vertica Cluster
Recovery
Refresh
System table queries
Web
Apps
Reporting Tools
Ad hoc
queries
Loads
Tuple Mover
(moveout/mergeout)
DBD

查询执行过程
• Create Query Plan on Initiator
– Reject if request requires resources beyond availability
• Distribute Query Plan to Executors
• Create Local Query Plan on Executors
– Determine required resources
• Determine admission to Executors
– Run query
– Queue query - possible reject
• Launch Execution Engine on Executors
– Manage runtime resources
• Process results and send to initiator node for aggregation
RESOURCEMANAGER

资源池(Resource Pools)
控制内存分配, 并发, 排队超时, 优先级
控制用户查询和系统内部操作
可为满足不同并发要求来调优
增加用户自定义资源池，可按优先级调度系统资源
可为用户指定特定的资源池
缺省为 General pool

资源池参数(1 of 7)
MEMORYSIZE: 保留内存 (0 表示不保留)
MAXMEMORYSIZE: 最大可用内存。无论是保留的还是从
GENERAL pool 借的
如果一个资源池设置 MEMORYSIZE = 3G and MAXMEMORYSIZE = 3G 一位着什么
??
如果你有一个资源池，参数为：MEMORYSIZE = 1G, MAXMEMORYSIZE = 5G, 并
且执行一个查询需要 5G 内存，那么需要从 General pool 借多少内存? 如果执行查询
需要 6G 内存呢?
?

资源池参数 (2 of 7)
MAXCONCURRENCY: 最大并发查询数
超过 MAXCONCURRENCY 时，新的查询请求进入等待队列
PLANNEDCONCURRENCY: 并发查询数期望值
用于决定分配给每个查询的路标内存
缺省值为 CPU 核数
Allotted memory
size per query
=
[MAX]MEMORYSIZE
PLANNEDCONCURRENCY

PLANNEDCONCURRENCY 场景: 6 个用户被分配到
名叫 “ABC” 的资源池，所有用户同时运行需
要 1G 内存的查询
ABC pool parameters:
MEMORYSIZE 4G
PLANNEDCONCURRENCY 4
MAXCONCURRENCY 5
Allotted memory
size per query
=
[MAX]MEMORYSIZE
PLANNEDCONCURRENCY
那么在本案例 4G
4
= 1G per query
Query 1 1G
Query 2 1G
Query 3 1G
Query 4 1G
Query 5 1G
Query 6 1G
ABC
General
Queue
这些查询会怎么执行?

EXECUTIONPARALLELISM: 执行并发度。限制执行每个查询可用的线程数
降低这个参数可以提供小查询的吞吐能力（避免不必要的线程上下文切换）
PRIORITY: 优先级。指定资源管理器分配内存的顺序
只对排队的请求起作用
相同优先级的请求，按请求达到的顺序
优先级不会让查询执行的更快，但可以减少等待时间
Query   Results
Threads

RUNTIMEPRIORITY:运行时优先级。代表总体上用于本资源池的资源量(CPU,
I/O bandwidth)
有效取值：HIGH, MEDIUM, or LOW
HIGH 运行时优先级的查询，会比 MEDIUM/LOW 的查询得到更多的 CPU 和 I/O 资源
RUNTIMEPRIORITYTHRESHOLD:运行时优先级阀值。运行时优先级起作用之
前，查询可以按 HIGH 执行的时间(单位seconds)。
目的是提升整体吞吐能力：短查询快速完成，长时间执行的任务可逐步降低优先级
设置 RUNTIMEPRIORITYTHRESHOLD 为 0 并且
RUNTIMEPRIORITY 为 high 意味着什么?
?

RUNTIMECAP: 最长执行时间
QUEUETIMEOUT: 队列中等待最长时间

CPUAFFINITYMODE: CPU 粘滞模式
有效取值：any (缺省), exclusive 或 shared
CPUAFFINITYSET: 资源池上执行查询可用的CPU集合
修改这些参数之前，请咨询 Vertica 技术支持！

资源池参数缺省值
Parameter default description
is_internal f the pool is not built-in
memorysize null no reserved memory
maxmemorysize null no maximum memory
executionparallelism auto defaults to # cores
priority 0 no priority on queued transactions
runtimepriority medium medium priority once threshold is met
runtimeprioritythreshold 2 transaction runs at high priority for 2 seconds
queuetimeout 300 transaction will time out if queued for 5 minutes
plannedconcurrency auto defaults to # cores
maxconcurrency null unlimited concurrency
runtimecap null
no transaction time limit (allows run-away
queries)
singleinitiator f for backwards compatibility only; retain default
cpuaffinityset | Set to run all queries on any cpu
cpuaffinitymode Any Queries from this pool can run on any cpu

内建资源池
GENERAL
95% of RAM
64M
SYSQUERY
100M
SYSDATA
200M
TM (Tuple Mover)
WOSDATA JVM RECOVERY REFRESH
保留内存
不保留内存
DBD

内建资源池 (1 of 2)
GENERAL
用户查询的缺省资源池
其它资源池的内存不够时，会从向这个此借
使用一部分系统内存作为上线，缺省为 95%
SYSQUERY
执行系统内部查询所用的资源池
SYSDATA
系统表数据存储空间
TM
用于Tuple Mover 任务 (moveout 和 mergeout)

内建资源池 (2 of 2)
WOSDATA
用于小批量数据装载，缺省为2G 和 25%可用内存的最小值
如果只采用批量数据装载，可以尽可能减少这个资源池的内存
如果小批量数据装载任务非常频繁，可以适当调高这个资源池的内存
JVM
专用与 Java 自定义函数
2G 或 10%可用内存
DBD
专用与DBD
RECOVERY
用于节点故障后恢复
REFRESH
用于新建 projection 数据刷新

内建资源池参数对比
name general sysquery tm recovery wosdata
executionparallelism AUTO AUTO AUTO AUTO
maxconcurrency 3 1
maxmemorysize Special: 95% 2G
memorysize 64M 200M 0% 0%
plannedconcurrency AUTO AUTO AUTO AUTO AUTO
priority 0 110 105 107
queuetimeout 300 300 300 300
runtimecap
runtimepriority MEDIUM HIGH MEDIUM MEDIUM
runtimeprioritythreshold 2 0 60 60
cpuaffinitymode DEFAULT DEFAULT DEFAULT DEFAULT DEFAULT
cpuaffinityset

用户自定义资源池
为你的特定场景的设计资源池
所有的参数都可以定制
如果查询需要更多的资源（内存），它们可能会向 General pool 去借
CREATE RESOURCE POOL load_pool MEMORYSIZE '10G' PRIORITY 100;
用户自定义资源池
可能会以100优先级向 general pool
借资源
(由于 MAXMEMORY 未指定)
10 GB 保留内存

用户的资源池使用规则
如果未指定自定义资源池，用户查询会
在 General 或者 SYSQUERY 中执行
一个用户只能指定一个资源池
用户组不能指定资源池
GENERAL/
SYSQUERY
User-defined
GENERAL/
SYSQUERY
Admin
group


GENERAL/
SYSQUERY


User-defined/
SYSQUERY

为用户指定资源池
创建资源池
指定用户的资源池方式:
创建用户的时候指定
或者修改用户属性
CREATE RESOURCE POOL load_pool MEMORYSIZE '10G' PRIORITY 100;
CREATE USER test RESOURCE POOL load_pool;
ALTER USER…

用例 – 在线零售企业的 CEO
我们的 CEO 每周一9AM要生成报表.
我们如何保证报表总是能够及时生成出来?

用例 – 在线零售企业的 CEO，解决办法
用 PROFILE 评估查询执行需要的内存
创建专用的资源池
设置足够的 MEMORYSIZE
把资源池指定给 CEO 执行报表的用户
这个方法有什么不足?
# PROFILE SELECT region, sum(revenue) FROM sales group by region;
NOTICE: Statement is being profiled.
HINT: select *
from v_monitor.execution_engine_profiles
where transaction_id=45035996273751349
and statement_id=6;
NOTICE: Initiator memory estimate for query:
[on pool general: 1723648 KB, minimum: 355920 KB]
# CREATE RESOURCE POOL ceo_pool MEMORYSIZE '1800M' PLANNEDCONCURRENCY 1 PRIORITY
50;
# ALTER USER ceo_user RESOURCE POOL ceo_pool;

用例 – 手机供应商的Web应用
我们有一个集成门户的Web应用。当 IT 执行批量报表的时候，用户抱怨
页面执行更新会变慢，要花很长时间。
在不终止批量报告的情况下，我们如何能改善网站用户的用户体验?

用例 – 手机供应商的Web应用，答案
为网页更新查询创建专门的资源池
设置 PLANNEDCONCURRENCY 和 MEMORYSIZE
指定资源池到网站查询所用的数据库用户
为批量报表创建资源池，限制固定大小内存，为其它任务保留尽可能多的
内存
# CREATE RESOURCE POOL web_pool MEMORYSIZE '250M' PRIORITY 50
MAXCONCURRENCY 5 PLANNEDCONCURRENCY 1
# CREATE RESOURCE POOL batch_pool MEMORYSIZE '4G‘ MAXMEMORYSIZE '4G'
MAXCONCURRENCY 10:

监控资源池
系统表描述
RESOURCE_POOLS 所有资源池的参数，包括内建资源池
RESOURCE_REJECTIONS 资源请求拒绝情况和拒绝原因
RESOURCE_ACQUISITIONS 通过的每个查询资源请求信息
RESOURCE_POOL_STATUS 所有资源池的当前状态，包括内存使用情况、正在执行的并
发查询数
RESOURCE_QUEUES 当前等待队列中的查询,保持资源池和优先级信息
USERS 用户关联的资源池信息

安装过程
规划和准备软、硬件环境
X86 Linux服务器，建议：
• 2 Socket, 12～20核
• 内存:CPU核数=4～8，建议8
• 磁盘：建议16～25块SAS盘/节点
– 生产环节一定要做RAID，避免频繁的磁盘故障导致节点故障。建议用RAID10
• 尤其是写操作较多（实时装载、大量汇总）的场景，或者磁盘数量较少（<16块/节点）
– 直接用硬盘分区而不是逻辑卷
• Linux的逻辑卷管理不够成熟，特定条件下会有数据丢失风险，不支持在生产环境上使用
– 读写性能满足：20～40 MB/CPU核，可用 /opt/vertica/bin/vioperf 评估
– 尽肯能用SAS盘而不是SATA盘
• 万兆/千兆网络：最好4块网卡，每2块网卡绑定，分别用于集群内部网络和外部服务网络
生产环境建议3节点以上，否则没有高可用能力
一键安装Vertica和Manage Console，详见《Installation Guide》

访问管理控制台(Management Console)
打开浏览器，在地址栏输入
https://<IPAddressofVerticaConsole>:5450
mcadmin

管理控制台 – 主窗口

管理控制台 – 数据库窗口
mcadmi
n

管理控制台 – 概览
mcadmi
n

管理控制台 – 活动
mcadmi
n

管理控制台 – 管理窗口
mcadmi
n
KPI Views include: Node State, CPU Utilization, Memory Utilization and
Storage Used

管理控制台 – 通用设置
mcadmi
n

管理控制台 – Tuple Mover 设置
mcadmi
n

管理控制台 – 事务(Epoch) 管理设置
mcadmi
n

管理控制台 – 监控设置
mcadmi
n

管理控制台 - Database Designer
mcadmi
n

使用 admintools
执行系统管理任务的控制台（菜单导航）
可以在任一节点上执行，但不允许并发执行
常用管理任务
执行 Database Designer
管理集群节点

监控服务器
CPU：每个节点的 CPU 使用情况
内存：每个节点的内存使用情况
I/O：每个节点、每个数据存储位置的I/O吞吐量
可用磁盘空间：保留不低于 40% (用于 mergeout 和临时空间)

监控网络
确定活动IP所在的网段
验证服务IP端口或应用协议发送／接受吞吐量
监控丢包率
监控带宽使用情况

常用Linux监控命令
Memory Utilization
free
top
CPU and Disk I/O
iostat
vmstat
sar
Disk
df –h
Network
ifconfig -e

监控 Vertica
Vertica 日志和相关目录
管理控制台
Simple Network Management Protocol (SNMP)
评估工具
系统表

Catalog 目录结构

Data 目录结构

Vertica 日志内样例
2012-05-08 16:06:36.273 Init Session:0xace3048 [Txn] <INFO> Starting Commit: Txn: a00000000000c0 'COPY test_tick_data FROM
'/data3/test/Blue/test_tick_data.txt' DELIMITER '|' EXCEPTIONS '/data3/test/Blue/dim_e5.txt' DIRECT NULL '';‘
2012-05-08 16:06:36.275 Init Session:0xace3048 [Command] <INFO> [Bulkload] Direct copy to test_tick_data from pipe committed at epoch 23.
2012-05-08 16:06:52.590 Init Session:0xace3048 [Session] <INFO> [Query] TX:0(Earth17243:0x1869) at epoch latest
SELECT TDS.T, TDS.TPREV, TDS.D FROM TEST_TICK_DATA TDS WHERE TDS.T > 2 and TDS.TPREV <= 2;
2012-05-08 16:06:52.593 Init Session:0xace3048 [Txn] <INFO> Begin Txn: a00000000000c3 'at epoch latest
SELECT TDS.T, TDS.TPREV, TDS.D FROM TEST_TICK_DATA TDS WHERE TDS.T > 2 and TDS.TPREV <= 2;'
2012-05-08 16:06:52.645 Init Session:0xace3048 <ERROR> @v_demo_node0004: 42V15: Insufficient projections to answer query
DETAIL: No projections eligible to answer query
HINT: Projection test_tick_data_P3_v_demo_node0006 not used in the plan because the projection create epoch is greater than the
query end epoch.
Projection test_tick_data_P3_v_demo_node0005 not used in the plan because the projection create epoch is greater than the
query end epoch.
Projection test_tick_data_P3_v_demo_node0004 not used in the plan because the projection create epoch is greater than the
query end epoch.
LOCATION: throwInsufficientProjectionsError, /scratch_a/release/vbuild/vertica/Optimizer/Path/StarOpt.cpp:5653
2012-05-08 16:06:52.647 Init Session:0xace3048 [Session] <INFO> [Query] TX:a00000000000c3(Earth17243:0x1869) at epoch latest select
count(*) from TEST_TICK_DATA;
2012-05-08 16:06:52.665 Init Session:0xace3048 <ERROR> @v_demo_node0004: 42V15: Insufficient projections to answer query
DETAIL: No projections eligible to answer query
vertica.log files on each node in
…/<DatabaseName>/v_<DatabaseName>_<NodeName>_catalog

评估工具
vioperf
评估 I/O 速度和稳定性
vnetperf
测试节点间网络延迟和带宽
vcpuperf
测试CPU性能和节能模式

系统表
位于2个Schemas中
Catalog information is in v_catalog (47 tables)
Monitoring information is in v_monitor (82 tables)
• SELECT * FROM system_tables
ORDER BY table_schema, table_name;
例：
WHERE table_description ilike '%projections%';
WHERE table_name ilike '%resource%';

配置参数
• SELECT * FROM configuration_parameters;
– current_value
– default_value
– change_under_support_guidance
– change_requires_restart
• SELECT * FROM configuration_parameters
WHERE parameter_name ilike '%interval%';

监控 ROS 和 WOS, 存储和删除
SELECT PS.node_name, SC.projection_name,
PS.ros_count ROS_count_per_projection,
used_bytes_per_proj,
wos_row_count, wos_used_bytes,
ros_row_count, ros_used_bytes,
SC.total_row_count rows_per_ros,
SC.deleted_rows,
SC.grouping
FROM projection_storage PS INNER JOIN
storage_containers SC
ON PS.node_name = SC. node_name
AND PS.projection_name = SC.projection_name
AND PS.projection_schema = SC.schema_name
Alternatively, use column_storage system table for column level storage
node_name
projection_na
me
ROS_count_per
_proj
used_bytes_per
_proj
wos_row_co
unt
wos_used_byt
es ros_row_count ros_used_bytes rows_per_ros deleted_rows grouping
v_test_402_node0001 P_bydate2 2 57442590 0 0 1668224 57442590 1667712 0 PROJECTION
v_test_402_node0001 P_bydate2 2 57442590 0 0 1668224 57442590 512 0 ALL
v_test_402_node0001 P_bydate 2 57342374 0 0 1665267 57342374 1664755 0 PROJECTION
v_test_402_node0001 P_bydate 2 57342374 0 0 1665267 57342374 512 0 ALL

在Vertica中监控
数据装载
Projection 刷新
节点恢复
查询执行

装载监控
LOAD_STREAMS：监控装置过程的系统表
CopyErrorLogs 目录：查看拒绝信息
PARTITIONS：查看每个分区数据文件数目的系统表
TUPLE_MOVER_OPERATIONS：监控 moveout 和 mergeout 信息的系统表

Projection 刷新
PROJECTION_REFRESHES：刷新状态系统表
vertica.log日志：刷新失败原因
Disk 空间：临时和数据空间监控

节点恢复
PROJECTION_RECOVERIES：恢复过程系统表
相邻节点的资源使用情况：
节点恢复过程中，可能需要从相邻节点去同步新的数据，会消耗CPU、I/O和网络

查询执行
资源池相关系统表
RESOURCE_POOLS, RESOURCE_POOL_STATUS, USERS
资源状态相关系统表
RESOURCE_ACQUISITIONS, RESOURCE_POOL_STATUS, RESOURCE_QUEUES, RESOURCE_REJECTIONS
管理控制台图表
用 Profile 评估查询资源要求
用 vsql 的 timing 开关评估查询响应时间

排错工具
诊断工具
会话信息
锁冲突
查询性能诊断
实用个工具
Spread

诊断工具: Vertica Logs
vertica.log files
On each node in: …/<DatabaseName>/v_<databaseName>_<NodeName>_catalog
Database Designer Log
<designer_output_directory>/designer.log

诊断工具: Copy Error Logs
…/<DatabaseName>/v_<databaseName>_<NodeName>_catalog/CopyErrorLogs
<input_filename>-copy-from-exceptions – reason for rejection
<input_filename>-copy-from-rejected-data – rejected data

其他诊断工具
查看 Vertica 版本号
通过管理控制台
rpm -qa | grep vertica
select version();

Managing Database Sessions
SELECT * FROM sessions;
查看正连接的会话
SELECT close_session ('sessionid');
关闭指定会话
SELECT close_all_sessions();
关闭所有会话
SELECT set_config_parameter
('MaxClientSessions','0');
禁止新的客户端连接，但允许 5 个 dbadmin 连接

锁类型和冲突
Granted Mode
Requested Mode S I X T U O
S Yes No No Yes Yes No
I No Yes No Yes Yes No
X No No No No Yes No
T Yes Yes No Yes Yes No
U Yes Yes Yes Yes Yes No
O No No No No No No
S I
X
COMPLETE COMPATIBILITY MATRIX
LOCK
CONFLICT
GRAPH
• S — 一致性读共享锁 (紧用于
serializable 事务隔离模式)
• I — 数据插入锁，用于 insert
操作
• X — 排他锁，用于 delete 操作
• T — Tuple Mover锁，用于
Tuple Mover 和 pre-join
projections数据装载
• U — 使用锁，用于查询处理
• O — 物主锁，用于
DROP_PARTITION, TRUNCATE
TABLE, ADD COLUMN 操作

查询性能诊断
执行计划
显示详细的执行步骤
不真正执行
查询 Profiling
显示评估和实际的资源消耗
真正执行

Access Path:
+-JOIN HASH [Cost: 35, Rows: 1]
| Join Cond: (fact.B = dim.b)
| Materialize at Output: fact.A
| Execute on: Query Initiator
| +-- Outer -> STORAGE ACCESS PROJECTION
fact_super [Cost:16, Rows:3]
| | Materialize: fact.B
| | Filter: (fact.B < 3)
| | Execute on: Query Initiator
| +-- Inner -> STORAGE ACCESS PROJECTION
dim_super [Cost:16, Rows:2]
| | Materialize: dim.b
| | Filter: (dim.b < 3)
| | Execute on: Query Initiator
EXPLAIN
SELECT fact.a, fact.b
FROM fact
JOIN dim on fact.B = dim.b
WHERE dim.b < 3;
执行计划范例
Digraph from
GraphViz

管理控制台 – 执行计划 (1 of 2)
• 输入查询语句，点击“Explain Plan”按钮

管理控制台 – 执行计划 (2 of 2)
• 显示详细的执行计划

查询 Profile 范例
PROFILE SELECT order_number,date_ordered
FROM store.store_orders_fact orders
WHERE orders.store_key IN (
SELECT store_key
FROM store.store_dimension
WHERE store_state = 'MA');
NOTICE 4788: Statement is being profiled.
HINT: SELECT *
FROM v_monitor.execution_engine_profiles
WHERE transaction_id = 45035996273738674 AND
statement_id = 15;
NOTICE 3557: Initiator memory for query: [on pool general: 480694 KB,
minimum: 147120 KB]
NOTICE 5077: Total memory required by query: [480694 KB]
order_number | date_ordered
--------------+--------------
292437 | 2012-01-01
. . .

管理控制台 – 查询 Profile (1 of 2)
• 查看查询 Profile 结果

管理控制台 – 查询 Profile (2 of 2)
• 图形化对比展示每一步的时间

Vertica 诊断实用工具: Scrutinize
/opt/vertica/bin/scrutinize
用 dbadmin 用户执行
在当前目录中创建诊断结果文件VerticaScrutinize.<date>.zip
结果包含部分 vertica.log 文件, 配置信息，操作系统信息
• 用 -z X 开关指定包含 X 天的日子文件 [缺省为 -z 1]

Scrutinize 诊断结果内容
Vertica 日志文件
installer, admintools, vertica
Linux管理命令输出
uname, ulimit, sysctl, ifconfig, netstat, etc.
系统表
storage_containers, locks, dc_requests_issued, etc.
数据库设计
Tables, Projections, Views, etc.
不收集
非系统表的数据（业务数据）

什么是Spread?
开源的集群网络通信工具
可靠的信息群发服务
Spread 是随着数据库启动和停止的
Vertica 7.0 之前，Spread是一个单独服务
Spread 是随着数据库启动和停止的

Vertica实时分析平台——助您从大数据中挖掘财富
实时决策，更加明智。
实时赚钱更明智的
决策
分析统计

HP Vertica培训-基础篇

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to HP Vertica培训-基础篇

Similar to HP Vertica培训-基础篇 (20)

Recently uploaded

Recently uploaded (20)

HP Vertica培训-基础篇