二.海量数据实时分析-Doris数据表设计

2024-09-03 11:44
文章标签 分析 数据 设计 doris 实时 海量 数据表

本文主要是介绍二.海量数据实时分析-Doris数据表设计，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言

Apache Doris 支持标准 SQL 语法，采用 MySQL 网络连接协议，高度兼容 MySQL 相关生态。因此，在数据类型支持方面，尽可能对齐 MySQL 相关数据类型。

数据表设计

1.数据类型

Apache Doris 支持的数据类型比较丰富，完整的类型可以通过官网(https://doris.incubator.apache.org/zh-CN/docs/table-design/data-type)去了解，我这里只贴了一部分常用的

类型名存储空间（字节）描述
BOOLEAN1布尔值，0 代表 false，1 代表 true。
TINYINT1有符号整数，范围 [-128, 127]。
SMALLINT2有符号整数，范围 [-32768, 32767]。
INT4有符号整数，范围 [-2147483648, 2147483647]
BIGINT8有符号整数，范围 [-9223372036854775808, 9223372036854775807]。
LARGEINT16有符号整数，范围 [-2^127 + 1 ~ 2^127 - 1]。
FLOAT4浮点数，范围 [-3.410^38 ~ 3.410^38]。
DOUBLE8浮点数，范围 [-1.7910^308 ~ 1.7910^308]。
DECIMAL4/8/16高精度定点数，格式：DECIMAL(M[,D])。其中，M 代表一共有多少个有效数字（precision），D 代表小数位有多少数字（scale）。有效数字 M 的范围是 [1, 38]，小数位数字数量 D 的范围是 [0, precision]。0 < precision <= 9 的场合，占用 4 字节。9 < precision <= 18 的场合，占用 8 字节。16 < precision <= 38 的场合，占用 16 字节
DATE16日期类型，目前的取值范围是 [‘0000-01-01’, ‘9999-12-31’]，默认的打印形式是 ‘yyyy-MM-dd’。
DATETIME16日期时间类型，格式：DATETIME([P])。可选参数 P 表示时间精度，取值范围是 [0, 6]，即最多支持 6 位小数（微秒）。不设置时为 0。取值范围是 [‘0000-01-01 00:00:00[.000000]’, ‘9999-12-31 23:59:59[.999999]’]。打印的形式是 ‘yyyy-MM-dd HH:mm:ss.SSSSSS’。
CHARM定长字符串，M 代表的是定长字符串的字节长度。M 的范围是 1-255。
VARCHAR不定长变长字符串，M 代表的是变长字符串的字节长度。M 的范围是 1-65533。变长字符串是以 UTF-8 编码存储的，因此通常英文字符占 1 个字节，中文字符占 3 个字节。
STRING不定长变长字符串，默认支持 1048576 字节（1MB），可调大到 2147483643 字节（2GB）。可通过 BE 配置 string_type_length_soft_limit_bytes 调整。String 类型只能用在 Value 列，不能用在 Key 列和分区分桶列。
HLL不定长HLL 是模糊去重，在数据量大的情况性能优于 Count Distinct。HLL 的误差通常在 1% 左右，有时会达到 2%。HLL 不能作为 Key 列使用，建表时配合聚合类型为 HLL_UNION。用户不需要指定长度和默认值。长度根据数据的聚合程度系统内控制。HLL 列只能通过配套的 hll_union_agg、hll_raw_agg、hll_cardinality、hll_hash 进行查询或使用。
BITMAP不定长Bitmap 类型的列可以在 Aggregate 表、Unique 表或 Duplicate 表中使用。在 Unique 表或 Duplicate 表中使用时，其必须作为非 Key 列使用。在 Aggregate 表中使用时，其必须作为非 Key 列使用，且建表时配合的聚合类型为 BITMAP_UNION。用户不需要指定长度和默认值。长度根据数据的聚合程度系统内控制。BITMAP 列只能通过配套的 bitmap_union_count、bitmap_union、bitmap_hash、bitmap_hash64 等函数进行查询或使用。

2.数据模型

在 Doris 中，数据以表（Table）的形式进行逻辑上的描述。一张表包括行（Row）和列（Column）。Row 即用户的一行数据，Column 用于描述一行数据中不同的字段。

Column 可以分为两大类：Key 和 Value。从业务角度看，Key 和 Value 可以分别对应维度列和指标列。Doris 的 Key 列是建表语句中指定的列，建表语句中的关键字 unique key 或 aggregate key 或 duplicate key 后面的列就是 Key 列，除了 Key 列剩下的就是 Value 列。

Doris 的数据模型主要分为 3 类：

  • 明细模型（Duplicate Key Model）：允许指定的 Key 列重复；适用于必须保留所有原始数据记录的情况。

  • 主键模型（Unique Key Model）：每一行的 Key 值唯一；可确保给定的 Key 列不会存在重复行。

  • 聚合模型（Aggregate Key Model）：可根据 Key 列聚合数据；通常用于需要汇总或聚合信息（如总数或平均值）的情况

明细模型

明细模型，也称为 Duplicate 数据模型。在明细数据模型中，数据按照导入文件中的数据进行存储，不会有任何聚合。即使两行数据完全相同，也都会保留。而在建表语句中指定的 Duplicate Key，只是用来指明数据存储按照哪些列进行排序。在 Duplicate Key 的选择上，建议选择前 2-4 列即可。案例：

create database db;
CREATE TABLE IF NOT EXISTS db.example_tbl_by_default
(`timestamp` DATETIME NOT NULL COMMENT "日志时间",`type` INT NOT NULL COMMENT "日志类型",`error_code` INT COMMENT "错误码",`error_msg` VARCHAR(1024) COMMENT "错误详细信息",`op_id` BIGINT COMMENT "负责人id",`op_time` DATETIME COMMENT "处理时间"
)
DUPLICATE KEY("timestamp","type") -- 默认就是明细模型，会安装这2列进行排序
DISTRIBUTED BY HASH(`type`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);-- 查看表结构
> desc db.example_tbl_by_default;

简单理解就是：我往Doris中插入了10条数据，那么Doris中就会有10条数据，明细模型并不会对数据做聚合处理。会保留原生的数据

主键模型

当用户有数据更新需求时，可以选择使用主键数据模型（Unique）。主键模型能够保证 Key（主键）的唯一性，当用户更新一条数据时，新写入的数据会覆盖具有相同 key（主键）的旧数据。

主键模型提供了两种实现方式：

  • 读时合并 (merge-on-read)。在读时合并实现中，用户在进行数据写入时不会触发任何数据去重相关的操作，所有数据去重的操作都在查询或者 compaction 时进行。因此，读时合并的写入性能较好，查询性能较差，同时内存消耗也较高。
  • 写时合并 (merge-on-write)。在 1.2 版本中，我们引入了写时合并实现，该实现会在数据写入阶段完成所有数据去重的工作，因此能够提供非常好的查询性能。自 2.0 版本起，写时合并已经非常成熟稳定，由于其优秀的查询性能，我们推荐大部分用户选择该实现。自 2.1 版本，写时合并成为 Unique 模型的默认实现。

读时合并的建表语句如下：

CREATE TABLE IF NOT EXISTS db.example_tbl_unique
(`user_id` LARGEINT NOT NULL COMMENT "用户id",`username` VARCHAR(50) NOT NULL COMMENT "用户昵称",`city` VARCHAR(20) COMMENT "用户所在城市",`age` SMALLINT COMMENT "用户年龄",`sex` TINYINT COMMENT "用户性别",`phone` LARGEINT COMMENT "用户电话",`address` VARCHAR(500) COMMENT "用户地址",`register_time` DATETIME COMMENT "用户注册时间"
)
UNIQUE KEY(`user_id`, `username`)	--可以理解为：按照这2列创建唯一索引，默认读时合并
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

写时合并建表语句为：

CREATE TABLE IF NOT EXISTS db.example_tbl_unique_merge_on_write
(`user_id` LARGEINT NOT NULL COMMENT "用户id",`username` VARCHAR(50) NOT NULL COMMENT "用户昵称",`city` VARCHAR(20) COMMENT "用户所在城市",`age` SMALLINT COMMENT "用户年龄",`sex` TINYINT COMMENT "用户性别",`phone` LARGEINT COMMENT "用户电话",`address` VARCHAR(500) COMMENT "用户地址",`register_time` DATETIME COMMENT "用户注册时间"
)
UNIQUE KEY(`user_id`, `username`) --可以理解为：按照这2列创建唯一索引，默认读时合并
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"enable_unique_key_merge_on_write" = "true"	--指定为写时合并
);

