这是一个创建于 332 天前的主题，其中的信息可能已经有所发展或是发生改变。
 |
1
token10086 332 天前  1
兄弟你这个地址秀我一脸。。。。
|
 |
2
4u1kto 332 天前 1
看来预计算的时代真该结束了
|
 |
3
qk3z 332 天前 1
兄弟，趁别人没看到，赶紧换个地址
|
 |
4
Braisdom OP @token10086 抱歉，修改好了。实在没留意，文章刚刚写好。
|
|
5
Braisdom OP 统一感谢一下。。。。
|
 |
6
lexa 332 天前
kyligence 估计要急了哦。
|
 |
7
JavaGo 332 天前
你这是要推翻世界的节奏呀...
|
 |
8
hanhugh 332 天前 1
看上去不错，关于数据透视表目前我们是才用写代码的方式来生成交叉维度报表，后面准备换成 flink 单机运行，使用标准的 map 、flatmap 、reduce 、groupby 等算子来完成。
预计算，数据量大肯定是需要的。 |
|
9
hanhugh 332 天前
有很多大数据引擎，特别是时序相关的引擎，都想使用自己设计的 dsl 来替换掉 sql ，但好像都不是很理想
|
|
10
Braisdom OP 2
@hanhugh 非常同意你的看法，自己设计的 DSL 短期内很难产生影响力，毕竟 SQL 已经出现近 40 年了，已经根深蒂固了，只能通过间接的方法实现，除非有越级大的公司做背书。
Google 提的 NoSQL 目前只能在部分领域适用，关系运算还是以 SQL 为主，估计还得需要类似 OpenAI 形式的创新，来改写历史。 |
 |
11
dayeye2006199 332 天前
我记得前几年有个 kylin 的框架非常流行，就是预先按维度聚合之后再提供查询
|
|
12
Braisdom OP @dayeye2006199 kylin 是预计算最典型的产品，
|
 |
13
Alias4ck 332 天前
@Braisdom openai 形式的我知道有一个产品 在外网很火 https://github.com/mindsdb/mindsdb
|
 |
15
beneo 331 天前 11
说真的，别再吹了。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 （的一个小边角）。次次都在转弯。 所以，你到底要做个什么东西？你面相的用户到底是谁？ |
|
16
Braisdom OP @beneo 兄弟本质上是一个 DSL 生成 SQL ，关键是如何生成的 SQL ，
生成的 SQL 能不能进行 "RFM 分析"、"同环比分析"、"客户画像"等， 如果兄弟开发出通过拖拽实现上述分析，我需要向兄弟你好好学习一下，有机会一定去拜访。 |
|
17
lexa 331 天前
@beneo 大佬，我们用 superset 做 BI ，最复杂的就是各 SQL 了，虽然有模板，但维护起来还是很痛苦呀，楼主的产品如果能解决 SQL 编写这块，已经解决 BI 中最主要的矛盾了。
|
|
19
Braisdom OP @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 的就差太远了。 |
|
20
Braisdom OP |
 |
27
dexterzzz 331 天前 2
闭门造车.
预计算在 2010 年以后就被淘汰了,使用内存数据库+列存储.SQL Server Analysis Services Tabular/Power BI,SAP HANA. 要说最新的计算方向去了解下 Power BI Direct Lake,基于 Delta 文件的内存分析. SQL 方向 DSL,这些在 BI 领域从 90 年代就开始就有成熟的方案和实践,无论是已经淘汰的 MDX 还是最领先的 DAX. 了解下企业领域的跨层级计算如最典型的财务预算的多管道预算分析,Total <> 汇总 |
|
28
Braisdom OP @dexterzzz 兄弟的回复比较全面，有些信息我的确不知道需要仔细研究了，
既然 DSL 是个成熟的方案，为什么像 FineBI 还是预计算的形式进行数据开发， 你说的那些 DSL 是否能解决多表关联时引发的过度计算，是否需要数据工程手工去处理。 本质上 Agile Query 的 DSL 不是新语法，只不过是为了自动关联表，并且自动处理过度计算而已。 |
 |
