检测到您已登录华为云国际站账号,为了您更好的体验,建议您访问国际站服务网站 https://www.huaweicloud.com/intl/zh-cn
不再显示此消息
如果两辆车都通过相同序列的收费站, 通过同一收费站之间的时间差小于一个特定的值。 该例子有两种实现模式,其中实现1的逻辑如图1所示,实现2的逻辑如图2所示。 图1 实现1逻辑 实现1的逻辑说明 : 根据车牌号聚合该车通过的所有收费站并排序,处理后数据如下。 车牌号1,[(通过时间,
ClickHouse索引设计 一级索引设计 在建表设计时指定主键字段的建议:按查询时最常使用且过滤性最高的字段作为主键。依次按照访问频度从高到低、维度基数从小到大来排列。数据是按照主键排序存储的,查询的时候,通过主键可以快速筛选数据,合理的主键设计,能够大大减少读取的数据量,提升
ClickHouse分区设计 合理设置分区键,控制分区数在一千以内,分区字段使用整型。 分区part数与查询性能关系 图1 分区part数与查询性能关系图 分区建议 建议使用toYYYYMMDD(pt_d)作为分区键,pt_d是date类型。 如果业务场景需要做小时分区,使用pt
ClickHouse DataBase设计 业务隔离设计-各业务分库设计 在业务规划时,不同业务归属于不同数据库,便于后续对应用户关联的数据库下表、视图等数据库对象权限的分离管理和维护。 业务隔离设计-不要在system库中创建业务表 system数据库是ClickHouse默认
Hudi表分区设计规范 规则 分区键不可以被更新: Hudi具有主键唯一性机制,但在分区表的场景下通常只能保证分区内主键唯一,因此如果分区键的值发生变更后,会导致相同主键的行记录出现多条的情况。在以日期分区的场景,可采用数据的创建时间为分区字段,切记不要采用数据更新时间做分区。
ClickHouse分布式表设计 建议 分布式表建表参考: CREATE TABLE default.my_table_dis ON CLUSTER default_cluster AS mybase.my_table_local ENGINE = Distributed(default_cluster
如果两辆车都通过相同序列的收费站, 通过同一收费站之间的时间差小于一个特定的值。 该例子有两种实现模式,其中实现1的逻辑如图1所示,实现2的逻辑如图2所示。 图1 实现1逻辑 实现1的逻辑说明 : 根据车牌号聚合该车通过的所有收费站并排序,处理后数据如下: 车牌号1,[(通过时
Select必须是Projection定义中Select的子集。 多表join场景不支持Projection特性,此种场景建议用普通物化视图实现。 父主题: ClickHouse物化视图设计
Hudi表模型设计规范 规则 Hudi表必须设置合理的主键。 Hudi表提供了数据更新和幂等写入能力,该能力要求Hudi表必须设置主键,主键设置不合理会导致数据重复。主键可以为单一主键也可以为复合主键,两种主键类型均要求主键不能有null值和空值,可以参考以下示例设置主键: SparkSQL:
ClickHouse依赖服务设计 为了保证ClickHouse服务的稳定,需要提早规划好对于底层依赖服务的设计,主要是ZooKeeper,尤其是在使用replicated*系列表引擎的场景下。 ZooKeeper默认部署在MRS集群的Master节点,根据节点CPU和内存规格,调
ClickHouse宽表设计 ClickHouse宽表设计原则 ClickHouse表字段设计 ClickHouse本地表设计 ClickHouse分布式表设计 ClickHouse分区设计 ClickHouse索引设计 父主题: ClickHouse应用开发规范
Hudi表索引设计规范 规则 禁止修改表索引类型。 Hudi表的索引会决定数据存储方式,随意修改索引类型会导致表中已有的存量数据与新增数据之间出现数据重复和数据准确性问题。常见的索引类型如下: 布隆索引:Spark引擎独有索引,采用bloomfiter机制,将布隆索引内容写入到Parquet文件的footer中。
ClickHouse本地表设计 规则 单表(分布式表)的记录数不要超过万亿,对于万亿以上表的查询,性能较差,且集群维护难度变大。单表(本地表)不超过百亿。 表的设计都要考虑到数据的生命周期管理,需要进行TTL表属性设置或定期老化清理表分区数据。 单表的字段建议不要超过5000列。
ClickHouse表字段设计 规则 不允许用字符类型存放时间或日期类数据,尤其是需要对该日期字段进行运算或者比较的时候。 不允许用字符类型存放数值类型的数据,尤其是需要对该数值字段进行运算或者比较的时候。字符串的过滤效率相对于整型或者特定时间类型有下降。 建议 不建议表中存储过
ClickHouse宽表设计原则 宽表设计原则 由于ClickHouse的宽表查询性能较优,且当前ClickHouse可支持上万列的宽表横向扩展。 在大部分场景下,有大表两表join以及多表join的场景,且多个join的表数据变化更新频率较低,这种情况,建议对多个表join查询
如果两辆车都通过相同序列的收费站, 通过同一收费站之间的时间差小于一个特定的值。 该例子有两种实现模式,其中实现1的逻辑如图1所示,实现2的逻辑如图2所示。 图1 实现1逻辑 实现1的逻辑说明 : 根据车牌号聚合该车通过的所有收费站并排序,处理后数据如下: 车牌号1,[(通过时
ClickHouse数据分布设计 Shard和副本概念介绍 图1 ClickHouse集群架构图 从横向来看ClickHouse数据库集群,所有数据都会平均分布到多个shard分片中进行保存,数据平均分布后,保证了查询的高度并行性,以提升数据的查询性能。 从纵向来看,每个shar
d; 修改明细表、聚合表结构,严格按照以下步骤实施: 停止明细表数据插入。 修改聚合表结构设计。 删除物化视图表。 重新创建新转化关系的物化视图。 父主题: ClickHouse物化视图设计
ClickHouse物化视图设计 ClickHouse物化视图概述 ClickHouse普通物化视图设计 ClickHouse Projection设计 父主题: ClickHouse应用开发规范
ClickHouse数据库设计 ClickHouse DataBase设计 ClickHouse表引擎适用场景说明 父主题: ClickHouse应用开发规范