用户需要在建表时添加下面的 property 来开启写时合并 : “enable_unique_key_merge_on_write” = “true”

聚合模型

聚合数据模型，也称为 Aggregate 数据模型,其实聚合模型就是在写入数据的时候按照某些字段对数据进行统计，比如：最大值max ,最小值 min等。AggregationType 目前有以下几种聚合方式和 agg_state：

  • SUM：求和，多行的 Value 进行累加。
  • REPLACE：替代，下一批数据中的 Value 会替换之前导入过的行中的 Value。
  • MAX：保留最大值。
  • MIN：保留最小值。
  • REPLACE_IF_NOT_NULL：非空值替换。和 REPLACE 的区别在于对于 null 值，不做替换
  • HLL_UNION：HLL 类型的列的聚合方式，通过 HyperLogLog 算法聚合。
  • BITMAP_UNION：BIMTAP 类型的列的聚合方式，进行位图的并集聚合。
CREATE TABLE IF NOT EXISTS db.example_tbl_agg1
(`user_id` LARGEINT NOT NULL COMMENT "用户id",`date` DATE NOT NULL COMMENT "数据灌入日期时间",`city` VARCHAR(20) COMMENT "用户所在城市",`age` SMALLINT COMMENT "用户年龄",`sex` TINYINT COMMENT "用户性别",-- 下面这几个字段是聚合字段`last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "用户最后一次访问时间",`cost` BIGINT SUM DEFAULT "0" COMMENT "用户总消费",`max_dwell_time` INT MAX DEFAULT "0" COMMENT "用户最大停留时间",`min_dwell_time` INT MIN DEFAULT "99999" COMMENT "用户最小停留时间"
)
AGGREGATE KEY(`user_id`, `date`, `city`, `age`, `sex`)	-- 指定聚合的key列（维度列）
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

表中的列按照是否设置了 AggregationType，分为 Key (维度列) 和 Value（指标列）。没有设置 AggregationType 的 user_id、date、age、sex 称为 Key，而设置了 AggregationType 的称为 Value。当导入数据时，对于 Key 列相同的行会聚合成一行，而 Value 列会按照设置的 AggregationType 进行聚合。

比如导入下面的数据

insert into db.example_tbl_agg1 values
(10000,"2017-10-01","北京",20,0,"2017-10-01 06:00:00",20,10,10),
(10000,"2017-10-01","北京",20,0,"2017-10-01 07:00:00",15,2,2),
(10001,"2017-10-01","北京",30,1,"2017-10-01 17:05:45",2,22,22),
(10002,"2017-10-02","上海",20,1,"2017-10-02 12:59:12",200,5,5),
(10003,"2017-10-02","广州",32,0,"2017-10-02 11:20:00",30,11,11),
(10004,"2017-10-01","深圳",35,0,"2017-10-01 10:00:15",100,3,3),
(10004,"2017-10-03","深圳",35,0,"2017-10-03 10:20:22",11,6,6);

那么当这批数据正确导入到 Doris 中后，Doris 中最终存储如下：

user_iddatecityagesexlast_visit_datecostmax_dwell_timemin_dwell_time
100002017/10/1北京2002017/10/1 7:0035102
100012017/10/1北京3012017/10/1 17:0522222
100022017/10/2上海2012017/10/2 12:5920055
100032017/10/2广州3202017/10/2 11:20301111
100042017/10/1深圳3502017/10/1 10:0010033
100042017/10/3深圳3502017/10/3 10:201166

可以看到，用户 10000 只剩下了一行聚合后的数据。而其余用户的数据和原始数据保持一致。对于用户 10000 聚合后的数据，前 5 列没有变化：

第 6 列值为 2017-10-01 07:00:00。因为 last_visit_date 列的聚合方式为 REPLACE，所以 2017-10-01 07:00:00 替换了 2017-10-01 06:00:00 保存了下来。注意：在同一个导入批次中的数据，对于 REPLACE 这种聚合方式，替换顺序不做保证，如在这个例子中，最终保存下来的，也有可能是 2017-10-01 06:00:00；而对于不同导入批次中的数据，可以保证，后一批次的数据会替换前一批次。

第 7 列值为 35：因为 cost 列的聚合类型为 SUM，所以由 20 + 15 累加获得 35。

第 8 列值为 10：因为 max_dwell_time 列的聚合类型为 MAX，所以 10 和 2 取最大值，获得 10。

第 9 列值为 2：因为 min_dwell_time 列的聚合类型为 MIN，所以 10 和 2 取最小值，获得 2。

经过聚合，Doris 中最终只会存储聚合后的数据。换句话说，即明细数据会丢失，用户不能够再查询到聚合前的明细数据了，有了聚合模型就不需要我们自己去统计或者分组了。

小结

Aggregate 模型可以通过预聚合，极大地降低聚合查询时所需扫描的数据量和查询的计算量，非常适合有固定模式的报表类查询场景。但是该模型对 count(*) 查询很不友好

Unique 模型针对需要唯一主键约束的场景，可以保证主键唯一性约束。但是无法利用 ROLLUP 等预聚合带来的查询优势。对于聚合查询有较高性能需求的用户，推荐使用自 1.2 版本加入的写时合并实现

Duplicate 适合任意维度的 Ad-hoc 查询。虽然同样无法利用预聚合的特性，但是不受聚合模型的约束，可以发挥列存模型的优势（只读取相关列，而不需要读取所有 Key 列）。

3.分区和分桶（Partition & Tablet）

Doris 支持两层的数据划分。第一层是分区（Partition），第二层是 桶 Bucket（或Tablet），在 Doris 的存储引擎中，用户数据被水平划分为若干个数据分片（Tablet，也称作数据分桶）。分区的方式有， List分区，Range分区， Null分区 。每个 Tablet 包含若干数据行。各个 Tablet 之间的数据没有交集，并且在物理上是独立存储的，下面举个例子
在这里插入图片描述
采用两层数据划分的好处：

  • 有时间维度或类似带有有序值的维度，可以以这类维度列作为分区列。分区粒度可以根据导入频次、分区数据量等进行评估。

  • 历史数据删除需求：如有删除历史数据的需求（比如仅保留最近 N 天的数据）。使用复合分区，可以通过删除历史分区来达到目的。也可以通过在指定分区内发送 DELETE 语句进行数据删除。

  • 解决数据倾斜问题：每个分区可以单独指定分桶数量。如按天分区，当每天的数据量差异很大时，可以通过指定分区的分桶数，合理划分不同分区的数据，分桶列建议选择区分度大的列。

如果做过Mysql的分库分表的童鞋就能理解这个和分库分表很像，那既然要分区和分桶，如何分呢？就需要分区算法和分桶算法.

建表举例

Doris 的建表是一个同步命令，SQL 执行完成即返回结果，命令返回成功即表示建表成功。具体建表语法可以参考CREATE TABLE，也可以通过 HELP CREATE TABLE 查看更多帮助。这里给出了一个采用了 Range 分区 和 Hash 分桶的建表举例。

-- Range Partition
CREATE TABLE IF NOT EXISTS example_range_tbl
(`user_id` LARGEINT NOT NULL COMMENT "用户id",`date` DATE NOT NULL COMMENT "数据灌入日期时间",`timestamp` DATETIME NOT NULL COMMENT "数据灌入的时间戳",`city` VARCHAR(20) COMMENT "用户所在城市",`age` SMALLINT COMMENT "用户年龄",`sex` TINYINT COMMENT "用户性别",-- 下面这些是聚合字段`last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "用户最后一次访问时间",`cost` BIGINT SUM DEFAULT "0" COMMENT "用户总消费",`max_dwell_time` INT MAX DEFAULT "0" COMMENT "用户最大停留时间",`min_dwell_time` INT MIN DEFAULT "99999" COMMENT "用户最小停留时间"
)
ENGINE=OLAP
AGGREGATE KEY(`user_id`, `date`, `timestamp`, `city`, `age`, `sex`) --数据表类型，key相同进行聚合
PARTITION BY RANGE(`date`) --使用range范围分区，根据date进行分区，规则如下
(PARTITION `p201701` VALUES LESS THAN ("2017-02-01"), --小于该时间2017-02-01的放入该分区p201701PARTITION `p201702` VALUES LESS THAN ("2017-03-01"),PARTITION `p201703` VALUES LESS THAN ("2017-04-01"),PARTITION `p2018` VALUES [("2018-01-01"), ("2019-01-01"))
)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 16	--根据用户ID的Hash值进行分桶，16个桶
PROPERTIES
("replication_num" = "1" -- 指定副本数量，因为只有一个BE所以只能有1个副本
);

  • PARTITION BY RANGE(date) ：这里采用了时间范围分区RANGE(date) ，不同时间范围的数据会分到不同的区，

  • DISTRIBUTED BY HASH(user_id) BUCKETS 16 ：使用用户IDHash分桶HASH(user_id)，不同的user_id的Hash值的数据会分到不同的桶，每个分区指定了16个桶

  • AGGREGATE KEY : 这里采用了聚合模型，除了 (user_id, date, timestamp, city, age, sex) 这些列之外的其他列会进行聚合。

  • replication_num : 副本数。默认副本数为 3。如果 BE 节点数量小于 3，则需指定副本数小于等于 BE 节点数量。

  • ENGINE 的类型是 OLAP，即默认的 ENGINE 类型。在 Doris 中，只有这个 ENGINE 类型是由 Doris 负责数据管理和存储的。其他 ENGINE 类型，如 MySQL、 Broker、ES 等等，本质上只是对外部其他数据库或系统中的表的映射，以保证 Doris 可以读取这些数据。而 Doris 本身并不创建、管理和存储任何非 OLAP ENGINE 类型的表和数据。