30
swim2sun 331 天前
AgiQuery 面向的用户是开发者，还是不懂编程的业务人员？
业务人员不会去用 DSL ，因为对他们有学习成本，他们只想要最终的报表。 开发人员也不会去用 DSL ，SQL 能解决的问题为什么要引入另一套系统。 而且最终还是得编译成 SQL 的话为什么不直接用 SQL 。 业务太复杂？让 chatgpt 帮你写。 chatgpt 能生成 SQL ，而且写的大概率比开发人员写的都好。但 gpt 没法生成你发明的 AgiQuery ，也许经过 few shot 或 fine-turning 后能够生成，但肯定写的不如 SQL 好。 另外问下，那么多 SQL 方言 AgiQuery 都支持哪些？这可是大工程啊 |
|
31
Braisdom OP @swim2sun
1 ） SQL 方言在 Agile Query 是极小的工程，目前支持 PostgreSQL, Starrocks, BigQuery, DuckDB, Databend ， 基本上两天实现一个新的 SQL 方言。 2 ） Agile Query 的函数的难易程度接近 Excel 的函数，面向的是非技术人员。 |
 |
34
1018ji 331 天前
我还是 SQL 吧
啥时候把 SQL 替换了我在用 |
 |
36
AlohaV2 330 天前
不是很了解目标群体是谁...感觉大多数想替代 SQL 的东西最后都会写成 SQL 。
如果需要灵活性，用 python 之流（ pandas, arrow, xarray, ...)岂不是更灵活，现在 CPU MEM 比前几年便宜多了，贵的是成规模的 GPU 资源。 |
 |
39
pp3182429 330 天前
sql 是可以编程的，解析成抽象语法树就行了。你做了个语法表达类似 sql 的语义，甚至把 sql 里解决分桶问题的 case when 语法也留下了。
sql 已经是能清晰表达 query 语义非常简单的通用表达了，其它变化都是特定场景的包装而已。 |
 |
40
szdosar 330 天前
为何不把结论前置呢？
我要是没看错的话，文章最后，提出了 Agile Query 作为一种解决方案，提供了更便捷的语言来替代复杂的 SQL ，简化数据分析，减少对预计算的依赖，这是蛮重要的观点。 |
 |
46
tikazyq 330 天前
Agile Query 会开源么？如果能做成像 Apache Superset 那样的项目很多公司使用就会有更多机会进行产品优化了。据我所在的行业来看，微软体系下的 PowerBI 是首选。
|
|
47
Braisdom OP @tikazyq 是的 PowerBI 目前是复杂分析的首选，但使用复杂度也比较高，而且是自有的计算引擎，开源的 superset 类的 BI 的开发成本还是有点高的，使用的，大都数还是技术型公司，像国内的帆软，永洪存在的问题就更多了。
Agile Query 是处于中间位置，既能解决 PowerBI 的问题，同样能解决 superset, redash, metabase 的问题。这是我们的定位。 |
 |
49
zuston 330 天前
其实，更进一步，直接 text -> SQL 或者 AI 直接自动探查数据价值？粗粗理解下，感觉目前这个 dsl 处于不上不下的阶段
|
|
50
tikazyq 330 天前
@Braisdom 说实话，目前从 demo 视频上来看，很 superset 没有什么本质的区别，也离 PowerBI 有很大差距，不管是从可视化和 ETL 方面来说。但毕竟是个人开发的，因此功能迭代肯定不会像微软、Tableau 之类的那么快。建议还是尽可能开源出来，结合社区的力量打造产品。Superset 这样的开源产品缺点非常多，我也希望能有一个更强大的 BI 开源项目出来
|
 |
53
bzzhou 330 天前 3
哥们，我看了一下，认为可能还是有点闭门造车了。
首先，数据分析师如果不会 SQL 的，那么基本上也不用指望会学会你的 DSL （而且你认为你的 DSL 简单，是因为你自己设计出来的；但是一个完全没看到你的 DSL 的，他可能宁愿去学 SQL ）。 其次，如果你要定义一个全新的分析师语言，只能说这个难度很大（至少对于创业团队来说）。而且我觉得有这个需求的分析师，可能用 Python + Pandas + SQL 会是一个更好的组合。 建议这个阶段，可以找一些种子用户，看看他们愿意去学+使用不，多听听他们的反馈。 |
 |
