Agile Query 全流程演示视频

近期在寻找落地实践，有兴趣的公司可以联系我：WX: braisdom

好像挺牛逼的样子，但是还不是完全知道这东西干什么用的。

@tlerbao 其实就是一个完全不用写 SQL 的 BI 平台，支持各种数据库 SQL 的编译

你说你看过了 BI ，请问你这个，和 BI 到底有啥区别？

我们来根据你的 demo 一步一步分析
1. 连数据库，配置主键，配置现实字段，几个表之间的链接，这些部分全部等于 BI 的数据源、数据集
2. 1:24 秒开始，Agile 选择显示名称来输出数据，BI 是选择拖来拽，BI 还分类了维度和度量
3. 1:53 秒开始，功能能等同 BI 的计算字段
4. 4:03 秒开始，功能等同于 BI 的分组字段

我感觉就是一个简单的 BI ，而且很浅。现在支持了一种数据库。如果要支持多数据库，你的 UI 抽象逻辑要牛逼，这也是 BI 的难点之一，后面的联邦查询，查询加速也需要考虑，可视化部分也没有。你牛逼的一套语法支持多个数据库的 AST 在哪里体现？

如果把人群，按照 code 能力分成：甲方爸爸（代码能力 0 ），数据分析师，数据开发者，开发，你这个系统介于数据分析师，数据开发者之间，数据分析师用，他觉得这套系统 UI 能力弱于 BI ，如果数开来用，他 SQL 创建数据集而不是拖来拉。

之前你一直说自己不是 BI ，但就 DEMO 来看，看上去就是要做 BI 的事情，但是离 BI 还有很长的路要走

@beneo 还有，是否是 BI 系统，这个问题我也没想好，至少我能明白一点，我的系统解决的是各种复杂的查询，不需要写 SQL ，也不需要预先按各维度去加工数据。这算不算 BI 我也说不好。

@beneo 仔细看了您的回复，我的公式就是可会编译成不同数据库的 SQL ，就是用统一的语法，实现不同数据库 SQL 的查询的。

你目前这个功能，几乎国内 BI 产品都有，大同小异；建议你自己做一套简单的 BI 产品，这个功能当作一个模块集成进去。单一弄这么个图形化的界面，适用面太窄了

@Braisdom u1s1 ，加工数据本身就是 BI 很重要的一环。正好现在服务的公司刚上线了一套类似的东西，但感觉流畅度上不如你这个，不确定是否是用开源的东西拼出来的。至于你说的不算 BI ，我觉得可以算作是 BI 中的语义层。

@boshok 加工数据有两个原因，1 ）查询效率不足，2 ） SQL 太复杂，维度成本太高，所以才会产生大量过程中的表，有些公司有好几千张，我的产品本质上就是为了解决这个两个问题。

@aw2350 外表是相似的，但内部的差别非常大，复杂 SQL 生成这块，外面很难感知到的。

@boshok 核心的 SQL 编译是自研的，国外的公司有专利。

@Braisdom “解决这两个问题”粗浅的理解是直接跳过这两个问题。可能我的理解不太对哈。

@boshok 当然不是跳过了，是彻底的解决它，让这部分工作通过机器自动完成，而且效率不会有太大损失。

我看出来了，你没有用过 BI ，也不懂 BI 。阿里云 quick bi 免费一个月，建议你注册并试用。你 demo 展现的功能叫做即席分析，你的计算能力和分组能力都属于数据集。

@beneo 感谢提醒，您说的 BI 中的数据集概念是否有必要存在呢，如果完全没有数据集概念的 BI 会是个什么样的呢？这样的 BI 对数据工程师的工作会有什么样的影响

@beneo 不仅仅不需要做数据集，还不需要写 SQL 。您觉得怎么样？

@Braisdom 我真的，再看你一眼都算我输

你很有勇气，也有行动力。但就你这个项目来说，你还有很长的路要走

@beneo 感谢，之前花了一年半时间解决了最复杂的 SQL 编译，现在只有 UI 这块的开发工作了。近期会出第一个可用版本，支持部分数据库。

@beneo 赞同。OP 有技术人员的执着，从上下文来看对 BI 的理解的确不太够，可以找一两本经典的书看看，再结合实际的项目对比下可能更好一些。另外，九几年的商用产品就有这些功能了。

@boshok
@beneo 感谢两位的提醒，等产品上线，邀请两位指点，多提点建议。目前这块国外的专利是 2020 下半年才出来，我看英文的专利文档费了好大的劲，完全颠覆了我超过 10 年的数据开发工作。

@beneo @boshok

https://v2ex.com/t/934205#reply0

这个贴子演示了在不加工数据的情况下，实现了复杂查询，有兴趣的可以交流一下。

@Braisdom #23 已看，没有任何新意。同样的东西看过太多了。

@boshok 麻烦问一下，你在其它什么地方看到基于复合函数生成 SQL 的。像 growth_of 类的。

