预计算的时代该结束了

[Braisdom]

原文链接： https://www.agiquery.com/blog/precomputation-should-be-over

[Braisdom]

@beneo 这个函数生成的 SQL 比较复杂，纯粹的在 superset 里写这样的 SQL 还是有难度的。
@lexa

[lexa]

@Braisdom sum 和 count 可以这么使用吗？

[lexa]

@Braisdom 这个函数生成的 SQL 是什么样的呀？

[Braisdom]

@lexa 这个 SQL 比较复杂

[lexa]

@Braisdom 牛 B 呀。

[lexa]

@beneo 老兄对楼主的反馈怎么没反应了，喜欢看热闹，哈哈。

[dexterzzz]

闭门造车.
预计算在 2010 年以后就被淘汰了,使用内存数据库+列存储.SQL Server Analysis Services Tabular/Power BI,SAP HANA.
要说最新的计算方向去了解下 Power BI Direct Lake,基于 Delta 文件的内存分析.
SQL 方向 DSL,这些在 BI 领域从 90 年代就开始就有成熟的方案和实践,无论是已经淘汰的 MDX 还是最领先的 DAX.
了解下企业领域的跨层级计算如最典型的财务预算的多管道预算分析,Total <> 汇总

[Braisdom]

@dexterzzz 兄弟的回复比较全面，有些信息我的确不知道需要仔细研究了，
既然 DSL 是个成熟的方案，为什么像 FineBI 还是预计算的形式进行数据开发，

你说的那些 DSL 是否能解决多表关联时引发的过度计算，是否需要数据工程手工去处理。

本质上 Agile Query 的 DSL 不是新语法，只不过是为了自动关联表，并且自动处理过度计算而已。

[Braisdom]

@dexterzzz 再说，内存计算，也还是无法回避过度计算的问题，如果不能自动解决过度，Agile Query 还是有一定的生存空间的。

[swim2sun]

AgiQuery 面向的用户是开发者，还是不懂编程的业务人员？

业务人员不会去用 DSL ，因为对他们有学习成本，他们只想要最终的报表。

开发人员也不会去用 DSL ，SQL 能解决的问题为什么要引入另一套系统。
而且最终还是得编译成 SQL 的话为什么不直接用 SQL 。
业务太复杂？让 chatgpt 帮你写。
chatgpt 能生成 SQL ，而且写的大概率比开发人员写的都好。但 gpt 没法生成你发明的 AgiQuery ，也许经过 few shot 或 fine-turning 后能够生成，但肯定写的不如 SQL 好。

另外问下，那么多 SQL 方言 AgiQuery 都支持哪些？这可是大工程啊

[Braisdom]

@swim2sun
1 ） SQL 方言在 Agile Query 是极小的工程，目前支持 PostgreSQL, Starrocks, BigQuery, DuckDB, Databend ，
基本上两天实现一个新的 SQL 方言。

2 ） Agile Query 的函数的难易程度接近 Excel 的函数，面向的是非技术人员。

[JavaGo]

@Braisdom 支持阿里云的 ADB 吗？

[Braisdom]

@JavaGo 如果需要，可以很快支持

[1018ji]

我还是 SQL 吧

啥时候把 SQL 替换了我在用

[Braisdom]

@1018ji 是的，我们的目标是替换分析型查询 SQL 。

[AlohaV2]

不是很了解目标群体是谁...感觉大多数想替代 SQL 的东西最后都会写成 SQL 。
如果需要灵活性，用 python 之流（ pandas, arrow, xarray, ...)岂不是更灵活，现在 CPU MEM 比前几年便宜多了，贵的是成规模的 GPU 资源。

[Braisdom]

@AlohaV2 我们是用 SQL 替代 SQL

[Braisdom]

@AlohaV2 再说，pandas, arrow 从来没宣称过要替代 SQL ，他们本质上和 SQL 一样。

[pp3182429]

sql 是可以编程的，解析成抽象语法树就行了。你做了个语法表达类似 sql 的语义，甚至把 sql 里解决分桶问题的 case when 语法也留下了。

sql 已经是能清晰表达 query 语义非常简单的通用表达了，其它变化都是特定场景的包装而已。

[szdosar]

为何不把结论前置呢？
我要是没看错的话，文章最后，提出了 Agile Query 作为一种解决方案，提供了更便捷的语言来替代复杂的 SQL ，简化数据分析，减少对预计算的依赖，这是蛮重要的观点。