59
sampeng 330 天前
我觉得做技术不能光做技术。还是要考虑点别的。
横竖你是不考虑成本的，但这通常又是选型中的重点。 就我自己身边的统计学来看，如果只是集中怎么查。怎么说呢。起步做大数据分析的时候考虑，但是不重要，只要满足 MVP 功能要求，这个事就算起步了，kpi 就算完成了，前端只要有时间随时可以换。在选型过程中反而最怕选这类没什么公司用过的。后面数据多了，就跳进去出不来了。学习成本是最大的成本，这是在很多做决策的人都明白的道理。这也是为什么最近出现的产品绝大部分是即支持自己的 DSL 又支持 SQL 。这是学习成本的一方面，另一方面，计算引擎和算法确实是核心，但是使用者不关心，作为大数据平台还关心一点：我能不能把这玩意很方便接入到别的平台上去。 metabase ，superset 这类就选起来没什么压力，不好用换一个就是了，想两套展示，一套研发自己看，一套给领导看。数据展示平台直接支持 sql 接入，轻轻松松，没工作压力。来个 dsl ？你要说服决策者会有很大的阻力。 对于决策选型的人来说，不会考虑实现细节。就几点： 1.能不能满足数据分析需求 2.成本多少。和别的技术比起来成本差异怎么样。成本包含计算成本，存储成本，人力成本和学习成本。 3.扩展性，n 年后，有新的技术出现，现在这个选型会不会成为阻碍。 OP 的产品只回答了第一个问题。 预计算成本在大数据+云平台的情况下成本只有存储成本。极其低廉。 绝大多数数据，早上跑个把小时，所有计算资源就可以释放了。只有少量的数据需要实时分析，这是实时分析的舞台。因为在这个博客里面有这么一句：“人工是最贵的开销。”。这句话我以前是信的，当然，现在用来推脱一些不想做的事也会说这句话。但这句话对于 99%国内公司不成立，人工反而是最便宜的开销。如果你现在就是 CEO 。。。你做几年老板就知道了。 |
|
60
sampeng 330 天前
PS 一句。。刚顺手按回复了。
你这个无非就是一个 sql 的语法糖。那么问题来了，这个和预计算有啥必要的关系吗？？硬联系在一起？ |
 |
61
Magentaize 330 天前
Agile Query 完全不需要数据预计算
不一定，针对超大数据量，或者过度个性化的分析，建议通过物化视图的方式预先处理数据，Agile Query 依然可以集成。 |
|
65
Braisdom OP 写在 BP 里的：
• 过度计算识别算法 • 编译器相关算法 • 数据分析意图识别算法 |
 |
69
encro 329 天前
坐等 PG 物理视图出来
|
 |
70
iugo 329 天前 1
|
 |
72
meeop 329 天前
看起来只是提供了一些语法糖包装 sql,底层还是普通 sql?
那和标题的预计算有什么关系,并没有预聚合任何数据啊 |
 |
74
SingeeKing 328 天前 via iPhone
只有我更好奇原来的地址是什么吗
|
 |
75
KevinShiCN 281 天前
@Braisdom
我是从别的帖子看到你的项目，点进来看了你的网站和一些回复 就拿 RFM 分析来说 我通过 FineBI 的这个纯界面的方式也能快速实现 RFM 分析 https://help.fanruan.com/finebi/doc-view-703.html 截止到目前我并没有看到 Agile Query 比 FineBI 更先进的地方 既没有帮我更智能的清理数据、也没有更高效的产品体验 希望可以帮助我（以及其他用户）梳理一下这方面的差异 |
|
76
Braisdom OP @KevinShiCN 可能你没用 FineBI 做过 RFM 分析吧，如果是多张表的时候，用户表，订单表，订单明细表的时候，用 FineBI 怎么快速做呢。
|
|
77
Braisdom OP @KevinShiCN 还有 RFM 只输出一个分类，如果再增加近 30 天的订单数量 ，销售情况，购买其它商品的销售情况，FineBI 又是怎么做的呢。
|
Select Language