智能 SQL 分析系统（我的新作品）

[Braisdom]

视频： https://www.youtube.com/watch?v=18_ykWVmQ08

###技术特点：

• 根据关键字智能生成各类数据库 SQL ，自动计算多表查询
• 支持复杂公式，实现复杂分析
• 支持种类可视化

重要特性演示：

大数量场景下，性能测试：

最近在写BP，整理了Agile Query 的主要优势：

• 我们设计了FlatQL 语言，一种高级数据查询语言,其目的是降低数据计算的门槛，让数据分析师也能轻松地进行数据分析和复杂计算。

• 基于ChatGPT 理解自然语言，智能生成复杂计算公式和可视化参数，优化交互体验。

• 依托MPP 型数据库的计算性能，以零编码的形式智能优化查询SQL，提升整体计算效率。

[liuhouer]

有没有部署链接 需要的时候能试一下

[Braisdom]

近期会发布社区 beta 版。

[godfunc]

开源吗

[Braisdom]

后面有可能会开源出来 。

[passon]

赞

[3t]

关注一波

[alexsunxl]

有点厉害。 不简单配点声音字幕吗。

[Braisdom]

刚刚完成了全流程跑通，后面完善一下。增加产品解读。

[5G]

这个产品，是主打一个对数据库的结构分析还是数据分析？主打的是不是分析以及分析结果的呈现？我看了一下你这个感觉还是不太明朗

[VHacker1989]

不少 bi 工具也支持直接拖拉某些列来生成报表，你这个是根据输入的内容模糊查询匹配到这些列的吗。另外楼主什么工作的，怎么这么多时间折腾这些轮子的，像你之前搞的 orm 框架有在生产代码中用到吗？

[Braisdom]

@5G 这个产品主要面向企业内部的数据分析，大批量的数据通常是存储在数据库中，Agile Query 可以动态将各种指标定义编译成各种数据库的 SQL ， 直接分析，生成可视化图表等操作。

这样企业内部也就不需要专门做 BI 平台了，不需要写 SQL ，可以像 Excel 一样分析大数据。

[Braisdom]

@VHacker1989 目前 BI 的产品，我都深入分析过。大部分都是按维度进行数据再加工，分层设计，然后通过拖拉生成简单的 SQL 查询，数据开发成本非常高。

而 Agile Query 直接在原生数据库上进行查询，不需要再加工，几乎不需要二次开发，关键现在 MPP 类数据库发展比较快，查询效率非常高。

[winglight2016]

字段和中文名的映射需要手动维护吗？

[Braisdom]

@winglight2016 字段，计算公式，表关系需要手动维护的，也就是初始部署时维护一次就可以了。后期可以进行各种组合分析。

[li746224]

期待社区版

[NeroKamin]

看起来有点意思，有开源计划吗

[Braisdom]

前期会部分开源，最核心的 SQL 编译那块，后期会开源出来 。

[jones2000]

支持多数据源的展示吗？ 公司买了一堆外部数据， 有 Oracle, mysql , db2 的数据源的库， 需要把这些数据整合到一些页面统一展示。
select xx,xxx from 表（ mysql) A left join 表（ Oracle ） B where A.ID=B.ID 这样的， 如果可以 UI 拖拽就更好了。

[Braisdom]

多数据源会支持的，联邦分析现在的需求还是比较旺盛的。

[zedboy]

赞

[lizhenda]

确实不错哦，期待后续版本

[heyleo]

蹲后续

[joApioVVx4M4X6Rf]

大佬关注你很久了，请问有内测版本的，让大家玩玩，

[Braisdom]

@v2exblog 快了，争取本月，或下月初出第一个版本。

[allAboutDbmss]

如何做 window function?

[tcpdump]

回复标记一下

[Braisdom]

@allAboutDbmss 有公式配置，已经支持窗口函数，也增加了 nested aggregation 主要支持像复购分析，留存率分析等，例如：ncount, nsum, navg...，后面还会增加更多函数

[beneo]

BI 后面要遇到的问题，你都会遇到。

[xmh51]

了解过 Power BI (Microsoft Power BI)这个产品吗？

[xmh51]

Power BI 有免费本地版本

[Braisdom]

@xmh51 power bi 当然了解过，power bi 用的是自己的计算引擎，需要将数据导入进 power bi ，而我的 agile query 是直接在数据库上进行计算的，这是本质的区别。我只是计算定义的公式编译成不同数据库的 SQL 。

[Braisdom]

@beneo 我解决的就是传统 BI 的问题，1 ）数据的二次处理，3 ）大量复杂的 SQL ，
这两块我都不需要，我不会加工数据，也不需要写任何 SQL 。

