不太明白直接在数据库计算的意义指向？大数据分析通常都是在数仓数据库做分析（一般不可能允许直接连接业务系统数据库做大数据分析），这个产品的解决方案我理解没错的话是只要 ETL 到 ODS 层就可以做分析了。不过，这听上去并不是一个显著的优点，（可能与我们的客户群体有关）因为你提到的 MPP 性能在变强，实际上现在的设计趋向是 DW 层在变薄，DW 不再细分很多层，存很多宽表了，基本上 ODS 层清洗转换后存到 DW 层，然后就能通过计算引擎写 SQL 输出所有 ADS 层需求的指标数据，用到的 DW 层宽表不会经常发生大量变动，所以避免 报表需求变动导致 DW 层变动而且直连数仓数据库 ODS 层这个需求，我觉得这个需求并不强。 另外，实际工作中，SQL 是行业标准，是数据分析师的必备技能，现有的 SQL 编写辅助工具已经很强，而且写 SQL 在整个 BI 工作流程中不占很多时间。 集成 ChatGPT 很难建立壁垒，其他竞品很容易就能集成 ChatGPT 加强自身特性。 BI 产品竞争非常激烈，仅从 OP 的产品描述看，我个人觉得竞争优势不是很明显。我想这个产品的目标群体可能是有计划以数据驱动业务的中小企业，如果能找到这样的客户，加上匹配的定价、运维、售后等会有市场机会。
@leeg810312 首先，ODS ，DW ，ADS ，宽表，数据血缘，数据集市等， 这些概念本身就是受限技术才衍生出来，本来就不应该存在。 抽象出各种层次的封装就是为了降低 SQL 的复杂度，因为写好复杂 SQL 的人太少了，维护成本极高。 现在数据的计算性能已经非常高了，为什么还要做那些层次的抽象，复杂的 SQL 也不需要写了，这难道不香吗？
@Braisdom 行业现有的大数据计算引擎已经好到可以低成本实时计算海量数据了吗？分层仅仅是为了降低 SQL 复杂度？不是还有性能优化的考量吗？ MPP 性能在增长，但总有上限。从原始表复制清洗后直接计算到报表，看上去不手写 SQL 且少了 2 层，但很明显没有可重复利用的 DW 层和 ADS 层，很多报表指标都必须从原始数据层提取来计算，当数据量增加到一定程度必定会遇到性能瓶颈，而且会比分层架构更容易更频繁地遇到性能瓶颈。随着数据量快速增长，每隔几个月频繁让客户提升硬件现实吗？还是做 SQL 调优？如果生成的 SQL 被认为是最优，那剩下的调优不就要做分层做中间表吗？所以这个产品如何保证一直只用原始数据写 SQL 呢？
@leeg810312 首先，您说的我部分同意，分层设计是为了解决海量数据计算和 SQL 复杂度，这两点都是 BI 比较痛的点。 目前复杂 SQL 可以通过 Agile Query 来实现，优化工作来就是 Agile Query 算法要解决的核心问题之一，会一直持续下。当然有了 Agile Query 也不能完全不做分层，针对海量数据，可以通过物化视图的方法实现，但相比传统所谓的数据集市要抽象得多，不需要基于场景去设计数据。当然也不需要额外的计算层去处理，也不会需要 Spark 这种低效率的计算工具。 难道这不是一种进步吗？
@leeg810312 Agile Query 主要解决的是复杂 SQL 编程的问题，让数据系统不需要针对业务场景进行复杂的抽象过程，不再出现，同样计算公式计算的结果按不同维度存储在不同的表中，减少数据不一致产生的问题。 提升数据系统能够快速响应需求变化的能力
@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 能找到自己的目标用户。
@leeg810312 您的回答非常专业，我分别回答一下： 1 ）根据查询的数据设计中间表：Agile Query 屏蔽的是为了简化查询而设计的中间表，如果纯粹的基于海量数据的优化，我们无法避免。 2 ）物化视图：它本身不是为了节约性能，更重要的是降低开发成本。 3 ） SQL：Agile Query 会依据不同的 SQL 执行引擎进行特殊的优化，理论上人能够优化的 SQL ，Agile Query 都可能设计规则进行优化。 Agile Query 内的所有维度和指标可以进行自由的组合，不需要做任何其它工作，单纯这块就可以提升需求响应速度很多倍，传统 BI 中，不同维度的组合都需要设计中间表，如果纯粹写 SQL ，也是非常复杂的。 如果您有兴趣，我可以给你在线演示一下系统，您也可以在线挑战。
@leeg810312 还有一点补充一下： 1 ）快速响应需求变化在传统 BI 中有两种方法：1 ）设计中间表，成本非常昂贵，基本以周为单位，2 ）在 BI 中增加复杂 SQL ，基本以天为单位。但在 Agile Query 中，是以秒为单位的，已经将成本降至最低了，代价也已经是最低的了。
@leeg810312 不好意思有一点，是我理解错了。 您的观点是通过 SQL 去计算的效率，还是不如自已写程序计算（例如：Spark/Flink ）的效率高。 复杂 SQL 是更难写呢？还是更难优化呢？这是两个不同的概念，SQL 优化本身有自身的规则，不同的 SQL 引擎会有一些区别，但本质上还是有规律的。
