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

社交媒体

视频

音频

电子邮件

文本

移动电话

交易数据

设备数据

文档

收索引擎

图片

• 快速收集

• 海量存储

• 深度挖掘

• 实时分析

大数据给传统分析平台带来巨大挑战


大数据分析关键技术

Co

lum

n

MPP

大数据分析系统主流优化技术

列式存储和计算

内存计算

并行计算

核心是并行计算和降低I/O

Co

lum

n

Co

lum

n

有效解决单机“天花板”问题

有效解决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’

1256678 Cappiello, Emilia F Sophomore 62 D 1254038 Dalal, Alana F Senior 92 A 1278858 Orner, Katy F Junior 76 C 1230807 Frigo, Avis M Senior 64 D 1210466 Stober, Saundra F Junior 90 A 1249290 Borba, Milagros F Freshman 96 A 1244262 Sosnowski, Hillary F Junior 68 D 1252490 Nibert, Emilia F Sophomore 59 F 1267170 Popovic, Tanisha F Freshman 95 A 1248100 Schreckengost, Max M Senior 76 C 1243483 Porcelli, Darren M Junior 67 D 1230382 Sinko, Erik M Freshman 91 A 1240224 Tarvin, Julio M Sophomore 85 B 1222781 Lessig, Elnora F Junior 63 D 1231806 Thon, Max M Sophomore 82 B 1246648 Trembley, Allyson F Junior 100 A

谓词中使用的列按照前置列数值进行排序的相关数值

学生_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

1256678 Cappiello, Emilia Sophomore 62 D 1254038 Dalal, Alana Senior 92 A

1278858 Orner, Katy 76 C

1230807 Frigo, Avis 64 D

1210466 Stober, Saundra Junior 90 1249290 Borba, Milagros 96

1244262 Sosnowski, Hillary 68

1252490 Nibert, Emilia 59 F

1267170 Popovic, Tanisha F Freshman 95 A

1248100 Schreckengost, Max Senior 76 C

1243483 Porcelli, Darren Junior 67 D 1230382 Sinko, Erik M Freshman 91 A

1240224 Tarvin, Julio 85

1222781 Lessig, Elnora 63 D

1231806 Thon, Max Sophomore 82 B

1246648 Trembley, Allyson 100

学生_ID 姓名成绩班级性别级别

A F 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 D C A


结构和半结构化融合分析

支持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、复制与数据质量分析、报告

http://images.google.com/imgres?imgurl=http://linux.softpedia.com/screenshots/Talend-Open-Studio_1.png&imgrefurl=http://linux.softpedia.com/progScreenshots/Talend-Open-Studio-Screenshot-19135.html&h=598&w=768&sz=130&hl=en&start=12&sig2=fectlnlgp7ogqTwkTgmOGw&tbnid=x2Jye0DbxrcydM:&tbnh=111&tbnw=142&ei=iO5GSI_rCY2EpASfuOXOBQ&prev=/images?q=talend&gbv=2&hl=en


内置资源管理

器

可配置的资源

池

限定用户/角色

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

Vertica 架构关键


创造性的Projection组织列数据，表变为逻辑层

Vertica的列式存储

按列分开存储，性能提升10x

查询可跳过无关列

按列主动排序和压缩，性能再提升10x

大幅降低I/O开销

节约大量存储空间

不影响数据量模型

立即获得性能大幅提升

Table

Projections

Files

Containers

customer

A B C

customer_p1 customer_p2 customer_p3

A

C

C

C

A

A

B

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和DBD设计


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

SELECT record_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,





sex

blood_pressure

heart_rate

FROM vitals



ALL NODES KSAFE;


age encoding rle,





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 C

A

B

A B C

.fdb fiIes POSITION EPOCH…

2 1092

4 1092

9 1093

Delete Vector STORAGE_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高级设计


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)


00034892 ABC's storm 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 Jim 00034892 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 1 2

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 1 2 B Count( ) = 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

RE

SO

UR

CE

M

AN

AG

ER


资源池(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 v_test_402_node0002 P_bydate2 2 57342374 0 0 1665267 57342374 1664755 0 PROJECTION v_test_402_node0002 P_bydate2 2 57342374 0 0 1665267 57342374 512 0 ALL v_test_402_node0002 P_bydate 2 57381327 0 0 1666509 57381327 1665997 0 PROJECTION v_test_402_node0002 P_bydate 2 57381327 0 0 1666509 57381327 512 0 ALL v_test_402_node0003 P_bydate2 2 57381327 0 0 1666509 57381327 1665997 0 PROJECTION v_test_402_node0003 P_bydate2 2 57381327 0 0 1666509 57381327 512 0 ALL v_test_402_node0003 P_bydate 2 57442590 0 0 1668224 57442590 1667712 0 PROJECTION v_test_402_node0003 P_bydate 2 57442590 0 0 1668224 57442590 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培训-基础篇

Internet