查看分区信息
可以通过 show create table 来查看表的分区信息。

show create table  example_range_tbl

可以通过 show partitions from your_table 来查看表的分区信息。

修改分区信息

通过 alter table add partition 来增加新的分区

ALTER TABLE example_range_tbl ADD PARTITION p201704 VALUES LESS THAN(“2020-05-01”) DISTRIBUTED BY HASH(user_id) BUCKETS 5;

Range 分区

分区列通常为时间列，以方便的管理新旧数据。Range 分区支持的列类型 DATE, DATETIME, TINYINT, SMALLINT, INT, BIGINT, LARGEINT。

  1. FIXED RANGE：定义分区的左闭右开区间。
PARTITION BY RANGE(`date`)
(-- 大于左边，小于右边日期内的数据，放到p201701分区PARTITION `p201701` VALUES [("2017-01-01"),  ("2017-02-01")),PARTITION `p201702` VALUES [("2017-02-01"), ("2017-03-01")),PARTITION `p201703` VALUES [("2017-03-01"), ("2017-04-01"))
)
  1. LESS THAN：仅定义分区上界。下界由上一个分区的上界决定。
PARTITION BY RANGE(`date`)
(-- 小于该时间的数据放入p201701分区PARTITION `p201701` VALUES LESS THAN ("2017-02-01"),PARTITION `p201702` VALUES LESS THAN ("2017-03-01"),PARTITION `p201703` VALUES LESS THAN ("2017-04-01"),PARTITION `p2018` VALUES [("2018-01-01"), ("2019-01-01")),PARTITION `other` VALUES LESS THAN (MAXVALUE)
)
  1. BATCH RANGE：批量创建数字类型和时间类型的 RANGE 分区，定义分区的左闭右开区间，设定步长。