[perfectlife]

等一波开源啊

[xmh51]

楼主加油，数据分析，可视化的这条路比较难走，产品太多，卷死了。
免费的有
https://github.com/dataease/dataease
https://github.com/running-elephant/datart
https://github.com/WeBankFinTech/DataSphereStudio/blob/master/README-ZH.md
https://github.com/apache/superset
Power BI (Microsoft Power BI)桌面版
付费的就更多了。
借助 mmp 数据库支持多数据源，已经有产品这么干了。
双拳难敌四手，楼主有能力竞争这么多产品吗？

[xmh51]

@Braisdom 客户不关心技术实现的，Power BI (Microsoft Power BI)桌面版能满足百万级数据的需求，千万级以上的需求，客户的个性化需求会变多，所以这块，个人的意见是单打独斗非常难。

[Braisdom]

@xmh51 这些产品我都研究过，之前的公司也在项目里使用 superset ，这一系列数据分析和可视化产品都有一个共同点，就是写大量 SQL ，之前的公司 1000 多张报表，每个报表都有几百行的 SQL 。

而我的 Agile Query 不需要写一行 SQL ，都是动态生成的，其它可视化都是辅助的特性。

[Braisdom]

@xmh51 我要计算的是过亿级别的数据，其它的小数据 excel 和 power bi 足够了。

[xmh51]

@Braisdom
1 ）数据的二次处理 正是因为数据规整化的需求，才诞生了二次处理的这个实现。就算没有 etl ，你用原生的 sql 做多表的连接，也是数据的规整化的一个环节。这个只是技术实现方式的不同而已。原生 sql 和 etl 和轻量级可视化 elt 和可视化生成的优劣不在这里进行对比
3 ）大量复杂的 SQL
没有见到过主流的 bi 产品必须要写 sql 的，各大 bi 产品，sql 都是可选功能。

[Braisdom]

@xmh51 如果没有数据的再加工（提前按维度聚合），现有的 BI 都需要写 SQL 的。都是原始表的话，任何一个分析基本上都需要几百行的 SQL ，join 几十几张表。

[beneo]

@Braisdom 用一下国内的 BI （远观，网易有数，帆软，Quick BI ），基本上都是无代码。功能基本上都是，数据源（各种数据库），数据集（库内 SQL 各种 JION ），自助取数，即席分析，仪表板，中国式电子表格，加速引擎。这些都是无代码 OLAP 最后落地的产品。你引以为傲的用户输入端的 SQL ，解析成为语法树，再到生成各个数据库的 SQL ，这样的能力，说真的到处都是（做法不同，但是都做出来了 SQL 适配各种数据库的方言）。我很鼓励你去做这个系统，我还是只能说，你往后要做的路，无疑还是一个中国 BI

[SiuRayyy]

关注一下

[Braisdom]

@beneo 这些 BI 我都用过，也研究过他们的实现方案，基本上都是通过宽表的方式解决的。网易有数，帆软 这两个我特别仔细的研究过，很难做到开箱即用，前期都需要做很多工作。

[xmh51]

@Braisdom 提几个问题，希望你不熬介意，有接触过亿级别数据量公司的具体诉求吗？市场规模有多大？他们正在使用的产品是什么？出于什么原因，这些公司会使用 bi 产品？这些核心功能交互是怎么样的？准备投入多少成本进来开发？你有信心说服客户更换系统吗？你的核心优势是什么？
恕我直言，你认为两个痛点，已经有很多的可视化解决方案了
另外，稍微大的公司是不会让你裸连 sql 服务器的，不建设 bi 平台，怎么访问 sql 服务器？
bi 产品不在于技术，不是拼谁的刀快，而是拼厚度，深度，这个积累的成本非常高。

[Braisdom]

@beneo 还有用户端输入的不是 SQL ，而是任意关系的几十张表中的列，或者 count, sum 聚合，还有各种多表的计算表达式映射的中文指标。生成的 SQL 中会有大量子查询解决 overcounting 问题，不是简单的 join

[xmh51]

@Braisdom 有想过为什么没有办法做到开箱即用吗？ bi 不像基础架构类似的组件，简洁优雅，直面客户的产品，尤其是大客户的业务产品的复杂度都不会低，希望你有准备。

[Braisdom]

@xmh51
1 ）我之前的公司是个很小公司，做零售数据业务的，正常分析的数据差不多 20 亿左右吧。后面换了一个做招聘数据分析
的公司，数据也过亿了。
2 ）我的 Agile Query 是个开箱即用的，不需要二次开发，直接连接上数据库就可以进行各种复杂分析。
3 ）数据分析和正常的业务完全可以分开的，通过 CDC 实时同步一份进行分析。不存在安全问题。
4 ）技术的发展是降低开发、维护工作量，充分满足灵活的业务发展，以及更便宜的价格。