@boshok 还有，在不提前做任何数据加工的情况下，能够进行各工复杂查询的工具，我也想学习一下。

@Braisdom #26 彼此对“复杂查询”的定义不同，你认为你演示的是复杂查询而已，实际还是要将基础逻辑放在语义层吧？恰好做过头部零售企业的项目，包含百货、奥莱、购物中心、免税、超市、便利店、电商复合业态。简单举例几个指标：不同等级会员的同店、跨店、折扣、看了又看、买了又买、跨渠道、遗失销售等。这些能体现在你的演示中可能更加有说服力。

@beneo 可以的，Agile Query 的函数是一种抽象的语义表达，我只是列举了几个常见的示例，您说的这些业务我后面会完善起来的，本质上这些统计都是不同维度的数据，聚合后进行的运算，基本上灵活的聚合+窗口，基本就可以实现了。

接入 gpt 吧，你的功能都 out 了

@gaobh 是的，我们正在深试通过 GPT 生成 Agile Query 的统计公式（各和聚合函数），直接生成 SQL 难度比较大。
SQL 的编译还是必要的。

BI 连接数据库，拖一个 chart ，所谓的复合函数简单的 rank ，percentile ，MoM 啥的不都算是 table calculation 么，点一点 chart 和 table 数据都有了，也不需要写 sql

但上面几位提到的 BI 相关的 datasource/dataset 想换概念还是有的。确实没看出来有啥用。

最终也就简单的，复杂点还是得手写，AIML 相关的语义分析等，商业 BI 基本都开始标配了。

没啥用

@xenme 理论上再复杂的查询，也不需要写 SQL ，都可以通过 Agile Query 的函数实现，目前实现了 group_count, group_sum...，count_if, sum_if...，还有 growth_of 系列，rank_of 等这些很快也会实现，这些函数都可以内部嵌套普通聚合函数的运算。

还有，生成的 SQL 是比较复杂的，理论上可以实现所有复杂查询。

@Braisdom 常用的一个 BI 提供的内置函数：
Aggregate functions ，如 avgif,以及你说的 countif, sumif
Conditional functions , 如 coalesce, ifelse, switch
Date functions
Numeric functions
Mathematical functions
String functions
Table calculations 如 percentDiff, AvgOver, rank, runningAvg

这都是 BI 最基本的，这些做不了的。

打了一半，感觉楼主还是找个 BI 工具试试比较好。盲目造车没必要

@xenme 传统 BI 中的 countIf, sumIf 内部是不能嵌套其它聚合的，例如：

count_if(group_count(orders.id, customer.id) >= 2)

sum_if(group_count(orders.id, customer.id) >= 2, order_details.quantity * ordertails.unit_price)

单表，多表的运算都可以在一个公式中实现，Agile Query 可以动态的 join 多张表，进行计算，这是传统 BI 无法做到的。

@xenme 目前的 BI ，针对单表运算是足够了，如果同一个表达式中涉及多张表，目前我还没有看到。大都数是将多张表的数据合并到一张表中，然后再进行运算，这样数据工程师的工作量就大很多。Agile Query 本质上就解决任意多张表的数据运算，在同一个指标公式中，可以多张表同时运算，内部拆分不同的子查询和 Join

但也不是所有都不能嵌套，有些嵌套有冲突，所以不行。另外多表动态 join 不就是 dataset ，BI 也一样是定义关系，并不是提前 join 了大宽表（有性能要求场景有些会提前 join 缓存）

@xenme 多表 join 时，Agile Query 会自动处理 double-counting 的问题，会智能拆分子查询，传统的 BI 是需要数据工程师手工处理的，如果表比较多，数据工程师的工作量会非常大。

@xenme 多表 join 时，一对多，多对多这些问题都需要数据工程师自己处理，进行数据去重，而在 Agile Query 中，这些问题都是智能处理的。数据工程师完全不需要考虑这些事件，只需要知道指标是哪几个字段计算的就可以了。

@Braisdom 你的数据库连接和关系配置在 BI 里面叫 data source/connection 和 dataset ，并不是定义完了就是 join 好的。

你的数据库连接已经是所谓的处理好的数据了。数据库工程师处理只是把一些半结构化、非结构化的处理成结构化方便查询的，大宽表这种所谓计算好的也更多是因为类似数据需求多，处理好后性能更好，提供给更多的业务方，不单是给 BI 用，偏数仓了。

到现在没看到楼主的优势和应用场景

@xenme 如果做数据报表，出现的最多的问题就是因为一对多，多对多产生的数据重复计算的问题吧，而这些问题在 Agile Query 中，你可以完全忘记它。这就是 Agile Query 最大的优势。

大宽表是一种畸形的设计，对低层数据的变化，数据的一致性，数据的实时性响应都非常差，是由于针对技术实现的一种折中的做法。

@xenme 如果没有大宽表，不用关心数据的重复计算，性能也特别高，当然也不需要写复杂的 SQL ，这难道不是一种更好的选择吗？