PARTITION BY RANGE(age)
(-- 年龄分区，1-100之间的步长是10FROM (1) TO (100) INTERVAL 10
)PARTITION BY RANGE(`date`)
(FROM ("2000-11-14") TO ("2021-11-14") INTERVAL 2 YEAR
)
  1. MULTI RANGE：批量创建 RANGE 分区，定义分区的左闭右开区间。示例如下：
PARTITION BY RANGE(col)                                                                                                                                                                                                                
(                                                                                                                                                                                                                                      FROM ("2000-11-14") TO ("2021-11-14") INTERVAL 1 YEAR,                                                                                                                                                                              FROM ("2021-11-14") TO ("2022-11-14") INTERVAL 1 MONTH,                                                                                                                                                                             FROM ("2022-11-14") TO ("2023-01-03") INTERVAL 1 WEEK,                                                                                                                                                                              FROM ("2023-01-03") TO ("2023-01-14") INTERVAL 1 DAY,PARTITION p_20230114 VALUES [('2023-01-14'), ('2023-01-15'))                                                                                                                                                                                
)
List 分区

分区列支持 BOOLEAN, TINYINT, SMALLINT, INT, BIGINT, LARGEINT, DATE, DATETIME, CHAR, VARCHAR 数据类型，分区值为枚举值。只有当数据为目标分区枚举值其中之一时，才可以命中分区。Partition 支持通过 VALUES IN (…) 来指定每个分区包含的枚举值。