[Braisdom]

@xmh51 目前我是按最复杂的分析场景设计的，当然后面还会遇到很多挑战，一点一点迭代解决。就像 typescript 编译成 javascript 一下，我将简单，容易生成的表达式，编译成不同数据库的 SQL 一样的原理。

[xmh51]

@Braisdom 我说一个现实场景吧，我司的 bi 产品库表权限要求到字段

[xmh51]

@Braisdom 不同的人，在 bi 产品拥有的库表字段权限是不一样的

[Braisdom]

@xmh51 这块我之前就设计过，后面录个视频给你看一下，Agile Query 本身是有权限控制的，不同人看到的指标和列是不一样的，管理员会在 Agile Query 里创建不的 Schema ，Schema 中包含不同的列和字段 ，然后分配给不同的人使用。

[xmh51]

@Braisdom 越小的公司，越不规范。所以你对大公司的需求存在脱节的问题，建议多调研调研。

[xmh51]

@Braisdom 不是说没有 bi 平台吗？ 有管理员有页面在线上环境部署，不叫 bi 产品叫啥？

[Braisdom]

@xmh51 感谢提醒，大公司也呆过，产品先上线，先落地。

[xmh51]

@Braisdom 多想下我提的那几个问题，问题很尖锐，希望不要介意，祝你成功。

[Braisdom]

@xmh51 产品上线后，希望你能提更多问题，不断优化。感谢

[beneo]

@Braisdom 你这个还要 CDC ，支持几个数据源的 CDC 呢？还要开箱即用，那这个工程量有多大，没团队么，你自己一个人？

[Braisdom]

@beneo 不需要 CDC ，你可以直接连接到数据库上分析。

[lmq2582609]

请教大佬，前端页面是用什么框架，看着蛮不错的

[bojue]

@lmq2582609 #58 前端和框架没关系吧，你要说数据血缘图的话 gojs 可以实现

[1044523901]

niubi

[Braisdom]

@bojue 数据血缘是由于数据的再加工衍生出来的。


@lmq2582609 前端用的是 React + elastic ui

[Guidoo]

蹲一个开源版 感谢大佬

[psyer]

还没看，弱弱问一句有啥用？

[1d074bfa18d34f6c]

关注一下

[li746224]

感觉挺符合我们公司下一阶段的需求，请问有没有社群之类的可以关注一下

[yunxiao99]

mark 一下 我最近也写了个生成 sql 的小工具，类似于 navicat 的查询创建工具，把前端的拖拽点选变成 sql ，适配不同数据库还是挺麻烦的 我基本都是硬逻辑的字符串拼接做的 不知道有啥其他好的方案没 期待后续的开源

[Braisdom]

@li746224 有兴趣的话，可以加我微信，近期会出一个版本，可以深度交流一下，
我的微信：braisdom ， 或者电话：[phone]

[2020beBetter]

期待开源，看起来挺快的

[zhaoyy0513]

等一波开源

[shuxge1223]

如果有 excel 就好了

[Braisdom]

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

[wooke]

关注，蹲后续

[qingfengxulai1]

是通过 JDBC/ODBC 的方式连接数据库吗？ 能解决跨数据源多数据源关联查询的问题吗？

[Braisdom]

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

[move]

贴个爪，等待开源使用

[Braisdom]

@move 可以的

[Zonecde]

收藏，蹲

[tcpdump]

关注一下

[sbabybird]

关注，支持

[stardustree]

感觉能支持的分析场景还是比较有限呀，比如要统计最近 30 天，每天销售额相比上个月的变化比值，似乎搞不出来。

[doornotdo]

CY 关注后续

[Braisdom]

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

[Braisdom]

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

[Chad0000]

这波未来是 ai 的天下。前几天 OpenAI 那边已经演示过几乎 csv 的例子了。过不了多久可能这种直连 db 的就具备了。

[Braisdom]

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

[Chad0000]

@Braisdom
你也看到了现在 GPT-4 的进步，我个人是认为用不了多久它就能掌握绝大部分的分析场景。剩下的再交给专业人士去手动调整 Sql 。

你可以试试将复杂的场景喂给它，告诉它数据结构，报表要求，看看它输出质量怎么样。

[Braisdom]

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

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

[leeg810312]

