Apache Doris 基础 -- 数据表设计（数据模型）

已于 2024-06-04 17:02:16 修改
阅读量1.1k 收藏 29
点赞数 18
分类专栏： BigData 文章标签： Apache Doris
于 2024-05-28 11:03:20 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/chinus_yan/article/details/139063458
版权

Versions: 2.1

1、模型概览

本主题从逻辑角度介绍了Doris中的数据模型，以便您可以在不同的业务场景中更好地使用Doris。

基本概念

本文主要从逻辑的角度描述Doris的数据模型，旨在帮助用户在不同的场景更好地利用Doris。

在Doris中，数据在逻辑上以表的形式表示。表由行和列组成。行（Row）表示来自用户的单个数据条目。这一行包含一组相关的值，这些值表示表的列(Column)定义的不同属性或字段。

列可以大致分为两种类型:键（Key）和值（Value）。从业务角度来看，Key和Value可以分别对应于维度列和度量列。在Doris中，Key列是在表创建语句中指定的列。在表创建语句中，唯一键（unique key）、聚合键（aggregate key）或重复键（duplicate key）后面的列被认为是键列，而其余列是值列。

Doris中的数据模型主要分为三种类型:

  • 重复（Duplicate）:此数据模型允许基于指定的键列存储重复行。它适用于必须保留所有原始数据记录的场景。
  • 唯一性（Unique）:在此数据模型中，每一行都由键列中的值组合唯一标识。这确保给定的键值集不存在重复行。
  • 聚合（Aggregate）:该模型支持基于键列的数据聚合。它通常用于需要汇总或聚合信息(如总数或平均值)的场景。

2、Duplicate Key Model

在某些多维分析场景中，数据缺少主键和聚合需求。对于这些情况，可以使用重复数据模型。

在Duplicate Data Model中，数据按照导入文件中出现的样子精确地存储，没有任何聚合。即使两行数据相同，也将保留这两行数据。在表创建语句中指定的Duplicate Key仅用于指示数据在存储期间应按哪些列排序。建议选择前2-4列作为“Duplicate Key”。

例如，考虑一个包含以下数据列的表，它不需要主键更新或基于聚合键的聚合:

在这里插入图片描述
如果在创建表时没有指定数据模型(Unique、Aggregate或Duplicate)，则默认创建Duplicate模型表，并根据一定的规则自动选择排序列。例如，在下面的表创建语句中，如果没有指定数据模型，则会建立一个Duplicate模型表，系统将自动选择前三列作为排序列。