PARTITION BY LIST(city)
(PARTITION `p_cn` VALUES IN ("Beijing", "Shanghai", "Hong Kong"),PARTITION `p_usa` VALUES IN ("New York", "San Francisco"),PARTITION `p_jp` VALUES IN ("Tokyo")
)

List 分区也支持多列分区，示例如下：

PARTITION BY LIST(id, city)
(PARTITION p1_city VALUES IN (("1", "Beijing"), ("1", "Shanghai")),PARTITION p2_city VALUES IN (("2", "Beijing"), ("2", "Shanghai")),PARTITION p3_city VALUES IN (("3", "Beijing"), ("3", "Shanghai"))
)

Doris还支持NULL分区，和动态分区，这2中不怎么使用，具体的可以参考官网

Bucket桶

如果使用了Partition,则DISTRIBUTED.语句描述的是数据在各个分区内的划分规则。如果不使用Partition,则描述的是对整个表的数据的划分规则。

  • 分桶列可以是多列，但必须为Key列。分桶列可以和Partition列相同或不同。
  • 分桶列的选择，是在查询吞吐和查询并发之间的一种权衡,如果选择多个分桶列，则数据分布更均匀。如果一个查询条件不包含所有分桶列的等值条件，那么该查询会触发所有分桶同时扫描，这样查询的吞吐会增加，单个查询的延迟随之降低。这个方式适合大吞吐低并发的查询场景。
  • 如果仅选择一个或少数分桶列，则对应的点查间可以仅触发一个分桶扫描。此时，当多个点查间并发时，这些查询有较大的概率分别触发不同的分桶扫描，各个查询之间的影响较小（尤其当不同桶分布在不同磁盘上时)，所以这种方式适合高并发的点查询场景。
  • 分桶的数量理论上没有上限

