数据仓库 表1 数据仓库权限 权限 对应API接口 授权项（Action） IAM项目 (Project) 企业项目 (Enterprise Project) 获取数据仓库列表 GET /v1.0/{project_id}/common/warehouses octopus:dataWarehouse:list

查看更多 →

数据仓库 获取数据仓库列表信息 获取数据仓库的数据列表 父主题： API

查看更多 →

如何设计宽表主键 GeminiDB Cassandra是一款分布式数据引擎，宽表引擎中的数据均按照主键进行分布。在执行查询时，如果表中存在多列主键，系统会从最左边的主键开始匹配。如果主键设置不当，则可能导致主键无法被有效利用，进而产生热点问题，影响查询性能。因此，在数据分区和数据

查看更多 →

ClickHouse宽表设计 ClickHouse宽表设计原则 ClickHouse表字段设计 ClickHouse本地表设计 ClickHouse分布式表设计 ClickHouse分区设计 ClickHouse索引设计 父主题： ClickHouse应用开发规范

查看更多 →

【建议】表的分布方式的选择一般遵循以下原则： 表2 表的分布方式及使用场景 分布方式 描述 适用场景 Hash 表数据通过Hash方式散列到集群中的所有DN上。 数据量较大的事实表。 Replication 集群中每一个DN都有一份全量表数据。 维度表、数据量较小的事实表。 Roundrobin

查看更多 →

支持的并发度。通过对关联条件和分组条件的仔细设计，能够尽可能的减少不必要的数据shuffle。 选择存储方案 【建议】表的存储类型是表定义设计的第一步，用户业务类型是决定表的存储类型的主要因素，表存储类型的选择依据请参考表1。 表1 表的存储类型及场景 存储模型 优点 缺点 适用场景

查看更多 →

获取数据仓库列表信息 功能介绍 获取数据仓库列表 URI GET /v1.0/{project_id}/common/warehouses 表1 路径参数 参数 是否必选 参数类型 描述 project_id 是 String 项目id，获取方法请参见获取项目ID 表2 Query参数

查看更多 →

，完成维度表、事实表等逻辑模型设计。 图7 总线矩阵 逻辑模型创建 在逻辑模型设计中，用户可以定义维度、事实等类型的逻辑模型，新增属性，添加属性编码、名称、字段类型等参数，完成逻辑模型设计，并为其分配到指定的数据域及数据分层中。 图8 逻辑模型创建 可视化设计 在设计模式中，可以

查看更多 →

建议使用。 建议 事实表采用日期分区表，维度表采用非分区或者大颗粒度的日期分区 是否采用分区表要根据表的总数据量、增量和使用方式来决定。从表的使用属性看事实表和维度表具有的特点： 事实表：数据总量大，增量大，数据读取多以日期做切分，读取一定时间段的数据。 维度表：总量相对小，增量

查看更多 →

建议使用。 建议 事实表采用日期分区表，维度表采用非分区或者大颗粒度的日期分区 是否采用分区表要根据表的总数据量、增量和使用方式来决定。从表的使用属性看事实表和维度表具有的特点： 事实表：数据总量大，增量大，数据读取多以日期做切分，读取一定时间段的数据。 维度表：总量相对小，增量

查看更多 →

，规格详情请参见表5。 存算分离本地盘规格，该规格存储容量固定，不能够进行磁盘扩容和规格变更，只能进行节点扩容，规格详情请参见表6。 创建存算分离集群时规格仅显示后半部分（例如4U16G.4DPU），下列规格列表中前缀（dwsx3/dwsax3/dwsk3）代表存算分离对应的CPU架构。

查看更多 →

备注1：存算分离表数据存储在OBS上，无需重分布，但是元数据和索引存储在本地，仍然需要进行重分布。存算分离表在重分布时，表只支持读，元数据的重分布时间一般比较短，但是，如果表上创建了索引，索引会影响重分布的性能，重分布完成时间与索引的数据量成正比关系，在此期间，表只支持读。 存算

查看更多 →

流式计算采用MOR表。 流式计算为低时延的实时计算，需要高性能的流式读写能力，在Hudi表中存在的MOR和COW两种模型中，MOR表的流式读写性能相对较好，因此在流式计算场景下采用MOR表模型。关于MOR表在读写性能的对比关系如下： 对比维度 MOR表 COW表 流式写 高 低 流式读

查看更多 →

视图和关联表设计 视图设计 【建议】除非视图之间存在强依赖关系，否则不建议视图嵌套。 【建议】视图定义中尽量避免排序操作。 关联表设计 【建议】表之间的关联字段应该尽量少。 【建议】关联字段的数据类型应该保持一致。 【建议】关联字段在命名上，应该可以明显体现出关联关系。例如，采用同样名称来命名。

查看更多 →

Hudi表索引设计规范 规则 禁止修改表索引类型。 Hudi表的索引会决定数据存储方式，随意修改索引类型会导致表中已有的存量数据与新增数据之间出现数据重复和数据准确性问题。常见的索引类型如下： 布隆索引：Spark引擎独有索引，采用bloomfiter机制，将布隆索引内容写入到Parquet文件的footer中。

查看更多 →

getListFactLogicTable 创建事实表 DAYU_DS dsFactLogicTable createFactLogicTable 更新事实表 DAYU_DS dsFactLogicTable updateFactLogicTable 发布事实表 DAYU_DS dsFactLogicTable

查看更多 →

避免使用分区表，如有需要，可以使用多个独立的表代替。 分区表的缺点： DDL操作需要锁定所有分区，导致所有分区上操作都被阻塞。 当表数据量较大时，对分区表进行DDL或其他运维操作难度大风险高。 分区表使用较少，存在未知风险。 当单台 服务器 性能无法满足时，对分区表进行分拆的成本较高。

查看更多 →

视图和关联表设计 视图设计 除非视图之间存在强依赖关系，否则不建议视图嵌套。 视图定义中尽量避免排序操作。 关联表设计 表之间的关联字段应该尽量少。 关联字段的数据类型应该保持一致。 关联字段在命名上，应该可以明显体现出关联关系。例如，采用同样名称来命名。 父主题： 数据库对象设计

查看更多 →

流式计算采用MOR表。 流式计算为低时延的实时计算，需要高性能的流式读写能力，在Hudi表中存在的MOR和COW两种模型中，MOR表的流式读写性能相对较好，因此在流式计算场景下采用MOR表模型。关于MOR表在读写性能的对比关系如下： 对比维度 MOR表 COW表 流式写 高 低 流式读

查看更多 →

ClickHouse宽表设计原则 宽表设计原则 由于ClickHouse的宽表查询性能较优，且当前ClickHouse可支持上万列的宽表横向扩展。 在大部分场景下，有大表两表join以及多表join的场景，且多个join的表数据变化更新频率较低，这种情况，建议对多个表join查询逻辑提

查看更多 →

ClickHouse本地表设计 规则 单表（分布式表）的记录数不要超过万亿，对于万亿以上表的查询，性能较差，且集群维护难度变大。单表（本地表）不超过百亿。 表的设计都要考虑到数据的生命周期管理，需要进行TTL表属性设置或定期老化清理表分区数据。 单表的字段建议不要超过5000列。

查看更多 →