CREATE TABLE IF NOT EXISTS example_tbl_by_default
(
    `timestamp` DATETIME NOT NULL COMMENT "Log time",
    `type` INT NOT NULL COMMENT "Log type",
    `error_code` INT COMMENT "Error code",
    `error_msg` VARCHAR(1024) COMMENT "Error detail message",
    `op_id` BIGINT COMMENT "Operator ID",
    `op_time` DATETIME COMMENT "Operation time"
)
DISTRIBUTED BY HASH(`type`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

MySQL > desc example_tbl_by_default; 
+------------+---------------+------+-------+---------+-------+
| Field      | Type          | Null | Key   | Default | Extra |
+------------+---------------+------+-------+---------+-------+
| timestamp  | DATETIME      | No   | true  | NULL    | NONE  |
| type       | INT           | No   | true  | NULL    | NONE  |
| error_code | INT           | Yes  | true  | NULL    | NONE  |
| error_msg  | VARCHAR(1024) | Yes  | false | NULL    | NONE  |
| op_id      | BIGINT        | Yes  | false | NULL    | NONE  |
| op_time    | DATETIME      | Yes  | false | NULL    | NONE  |
+------------+---------------+------+-------+---------+-------+
6 rows in set (0.01 sec)

没有排序列的默认复制模型(V2.0起)

当用户没有排序需求时，他们可以向表属性添加以下配置。这样，在创建默认Duplicate模型时，系统将不会自动选择任何排序列。

"enable_duplicate_without_keys_by_default" = "true"

CREATE TABLE语句对应如下:

CREATE TABLE IF NOT EXISTS example_tbl_duplicate_without_keys_by_default
(
    `timestamp` DATETIME NOT NULL COMMENT "Log time",
    `type` INT NOT NULL COMMENT "Log type",
    `error_code` INT COMMENT "Error code",
    `error_msg` VARCHAR(1024) COMMENT "Error detail message",
    `op_id` BIGINT COMMENT "Operator ID",
    `op_time` DATETIME COMMENT "Operation time"
)
DISTRIBUTED BY HASH(`type`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"enable_duplicate_without_keys_by_default" = "true"
);

MySQL > desc example_tbl_duplicate_without_keys_by_default;
+------------+---------------+------+-------+---------+-------+
| Field      | Type          | Null | Key   | Default | Extra |
+------------+---------------+------+-------+---------+-------+
| timestamp  | DATETIME      | No   | false | NULL    | NONE  |
| type       | INT           | No   | false | NULL    | NONE  |
| error_code | INT           | Yes  | false | NULL    | NONE  |
| error_msg  | VARCHAR(1024) | Yes  | false | NULL    | NONE  |
| op_id      | BIGINT        | Yes  | false | NULL    | NONE  |
| op_time    | DATETIME      | Yes  | false | NULL    | NONE  |
+------------+---------------+------+-------+---------+-------+
6 rows in set (0.01 sec)

有排序列复制模型

在表创建语句中，可以指定Duplicate Key来指示数据存储应该根据这些键列进行排序。选择“Duplicate Key”时，建议选择前2 ~ 4列。

表创建语句的示例如下，它根据timestamp、type和error_code列指定排序。

CREATE TABLE IF NOT EXISTS example_tbl_duplicate
(
    `timestamp` DATETIME NOT NULL COMMENT "Log time",
    `type` INT NOT NULL COMMENT "Log type",
    `error_code` INT COMMENT "Error code",
    `error_msg` VARCHAR(1024) COMMENT "Error detail message",
    `op_id` BIGINT COMMENT "Operator ID",
    `op_time` DATETIME COMMENT "Operation time"
)
DUPLICATE KEY(`timestamp`, `type`, `error_code`)
DISTRIBUTED BY HASH(`type`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

MySQL > desc example_tbl_duplicate; 
+------------+---------------+------+-------+---------+-------+
| Field      | Type          | Null | Key   | Default | Extra |
+------------+---------------+------+-------+---------+-------+
| timestamp  | DATETIME      | No   | true  | NULL    | NONE  |
| type       | INT           | No   | true  | NULL    | NONE  |
| error_code | INT           | Yes  | true  | NULL    | NONE  |
| error_msg  | VARCHAR(1024) | Yes  | false | NULL    | NONE  |
| op_id      | BIGINT        | Yes  | false | NULL    | NONE  |
| op_time    | DATETIME      | Yes  | false | NULL    | NONE  |
+------------+---------------+------+-------+---------+-------+
6 rows in set (0.01 sec)

数据将按照导入文件中的原始数据进行存储，不进行任何聚合。即使两行数据完全相同，系统也会保留它们。在表创建语句中指定的Duplicate Key仅用于指示在数据存储期间应使用哪些列进行排序。选择“Duplicate Key”时，建议选择前2 ~ 4列。

3、Unique Key Model

当用户有数据更新需求时，他们可以选择使用Unique数据模型。唯一性模型可以保证主键的唯一性。当用户更新数据时，新写入的数据将用相同的主键覆盖旧数据。

Unique数据模型提供了两种实现方法:

  • Merge-on-read。当用户写入数据时，不会触发重复数据删除相关操作。所有的重复数据删除操作都在查询或压缩过程中执行。因此，merge-on-read 的写性能较好，查询性能较差，内存消耗也较高。
  • Merge-on-write。在1.2版本中，我们引入了写时合并(merge-on-write)实现，它在数据写入阶段完成所有的重复数据删除任务，从而提供了出色的查询性能。从2.0版本开始，写时合并已经变得非常成熟和稳定。由于其出色的查询性能，我们建议大多数用户选择此实现。从2.1版本开始，写时合并已经成为Unique模型的默认实现。

Unique模型的默认更新语义是全行UPSERT(full-row UPSERT)，代表UPDATE或INSERT。如果行数据的键存在，则执行更新;如果不存在，则插入新数据。在全行UPSERT语义下，即使用户使用INSERT INTO指定要写入的部分列，Doris也会用NULL值或Planner中的默认值填充未提供的列。

如果用户希望更新部分字段，他们需要使用写时合并实现，并通过特定参数启用对部分列更新的支持。请参阅Data Operate/Data Update部分了解更多细节。

让我们以一个典型的用户基本信息表为例，看看如何创建一个具有读时合并和写时合并的Unique模型表。该表没有聚合要求，只需要保证主键的唯一性(主键为user_id + username)。
在这里插入图片描述

Merge-on-Read

Merge-on-read的表创建语句如下:

CREATE TABLE IF NOT EXISTS example_tbl_unique
(
    `user_id` LARGEINT NOT NULL COMMENT "User ID",
    `username` VARCHAR(50) NOT NULL COMMENT "Username",
    `city` VARCHAR(20) COMMENT "User location city",
    `age` SMALLINT COMMENT "User age",
    `sex` TINYINT COMMENT "User gender",
    `phone` LARGEINT COMMENT "User phone number",
    `address` VARCHAR(500) COMMENT "User address",
    `register_time` DATETIME COMMENT "User registration time"
)
UNIQUE KEY(`user_id`, `username`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

Merge-on-Write

写时合并的表创建语句如下:

CREATE TABLE IF NOT EXISTS example_tbl_unique_merge_on_write
(
    `user_id` LARGEINT NOT NULL COMMENT "User ID",
    `username` VARCHAR(50) NOT NULL COMMENT "Username",
    `city` VARCHAR(20) COMMENT "User location city",
    `age` SMALLINT COMMENT "User age",
    `sex` TINYINT COMMENT "User gender",
    `phone` LARGEINT COMMENT "User phone number",
    `address` VARCHAR(500) COMMENT "User address",
    `register_time` DATETIME COMMENT "User registration time"
)
UNIQUE KEY(`user_id`, `username`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1",
"enable_unique_key_merge_on_write" = "true"
);

用户需要在创建表时添加enable_unique_key_merge_on_write" = "true"属性来启用写合并。

"enable_unique_key_merge_on_write" = "true"

在版本2.1中，写时合并将是主键模型的默认方法。
对于新用户，强烈建议使用2.0或更高版本。在2.0版本中，merge-on-write的性能和稳定性得到了显著的改进和优化。
对于1.2版本的用户:

  • 建议使用1.2.4或更高版本，该版本修复了一些错误和稳定性问题。
  • 在be.conf中增加配置项disable_storage_page_cache=false。不加该配置项，可能会对数据导入性能造成较大影响。

使用注意事项：

  • Unique模型的实现只能在表创建期间确定，不能通过模式更改进行修改。
  • 读时合并表不能无缝地升级到写时合并表(由于完全不同的数据组织方法)。如果您需要切换到Merge-on-write，您必须手动执行INSERT INTO unique-mow-table SELECT * FROM source_table来重新导入数据。
  • Whole-row Updates:Unique模型的默认更新语义是整行UPSERT，它代表UPDATE OR INSERT。如果一行数据的键存在，它将被更新;如果不存在，则插入新数据。在整行UPSERT语义下，即使用户使用INSERT INTO只指定要插入的某些列，Doris也会用NULL值或计划阶段的默认值填充未提供的列。
  • Partial Column Updates: 如果用户希望只更新某些字段，他们必须使用Merge-on-write，并通过特定参数启用对部分列更新的支持。请参考部分列更新的文档以获得相关的使用建议。

4、Aggregate Key Model

以下是演示聚合模型是什么以及如何正确使用它的实际示例。

Importing Data Aggregation

假设业务具有以下数据表模式:
在这里插入图片描述
与CREATE TABLE语句对应的语句如下(省略Partition和Distribution信息):

CREATE DATABASE IF NOT EXISTS example_db;

CREATE TABLE IF NOT EXISTS example_db.example_tbl_agg1
(
    `user_id` LARGEINT NOT NULL COMMENT "user id",
    `date` DATE NOT NULL COMMENT "data import time",
    `city` VARCHAR(20) COMMENT "city",
    `age` SMALLINT COMMENT "age",
    `sex` TINYINT COMMENT "gender",
    `last_visit_date` DATETIME REPLACE DEFAULT "1970-01-01 00:00:00" COMMENT "last visit date time",
    `cost` BIGINT SUM DEFAULT "0" COMMENT "user total cost",
    `max_dwell_time` INT MAX DEFAULT "0" COMMENT "user max dwell time",
    `min_dwell_time` INT MIN DEFAULT "99999" COMMENT "user min dwell time"
)
AGGREGATE KEY(`user_id`, `date`, `city`, `age`, `sex`)
DISTRIBUTED BY HASH(`user_id`) BUCKETS 1
PROPERTIES (
"replication_allocation" = "tag.location.default: 1"
);

如您所见，这是一个典型的用户信息和访问行为事实表。在星型模型中，用户信息和访问行为通常分别存储在维度表和事实表中。这里，为了便于解释，我们将这两种类型的信息存储在一个表中。

表中的列根据是否使用AggregationType设置，分为Key(维度列)和Value(指标列)列。键列没有AggregationType，例如user_id、date和age，而值列有AggregationType。

在导入数据时，在Key列中具有相同内容的行将聚合为一行，并且它们在Value列中的值将按照其AggregationType指定的方式聚合。目前，有几种聚合方法和“agg_state”选项可用:

  • SUM: Accumulate the values in multiple rows.

  • REPLACE: The newly imported value will replace the previous value.

  • MAX: Keep the maximum value.

  • MIN: Keep the minimum value.

  • REPLACE_IF_NOT_NULL: Non-null value replacement. Unlike - REPLACE, it does not replace null values.

  • HLL_UNION: Aggregation method for columns of HLL type, using the HyperLogLog algorithm for aggregation.

  • BITMAP_UNION: Aggregation method for columns of BITMAP type, performing a union aggregation of bitmaps.

如果这些聚合方法不能满足需求，您可以选择使用“agg_state”类型。

假设您有以下导入数据(原始数据):
在这里插入图片描述
你可以用下面的sql来导入数据:

insert into example_db.example_tbl_agg1 values
(10000,"2017-10-01","Beijing",20,0,"2017-10-01 06:00:00",20,10,10),
(10000,"2017-10-01","Beijing",20,0,"2017-10-01 07:00:00",15,2,2),
(10001,"2017-10-01","Beijing",30,1,"2017-10-01 17:05:45",2,22,22),
(10002,"2017-10-02","Shanghai",20,1,"2017-10-02 12:59:12",200,5,5),
(10003,"2017-10-02","Guangzhou",32,0,"2017-10-02 11:20:00",30,11,11),
(10004,"2017-10-01","Shenzhen",35,0,"2017-10-01 10:00:15",100,3,3),
(10004,"2017-10-03","Shenzhen",35,0,"2017-10-03 10:20:22",11,6,6);

这是一个记录用户在访问某个商品页面时的行为的表格。以第一行数据为例，解释如下:
在这里插入图片描述
此批数据正确导入Doris后，将在Doris中保存如下:
在这里插入图片描述
用户10000的数据被聚合到一行，而其他用户的数据保持不变。对于用户10000的聚合数据的解释如下(前5列保持不变，所以从第6列last_visit_date开始):

  • 第6列的值为2017-10-01 07:00:last_visit_date列通过REPLACE进行聚合，因此2017-10-01 07:00取代了2017-10-01 06:00。
  • 第7列中的值为35:cost列通过SUM进行聚合，因此更新值35是20 + 15的结果。
  • 第8列中的值为10:max_dwell_time列是由MAX聚合的，因此10被保存为10到2之间的最大值。
  • 第9列中的值为2:min_dwell_time列由MIN聚合，因此2被保存为10到2之间的最小值。

聚合后，Doris只存储聚合后的数据。换句话说，详细的原始数据将不再可用。

导入数据并与现有数据聚合

假设表中已经包含了之前导入的数据:
在这里插入图片描述

现在导入新一批数据:

insert into example_db.example_tbl_agg1 values
(10004,"2017-10-03","Shenzhen",35,0,"2017-10-03 11:22:00",44,19,19),
(10005,"2017-10-03","Changsha",29,1,"2017-10-03 18:11:02",3,1,1);

导入后，存储在Doris中的数据会更新如下:
在这里插入图片描述
可以看到，User 10004的现有数据和新导入的数据已经聚合。同时，新增了用户10005的数据。

在Doris中，数据聚合发生在以下3个阶段:
1、每批导入数据的ETL阶段。在此阶段，将在内部聚合一批导入数据。
2、底层BE的数据压缩阶段。在此阶段，BE将聚合来自已导入的不同批次的数据。
3、数据查询阶段。查询中涉及的数据将相应地聚合。

在不同阶段，数据的汇总程度不同。例如，当刚导入一批数据时，它可能不会与现有数据聚合。但对于用户来说，他们只能查询聚合数据。也就是说，用户看到的是聚合的数据，他们不应该假设他们看到的是不聚合的或部分聚合的。

agg_state

AGG_STATE不能用作键列，在创建表时，需要声明聚合函数的签名。用户不需要指定长度或默认值。数据的实际存储大小取决于函数的实现。

CREATE TABLE

set enable_agg_state=true;
create table aggstate(
    k1 int null,
    k2 agg_state<sum(int)> generic,
    k3 agg_state<group_concat(string)> generic
)
aggregate key (k1)
distributed BY hash(k1) buckets 3
properties("replication_num" = "1");

agg_state用于声明数据类型为agg_state, sum/group_concat是聚合函数的签名。

请注意，agg_state是一种数据类型，类似于int、数组(array)或字符串(string)。
agg_state只能与state/merge/union函数组合子一起使用。

agg_state表示聚合函数的中间结果。例如，对于聚合函数sum, agg_state可以表示sum(1,2,3,4,5)等求和值的中间状态，而不是最终结果。

agg_state类型需要使用state函数生成。对于当前表，对于“sum”和group_concat聚合函数，分别是sum_state和group_concat_state。

insert into aggstate values(1,sum_state(1),group_concat_state('a'));
insert into aggstate values(1,sum_state(2),group_concat_state('b'));
insert into aggstate values(1,sum_state(3),group_concat_state('c'));

此时，该表只包含一行。请注意，下表只作说明用途，不能直接选择/显示:

在这里插入图片描述
插入另一条记录。

insert into aggstate values(2,sum_state(4),group_concat_state('d'));

这张表目前的结构是……
在这里插入图片描述
我们可以使用merge操作来组合多个状态，并返回聚合函数计算出的最终结果。

mysql> select sum_merge(k2) from aggstate;
+---------------+
| sum_merge(k2) |
+---------------+
|            10 |
+---------------+

sum_merge首先将sum(1,2,3)和sum(4)合并为sum(1,2,3,4)，并返回计算结果。因为group_concat有特定的顺序要求，所以结果不稳定。

mysql> select group_concat_merge(k3) from aggstate;
+------------------------+
| group_concat_merge(k3) |
+------------------------+
| c,b,a,d                |
+------------------------+

如果不想要最终的聚合结果，可以使用union将多个中间聚合结果组合起来，生成一个新的中间结果。

insert into aggstate select 3,sum_union(k2),group_concat_union(k3) from aggstate ;

这张表目前的结构是……
在这里插入图片描述
您可以通过查询实现这一点。

mysql> select sum_merge(k2) , group_concat_merge(k3)from aggstate;
+---------------+------------------------+
| sum_merge(k2) | group_concat_merge(k3) |
+---------------+------------------------+
|            20 | c,b,a,d,c,b,a,d        |
+---------------+------------------------+

mysql> select sum_merge(k2) , group_concat_merge(k3)from aggstate where k1 != 2;
+---------------+------------------------+
| sum_merge(k2) | group_concat_merge(k3) |
+---------------+------------------------+
|            16 | c,b,a,d,c,b,a          |
+---------------+------------------------+

用户可以使用agg_state执行更详细的聚合函数操作。

agg_state带来了一定的性能开销。

5、用法说明

列类型建议

创建表时对列类型的建议:
1、键列应该在所有值列之前。
2、只要可能，请选择整数类型。这是因为整数类型的计算和搜索效率远远高于字符串类型。
3、选择不同长度的整数类型时，遵循充分性原则。
4、对于VARCHAR和STRING类型的长度，也要遵循充分性原则。

聚合模型的局限性

本节是关于聚合模型的局限性。

聚合模型只表示聚合的数据。这意味着我们必须确保尚未聚合的数据(例如，两个不同的导入批)的表示一致性。下面通过示例提供进一步的解释。

假设您有以下表模式:
在这里插入图片描述
假设已有两批数据导入到存储引擎中，如下所示:
在这里插入图片描述
如您所见，这两个导入批中关于User 10001的数据尚未聚合。但是，为了保证用户只能查询聚合后的数据，如下所示:
在这里插入图片描述
我们向查询引擎添加了一个聚合操作符，以确保数据的表示一致性。

另外，在聚合列(Value)上，当执行与聚合类型不一致的聚合类查询时，请注意语义。例如，在上面的示例中，如果执行以下查询:

SELECT MIN(cost) FROM table;

结果是5，不是1。

同时，这种一致性保证可能会大大降低某些查询的效率。

以基本count(*)查询为例:

SELECT COUNT(*) FROM table;

在其他数据库中，这样的查询可以快速返回结果。因为在实际实现中，模型可以通过对行进行计数并在导入时保存统计信息来获得查询结果，或者通过仅扫描某一列数据以在查询时获得计数值，开销很小。但是在Doris的聚合模型中，此类查询的开销很大。

对于前面的例子:
在这里插入图片描述
由于最终的聚合结果为:
在这里插入图片描述
select count (*) from table的正确结果;应该是4。但是，如果模型只扫描user_id列并在查询时操作聚合，则最终结果将是3(10001,10002,10003)。如果它不操作聚合，最终结果将是5(两批共5行)。显然，这两个结果都是错误的。

为了得到正确的结果，我们必须同时读取user_id和date列，并在查询时执行聚合。也就是说，在count(*)查询中，Doris必须扫描所有的AGGREGATE KEY列(在本例中是user_id和date)并聚合它们以获得语义正确的结果。这意味着如果有许多聚合列，count(*)查询可能涉及扫描大量数据。

因此，如果需要执行频繁的count (*)查询，我们建议通过添加值为1的列和聚合类型SUM来模拟count (*)。这样，上例中的表模式将被修改如下:
在这里插入图片描述
上面的代码添加了一个count列，它的值总是1，所以select count (*) from table;相当于select sum (count) from table;后者比前者效率高得多。然而，这种方法也有它的缺点。也就是说，它要求用户不能在AGGREGATE KEY列中导入具有相同值的行。否则，选择sum (count) from table;只能表示原始导入数据的行数，而不是select count (*) from table的语义;

另一种方法是添加值为1但聚合类型为REPLACE的count列。然后选择sum (count) from table;和select count (*) from table;可以产生同样的结果。此外，此方法不要求导入数据中不存在相同的AGGREGATE KEY列。

Merge on write of unique model

unique 模型中的写时合并实现不像聚合模型那样施加相同的限制。在“写时合并”中，模型为每个导入的行集添加删除位图（delete bitmap），以标记正在覆盖或删除的数据。如上例所示，导入第一批后，数据状态如下:
在这里插入图片描述
导入第二批数据后，第一批数据中的重复行将被标记为已删除，两批数据的状态如下
在这里插入图片描述
在查询中，删除位图中所有标记为true的数据都不会被读取，因此不需要进行数据聚合。由于上述数据中有4行有效数据，因此查询结果也应该是4。这也使开销最小，因为它只扫描一列数据。

在测试环境中，Unique Model的Merge on Write中的count(*)查询的性能是Aggregate Model的10倍。

Duplicate model

复制模型不像聚合模型那样施加相同的限制，因为它不涉及聚合语义。对于任何列，它都可以在count(*)查询中返回语义正确的结果。

Key columns

对于Duplicate、Aggregate和Unique模型，Key列将在创建表时指定，但存在一些区别:在Duplicate模型中，表的Key列可以视为“排序列”，而不是唯一标识符。在聚合和唯一模型中，Key列既是“排序列”又是“唯一标识符列”。

选择数据模型的建议

由于数据模型是在构建表时建立的，并且此后不可撤销，因此选择合适的数据模型非常重要。

1、聚合模型通过预聚合可以大大减少扫描数据量和查询计算量。因此，它非常适合具有固定模式的报表查询场景。但是这个模型对count(*)查询不友好。同时，由于Value列上的聚合方法是固定的，因此在其他类型的聚合查询中应该考虑语义正确性。
2、对于需要唯一主键的场景，唯一模型保证主键的唯一性。缺点是它不能利用预聚合带来的优势，例如查询中的ROLLUP。对于聚合查询有高性能要求的用户，建议使用1.2版以来新添加的Merge on Write实现。
3、Duplicate Model适用于任何维度的临时查询。虽然它可能无法利用预聚合特性，但它不受聚合模型约束的限制，可以充分发挥列存储的优势(仅读取相关列，而不是所有键列)。
4、如果用户需要使用部分更新，请参考部分更新文档

chinusyan
关注
  • 18
    点赞
  • 踩
  • 29
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
专栏目录
大数据Doris（二）：Doris原理篇
Lansonli（蓝深李）的博客
09-29 2454
在SQL优化器中最重要的一个组件是查询优化器（Query Optimization），在海量数据分析中一条SQL生成的执行计划搜索空间非常庞大，查询优化器的目的就是对执行计划空间进行裁剪减少搜索空间的代价，查询优化器对于SQL的执行来说非常重要，不管是关系型数据库系统Oracle、MySQL还是大数据领域中的Hive、SparkSQL、Flink SQL都会有一个查询优化器进行SQL执行计划优化。从寄存器中访问数据的速度，是从内存访问数据速度的300倍，是从磁盘中访问数据速度的30万倍。
Doris（13）：数据模型
u013938578的博客
04-21 720
在 Doris 中，数据以表（Table）的形式进行逻辑上的描述。一张表包括行（Row）和列（Column）。Row即用户的一行数据。Column 用于描述一行数据中不同的字段。Column可以分为两大类：Key（维度列）和Value（指标列）
Apache Doris 2.1 核心特性 Variant 数据类型技术深度解析
SelectDB
03-14 837
Variant 的引入，使得存储和查询性能上均有显著提升，相较于 JSON 类型，存储空间减少了约 65%，查询速度提升超 8 倍。
Doris数据表模型
weixin_67024075的博客
05-27 1338
表中的列按照是否设置了 AggregationType，分为 Key（维度列）和 Value（指标列），没有设置 AggregationType 的称为 Key，设置了 AggregationType 的称为 Value。即使两行数据完全相同，也都会保留。虽然同样无法利用预聚合的特性，但是不受聚合模型的约束，可以发挥列存模型的优势（只读取相关列，而不需要读取所有 Key 列).一个人不能同时干两件事情，所以我加一个字段，让这个数据灌入的时间精确到时分秒，确保他组合起来的key都是唯一的，是不是就能搞定了？
Doris【数据模型】
xiayuhaisong的博客
03-02 931
在 Doris 中，数据以表（Table）的形式进行逻辑上的描述。一张表包括行（Row）和列（Column）。Row 即用户的一行数据。Column 用于描述一行数据中不同的字段。Column 可以分为两大类：Key 和 Value。从业务角度看，Key 和 Value 可以分别对应维度列和指标列。
Doris数据模型
程裕强的专栏
08-31 2475
列可以分为两大类：Key 和 Value。从业务角度看，Key 和 Value 可以分别对应维度列和指标列。 Apache Doris主要有3种数据模型： 明细模型：Duplicate（重复，复制）模型，表中的Key值（类似关系模型中的主键）可以重复，和插入数据行一一对应。 聚合模型：Aggregate（聚合，合计）模型，表中key值不重复，对于插入的数据数据按照key值对value值进行聚合函数合并。 更新模型：UNIQUE 模型，聚合类型的特殊情况，key满足唯一性，最新插入的数据替换掉对应key的数
Doris系列之数据模型
Allen_人工智能与大数据
08-17 2534
Doris系列之3种数据模型
doris 表模型
qq_15138049的博客
11-23 728
doris 表模型
百度Palo-为数据分析而生.pdf
03-04
此外，Doris支持两种数据模型：聚合模型和明细模型。聚合模型允许用户指定相同key的Value列进行预聚合，提高查询效率；明细模型则保留数据的原始粒度，实现精准去重或快速排序。 物化视图是Doris提升性能的另一利器...
Apache Doris 技术调研
09-26
Doris 的优势包括实时和离线导入、高并发查询支持、MySQL协议兼容、多种数据模型（Aggregate/Unique/Duplicate）、简单运维和扩展性、物化视图和动态分区功能。然而，Doris 也存在一些不足，比如成熟度相对较低，对...
2-4基于DorisDB构建实时数据仓库.pdf
03-18
DorisDB是一款基于Apache开源项目的新一代极速MPP分析型数据库系统，旨在帮助企业构建实时数据仓库，提供秒级实时数据分析和查询能力。下面是基于DorisDB构建实时数据仓库的知识点： 1. 实时数据仓库的需求：企业...
【推荐】最强大数据学习与最佳实践资料合集（基础+架构+数仓+治理+案例）（100份）.zip
10-18
推荐，最强大数据学习与最佳实践资料合集，基础+架构+治理+案例，共100份。 一、基础篇 快手EB级HDFS挑战与实践 Hive任务开发规范 一文看懂Hadoop生态圈 资料-CentOS7搭建Hadoop-2.7.7集群 ClickHouse官方中文文档 ...
MPP数据库 doris 使用
08-30
使⽤StarRocks，用户可以灵活构建包括大宽表、星型模型、雪花模型在内的各种模型。 StarRocks兼容MySQL协议，支持标准SQL语法，易于对接使用，全系统无外部依赖，高可用，易于运维管理。StarRocks还兼容多种主流BI...
doris----数据表设计
Y521316的博客
05-25 222
doris----数据表设计
Doris---数据表设计
m0_53400772的博客
05-25 1017
Partition 支持通过 VALUES LESS THAN (...) 仅指定上界，系统会将前一个分区的上界作为该分区的下界，生成一个左闭右开的区间。此时，当多个点查询并发时，这些查询有较大的概率分别触发不同的分桶扫描，各个查询之间的IO影响较小（尤其当不同桶分布在不同磁盘上时），所以这种方式适合高并发的点查询场景。当不使用 Partition 建表时，系统会自动生成一个和表名同名的，全值范围的 Partition。一个表的 Tablet 数量，在不考虑扩容的情况下，推荐略多于整个集群的磁盘数量。
Doris--基础--10--数据模型
zhou920786312的博客
03-10 1186
数据完全按照导入文件中的数据进行存储，不会有任何聚合。即使两行数据完全相同，也都会保留。在建表语句中指定的 DUPLICATE KEY，只是用来指明底层数据按照那些列进行排序。适用场景：既没有聚合需求，又没有主键唯一性约束的原始数据的存储。
深入解析实时数仓Doris：三大数据模型详解
最新发布
码到三十五
03-29 2906
在 Doris 中，数据以表（Table）的形式进行逻辑上的描述。 一张表包括行（Row）和列（Column）。Row 即用户的一行数据。Column 用于描述一行数据中不同的字段。 Column 可以分为两大类：Key 和 Value。从业务角度看，Key 和 Value 可以分别对应维度列和指标列。Doris 的 key 列是建表语句中指定的列，建表语句中的关键字'unique key'或'aggregate key'或'duplicate key'后面的列就是 Key 列，除了 Key 列剩下的就是
doris通关之doris三种数据模型
u011624157的专栏
09-12 877
doris三种模型
基于 apache doris 的数据仓库平台架构设计
08-26
基于 Apache Doris 的数据仓库平台架构设计如下： 1. 架构模式： - 采用分布式架构模式，将数据仓库划分为多个节点，每个节点可以独立存储和处理数据，同时支持横向扩展，能够处理大规模的数据量和并发请求。 2. 数据存储层： - 使用分布式文件系统（如HDFS）存储数据，数据按照数据表的划分进行存储，支持数据的分片和复制，提高数据的可靠性和可用性。 - 数据以列式存储的方式存储，提高查询效率。 - 支持数据的压缩和索引，降低存储空间和提高查询效率。 3. 元数据管理： - 使用元数据管理系统（如MySQL）存储数据的元信息，包括表结构、分区、数据位置等。 - 元数据管理系统支持水平扩展，保证元数据的一致性和高可用性。 4. 查询引擎： - 使用分布式查询引擎，支持SQL语法，能够高效地执行复杂的数据查询和分析操作。 - 支持预编译和查询优化技术，提高查询性能。 5. 数据加载和导出： - 支持多种方式的数据加载和导出，如批量导入、实时流入、增量导入、导出到外部系统等。 - 支持数据的转换和清洗，提高数据的质量和一致性。 6. 安全性和权限管理： - 支持访问控制，可以对用户和角色进行权限管理，确保数据的安全性和合规性。 - 支持数据加密和身份认证，保护数据的机密性和完整性。 7. 可视化和监控： - 提供用户友好的可视化界面，方便用户管理和操作数据仓库。 - 支持实时监控和告警功能，及时发现和解决系统故障和性能问题。 总之，基于 Apache Doris 的数据仓库平台架构设计具备高可扩展性、高性能和高可靠性的特点，可以满足大规模数据处理和查询的需求，并提供丰富的功能和工具支持，帮助用户实现高效的数据分析和决策。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值