下面案例是根据省份和城市进行Hash分桶，桶的数量为4，根据查询条件不同，查询过程如下

在这里插入图片描述
下面案例是根据省份进行Hash分桶，根据查询条件不同，查询流程如下
在这里插入图片描述

分桶建议

  • 一个表的Tablet桶数量，在不考虑扩容的情况下，推荐略多于整个集群的磁盘数量。

  • 单个Tablet的数据量理论上没有上下界，但建议在1G-10G的范围内。如果单个Tablet数据量过小，则数据的聚合效果不佳，且元数据管理压力大。如果数据量过大，则不利于副本的迁移、补齐，且会增加Schema Change或者Rollup操作失败重试的代价（这些操作失败重试的粒度是Tablet)。分桶应该控制桶内数据量，不易过大或者过小

  • 在建表时，每个分区的Bucket数量统一指定。但是在动态增加分区时(ADD PARTITION),可以单独指定新分区的Bucket数量。可以利用这个功能方便的应对数据缩小或膨胀。

  • 一个Partition的Bucket数量一旦指定，不可更改。所以在确定Bucket数量时，需要预先考虑集群扩容的情况。比如当前只有3台host,每台host有1块盘。如果Bucket的数量只设置为3或更小，那么后期即使再增加机器，也不能提高并发度。

