OLAP Cube维度处理耗时超7小时的优化方案及相关问题咨询

问题1：是否有其他方案可进一步提升维度处理效率？ #

• 优先启用维度增量处理：避免每次执行全量维度处理，给所有维度源表新增last_updated时间戳字段，每次处理仅拉取该字段值大于上一次处理时间的变更记录，对于极少变更的维度可设置为周/月级低频处理，能直接砍掉绝大多数全量扫描开销。
• 拆分20属性的大维度：如果该维度的属性存在更新频率差异，比如基础属性（名称、ID）半年才变更一次，动态属性（状态、标签）每日更新，将二者拆分为两个独立维度，低频维度无需参与每日处理，可大幅降低日常处理的计算量。
• 优化属性存储类型：如果维度属性是低基数枚举值（比如性别、状态），提前在ETL阶段做整数编码映射，替换原有的字符串类型存储，降低维度处理时的哈希计算、排序开销。
• 关闭非必要的属性配置：如果维度属性不需要做层级聚合、排序、去重查询，可在Cube配置中关闭该属性的AttributeHierarchyEnabled选项，减少处理时的索引构建开销。

问题2：存在多个采用两列联合键、仅附带1-2个属性且无层级的维度，属于合理最佳实践还是会负面影响性能？ #

这类设计如果是业务逻辑必须的，不属于错误实现，但会带来额外的性能开销，不属于最佳实践：

• 两列联合键会让维度处理时的键匹配、哈希计算、排序开销至少是单列整数键的2倍以上，如果联合键包含字符串类型字段，开销还会进一步升高。
• 优化方案：在ETL阶段为这类维度提前生成单列整数类型的代理键，Cube处理时仅用代理键做关联，两列业务键仅作为普通维度属性存储即可，该优化通常能带来30%以上的性能提升。
• 如果这类小维度的属性不会频繁变更，可以直接将属性退化到事实表中，完全省去小维度的处理开销。

问题3：是否支持对维度进行分区操作？ #

主流OLAP服务（SSAS、Doris、ClickHouse等）均支持维度分区，但收益需结合场景判断：

• 维度分区规则建议和事实表的分区规则对齐，比如按时间、区域字段做分区，处理时可以仅处理对应分区的维度，避免全量扫描。
• 小于100万条的小维度不建议做分区，分区带来的元数据管理开销会超过性能收益，仅你的20属性大维度适合做分区处理。
• 不要对两列联合键的小维度做分区，反而会额外增加处理耗时。

内容的提问来源于stack exchange，提问作者Tweene