Doris（⼀）--从创建⼀张表开始
⼀、创建⼀张表的艰⾟路程
在 Doris 中，数据以表（Table）的形式进⾏逻辑上的描述。
创建⼀张合格的表，主要考虑以下⼏个⽅⾯：
字段
索引
引擎
模型
分区
分桶
属性
1、Doris中的引擎
olap
mysql
broker
Hive
2、Doris中的三⼤模型：
Aggregate
Uniq
Duplicate
3、Doris中分区类型
Range
List
4、建表⽰例
4.1 字段
Doris中的数据类型包括：
bigint
bigmap
boolean
char
date
datetime
decimal
double
float
Hll(HyperLogLog)
int
largeint
smallint
string
tinyint
Varchar
当我们创建表的时候，难免会遇见⼀张⼤表，⼤表的描述即某些个字段的值已经超出了你的想像，你不得不⽤varchar(65533) 设置。当然如果可以使⽤String这样的就⾮常nice，不过Doris⽐较坑的就是它的string在创建表的时候会⾃动转化为varchar(1)，所以⾯对⼤数据量的字段，只能使⽤varchar(655
33)，sql如下：
create table kochava_db.kochava_event_primary(
date_occurred INT,
install_id BIGINT,
matched_to_id BIGINT,
matched_to_id BIGINT,
date_received INT,
partition_date DATE,
android_id varchar(512),
adid varchar(512),
app_version varchar(512),
attribution_module varchar(512),
campaign_name varchar(512),
segment_name varchar(512),
city varchar(512),
country_code varchar(512),
creative_id varchar(512),
device_limit_tracking INT,
device_marketing_name varchar(512), device_model varchar(512),
device_os_version varchar(512),
device_os_name varchar(512),
device_ua varchar(512),
device_ver varchar(512),
dma_code varchar(512),
event_dimensions varchar(512),
event_id varchar(512),
event_name varchar(512),
event_value FLOAT,
identifiers varchar(65533),
identity_link varchar(512),
idfa varchar(512),
idfv varchar(512),
ip_address varchar(512),
kochava_device_id varchar(512),
latitude varchar(512),
longitude varchar(512),
lookback_seconds varchar(512),
lookback_used varchar(512),
match_object varchar(65533),
matched_to_type varchar(512),
network_id varchar(512),
network_name varchar(512),
postal_code varchar(512),
properties varchar(65533),
is_reengagement varchar(512),
region varchar(512),
sdk_version varchar(512),
site_id varchar(512),
tracker_guid varchar(512),
tracker_name varchar(512),
valid_receipt varchar(512),
cost float,
cost_type varchar(512),
traffic_verified varchar(512),
traffic_verification_fail_reason varchar(512), waterfall_level varchar(512),
agency_id varchar(512),
attribution_date varchar(512),
channel_type varchar(512),
ad_platform varchar(512),
ad_platform varchar(512),
event_att varchar(512),
event_att_detail varchar(512),
event_att_time varchar(512),
event_att_duration_sec varchar(512),
is_revenue varchar(512),
tracker_id varchar(512),
campaign_id varchar(512)
)ENGINE=olap
unique key (date_occurred,install_id,matched_to_id,date_received,partition_date)
partition by range (partition_date)
(
partition P2******* VALUES LESS THAN ("2021-08-20"),
partition P2******* VALUES LESS THAN ("2021-08-21"),
partition P2******* VALUES LESS THAN ("2021-08-22"),
partition P2******* VALUES LESS THAN ("2021-08-23"),
partition P2******* VALUES LESS THAN ("2021-08-24"),
partition P2******* VALUES LESS THAN ("2021-08-25"),
partition P2******* VALUES LESS THAN ("2021-08-26"),
partition P2******* VALUES LESS THAN ("2021-08-27"),
partition P2******* VALUES LESS THAN ("2021-08-29"),
partition P2******* VALUES LESS THAN ("2021-08-30"),
partition P2******* VALUES LESS THAN ("2021-08-31"),
partition P2******* VALUES LESS THAN ("2021-09-01")
)
distributed by hash (install_id) buckets 32
properties(
"replication_num" = "1",
"storage_format" = "V2",
"able" = "true",
"dynamic_partition.time_unit" = "DAY",
"d" = "3",
"dynamic_partition.prefix" = "P",
"dynamic_partition.buckets" = "10",
"in_memory" = "TRUE"
)
sql中字段⽐较多 ，其中有三个字段的⼤⼩已经是 varchar(65532) 了，此时建表 报错：
Execution failed: Error Failed to execute sql: ptions.jdbc4.MySQLSyntaxErrorException: errCode = 2, detailMessage = The size of a row (224286) exceed the maximal row size: 100000
1
⼤致意思就是单⾏⼤⼩超过了限制，怎么超出限制的呢？
其实是这样的，对于Doris，很类似mysql，在 mysql中，它要求⼀个⾏的定义长度不能超过65535。
（1）单个字段如果⼤于65535，则转换为TEXT 。
（2）单⾏最⼤限制为65535，这⾥不包括TEXT、BLOB。
mysql下载后的初次使用所谓单⾏最⼤限制指的就是⼀张表中所有字段的所设置的长度不得超过65535字节，
例如⼀个表中有三个varchar字段长度30000，那么这个表的单⾏长度为：30000*3=90000，
⼤于65535则报错不能建表，这⾥乘以3是因为数据库⽤的utf8编码，3个字节表⽰⼀个字符。
很正常，这张表是建不起来的，那么怎么解决呢？
很简单！先赋值⼩的⼤⼩ ⽐如varchar(100) ，然后使⽤alter语句更改列的⼤⼩，就OK了。
alter table kochava_event_primary modify column XXX varchar(65532)
1
4.2 索引
⽬前（即Doris现有版本）仅仅提到了三种索引：前缀索引、bitmap索引、布隆过滤器索引
– 前缀索引：
所谓前缀索引就是在表结构字段排序的基础上，根据给定前缀列，快速查询数据的索引⽅式。⽐如 有⼀张表如下
create table if not exists test.events_primary1
(
event_id varchar(10),
date_received INT,
dimension_key varchar(1024),
dimension_value varchar(1024),
partition_date DATE()
) engine=olap
这⾥的前缀索引是什么呢？
我们将⼀⾏数据的前 36 个字节 作为这⾏数据的前缀索引。当遇到 VARCHAR 类型时，前缀索引会直接截断。
1
前缀索引计算⽰例：10bytes + （遇到了varchar） 前缀索引为 event_id
如果有表为：
create table if not exists test.events_primary2
(
event_id bigint,
date_received INT,
dimension_key varchar(1024),
dimension_value varchar(1024),
partition_date DATE()
) engine=olap
前缀索引计算⽰例：8bytes + 4bytes +（遇到了varchar） 前缀索引为 event_id，date_received，dimension_key
那么好处是什么呢？
当我们执⾏如下两条sql查询时
select * from events_primary1 where date_received = xxx;
select * from events_primary2 where date_received = xxx;
明显第⼆条sql语句的效率是⾼于第⼀条的。
【注意】Doris在建完表之后是不⽀持修改前缀索引的，所以在建表之前，优先考虑字段的顺序和分配，不然就只能使⽤rollup了。1
– bitmap索引
bitmap index：位图索引，是⼀种快速数据结构，能够加快查询速度，创建和删除本质上就是⼀个schema change作业
需要注意的是：
⽬前索引仅⽀持 bitmap 类型的索引。
bitmap 索引仅在单列上创建。
bitmap 索引能够应⽤在 Duplicate 数据模型的所有列和 Aggregate, Uniq 模型的key列上。
bitmap 索引⽀持的数据类型如下:
TINYINT
SMALLINT
INT
UNSIGNEDINT
BIGINT
CHAR
VARCHAR
DATE
DATETIME
LARGEINT
DECIMAL
BOOL
bitmap索引仅在 Segment V2 下⽣效。当创建 index 时，表的存储格式将默认转换为 V2 格式。
由于它可以⽀持删除 添加 ，所以在初次创建表的时候⼤可不必太过纠结。
– 布隆过滤器索引
这个索引是隐藏在 属性中的索引，如果是 olap 引擎，我们可以指定该索引。bloom filter 索引仅适⽤于查询条件为 in 和 equal 的情况，该列的值越分散效果越好 ⽬前只⽀持以下情况的列：除了 TINYINT FLOAT DOUBLE 类型以外的 key 列及聚合⽅法为 REPLACE 的 value 列
4.3 引擎
Doris的引擎⽬前有四种，但主要分为两种：存数据和不存数据
olap引擎：存储数据，⼀般作为分析使⽤ ，也是默认的。
mysql引擎，broker引擎，hive引擎：Doris都不会存储数据 ，只会使⽤这些的元数据，类似于外部表使⽤。他们的配置都是在属性中设置的
4.4 模型
模型建的好，查询快⼀倍
Doris ⽬前的模型只有三种：Aggregate,Unique,Duplicate三种 ，相应的也有这三种key，分别是 AGGREGATE KEY，UNIQUE
KEY，DUPLICATE KEY
默认是Duplicate 这种模型啥都接受，也不会做任何操作，如果上游架构在去重⽅⾯做的⾮常nice的话，并且下游数据不需要做任何聚合等操作，只需要简单的做存储，那么这种模型挺适合的。
如果上游数据架构在去重⽅⾯做的不⾏并且下游的数据保证不能被重复消费，那么需要使⽤唯⼀键进⾏约束，相同key的value会被覆盖。那么优先选⽤Unique 模型，它可以保证相同的记录按照时间顺序进⾏覆盖。当然也可以选⽤Aggregate，不过需要加上 replace
如果下游数据需要进⾏聚合，⽐如需要统计 A城市出现的次数 ，我们可以选择Aggregate 模型，设置key为city字段，同时 num字段根据city进⾏聚合，那么这样在存储中就已经实现了聚合。⾮常适合k,v形式的指标查询。
对于UNIQUE KEY来说 ，它⾮常类似clickhouse中ReplicationMerge引擎，可以根据相同的key进⾏合并，但同时也需要注意，如果需要聚合相同的key，那么我们必须将相同的key放⼊同⼀个桶/分区中，这样才能保证对同⼀条数据进⾏合并进⾏合并。UNIQUE KEY可以是多个，也可以是⼀个，当然这取决于我们的定义的key值，我们需要将key列放在最前⾯。经过测试和验证，这个设定有以下条件
问题⼀、
1064 - errCode = 2, detailMessage = The partition column could not be aggregated column, Time: 0.017000s
1
sql如下：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。