V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  Braisdom  ›  全部回复第 13 页 / 共 31 页
回复总数  607
1 ... 9  10  11  12  13  14  15  16  17  18 ... 31  
321 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@harrozze 非常同意,Agile Query 有自己的边界,将跨表查询的 SQL 编译,其它的特性会适当的加上。
322 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@winglight2016 那是数据库选型的问题,针对 SQL 的结果进行 1 分钟,5 分钟的缓存就可以解决。异步执行
322 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@encro 哈哈,superset 多表查询是需要写 SQL 的,而 Agile Query 不需要写 SQL 自动多表查询。
322 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@encro 数据库连接是可以选择的,会不会搞死数据库,可以根据自身的需要。
338 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@Autmn
@wdmcode
目前系统已经具备演示条件,有兴趣可以加我微信:18901845760
338 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@wdmcode 至于数据治理,这属于一个新名字,不太理解到底是做什么的。
338 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@wdmcode 我分别回复一下:
第一点,数据清洗不是 Agile Query 的职责,Agile Query 只是解决数据的灵活计算,指标定义只是 Agile Query 中的一个公式而已,可能和传统 BI 系统的指标统一可能概念上不一样。

第二点,Agile Query 会根据表之间的关系自动 Join ,自动生成最优的查询 SQL ,数据工程师不需要写 SQL ,所以宽表存在的意义就不是那么大了,最近几年 MPP 型数据库发展的非常快,计算效率也越来越高,所谓 ODS ,ADS ,宽表,数据血缘,数据集市 这一堆概念产生的背景是:因为传统 BI 需要写复杂 SQL ,而且之前计算效率非常低效,如果这两个痛点都由 Agile Query 解决了,这些概念也就不存在了。
338 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@phatzhong24 后端用 Python
349 天前
回复了 ideacco 创建的主题 程序员 外贸团队求一个梯子方案
@ideacco 看看我这个产品,对您有帮助吗:

https://www.youtube.com/channel/UCN7ckPJv4c9kMHANlHiARdA
楼主要以看一下 LLVM ,目前大都数语言的跨平台都在往这个方向发展,有些时候站在别人的肩上也不会太丢人。

至少从高级语言 到汇编这块 LLVM 处理的还是很棒的。
很好的尝试,最近我在写 SQL 的编译器,大家都在往更底层技术的创新,很棒的想法...
358 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@loading 我们正在基于 Facebook 的 LLaMA 做自己的服务,就不用担心那玩意了。哈哈
358 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@yinyuncan6 可视化这块正在完善,应该很快就能发布了。
358 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@yinyuncan6 SQL 型数据库都可以完美的支持。接入只需要一天时间
359 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@leeg810312 再补充一点,Agile Query 的优势本质上是和 MPP 的发展紧密相关的,MPP 型数据库发展的越好,理论上 Agile Query 也会更好。

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

Agile Query 内部设计的 FlatQL 的作用也就越明显,因为它对外屏蔽了 JOIN, SUBQUERY ,更重要的是它会智能的优化过度计算(over-counting) 的问题,也就是 JOIN 后的表进行 count, sum 时数据重复计算的问题。
359 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@leeg810312 不好意思有一点,是我理解错了。

您的观点是通过 SQL 去计算的效率,还是不如自已写程序计算(例如:Spark/Flink )的效率高。

复杂 SQL 是更难写呢?还是更难优化呢?这是两个不同的概念,SQL 优化本身有自身的规则,不同的 SQL 引擎会有一些区别,但本质上还是有规律的。
359 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@leeg810312 还有一点补充一下:

1 )快速响应需求变化在传统 BI 中有两种方法:1 )设计中间表,成本非常昂贵,基本以周为单位,2 )在 BI 中增加复杂 SQL ,基本以天为单位。但在 Agile Query 中,是以秒为单位的,已经将成本降至最低了,代价也已经是最低的了。
359 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@leeg810312
您的回答非常专业,我分别回答一下:

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

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

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


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

如果您有兴趣,我可以给你在线演示一下系统,您也可以在线挑战。
359 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@leeg810312

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

提升数据系统能够快速响应需求变化的能力
359 天前
回复了 Braisdom 创建的主题 程序员 智能 SQL 分析系统(我的新作品)
@leeg810312
首先,您说的我部分同意,分层设计是为了解决海量数据计算和 SQL 复杂度,这两点都是 BI 比较痛的点。

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

难道这不是一种进步吗?
1 ... 9  10  11  12  13  14  15  16  17  18 ... 31  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1008 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 20ms · UTC 21:26 · PVG 05:26 · LAX 14:26 · JFK 17:26
Developed with CodeLauncher
♥ Do have faith in what you're doing.