结构相同的两个OLAP Cube结果能否合并及数据分区相关问题

两个同结构OLAP Cube的合并实现 #

• 完全可以实现两个结构完全一致的OLAP Cube查询结果合并，主流OLAP引擎（包括Apache Kylin、Druid、ClickHouse等）均原生支持相关能力，无需额外定制开发。
• 常见的合并实现方式有两种：
  • 查询层路由合并：在BI工具、查询代理层配置多Cube同路由规则，相同维度、度量的查询请求会同时下发给两个Cube，底层自动对返回结果做Sum、Count、Max等对应规则的聚合，对上层查询用户完全透明，无需修改原有查询语句。
  • 元数据层逻辑合并：部分引擎支持将多个同结构Cube注册为同一个逻辑Cube的不同存储分片，底层直接将两个Cube的存储识别为同一数据集的不同组成部分，查询时自动拉取所有分片的结果完成合并，性能比查询层合并更高。
• 合并前置要求：两个Cube的维度定义、度量聚合规则、时间统计口径必须完全一致，避免出现结果聚合偏差。

数据分区方案的运行逻辑与增量处理可行性 #

• 数据分区是比多Cube合并更适合你的场景的优化方案，完全可以实现仅处理新增数据，无需每次全量重跑3000万条以上的全量数据。
• 分区方案核心运行逻辑：
  • 选择时间字段作为分区键，将整个Cube的存储划分为多个相互独立的分区，每个分区对应固定时间范围的数据，比如可以将8年不变的冷历史数据划分为按年分区，新增的每日数据划分为按日分区。
  • 每个分区的构建、更新、删除操作完全独立，互不影响，新增数据仅需要构建对应日期的单个分区即可，不需要修改或重跑历史分区的已有数据。
  • 查询时引擎会根据查询条件中的时间范围自动扫描对应分区，不会扫描无关的历史数据，查询性能也会比单一全量Cube有明显提升。
• 性能收益参考：替换全量构建为分区增量构建后，每次仅需要处理当日的十万到百万级新增数据，构建耗时通常可以从数小时降低到数分钟，存储资源占用也会有30%左右的下降，同时维护成本远低于多Cube合并方案。

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