很好的尝试，最近我在写 SQL 的编译器，大家都在往更底层技术的创新，很棒的想法...

@loading 我们正在基于 Facebook 的 LLaMA 做自己的服务，就不用担心那玩意了。哈哈

@yinyuncan6 可视化这块正在完善，应该很快就能发布了。

@yinyuncan6 SQL 型数据库都可以完美的支持。接入只需要一天时间

@leeg810312 再补充一点，Agile Query 的优势本质上是和 MPP 的发展紧密相关的，MPP 型数据库发展的越好，理论上 Agile Query 也会更好。

因为 MPP 的计算效率越高，那么整个数据系统的结构就会越简单，像 Spark 那样通过代码进行离线计算的存在性就会越低，那么 SQL 的复杂度也就越高。

Agile Query 内部设计的 FlatQL 的作用也就越明显，因为它对外屏蔽了 JOIN, SUBQUERY ，更重要的是它会智能的优化过度计算(over-counting) 的问题，也就是 JOIN 后的表进行 count, sum 时数据重复计算的问题。

@leeg810312 不好意思有一点，是我理解错了。

您的观点是通过 SQL 去计算的效率，还是不如自已写程序计算（例如：Spark/Flink ）的效率高。

复杂 SQL 是更难写呢？还是更难优化呢？这是两个不同的概念，SQL 优化本身有自身的规则，不同的 SQL 引擎会有一些区别，但本质上还是有规律的。

@leeg810312 还有一点补充一下：

1 ）快速响应需求变化在传统 BI 中有两种方法：1 ）设计中间表，成本非常昂贵，基本以周为单位，2 ）在 BI 中增加复杂 SQL ，基本以天为单位。但在 Agile Query 中，是以秒为单位的，已经将成本降至最低了，代价也已经是最低的了。

@leeg810312
您的回答非常专业，我分别回答一下：

1 ）根据查询的数据设计中间表：Agile Query 屏蔽的是为了简化查询而设计的中间表，如果纯粹的基于海量数据的优化，我们无法避免。

2 ）物化视图：它本身不是为了节约性能，更重要的是降低开发成本。

3 ） SQL：Agile Query 会依据不同的 SQL 执行引擎进行特殊的优化，理论上人能够优化的 SQL ，Agile Query 都可能设计规则进行优化。


Agile Query 内的所有维度和指标可以进行自由的组合，不需要做任何其它工作，单纯这块就可以提升需求响应速度很多倍，传统 BI 中，不同维度的组合都需要设计中间表，如果纯粹写 SQL ，也是非常复杂的。

如果您有兴趣，我可以给你在线演示一下系统，您也可以在线挑战。

@leeg810312

Agile Query 主要解决的是复杂 SQL 编程的问题，让数据系统不需要针对业务场景进行复杂的抽象过程，不再出现，同样计算公式计算的结果按不同维度存储在不同的表中，减少数据不一致产生的问题。

提升数据系统能够快速响应需求变化的能力

@leeg810312
首先，您说的我部分同意，分层设计是为了解决海量数据计算和 SQL 复杂度，这两点都是 BI 比较痛的点。

目前复杂 SQL 可以通过 Agile Query 来实现，优化工作来就是 Agile Query 算法要解决的核心问题之一，会一直持续下。当然有了 Agile Query 也不能完全不做分层，针对海量数据，可以通过物化视图的方法实现，但相比传统所谓的数据集市要抽象得多，不需要基于场景去设计数据。当然也不需要额外的计算层去处理，也不会需要 Spark 这种低效率的计算工具。

难道这不是一种进步吗？

@leeg810312

首先，ODS ，DW ，ADS ，宽表，数据血缘，数据集市等， 这些概念本身就是受限技术才衍生出来，本来就不应该存在。

抽象出各种层次的封装就是为了降低 SQL 的复杂度，因为写好复杂 SQL 的人太少了，维护成本极高。

现在数据的计算性能已经非常高了，为什么还要做那些层次的抽象，复杂的 SQL 也不需要写了，这难道不香吗？

@Chad0000 是的，如果把所有复杂场景整理清楚，基本上编译器也设计出来了，

编译过程只需要 1 毫秒不到，用 GPT-4 不知道要多长时间了。一个查询可能也只要几秒钟

@Chad0000 我们 2018 年的时候就研究通过机器学习生成 SQL ，但过于复杂的 SQL ，AI 搞起来还是非常有限的，编译规则过度复杂。

@stardustree 我们有一系列的高级分析函数支持各种复杂分析。

@stardustree 这些是比较基础的分析，完全支持，还有更多更复杂的分析。有兴趣的话，可以加我微信，我给你演示一下。

@move 可以的

@qingfengxulai1 跨库问题，可以通过 Presto 解决。Agile Query 只能解决 SQL 编译这块，SQL 执行引擎，有很多成熟的方案。

@shuxge1223 你是指 Excel 导入。还是集成到一个 Web Excel 里？

具体要分场景看，目前国内数据库发展的非常快，行业要发展，必须往底层走，不然总是被人牵着鼻子走。

目前我验证过的：华为的 Opengauss, 阿里的 PolarDB-for-PostgreSQL ，腾讯的 TBase 都还有错的，还有各大云平台的数据也都可以。分析型数据库 百度开源的 Apache Doris 就更秒杀一了。我前面就是用 Doris 测试的，几亿数据量的 join 都是秒级出来的。