预计算的时代该结束了

原文链接：http://localhost:8080/blog/precomputation-should-be-over

1. 预计算模式​

预计算即预先按指定维度或规则聚合度量值，减少实际计算的数据行数，使得数据使用者可以高效的获得数据报告，降低计算引擎的计算成本，从而提升数据分析体验。 从数据开发的视角出发，预计算可以将复杂问题拆解成多个阶段，每个阶段依赖上一阶段的输出结果，再按新的聚合方式存储数据，从而降低数据开发的复杂度。 预计算模式是按程序设计的模式中的分层设计衍生而来，每个阶段产生的中间结果具备一定的抽象性，可以同时满足多个不同的数据报告或不同数据需求部门的需求。

预计算模式存在的历史较长，其存在主要原因如下：

1. 计算引擎计算效率低下，大规模数据量分析早期的代表计算引擎包括：Hadoop 生态圈和单线程计算引擎 MySQL 和 PostgreSQL，这类计算引擎的计算能力无法满足大规模数据量的计算。 超过百万行数据的关联计算，已经无法正常输出结果。预计算模式可以有效降低数据行数，使复杂统计可以正常输出。

2. SQL 缺少编程属性（无法抽象、重用），使得数据工程师实现复杂分析变得极为困难，开发成本和维护成本极高，工程化实施变得遥不可及。在这样的背景下， 预计算是最佳的方案，使得复杂数据分析得以实现。在这段期间内诞生了很多设计理论和概念，例如：分库分表、CUBE 模型、大宽表等等。

3. 并发访问也是其存在的关键因素，预计算是以空间换时间的一种模式，当单个查询的效率得以提升时，系统同时支持的并发量随之增加，从而提升了整个系统的可用性。

预计模式存在哪些缺点有哪些呢？

1. 增加数据延时：预计算的中间结果由一连串的异步任务生成，数据时延的长短由计算任务的复杂度和计算引擎的计算效率决定。同时新的数据分析需求， 无法实时响应。

2. 丧失灵活性：预计算的模式是基于有限的维度预先聚合数据，这样会导致前期需要花较长时间设计维度。当领域切换时，数据工程师需要花大量时间研究领域规则， 设计预计算维度。

预计模式还有一些缺陷，例如：底层数据发生变更或错误时，需要一层一层更新中间数据，多个报表统计的相同指标不一致等等，我认为这些问题都不是主要矛盾， 通过程序设计方法都可以解决，而上述两个缺陷是预计算模式先天的缺陷，无法根治的缺陷。

2. 技术的变革带来的变化​

技术的变化总会超出我们的想象，同样也有一些人无法理解，依然停留在旧的时代。MPP 型开源数据库以 2016 年的 Clickhouse 为代表，推动了整个行业的发展， 国内的 MPP 型开源数据库以 StarRocks、Databend 为典型代表，使得亿级数据量的单表计算时间到毫秒级别，百万级多表关联计算也能做到 1 秒以内。 只是内存和 CPU 的利用率过高，是一种以硬件换效率的模式，与预计算模式的以空间换时间属于同类型方案，只是在不同场景下权衡利弊后，会有不同的选择方案。 我个人更倾向于以硬件换效率的模式，因为人工是最贵的开销。

计算引擎的计算效率的提升了，但很多企业和 BI 产品依然保持着预计算的模式，虽然底层的计算引擎替换成 MPP 型数据，数据延时有了一定程度的提升， 但依然无法解决先天的缺陷，其最主要的障碍是无法降低 SQL 的复杂度，过度复杂的 SQL 不仅开发成本高，维护成本更高，当数据工程师更换时，问题更加明显。

Agile Query 正是在这样的大背景下诞生的。以一种更便捷的语言替代复杂的 SQL，将复杂的报表分解为单个指标或维度，使得数据分析师聚焦于单个指标， 而不用关系该指标与维度组合方式，所有底层的技术系统均由 Agile Query 的 SQL 编译器完成，SQL 编译器不仅仅理解单个指标，而且会结合多个指标和维度组合的上下文， 生成最合理的查询。

3. 分析实践​

下面我们以一个复杂场景为示例，详细阐述一下预计算场景和 Agile Query 场景下不同的实现方法和逻辑，具体的分析示例如下图所示：

客户分类： 是基于客户最近六个月的订单数量进行分析，订单数据小 5 为低价值客户，5-10 为一般价值客户，1--15 为中等价值客户，更高数据为高级客户

订单日期： 是基于订单时间聚合为月份

销售额： 是销售量与单价积的汇总值

销售额月增长率： 是每个客户分类、每个月份的销售额增长情况

在预计算的场景下，系统需要基于客户分类的规则，为每个客户生成分类标签，再汇总每个客户的销售额，最终再写一段简单的 SQL，实现上述统计报表， 当客户的分类规划发生变化时，需要重新生成客户的分类标签。实际的分析场景中，除了基础的分析维度，还有很多维度是基于聚合值产生的分类，有些基于客户， 有些基于商品。

在 Agile Query 中，只需要以下两个公式：

上述两个公式，清晰的描述了分析规则和月增长率的计算方法，当客户分类规则发生变化时，只需要修改公式即可，不需要刷新数据。

4. 总结​

总有人会不断质疑复杂 SQL 的执行效率，其实是他们的思维依然停留在单线程计算的数据库时代，或者惧怕复杂的 SQL，试问一下，企业内数据量超过亿级的公司能有多少？ 当单表最大行数才几百万行时，还采用预计算模式进行分析，是因为计算效率太低？，还是惧怕复杂的 SQL？

Agile Query 完全兼容预计算，可以像使用普通表一样使用，当数据规模巨大，在满足分析需求的情况下适当进行预计算也是合理的，只不过在 Agile Query 的场景下， 预计算表的数量会非常少，因为不需要为了完成复杂查询或特定的分析场景而构建预计算表。