报表工具常见数据加速方式

在BI和报表工具中有个永恒的话题，就是查询速度怎么做到最快最丝滑，而不是转圈等半天数据才出来。

针对这个问题，业界主要有两大类方向，一类是有条件的场景，在数据库和报表工具之间有一个加速层或缓冲层，比如Hive+Impala的成熟方案中利用Impala做加速查询，或者基于presto也可以，还有利用DuckDB来做加速缓冲等。

本文重点是针对第二类一些传统场景，尤其是只能对接关系型数据库的场景，主要就是通过对数据做预处理来提高查询速度，业界工具中一般有以下几种方式，供大家伙参考。

数据聚合加速

如图，其核心就是针对数据汇总统计查询慢的场景，在数据集配置时就根据数据集中定义的分组维度和指标等信息，自动产生相应的ETL任务进行汇总统计，生成相应的聚合表，然后用户在数据集的基础上定义的报表，查询时就会有一个动态路由能力，如果查询条件能命中某种分组聚合维度，则查询引擎自动从相应聚合表中查询数据，以提高查询速度，如果没有命中，则根据数据集口径，查询原始明细表。

数据物化加速

这种方式主要是针对多表关联查询慢的场景，和前面聚合加速一样，它也是通过在数据集定义阶段，就自动产生相应的ETL任务进行数据关联加工，生成一张宽表，后续基于该数据集定义的报表，查询时就全部从物化后的宽表进行查询。

这种方式除了用于提高关联查询速度，还有个作用就是“物化”，也就是数据快照的概念，让报表查询时查到的是物化后的快照数据，这个模式适用的场景，主要是报表定义者需要让领导或客户看到的报表，是完全符合“预期”的确定性结果，而不是数据库中动态变化的数据。

在数据集定义过程，可以要求一次性生成快照数据，也可以要求定期更新这份快照数据，对应就是针对自动产生的ETL任务设置执行频率。

数据体外加工

这种方式和前面两种方式的不同，核心就在于数据加工逻辑不是根据数据集配置自动产生的，而是要提前在数据层面，通过单独的ETL工具去配置完成的。在报表工具中如果数据集A指向的是加工表，则基于A定义的所有报表，查询时就从加工表中查询，如果数据集B指向的是原始表，则基于B定义的所有报表，查询时就从原始表中查询，两者之间没有任何关联。

这种模式适用于预加工逻辑复杂的场景，并且有相对专业的数据开发工程师去处理。

这三种模式不是非此即彼的，而是可以共存的，业界做得比较好的报表工具基本也都是兼容这三种方式，如果有同学也有打造报表工具的诉求，就可以参考，这样用户使用时就可以根据实际业务场景需要，灵活选择某种方式来提高查询速度。

—End—

文章源载：微信公众号“木昆子记录”，欢迎关注（注本文部分配图源自Garvey，特此感谢ing）