预计算的时代该结束了

[Braisdom]

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

[token10086]

兄弟你这个地址秀我一脸。。。。

[4u1kto]

看来预计算的时代真该结束了

[qk3z]

兄弟，趁别人没看到，赶紧换个地址

[Braisdom]

@token10086 抱歉，修改好了。实在没留意，文章刚刚写好。

[Braisdom]

统一感谢一下。。。。

[lexa]

kyligence 估计要急了哦。

[JavaGo]

你这是要推翻世界的节奏呀...

[hanhugh]

看上去不错，关于数据透视表目前我们是才用写代码的方式来生成交叉维度报表，后面准备换成 flink 单机运行，使用标准的 map 、flatmap 、reduce 、groupby 等算子来完成。
预计算，数据量大肯定是需要的。

[hanhugh]

有很多大数据引擎，特别是时序相关的引擎，都想使用自己设计的 dsl 来替换掉 sql ，但好像都不是很理想

[Braisdom]

@hanhugh 非常同意你的看法，自己设计的 DSL 短期内很难产生影响力，毕竟 SQL 已经出现近 40 年了，已经根深蒂固了，只能通过间接的方法实现，除非有越级大的公司做背书。

Google 提的 NoSQL 目前只能在部分领域适用，关系运算还是以 SQL 为主，估计还得需要类似 OpenAI 形式的创新，来改写历史。

[dayeye2006199]

我记得前几年有个 kylin 的框架非常流行，就是预先按维度聚合之后再提供查询

[Braisdom]

@dayeye2006199 kylin 是预计算最典型的产品，

[Alias4ck]

@Braisdom openai 形式的我知道有一个产品 在外网很火 https://github.com/mindsdb/mindsdb

[Braisdom]

@Alias4ck 我和这个项目不是同一类项目，后面再写个文章介绍一下 chatgpt 和实际的数据分析之间的距离。

[beneo]

说真的，别再吹了。Agile Query 本质上只是 BI 里面的 SQL 组装工具。

如今的 BI 系统，普遍通过数据集、分组字段、自定义计算字段等方式，结合可视化维度和度量的拖拽操作，来生成 SQL 语句。
而 Agile Query ，它仅仅是创建了一个 DSL 用来生成 SQL 。

这两种方法，无论是图形化界面生成 SQL ，还是你的 Agile Query ，其本质都在于简化查询过程。但最终，这些查询还是需要转换成 SQL ，由底层数据库执行。无论查询语言或工具有多高效，它们的数据处理和计算能力终究受限于底层数据库的性能。即便是高级的查询工具，也不能超越它们所依赖的数据库的基本性能限制。比如，最近有人在讨论 MySQL 单表一亿条数据的聚合查询，即使使用了 Agile Query ，也无法达到 Clickhouse 那样的效果。

此外，你提到的“预计算时代的结束”这一趋势，确实存在这样的方向。但是，别人的解决方案通常是采用像 Apache Doris 或 StarRocks 这样的 DB 。他们是引入更牛逼的 DB 啊，而不是引入一个“语法糖”。你怎么能把别人的能力当成你的 feature ，然后做一个广告呢 ？

最后，我真的好奇你家庭如何支撑你这样创业，或者有怎样的金主来支撑起你的事业。你这个东西搞了好几年了，V 站上面也宣传了小一年了，从承诺开源到不开源，从承诺 docker 镜像开放到现在没谱，从一直否认 Agile Query 不是 BI ，到现在就是 BI （的一个小边角）。次次都在转弯。

所以，你到底要做个什么东西？你面相的用户到底是谁？

[Braisdom]

@beneo 兄弟本质上是一个 DSL 生成 SQL ，关键是如何生成的 SQL ，
生成的 SQL 能不能进行 "RFM 分析"、"同环比分析"、"客户画像"等，

如果兄弟开发出通过拖拽实现上述分析，我需要向兄弟你好好学习一下，有机会一定去拜访。

[lexa]

@beneo 大佬，我们用 superset 做 BI ，最复杂的就是各 SQL 了，虽然有模板，但维护起来还是很痛苦呀，楼主的产品如果能解决 SQL 编写这块，已经解决 BI 中最主要的矛盾了。

[beneo]

@Braisdom FineBI ，PowerBI 没有么?
@lexa 本质上你公司就是想白嫖，开源的用的不爽，想嫖 B 兄弟的，QuickBI 不香吗？

[Braisdom]

@beneo Agile Query 只需要一个函数就可以实现，