举例

如果一个表总大小为500MB,则可以考虑4-8个分片。
- 5GB: 8-16个分片。
- 50GB: 32个分片。
- 500GB: 建议分区，每个分区大小在50GB左右，每个分区16-32个分片。
- 5TB:建议分区，每个分区大小在500GB左右，每个分区16-32个分片。
注：表的数据量可以通过SHOW DATA命令查看，结果除以副本数，即表的数据量。

4.properties属性

建表语句后面可以通过properties来执行一些属性,下面展示2个案例，更多可以查看官网

PROPERTIES
("replication_num" = "1"
);
  • replication_num : 副本数。默认副本数为 3。如果 BE 节点数量小于 3，则需指定副本数小于等于 BE 节点数量。
  • storage_medium/storage_cooldown_time : 数据存储介质。storage_medium 用于声明表数据的初始存储介质，而 storage_cooldown_time 用于设定到期时间。示例：
    "storage_medium" = "SSD",
"storage_cooldown_time" = "2020-11-20 00:00:00"
    这个示例表示数据存放在 SSD 中，并且在 2020-11-20 00:00:00 到期后，会自动迁移到 HDD 存储上。

5.案例DataBase连接Doris

doris使用的是Mysql的客户端，所以直接使用Mysql的方式进行连接即可，记得端口要使用：9030
在这里插入图片描述
打开Console，创建 一个数据库和表如下

