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

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

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

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

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

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

统一感谢一下。。。。

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

@hopehack
1 ）明细数据是普通的业务数据库的表，不需要额外加工
2 ）组装过程就是公式的编写过，只需要聚焦单个指标，不需要关注与其它维度的组合关系，那些都是由 SQL 编译器完成。

处理好依赖关系，和容错后重试就可以了，

很多伟大的产品都就小细节开始，加油楼主

我的项目都是 PostgreSQL 了，MySQL 好多年不接触了，Bug 实在太多了，
我的项目： https://www.agiquery.com

@JavaGo 我会尽补上的，里面的几个场景里已经涉及不少函数了。

@Alias4ck 您说的很对，前期我参考过这个项目，但是 proql 没有处理 "多对多" 关联时，直接 JOIN 导致的过度计算（有些团队称为数据膨胀），proql 还是需要数据工程师自己手工处理

Agile Query 通过算法智能处理过度计算，这也是最核心的算法。

@moyi97 这块后面我写篇文章详细介绍一下，这里我先简单回答一下。

superset, dataeasy, redash 这类 BI 所有的数据都需要数据工程师写 SQL 完成，像用户画像，RFM 这类统计的 SQL 非常复杂。

agiquery 中，这些都可以通过一些简单的抽象函数实现。SQL 是由编译器完成的。

用户画像： https://www.agiquery.com/blog/customer-profiling-segmentation/

RFM 统计： https://www.agiquery.com/blog/rfm/

@beneo 感谢祝福，看样兄弟应该钟情与手写 SQL 和预计算表了，应该还停留在 MySQL 的时候呢。

@GeekGao 是的，也是听取了其它朋友的建议。

@kingofzihua 支持 docker 部署的，公网的服务配置实在太低了，只有 2 核，4G 内存

@kingofzihua 已经上线了，还未公开发布，如果您需要可以联系我，单独交流。

@boshok
@beneo
@xenme

几位专业的朋友，提点建议。

@buruliu 总结下来，开源的 BI 工具就是二次开发的成本太高了。