SEGMENT(
CASE
WHEN MONTH_DIFF(NOW(), MAX(orders.order_date)) < 2
AND SUM(order_details.quantity * order_details.unit_price) > 1000
AND COUNT(orders.order_id) > 10 THEN '高价值客户'
WHEN DAY_DIFF(NOW(), MAX(orders.order_date)) < 50
AND SUM(order_details.quantity * order_details.unit_price) > 100 THEN '重要发展客户'
WHEN MONTH_DIFF(NOW(), MAX(orders.order_date)) > 4
AND SUM(order_details.quantity * order_details.unit_price) > 400 THEN '重要挽留客户'
ELSE '其它'
END,
customers.customer_id,
orders.order_date = LAST_YEARS(1)
)

FineBI 的： https://help.fanruan.com/finebi/doc-view-703.html

PowerBI 的： https://zhuanlan.zhihu.com/p/220408371

Agile Query 本质上和 PowerBI 比较接近，FineBI 的就差太远了。

[Braisdom]

@beneo 上面的确是一种 DSL ，只不过这类 DSL 更接近领域问题，使用起来更加方便。

建议去看一下： https://www.agiquery.com/blog/rfm/

[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 ，简化数据分析，减少对预计算的依赖，这是蛮重要的观点。

[Braisdom]

@pp3182429 理解非常到位，场景包装只是最简单的一部分，最核心的是 查询合并，查询重用，过度计算分解。

[Braisdom]

@szdosar 预计算目前是最优的方案，大部分公司都是这样的方案，文章的目的是终结预计算模式。

[bclerdx]

@Braisdom 那么，什么是创新？

[Braisdom]

@bclerdx 创新的核心是一种 "高级分析型语言"

[lexa]

@Braisdom 这块有开源的参考吗？查询合并，查询重用，过度计算分解

[tikazyq]

Agile Query 会开源么？如果能做成像 Apache Superset 那样的项目很多公司使用就会有更多机会进行产品优化了。据我所在的行业来看，微软体系下的 PowerBI 是首选。

[Braisdom]

@tikazyq 是的 PowerBI 目前是复杂分析的首选，但使用复杂度也比较高，而且是自有的计算引擎，开源的 superset 类的 BI 的开发成本还是有点高的，使用的，大都数还是技术型公司，像国内的帆软，永洪存在的问题就更多了。

Agile Query 是处于中间位置，既能解决 PowerBI 的问题，同样能解决 superset, redash, metabase 的问题。这是我们的定位。

[lexa]

@Braisdom 楼群主想的比较全面，希望写更多文章，想学习一下。

[zuston]

其实，更进一步，直接 text -> SQL 或者 AI 直接自动探查数据价值？粗粗理解下，感觉目前这个 dsl 处于不上不下的阶段

[tikazyq]

@Braisdom 说实话，目前从 demo 视频上来看，很 superset 没有什么本质的区别，也离 PowerBI 有很大差距，不管是从可视化和 ETL 方面来说。但毕竟是个人开发的，因此功能迭代肯定不会像微软、Tableau 之类的那么快。建议还是尽可能开源出来，结合社区的力量打造产品。Superset 这样的开源产品缺点非常多，我也希望能有一个更强大的 BI 开源项目出来

[Braisdom]

@zuston DSL 应该的文本与 SQL 之间的语言，想通过自然语言描述统计规则还是很难的，有很多复杂的统计只能通过标记语言定义。

[Braisdom]

@tikazyq 和 superset 的区别很大，至少不需要写 SQL 就可以实现复杂统计，和 PowerBI 肯定有距离，我们还在努力。

[bzzhou]

哥们，我看了一下，认为可能还是有点闭门造车了。

首先，数据分析师如果不会 SQL 的，那么基本上也不用指望会学会你的 DSL （而且你认为你的 DSL 简单，是因为你自己设计出来的；但是一个完全没看到你的 DSL 的，他可能宁愿去学 SQL ）。

其次，如果你要定义一个全新的分析师语言，只能说这个难度很大（至少对于创业团队来说）。而且我觉得有这个需求的分析师，可能用 Python + Pandas + SQL 会是一个更好的组合。

建议这个阶段，可以找一些种子用户，看看他们愿意去学+使用不，多听听他们的反馈。

[Braisdom]

@tikazyq 目前有好多商业公司在做这块，也都在想办法攻克核心算法，暂时不打算开源。先跑一段时间再说。

[Braisdom]

@bzzhou 如果数据分析师会用 Excel 的函数，就可以了，我们的函数和 Excel 一样。

[tikazyq]

@Braisdom 你这个有 demo 网站可以访问么？

[Braisdom]

@bzzhou 只不过 Excel 的函数大都是单表分析，多表分析还是比较复杂的。

[bzzhou]

@Braisdom 我的建议还是最好找几个种子用户，看看他们愿意学+使用不。如果 10 个人里面，有 1~2 个用起来了，那么恭喜；否则听听他们的反馈。

[sampeng]

我觉得做技术不能光做技术。还是要考虑点别的。

横竖你是不考虑成本的，但这通常又是选型中的重点。

就我自己身边的统计学来看，如果只是集中怎么查。怎么说呢。起步做大数据分析的时候考虑，但是不重要，只要满足 MVP 功能要求，这个事就算起步了，kpi 就算完成了，前端只要有时间随时可以换。在选型过程中反而最怕选这类没什么公司用过的。后面数据多了，就跳进去出不来了。学习成本是最大的成本，这是在很多做决策的人都明白的道理。这也是为什么最近出现的产品绝大部分是即支持自己的 DSL 又支持 SQL 。这是学习成本的一方面，另一方面，计算引擎和算法确实是核心，但是使用者不关心，作为大数据平台还关心一点：我能不能把这玩意很方便接入到别的平台上去。
metabase ，superset 这类就选起来没什么压力，不好用换一个就是了，想两套展示，一套研发自己看，一套给领导看。数据展示平台直接支持 sql 接入，轻轻松松，没工作压力。来个 dsl ？你要说服决策者会有很大的阻力。

对于决策选型的人来说，不会考虑实现细节。就几点：
1.能不能满足数据分析需求
2.成本多少。和别的技术比起来成本差异怎么样。成本包含计算成本，存储成本，人力成本和学习成本。
3.扩展性，n 年后，有新的技术出现，现在这个选型会不会成为阻碍。

OP 的产品只回答了第一个问题。

预计算成本在大数据+云平台的情况下成本只有存储成本。极其低廉。
绝大多数数据，早上跑个把小时，所有计算资源就可以释放了。只有少量的数据需要实时分析，这是实时分析的舞台。因为在这个博客里面有这么一句：“人工是最贵的开销。”。这句话我以前是信的，当然，现在用来推脱一些不想做的事也会说这句话。但这句话对于 99%国内公司不成立，人工反而是最便宜的开销。如果你现在就是 CEO 。。。你做几年老板就知道了。

[sampeng]

PS 一句。。刚顺手按回复了。

你这个无非就是一个 sql 的语法糖。那么问题来了，这个和预计算有啥必要的关系吗？？硬联系在一起？

[Magentaize]

Agile Query 完全不需要数据预计算

不一定，针对超大数据量，或者过度个性化的分析，建议通过物化视图的方式预先处理数据，Agile Query 依然可以集成。

[Braisdom]

@sampeng DSL 不是核心，算法是核心

[Braisdom]

@sampeng 你只提到了预计算的优点，还要看到缺点。

[lexa]

@Braisdom 哪些算法呀？

[Braisdom]

写在 BP 里的：

• 过度计算识别算法
• 编译器相关算法
• 数据分析意图识别算法

[lexa]

@Braisdom 有解释不，理解起来有困难啊

[Braisdom]

@lexa 后面写文档说明一下，可能会晚些时候

[JavaGo]

@Braisdom 期待中...

[encro]

坐等 PG 物理视图出来

[iugo]

君子爱财, 取之有道.

@lexa 现在是没有做评论隐私保护的, 可以看到 @lexa 现在的所有评论都是在 "捧" Agile Query, 而没有参加任何社区的其他讨论. 因此, 我认为 @lexa 是一名水军或小号.

我认为这是一种错误的营销方式.

[Braisdom]

@iugo 被你发现了，是我之前公司的同事，

[meeop]

看起来只是提供了一些语法糖包装 sql,底层还是普通 sql?

那和标题的预计算有什么关系,并没有预聚合任何数据啊

[Braisdom]

@meeop 预计算的优点之一是降低 SQL 的复杂度，用了 Agile Query 就不用考虑 SQL 的复杂度了。

[SingeeKing]

只有我更好奇原来的地址是什么吗

[KevinShiCN]

@Braisdom
我是从别的帖子看到你的项目，点进来看了你的网站和一些回复
就拿 RFM 分析来说
我通过 FineBI 的这个纯界面的方式也能快速实现 RFM 分析
https://help.fanruan.com/finebi/doc-view-703.html

截止到目前我并没有看到 Agile Query 比 FineBI 更先进的地方
既没有帮我更智能的清理数据、也没有更高效的产品体验

希望可以帮助我（以及其他用户）梳理一下这方面的差异

[Braisdom]

@KevinShiCN 可能你没用 FineBI 做过 RFM 分析吧，如果是多张表的时候，用户表，订单表，订单明细表的时候，用 FineBI 怎么快速做呢。

[Braisdom]

@KevinShiCN 还有 RFM 只输出一个分类，如果再增加近 30 天的订单数量 ，销售情况，购买其它商品的销售情况，FineBI 又是怎么做的呢。