metabase 看一看

@Lilacs metabase 的代码我都读完了，它也没办法解决，多对多 join 时，不用写 SQL 的问题。

@Lilacs
superset, metabase, tableau, qulik, looker 这些 BI ，当然也包括国内的 BI ，目前都没办法解决关系数据库中 chasm & fan trap 。

@Lilacs
@xenme

在不用人工干预的情况下，智能解决关系数据中的，Chasm & Fan Trap 是 Agile Query 最核心的能力，有兴趣的可以看一下： https://docs.sisense.com/main/SisenseLinux/chasm-and-fan-traps.htm 这篇文章。

mongodb 、es 这种 nosql ，是不是没有 Chasm & Fan Trap


目前开源的 bi 基本也都支持 nosql

@youngce 只有没有 JOIN 的数据库才会没有 Chasm 和 Fan Trap ，如果有 JOIN 就无法避免

可以实现销售数据同比增长计算和环比增长计算吗？

@ervqq 视频中有详细的介绍，
销售额同环比增长，客户数量同环比增长，销售量同环比增长都是通过 monthly_growth_of ，系统里还有 yearly_growth_of ，daily_growth_of 这些函数，都是很方便使用用的。

示例：
MONTHLY_GROWTH_OF(
SUM(order_details.quantity * order_details.unit_price),
orders.order_date,
1
)

第一个参数支持各种聚合函数，第二参数是日期字段，第三个字段是窗口大小和距离，如果是月，1 就代表一个朋的比较，12 就意味着去年的相同的月份。

@ervqq 当然这些指标公式可以和任意的维度进行组分析，例如：供应商，客户，员工，商品，品类等，像这些维度的分析在传统 BI 中，都需要使用不同的大宽表，而在 Agile Query 中，只需要输入一个关键字。

感觉这个软件应该适用在中小企业，而且 IT 力量相对薄弱，并且业务逻辑表相对简单的企业。对有一定规模的企业，本来业务数据库逻辑就相对复杂，可以梳理出「大宽表」的企业，一般已经有能力自己写 sql 搞 BI 。如果直接面向有一定数据分析需求的业务用会挺不错的，向低代码平台方向搞（譬如支持 excel 到导入导出之类的）。

@ervqq Agile Query 本质上就是面对复杂业务的，能够让中大型企业，不需要大宽表，不需要写 SQL 就能完成所有的数据分析。

@ervqq 大宽表和 SQL 带来的副作用，只有数据工程师才能深刻体会了。

@beneo @boshok 网站上线，完整的演示视频也有了

https://www.agiquery.com

@Braisdom 看什么，看首页么？ docker 本地部署点了也没有反应，在线免费试用也没反应

@beneo 首页里有完整的介绍，不知道能否解决你之前对 Agile Query 的误解。

@Braisdom 免费版放出来再 @我吧

@Braisdom 国内 BI 这个赛道上面，走云我有 quickBI ，走本地部署我可以 FineBI ，还有一堆名气不大，但是价格便宜的 BI ，所以兄弟，真看不明白，你这个赢利点在哪里，为什么非要用你的系统？

@beneo

让大数据的个性化分析，像 Excel 一样简单
* 高级分析型查询语言 FlatQL 、分析意图识别、自动连接表 & 拆分子查询、SQL 查询性能优化
* 智能解决断层和扇形陷阱、数十种聚合函数、跨表计算公式
* 支持所有 MPP 型数据库 SQL 生成

@Braisdom 跟你聊些实在的，你就开始虚头巴脑了，跟你讲话真的累

@beneo 你用过哪个 BI ，支持
1 ）在不加工数据的情况下，对任意表的字段进行分组，或者聚合统计的。
2 ）聚合函数支持多张表的字段。

这就是我的卖点。

1：加上文本类型的数据集管理，有些公司根本就没有数据库，或者没存在数据库里面
2：分析后不能形成报告，分析的和决策的可能是两个人

@leechen 你说的很对，Agile Query 不可能适用于所有场景，前期数据是经过结构化处理的，无论是 Excel 或数据库，抽象为关系型模型，这是 Agile Query 数据分析的前提。

@Braisdom 那我给你个建议，把这个东西做成插件化，我也正在开发一个模块，作为我们目前系统的一个模块套件，因为我们系统会产生大量数据，这些数据的分析，行业内我们有很多厂商在使用美林数据的产品（这个产品我也参与过设计）、帆软、powerBI 等等，但是这些东西的集成性和性价比都不是很好，很多功能更适合研究性工作，功能过于复杂，于是我决定自己写一个简单的，和你们这个很类似，但是是适用于数据分析师的，你这个可以从这个角度考虑，增加产品的可集成性，不做大而全，类似的厂商：葡萄城，活得也是相当滋润

@leechen 是的，后期可以提供 API 嵌入。这个需求是比较普遍的。