怎样建立销售网站,建设部考试中心网站,烟台app开发公司,wordpress程序出错的原因文章目录 前言2.3.3 管理分区2.3.3.1 增加分区2.3.3.2 删除分区2.3.3.3 恢复分区2.3.3.4 查看分区 2.3.4 设置分桶2.3.4.1 随机分桶#xff08;自 v3.1#xff09;2.3.4.2 哈希分桶2.3.4.2.1 优点2.3.4.2.2 如何选择分桶键2.3.4.2.3 注意事项 2.3.4.3 确定分桶数量 2.3.5 最佳… 文章目录 前言2.3.3 管理分区2.3.3.1 增加分区2.3.3.2 删除分区2.3.3.3 恢复分区2.3.3.4 查看分区 2.3.4 设置分桶2.3.4.1 随机分桶自 v3.12.3.4.2 哈希分桶2.3.4.2.1 优点2.3.4.2.2 如何选择分桶键2.3.4.2.3 注意事项 2.3.4.3 确定分桶数量 2.3.5 最佳实践 2.4 数据压缩2.4.1 选择数据压缩算法2.4.2 设置数据压缩算法 2.5 排序键和前缀索引2.5.1 排序原理2.5.2 排序效果2.5.3 选择排序列 3. 导入导出数据 前言
本文为Flink-StarRocks详解后续章节主要详解StarRocks分区分桶管理数据压缩 由于篇幅过长后续接着下面进行详解 StarRocks查询数据湖 实现即席查询案例
2.3.3 管理分区
2.3.3.1 增加分区
对于 Range 分区和 List 分区可以手动增加新的分区用于存储新的数据而表达式分区可以实现导入新数据时自动创建分区无需手动新增分区。 新增分区的默认分桶数量和原分区相同。也可以根据新分区的数据规模调整分桶数量。 如下示例中在 site_access5 表添加新的分区用于存储新月份的数据
ALTER TABLE test.site_access5
ADD PARTITION p4 VALUES LESS THAN (2020-04-30)
DISTRIBUTED BY HASH(site_id);2.3.3.2 删除分区
执行如下语句删除 site_access5 表中分区 p1 及数据 说明分区中的数据不会立即删除会在 Trash 中保留一段时间默认为一天。如果误删分区可以通过 RECOVER 命令恢复分区及数据。
ALTER TABLE test.site_access5
DROP PARTITION p1;2.3.3.3 恢复分区
执行如下语句恢复 site_access5 表中分区 p1 及数据
RECOVER PARTITION p1 FROM test.site_access5;2.3.3.4 查看分区
执行如下语句查看 site_access5 表中分区情况
SHOW PARTITIONS FROM test.site_access5;2.3.4 设置分桶
2.3.4.1 随机分桶自 v3.1
对每个分区的数据StarRocks 将数据随机地分布在所有分桶中适用于数据量不大对查询性能要求不高的场景。如果不设置分桶方式则默认由 StarRocks 使用随机分桶并且自动设置分桶数量。 不过值得注意的是如果查询海量数据且查询时经常使用一些列会作为条件列随机分桶提供的查询性能可能不够理想。在该场景下建议使用哈希分桶当查询时经常使用这些列作为条件列时只需要扫描和计算查询命中的少量分桶则可以显著提高查询性能。 使用限制 仅支持明细模型表。 不支持指定 Colocation Group。 不支持 Spark Load。 如下建表示例中没有使用 DISTRIBUTED BY xxx 语句即表示默认由 StarRocks 使用随机分桶并且由 StarRocks 自动设置分桶数量。
CREATE TABLE test.site_access9(event_day DATE,site_id INT DEFAULT 10, pv BIGINT DEFAULT 0 ,city_code VARCHAR(100),user_name VARCHAR(32) DEFAULT
)
DUPLICATE KEY(event_day,site_id,pv)
PROPERTIES (replication_num 1
);当然如果比较熟悉 StarRocks 的分桶机制使用随机分桶建表时也可以手动设置分桶数量。
CREATE TABLE test.site_access10(event_day DATE,site_id INT DEFAULT 10, pv BIGINT DEFAULT 0 ,city_code VARCHAR(100),user_name VARCHAR(32) DEFAULT
)
DUPLICATE KEY(event_day,site_id,pv)
DISTRIBUTED BY RANDOM BUCKETS 8 -- 手动设置分桶数量为 8PROPERTIES (replication_num 1
);2.3.4.2 哈希分桶
对每个分区的数据StarRocks 会根据分桶键和分桶数量进行哈希分桶。在哈希分桶中使用特定的列值作为输入通过哈希函数计算出一个哈希值然后将数据根据该哈希值分配到相应的桶中。
2.3.4.2.1 优点
提高查询性能。相同分桶键值的行会被分配到一个分桶中在查询时能减少扫描数据量。 均匀分布数据。通过选取较高基数唯一值的数量较多的列作为分桶键能更均匀的分布数据到每一个分桶中。
2.3.4.2.2 如何选择分桶键
假设存在列同时满足高基数和经常作为查询条件则建议选择其为分桶键进行哈希分桶。 如果不存在这些同时满足两个条件的列则需要根据查询进行判断。 如果查询比较复杂则建议选择高基数的列为分桶键保证数据在各个分桶中尽量均衡提高集群资源利用率。 如果查询比较简单则建议选择经常作为查询条件的列为分桶键提高查询效率。 并且如果数据倾斜情况严重还可以使用多个列作为数据的分桶键但是建议不超过 3 个列。
2.3.4.2.3 注意事项
建表时如果使用哈希分桶则必须指定分桶键。 组成分桶键的列仅支持整型、DECIMAL、DATE/DATETIME、CHAR/VARCHAR/STRING 数据类型。 分桶键指定后不支持修改。 如下示例中site_access 表采用 site_id 作为分桶键其原因在于 site_id 为高基数列。此外针对 site_access 表的查询请求基本上都以站点作为查询过滤条件采用 site_id 作为分桶键还可以在查询时裁剪掉大量无关分桶。
CREATE TABLE test.site_access11(event_day DATE,site_id INT DEFAULT 10,city_code VARCHAR(100),user_name VARCHAR(32) DEFAULT ,pv BIGINT SUM DEFAULT 0
)
AGGREGATE KEY(event_day, site_id, city_code, user_name)
PARTITION BY RANGE(event_day) (PARTITION p1 VALUES LESS THAN (2020-01-31),PARTITION p2 VALUES LESS THAN (2020-02-29),PARTITION p3 VALUES LESS THAN (2020-03-31)
)
DISTRIBUTED BY HASH(site_id)PROPERTIES (replication_num 1
);如下查询中假设每个分区有 10 个分桶则其中 9 个分桶被裁减因而系统只需要扫描 site_access 表中 1/10 的数据
select sum(pv)
from test.site_access11
where site_id 54321;但是如果 site_id 分布十分不均匀大量的访问数据是关于少数网站的幂律分布二八规则那么采用上述分桶方式会造成数据分布出现严重的倾斜进而导致系统局部的性能瓶颈。此时需要适当调整分桶的字段以将数据打散避免性能问题。例如可以采用 site_id、city_code 组合作为分桶键将数据划分得更加均匀。相关建表语句如下
CREATE TABLE test.site_access12
(site_id INT DEFAULT 10,city_code SMALLINT,user_name VARCHAR(32) DEFAULT ,pv BIGINT SUM DEFAULT 0
)
AGGREGATE KEY(site_id, city_code, user_name)
DISTRIBUTED BY HASH(site_id,city_code)
PROPERTIES (replication_num 1
);在实际使用中可以依据自身的业务特点选择以上两种分桶方式。采用 site_id 的分桶方式对于短查询十分有利能够减少节点之间的数据交换提高集群整体性能采用 site_id、city_code 的组合分桶方式对于长查询有利能够利用分布式集群的整体并发性能。 说明 短查询是指扫描数据量不大、单机就能完成扫描的查询。 长查询是指扫描数据量大、多机并行扫描能显著提升性能的查询。
2.3.4.3 确定分桶数量
在 StarRocks 中分桶是实际物理文件组织的单元。 建表时如何设置分桶数量 方式一自动设置分桶数量 自 2.5.7 版本起 StarRocks 支持根据机器资源和数据量自动设置分区的分桶数量。
建表示例
CREATE TABLE test.site_access13(site_id INT DEFAULT 10,city_code SMALLINT,user_name VARCHAR(32) DEFAULT ,pv BIGINT SUM DEFAULT 0
)
AGGREGATE KEY(site_id, city_code, user_name)
DISTRIBUTED BY HASH(site_id,city_code)
-- 无需手动设置分桶数量
PROPERTIES (replication_num 1
);如果需要开启该功能则需要确保 FE 动态参数 enable_auto_tablet_distribution 为 true。 建表后可以执行 SHOW PARTITIONS 来查看 StarRock 为分区自动设置的分桶数量。
SHOW PARTITIONS FROM test.site_access13; 方式二手动设置分桶数量 自 2.4 版本起StarRocks 提供了自适应的 Tablet 并行扫描能力即一个查询中涉及到的任意一个 Tablet 可能是由多个线程并行地分段扫描减少了 Tablet 数量对查询能力的限制从而可以简化对分桶数量的设置。简化后确定分桶数量方式可以是首先预估每个分区的数据量然后按照每 10 GB 原始数据一个 Tablet 计算从而确定分桶数量。 如果需要开启并行扫描 Tablet则需要确保系统变量 enable_tablet_internal_parallel 全局生效 SET GLOBAL enable_tablet_internal_parallel true;。
CREATE TABLE test.site_access14(site_id INT DEFAULT 10,city_code SMALLINT,user_name VARCHAR(32) DEFAULT ,pv BIGINT SUM DEFAULT 0)
AGGREGATE KEY(site_id, city_code, user_name)
DISTRIBUTED BY HASH(site_id,city_code) BUCKETS 30
-- 假设导入一个分区的原始数据量为 300 GB则按照每 10 GB 原始数据一个 Tablet则分桶数量可以设置为 30。
PROPERTIES (replication_num 1
); 新增分区时如何设置分桶数量 方式一自动设置分桶数量推荐 自 2.5.7 版本起 StarRocks 支持根据机器资源和数据量自动设置分区的分桶数量。 如果需要启用该功能则需要确保 FE 动态参数 enable_auto_tablet_distribution 保持默认值 true。如果需要关闭该功能则可以执行ADMIN SET FRONTEND CONFIG (“enable_auto_tablet_distribution” “false”);并且新增分区的时候未指定分桶数量则新增分区的分桶数量会继承建表时的分桶数量。 新增分区后可以执行 SHOW PARTITIONS 来查看 StarRocks 为新增分区自动设置的分桶数量。 方式二手动设置分桶数量 新增分区的时候也可以手动指定分桶数量。新增分区的分桶数量的计算方式可以参考如上建表时手动设置分桶数量。
-- 手动创建分区
ALTER TABLE table_name
ADD PARTITION partition_name[DISTRIBUTED BY HASH (k1[,k2 ...]) [BUCKETS num]];-- 手动设置动态分区的默认分桶数量
ALTER TABLE table_name
SET (dynamic_partition.bucketsxxx);注意 不支持修改已创建分区的分桶数量。
2.3.5 最佳实践
对于 StarRocks 而言分区和分桶的选择是非常关键的。在建表时选择合理的分区键和分桶键可以有效提高集群整体性能。因此建议在选择分区键和分桶键时根据业务情况进行调整。 数据倾斜 如果业务场景中单独采用倾斜度大的列做分桶很大程度会导致访问数据倾斜那么建议采用多列组合的方式进行数据分桶。 高并发 分区和分桶应该尽量覆盖查询语句所带的条件这样可以有效减少扫描数据提高并发。 高吞吐 尽量把数据打散让集群以更高的并发扫描数据完成相应计算。 元数据管理 控制Tablet数量因为Tablet 过多会增加 FE/BE 的元数据管理和调度的资源消耗。
2.4 数据压缩
StarRocks 支持对表和索引数据进行压缩 (compression)。数据压缩不仅有助于节省存储空间还可以提高 I/O 密集型任务的性能。 注意压缩和解压缩数据需要额外的 CPU 资源。
2.4.1 选择数据压缩算法
StarRocks 支持四种数据压缩算法LZ4、Zstandard或 zstd、zlib 和 Snappy。 这些数据压缩算法在压缩率和压缩/解压缩性能上有所不同。 通常来说这些算法的压缩率排名如下zlib Zstandard LZ4 Snappy。其中zlib 拥有较高的压缩比。但由于数据高度压缩使用 zlib 算法的表其导入和查询性能会受到一定程度的影响。而 LZ4 和 Zstandard 算法具有较为均衡的压缩比和解压缩性能。可以根据自身业务场景在这些压缩算法中进行选择以满足对存储或性能的需求。如果对存储空间占用没有特殊需求建议使用 LZ4 或 Zstandard 算法。 说明 不同的数据类型也会影响算法的压缩率。
2.4.2 设置数据压缩算法
只能在创建表时为其设置数据压缩算法且后续无法修改。 以下示例基于 Zstandard 算法创建表 data_compression。
CREATE TABLE test.data_compression(id INT(11) NOT NULL COMMENT ,name CHAR(200) NULL COMMENT
)
UNIQUE KEY(id)
DISTRIBUTED BY HASH(id)
PROPERTIES (
compression ZSTD,replication_num 1
);说明 如不指定数据压缩算法StarRocks 默认使用 LZ4。 可以通过 SHOW CREATE TABLE 命令查看指定表采用的压缩算法。
2.5 排序键和前缀索引
在建表时可以指定一个或多个列构成排序键 (Sort Key)。表中的行会根据排序键进行排序以后再落入磁盘存储。查询数据时可以使用排序列指定过滤条件StarRocks 不需要扫描全表即可快速找到需要处理的数据降低搜索的复杂度从而加速查询。 同时为减少内存开销StarRocks 在排序键的基础上又引入了前缀索引 (Prefix Index)。前缀索引是一种稀疏索引。表中每 1024 行数据构成一个逻辑数据块 (Data Block)。每个逻辑数据块在前缀索引表中存储一个索引项索引项的长度不超过 36 字节其内容为数据块中第一行数据的排序列组成的前缀在查找前缀索引表时可以帮助确定该行数据所在逻辑数据块的起始行号。前缀索引的大小会比数据量少 1024 倍因此会全量缓存在内存中在实际查找的过程中可以有效加速查询。
2.5.1 排序原理
在明细模型中排序列就是通过 DUPLICATE KEY 关键字指定的列。 在聚合模型中排序列就是通过 AGGREGATE KEY 关键字指定的列。 在更新模型中排序列就是通过 UNIQUE KEY 关键字指定的列。 自 3.0 版本起主键模型解耦了主键列和排序列排序列通过 ORDER BY 关键字指定主键列通过 PRIMARY KEY 关键字指定。 主键模型建表示例
CREATE TABLE test.site_access_primary
(site_id INT DEFAULT 10,city_code SMALLINT,user_id INT,pv BIGINT DEFAULT 0
)
PRIMARY KEY(site_id)
DISTRIBUTED BY HASH(site_id)
ORDER BY(site_id,city_code)
PROPERTIES (replication_num 1
);在明细模型、聚合模型、更新模型中定义排序列时需要注意以下几点 排序列必须从定义的第一列开始、并且是连续的。 在定义各列时计划作为排序列的列必须定义在其他普通列之前。 排序列的顺序必须与表定义的列顺序一致。 例如建表语句中声明要创建 site_id、city_code、user_id 和 pv 四列。这种情况下正确的排序列组合和错误的排序列组合举例如下 正确的排序列 site_id 和 city_code site_id、city_code 和 user_id 错误的排序列 city_code 和 site_id city_code 和 user_id site_id、city_code 和 pv 下面通过示例来说明如何创建使用各个数据模型的表。
2.5.2 排序效果
以上述建表语句为例排序效果可以分为三种情况 如果查询条件只包含 site_id 和 city_code 两列如下所示则可以大幅减少查询过程中需要扫描的数据行
select sum(pv) from test.site_access_duplicate where site_id 123 and city_code 2; 如果查询条件只包含 site_id 一列如下所示可以定位到只包含 site_id 的数据行
select sum(pv) from test.site_access_duplicate where site_id 123; 如果查询条件只包含 city_code 一列如下所示则需要扫描所有数据行排序效果大打折扣
select sum(pv) from test.site_access_duplicate where city_code 2;说明 这种情况下排序列无法实现应有的排序效果。 在第一种情况下为了定位到数据行的位置需进行二分查找以找到指定区间。如果数据行非常多直接对 site_id 和 city_code 两列进行二分查找需要把两列数据都加载到内存中这样会消耗大量的内存空间。这时候可以使用前缀索引来减少缓存的数据量、并有效加速查询。 另外在实际业务场景中如果指定的排序列非常多也会占用大量内存。为了避免这种情况StarRocks 对前缀索引做了如下限制: 前缀索引项的内容只能由数据块中第一行的排序列的前缀组成。 前缀索引列的数量不能超过 3。 前缀索引项的长度不能超过 36 字节。 前缀索引中不能包含 FLOAT 或 DOUBLE 类型的列。 前缀索引中 VARCHAR 类型的列只能出现一次并且处在末尾位置。 当前缀索引的末尾列是 CHAR 或 VARCHAR 类型时前缀索引项的长度不会超过 36 字节。
2.5.3 选择排序列
这里以 site_access_duplicate 表为例介绍如何选择排序列。 经常作为查询条件的列建议选为排序列。 当排序键涉及多个列的时候建议把区分度高、且经常查询的列放在前面。区分度高的列是指取值个数较多、且持续增加的列。例如在上述 site_access_duplicate 表中因为城市的数目是固定的所以 city_code 列中取值的个数是固定的而 site_id 列中取值的个数要比 city_code 列中取值的个数大得多、并且还会不断地增加所以 site_id 列的区分度就比 city_code 列要高不少。 排序键不应该包含过多的列。选择很多排序列并不有助于提升查询性能而且会增大排序的开销进而增加数据导入的开销。 综上所述在为 site_access_duplicate 表选择排序列时需要注意以下三点 如果需要经常按 site_id 列加 city_code 列的组合进行查询建议选择 site_id 列作为排序键的第一列。 如果需要经常按 city_code 列进行查询、偶尔按 site_id 列加 city_code 列的组合进行查询建议选择 city_code 列作为排序键的第一列。 极端情况下如果按 site_id 列加 city_code 列组合查询所占的比例与按 city_code 列单独查询所占的比例不相上下可以创建一个以 city_code 列为第一列的 Rollup 表。Rollup 表会为 city_code 列再建一个排序索引 (Sort Index)。
3. 导入导出数据
数据导入是指将原始数据按照业务需求进行清洗、转换、并加载到 StarRocks 中的过程从而可以在 StarRocks 系统中进行极速统一的数据分析。 具体详见
https://docs.starrocks.io/zh/docs/loading/Loading_intro/另外StarRocks也支持导出数据可以通过 EXPORT 语句把 StarRocks 集群中指定表或分区上的数据以 CSV 的格式导出到外部存储系统。
具体详见https://docs.starrocks.io/zh/docs/unloading/Export/