不太明白直接在数据库计算的意义指向？大数据分析通常都是在数仓数据库做分析（一般不可能允许直接连接业务系统数据库做大数据分析），这个产品的解决方案我理解没错的话是只要 ETL 到 ODS 层就可以做分析了。不过，这听上去并不是一个显著的优点，（可能与我们的客户群体有关）因为你提到的 MPP 性能在变强，实际上现在的设计趋向是 DW 层在变薄，DW 不再细分很多层，存很多宽表了，基本上 ODS 层清洗转换后存到 DW 层，然后就能通过计算引擎写 SQL 输出所有 ADS 层需求的指标数据，用到的 DW 层宽表不会经常发生大量变动，所以避免 报表需求变动导致 DW 层变动而且直连数仓数据库 ODS 层这个需求，我觉得这个需求并不强。

另外，实际工作中，SQL 是行业标准，是数据分析师的必备技能，现有的 SQL 编写辅助工具已经很强，而且写 SQL 在整个 BI 工作流程中不占很多时间。

集成 ChatGPT 很难建立壁垒，其他竞品很容易就能集成 ChatGPT 加强自身特性。

BI 产品竞争非常激烈，仅从 OP 的产品描述看，我个人觉得竞争优势不是很明显。我想这个产品的目标群体可能是有计划以数据驱动业务的中小企业，如果能找到这样的客户，加上匹配的定价、运维、售后等会有市场机会。

[Braisdom]

@leeg810312

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

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

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

[leeg810312]

@Braisdom 行业现有的大数据计算引擎已经好到可以低成本实时计算海量数据了吗？分层仅仅是为了降低 SQL 复杂度？不是还有性能优化的考量吗？ MPP 性能在增长，但总有上限。从原始表复制清洗后直接计算到报表，看上去不手写 SQL 且少了 2 层，但很明显没有可重复利用的 DW 层和 ADS 层，很多报表指标都必须从原始数据层提取来计算，当数据量增加到一定程度必定会遇到性能瓶颈，而且会比分层架构更容易更频繁地遇到性能瓶颈。随着数据量快速增长，每隔几个月频繁让客户提升硬件现实吗？还是做 SQL 调优？如果生成的 SQL 被认为是最优，那剩下的调优不就要做分层做中间表吗？所以这个产品如何保证一直只用原始数据写 SQL 呢？

[Braisdom]

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

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

难道这不是一种进步吗？

[Braisdom]

@leeg810312

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

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

[leeg810312]

@leeg810312 既然这个产品也要数据分层，现有主流模式的 DW 层也在变薄，那么 2 者从客户角度就相差不大了。我不太认可“不需要按场景设计分层数据”这个说法，你只要需要为了要查询的数据设计中间表，那就是在针对一个查询场景设计了，这种情况我理解可以算是 Ad hoc 设计，而主流方法是事先设计分层表。

MPP 数据库物化视图也是要其底层的计算引擎查出来的，MPP 的计算引擎是很昂贵的资源，不能忽略不计，实际上就不是不需要额外的计算层，区别是用 MPP 自己的计算引擎，还是外部的计算引擎 Spark/Flink 这种。

另外，我认为第三方 SQL 辅助编写理论上无法优化。这个产品的 SQL 最终是运行在 MPP 上，不可能通过改写 MPP 的 SQL 引擎而优化，所以只能是按目标 MPP 的最佳实践生成，所谓优化实际上是尽力不劣化 SQL ，或者说现在生成的 SQL 可能还不是最优。不仅大数据，常规数据库开发领域都在用各种工程化方法、架构设计尽力避免复杂的 SQL 而不是去怎么生成一个复杂的 SQL ，SQL 越复杂，优化器越难优化 SQL ，在实际工程中也越难衡量优化的效果。因此，我不觉得生成复杂 SQL 是值得探索的技术路径。

也许会提升响应需求的变化，但我看到的代价并不低，换来的效果值不值得可能只有真实案例才能检验。

以上是我一家之言，我认可这个产品的 BI 用户体验确实有提升，但还没有到具有独家优势的程度，还是之前的观点，有卖点的产品总会有人用，而且也不是只有技术一个因素，希望 OP 能找到自己的目标用户。

[Braisdom]

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

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

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

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


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

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

[Braisdom]

@leeg810312 还有一点补充一下：

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

[Braisdom]

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

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

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

[Braisdom]

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

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

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

[yinyuncan6]

不知道对 tidb 的支持度怎么样

[Braisdom]

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

[yinyuncan6]

@Braisdom 哇，感觉很酷，能够通过 ui 界面和公式生成 sql ，我觉得如果在图表模块再引入 echarts ，可以让数据展示在各种统计图上，再搭配一个 echarts 图表配置代码预览的功能，再生成一个 mybatis 的 sql ，这样可以让程序员分分钟将这些数据接入到后台，想想就很激动