leeg810312

@HustLiu GPT 看上去偷懒，但结果并不一定正确，候选人能分辨出来就没问题，而且它当面 GPT 答案，面试官让候选人对算法进行解析，看 ta 思路不就好了？ 6 楼的观点 允许 Google 禁 GPT 跟不上时代，我觉得一点没毛病

@blackboxo 抽成的前提是有付钱，网站存续的前提是有足够多的人付足够多的钱

我觉得开一个死一个，主要原因是用爱发电

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

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

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

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

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

虽然 API 开了 gpt4 ，测试用了些，但太贵了，费用是 3.5 的 10 倍，不舍得用，目前大多数时候 3.5 够用了