create database db_user;CREATE TABLE IF NOT EXISTS db_user.user_agg
(`user_id` LARGEINT NOT NULL COMMENT "用户id",`date` DATE NOT NULL COMMENT "数据灌入日期时间",`city` VARCHAR(20) COMMENT "用户所在城市",`age` SMALLINT COMMENT "用户年龄",`sex` TINYINT COMMENT "用户性别",`last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "用户最后一次访问时间",`cost` BIGINT SUM DEFAULT "0" COMMENT "用户总消费",`max_dwell_time` INT MAX DEFAULT "0" COMMENT "用户最大停留时间",`min_dwell_time` INT MIN DEFAULT "99999" COMMENT "用户最小停留时间"
)
AGGREGATE KEY(`user_id`, `date`, `city`, `age`, `sex`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

这里我采用的是官网的案例，创建了一个用户表，使用的是聚合模型，下面是插入数据和查询数据的SQL

insert into db_user.user_agg values(10000,"2017-10-01","北京",20,0,"2017-10-01 06:00:00",20,10,10),(10000,"2017-10-01","北京",20,0,"2017-10-01 07:00:00",15,2,2),(10001,"2017-10-01","北京",30,1,"2017-10-01 17:05:45",2,22,22),(10002,"2017-10-02","上海",20,1,"2017-10-02 12:59:12",200,5,5),(10003,"2017-10-02","广州",32,0,"2017-10-02 11:20:00",30,11,11),(10004,"2017-10-01","深圳",35,0,"2017-10-01 10:00:15",100,3,3),(10004,"2017-10-03","深圳",35,0,"2017-10-03 10:20:22",11,6,6);select * from db_user.user_agg

结果是进行过合并的
在这里插入图片描述

这篇关于二.海量数据实时分析-Doris数据表设计的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1132876。

相关文章

大模型研发全揭秘：客服工单数据标注的完整攻略

大模型研发全揭秘：客服工单数据标注的完整攻略

在人工智能（AI）领域，数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者，掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中，工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注，不仅能够帮助提升客服自动化系统的智能化水平，还能优化客户服务流程，提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行
阅读更多...
不懂推荐算法也能设计推荐系统

不懂推荐算法也能设计推荐系统

本文以商业化应用推荐为例，告诉我们不懂推荐算法的产品，也能从产品侧出发， 设计出一款不错的推荐系统。 相信很多新手产品，看到算法二字，多是懵圈的。 什么排序算法、最短路径等都是相对传统的算法（注：传统是指科班出身的产品都会接触过）。但对于推荐算法，多数产品对着网上搜到的资源，都会无从下手。特别当某些推荐算法 和 “AI”扯上关系后，更是加大了理解的难度。 但，不了解推荐算法，就无法做推荐系
阅读更多...
基于MySQL Binlog的Elasticsearch数据同步实践

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展，我们的业务数据越来越多，单纯使用 MySQL 已经不能满足我们的数据查询需求，例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后，随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步，我们目前的解决方案是建立数据中间表。把需要检索的业务数据，统一放到一张M
阅读更多...
关于数据埋点，你需要了解这些基本知识

关于数据埋点，你需要了解这些基本知识

产品汪每天都在和数据打交道，你知道数据来自哪里吗？ 移动app端内的用户行为数据大多来自埋点，了解一些埋点知识，能和数据分析师、技术侃大山，参与到前期的数据采集，更重要是让最终的埋点数据能为我所用，否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式，可以区分为： 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理：自动程度高的，能解决通用统计，便于统一化管理，但个性化定
阅读更多...
使用SecondaryNameNode恢复NameNode的数据

使用SecondaryNameNode恢复NameNode的数据

1）需求： NameNode进程挂了并且存储的数据也丢失了，如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2）故障模拟 （1）kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 （2）删除NameNode存储的数据（/opt/module/hadoop-3.1.4/data/tmp/dfs/na
阅读更多...
异构存储（冷热数据分离）

异构存储（冷热数据分离）

异构存储主要解决不同的数据，存储在不同类型的硬盘中，达到最佳性能的问题。 异构存储Shell操作 （1）查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies （2）为指定路径（数据存储目录）设置指定的存储策略 hdfs storagepolicies -setStoragePo
阅读更多...
Hadoop集群数据均衡之磁盘间数据均衡

Hadoop集群数据均衡之磁盘间数据均衡

生产环境，由于硬盘空间不足，往往需要增加一块硬盘。刚加载的硬盘没有数据时，可以执行磁盘数据均衡命令。（Hadoop3.x新特性） plan后面带的节点的名字必须是已经存在的，并且是需要均衡的节点。 如果节点不存在，会报如下错误： 如果节点只有一个硬盘的话，不会创建均衡计划： （1）生成均衡计划 hdfs diskbalancer -plan hadoop102 （2）执行均衡计划 hd
阅读更多...
性能分析之MySQL索引实战案例

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题，本文将一起从代码层去分析为什么没有建立索引？ 开源ERP项目地址：https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置
阅读更多...
【专题】2024飞行汽车技术全景报告合集PDF分享（附原数据表）

【专题】2024飞行汽车技术全景报告合集PDF分享（附原数据表）

原文链接： https://tecdat.cn/?p=37628 6月16日，小鹏汇天旅航者X2在北京大兴国际机场临空经济区完成首飞，这也是小鹏汇天的产品在京津冀地区进行的首次飞行。小鹏汇天方面还表示，公司准备量产，并计划今年四季度开启预售小鹏汇天分体式飞行汽车，探索分体式飞行汽车城际通勤。阅读原文，获取专题报告合集全文，解锁文末271份飞行汽车相关行业研究报告。 据悉，业内人士对飞行汽车行业
阅读更多...
【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

【Prometheus】PromQL向量匹配实现不同标签的向量数据进行运算

✨✨ 欢迎大家来到景天科技苑✨✨ 🎈🎈 养成好习惯，先赞后看哦~🎈🎈 🏆 作者简介：景天科技苑 🏆《头衔》：大厂架构师，华为云开发者社区专家博主，阿里云开发者社区专家博主，CSDN全栈领域优质创作者，掘金优秀博主，51CTO博客专家等。 🏆《博客》：Python全栈，前后端开发，小程序开发，人工智能，js逆向，App逆向，网络系统安全，数据分析，Django，fastapi
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2