V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Braisdom
V2EX  ›  推广

写一点最近看回复的感想

  •  
  •   Braisdom · 277 天前 · 3654 次点击
    这是一个创建于 277 天前的主题,其中的信息可能已经有所发展或是发生改变。

    1 )大家对 DSL 普遍感到鄙视,认为作用不大,实现难度也不高 其实所有高级编程语言都是 DSL ,只不过是语言的特性多与少,Agile Query 的确设计了一种新的 DSL ,但也有程序编译的所有过程,从词法 -> 语法 -> 语义 -> IR -> 有向无环图,最终构建所有子查询,再优化子查询,输出 SQL 。

    2 )对 BI 的认知误区 感觉 BI 系统就是要一层一层构建中间数据,这符合程序员的思维,将复杂问题分解成多个问题,逐个解决。Agile Query 提出了一种新的方式,将复杂的过程封装起来,外部无法感知而已,并不是复杂问题不存在了。

    53 条回复    2024-02-04 09:29:05 +08:00
    wenhuacode
        1
    wenhuacode  
       277 天前   ❤️ 1
    power bi 很方便
    Braisdom
        2
    Braisdom  
    OP
       277 天前
    @wenhuacode 对的,的确很方便。
    justdoit123
        3
    justdoit123  
       277 天前
    我自己觉得 DSL 多了,要记的东西就太多了。不同的 DSL ,等于有不同的编程语法。

    但是矛盾就在于,DSL 本质上是沉淀的结果,总不能每次写个新东西都从二进制开始吧?

    只能说希望同领域、同场景的 DSL 语法最好趋于相近,能有一个统一;不同领域、不同场景的 DSL 的语法,能遵循一定的规律。
    beneo
        4
    beneo  
       277 天前   ❤️ 6
    1. 不是鄙视 DSL ,是反感你的人设和执拗;一个人坚持搞了大半年的 Agile Query ,这种努力值得尊重。但是,一开始大谈特谈自己不是 BI ,结果最后还是 BI ,开始说要开源最后没影,开始说 Docker 本地试用,现在都烟消云散,你一开始就不要立 Flag 嘛。你的算法再牛,现在看上去核心卖点还是 DSL ,也不敢直接秀出来,藏着掖着,直接网页注册试用啊。哎哟你这东西多金贵,还天天怪大家思想跟不上你。

    2. 然后咱们聊聊 BI 。你可能觉得大家对 BI 有什么误解,但实际上,大家用 BI 的不少,用 BI 交付项目的也不少。在这个圈子里,操作的便利性,向上管理的艺术,以及数据的处理能力才是王道。你的 Agile Query 提供了新的 DSL ,挺好,但问题来了,如果大家已经用着 FineBI 、QuickBI 、PowerBI 挺顺手的,为啥还要折腾去用你的东西?你说的这些语法糖真的解决了什么实质性的痛点吗?什么过度计算在企业里面真的会算个大问题么?就像你家做的厕纸更薄更有韧性,减少成本 5%,但是对使用手法有了更高的要求,那这点改进真的值得大家换吗?

    说白了,你这个坚持,论谁都提倡都点赞,但你不吹牛没有人捶你,你有东西就秀出来,别搞了快一年了,时不时跳出来说你这个东西有多好多好,但是你们想看啊,来联系我吧。哎呀,兄弟,你要营销真发错地方,真累
    Braisdom
        5
    Braisdom  
    OP
       277 天前
    @justdoit123 习惯有时是个好东西,有时候反而会局限自身的认知,好奇一些往往会有意想不到的收获。
    Braisdom
        6
    Braisdom  
    OP
       277 天前
    @beneo 不是大半年,是 2 年多了,兄弟你估计 Agile Query 的一篇文档都没看完
    Braisdom
        7
    Braisdom  
    OP
       277 天前
    @beneo 我不是开源项目,不需要有人点赞,只是让更多人看到,其中找到需要的人而已,如果你真的对项目感兴趣,可以加我微信,而不是在贴里讨论。

    Agile Query 不能满足所有人的需求,但肯定能满足一部分人的需求,我需要的是让那部分人看到,看懂。
    beneo
        8
    beneo  
       277 天前
    @Braisdom 你要的热度效果我帮你添柴了
    Braisdom
        9
    Braisdom  
    OP
       277 天前
    @beneo 感谢。你公司的资料我也看了,我们应该算同行。
    sampeng
        10
    sampeng  
       277 天前   ❤️ 3
    不是。。没别的意思。技术人都是直来直去。。你要吹你的东西多好没问题。别整天想着搞个标题党然后就爆火了。就算是官方博客你即不是行业领袖也不是行业大拿。这个语气和内容完全不匹配。
    想赚钱没什么寒碜的,光明正大的赚光明正大的打广告爱看的就看一眼,不爱看的就划过了。
    CaptainD
        11
    CaptainD  
       277 天前
    我简单看了您的几篇文章,有点疑问
    1. 如果数据量比较小的情况下,我本身就不需要预计算,直接写 SQL 似乎更好,为什么要用一个新语法
    2. 如果数据量很大,依然需要预计算的话,Agile Query 为什么会减少预计算表,它的底层不是基于 SQL 吗
    3. 我个人认为分析报告也好,BI 也好,主要的精力不是复杂 SQL ,是各种指标能否正确计算,数据质量是否好,大量精力会用在处理脏数据上
    Braisdom
        12
    Braisdom  
    OP
       277 天前   ❤️ 1
    @CaptainD
    1 )数据量大小其实并不重要,关键看分析的复杂度,如果复杂高,写 SQL 是有难度的,而且维护起来也比较复杂,Agile Query 本质上是降低 SQL 的复杂编程,如果你的统计需求原本就很简单,那就不需要 Agile Query ,用 Excel 就能做了。
    2 ) Agile Query 有个大前提是 MPP 数据库的发展,使得大数据量的复杂 SQL 也可以正常查询了,而且效率非常高。
    3 )数据清洗在早期已经完成了,而分析需求是不断的新增的,这样的工作是持续的,没有尽头的,如果每个分析需求都有 300-500 行的 SQL ,维护成本是极高的。
    beneo
        13
    beneo  
       277 天前   ❤️ 1
    @Braisdom 我跟你同行个球,我搞教育的皮包公司而已
    Braisdom
        14
    Braisdom  
    OP
       277 天前
    @sampeng 我个人对每个技术人做的产品都保持着敬畏之心,无论是创业项目,还是个人兴趣,因为任何一个项目没个 3 个月,半年是搞不出来的,能潜下心来认真做一件事,实属不易。
    Braisdom
        15
    Braisdom  
    OP
       277 天前
    还有,在喷其它人的项目的同时,自己可以好好想想,自己能不能坚持 3 个月,半年搞一个小东西,做出来的东西敢于发出来让人挑战吗?
    weijancc
        16
    weijancc  
       277 天前
    DSL 相当于一种异类, 被排斥是正常的, 我本职是写 Java 的, 就很排斥 Rust, 语法接近的 typescript 就马上接受且上手. 你发明 DSL 相当于自己定了个标准, 问题你又没有大厂背书, 谁会那么闲专门去学你的语法呢?
    Braisdom
        17
    Braisdom  
    OP
       277 天前
    @weijancc Agile Query 没有定义语法,语法与 SQL 完全一致,只是新增了大量分析函数,你可以先简单了解一下 Agile Query
    weijancc
        18
    weijancc  
       277 天前
    @Braisdom 我没看过你的帖子, 只是看你这篇主题自己说了你自行定义了 DSL.
    fishily1993
        19
    fishily1993  
       277 天前   ❤️ 1
    有时候,坚持和执拗只有一墙之隔🙄
    Braisdom
        20
    Braisdom  
    OP
       277 天前
    @fishily1993 你说的非常对,坚持和执拗不是一墙之隔,是一回事。懂得坚持的人往往更酷一些
    leonhao
        21
    leonhao  
       277 天前
    @Braisdom 你这个前提就错了,首先复杂 SQL 没难度,难的是写出高性能的复杂 SQL 。第二 MPP 数据库大数据量下的复杂 SQL 效率没有非常高,这是分层搞中间表的非常重要的一个原因。
    Braisdom
        22
    Braisdom  
    OP
       277 天前
    @leonhao
    1 )复杂 SQL 的难度是相对的,如果是 SQL 的高手,相信再复杂的 SQL 也不难,关键没有那么多高手,也不好找。
    2 ) MPP 的性能也相对的,相比 5 ,6 年前的 MySQL 和 PG ,现在的 MPP 数据的查询性能要调出几百倍了。
    Braisdom
        23
    Braisdom  
    OP
       277 天前
    @leonhao

    2 ) MPP 的性能也相对的,相比 5 ,6 年前的 MySQL 和 PG ,现在的 MPP 数据的查询性能要高出几百倍了。
    Nile20
        24
    Nile20  
       277 天前
    @Braisdom 我对你的产品没有意见,毕竟我不是用户。但是如果你为产品的辩护是“在喷其它人的项目的同时,自己可以好好想想,自己能不能坚持 3 个月,半年搞一个小东西,做出来的东西敢于发出来让人挑战吗”,那可能你在产品推广策略上有一些优化空间。是否选择一款产品,是看它是否能有效解决需求,而不是开发者坚持做了多久。大家需要的是疗效,坚持了多久并不构成护身符。
    Braisdom
        25
    Braisdom  
    OP
       277 天前
    @Nile20 你说的当然正确了,我想表达的是产品的初期是很容易被扼杀的,大家多一些宽容,因为每个产品都是从初期发展起来的,就像我们面对刚毕业的大学生,多一些宽容更好。
    lichao
        26
    lichao  
       276 天前
    SQL 高手完全可以自己写 SQL ;
    SQL 低手大概率学不好、也用不好你的小众 DSL
    zvvvvv
        27
    zvvvvv  
       276 天前
    @Braisdom #7 两年多了,连个在线试用都没有,一开始还有些期待,但是现在的话真的没必要刷存在感了。用都用不了的东西,我看你文档有什么用。
    Braisdom
        28
    Braisdom  
    OP
       276 天前
    @zvvvvv 目前面向企业客户,个人用户暂时还不开放。
    Braisdom
        29
    Braisdom  
    OP
       276 天前
    @lichao 每个人的偏好不一样的,很难强求的。
    locoz
        30
    locoz  
       276 天前
    你似乎忽略了一个很关键的问题,就是你的产品本身是面向企业、面向不那么技术人员的人群的,你的主要目标也是企业用户,那你还在 V2EX 这种地方发推广干啥呢?纯纯的吃力不讨好...关键的潜在客户拉不到多少,还得花时间和精力应付挑毛病的,就很没必要。
    Braisdom
        31
    Braisdom  
    OP
       276 天前
    @locoz V2EX 只是一个渠道而已,不是唯一的渠道。指出产品的不足没关系,担心的是完全没看过产品,然后就在这里评论
    如果看了还不了解,我可以修改文档,在贴子里回复,
    dc2002007
        32
    dc2002007  
       276 天前
    如果目标是为了写 sql 的话,那直接写 sql 就行,DSL 有点多余了,还得在学习一个新的语法,当然我不是很了解你的软件,若说的不对话可以接受批评。
    Braisdom
        33
    Braisdom  
    OP
       276 天前
    之前的贴子里已经讲到过,Agile Query 没有设计新的语法,和 SQL 一模一样,唯一的不同是多了大量分析型函数而已,通过这个函数,使用者不要关心 『多表聚合运算』。
    Braisdom
        34
    Braisdom  
    OP
       276 天前
    你的 SQL 可以写成这样,不用关心多表连接,聚合函数可以嵌套:

    SELECT
    COUNT_IF(GROUP_COUNT(orders.order_id, customers.customer_id) > 2) AS "复购客户数量",
    categories.category_name AS "品类(指定关系)",
    GROUP_SUM(order_details.quantity * order_details.unit_price, categories.category_name) AS "品类销售额",
    SUM(order_details.quantity * order_details.unit_price) AS "销售额"
    FROM "329875" LIMIT 2000
    Braisdom
        35
    Braisdom  
    OP
       276 天前
    上述 SQL 可以直接出结果
    Braisdom
        36
    Braisdom  
    OP
       276 天前
    @dc2002007
    上术 SQL 涉及了 orders ,customers ,categories ,order_details ,categories 这些表,
    这些表的连接你完全不用关系,内部的子查询也是自动生成的,输出的数据符你的要求。
    Braisdom
        37
    Braisdom  
    OP
       276 天前
    @Braisdom
    @dc2002007
    @lichao
    @justdoit123
    对上面的 DSL 你们会拒绝使用吗?
    dc2002007
        38
    dc2002007  
       276 天前
    @Braisdom 如果做到了特定数据关系范围的语法简化,那还是很有价值的
    Braisdom
        39
    Braisdom  
    OP
       276 天前
    @dc2002007 数据关系是预定义的,不需要每次查询时指定,当然也支持动态关系
    lichao
        40
    lichao  
       276 天前
    @Braisdom 完全不会考虑使用,理由之前说过了,会 SQL 的人会自己去写,不会 SQL 的人也学不会(大概也不愿意去学)你的 DSL 。
    Braisdom
        41
    Braisdom  
    OP
       276 天前
    @lichao 您知道下面这条表达式生成的 SQL 有多少行吗?:

    SELECT
    COUNT_IF(GROUP_COUNT(orders.order_id, customers.customer_id) > 2) AS "复购客户数量",
    categories.category_name AS "品类(指定关系)",
    GROUP_SUM(order_details.quantity * order_details.unit_price, categories.category_name) AS "品类销售额",
    SUM(order_details.quantity * order_details.unit_price) AS "销售额"
    FROM "329875" LIMIT 2000
    Braisdom
        42
    Braisdom  
    OP
       276 天前
    @lichao 下面是最终编译的 SQL:
    lichao
        43
    lichao  
       276 天前
    @Braisdom 多少行都没有关系,行数多不影响可读性、可维护性。

    SQL 有问题可参考的学习资料多如牛毛,你的 DSL 有问题或某方面不理解、不知道怎么写,是不是只能加你微信来请教你?
    lichao
        44
    lichao  
       276 天前
    @Braisdom 看了你贴出来的截图,更加坚信不可能在公司项目上用你的 DSL
    Braisdom
        45
    Braisdom  
    OP
       276 天前
    @lichao OK ,理解了,对您而言,上面的 SQL 如果有 1000 条,甚至更服复杂一些的,也可以进行重用和断点调试了。
    lichao
        46
    lichao  
       276 天前
    @Braisdom 如果你的 DSL 可以 20 行 DSL 编译成 1000 行 SQL ,那么这 1000 行 SQL 大概率极其不合理
    Braisdom
        47
    Braisdom  
    OP
       276 天前
    @lichao 1000 行 SQL 合不合理是另一个问题,本身我就在持续优化,直到最优,这块相信一定可以解决。

    关键是假设 1000 行 SQL 是最合理的,你是愿意维护 1000 行 SQL ,还是 20 行 DSL ?
    Braisdom
        48
    Braisdom  
    OP
       276 天前
    @lichao 即使人肉优化 SQL 也是逐步优化的,只不是我把它变成了机器算法而已
    lichao
        49
    lichao  
       276 天前
    @Braisdom 不想回答可能性极低的假设
    locoz
        50
    locoz  
       275 天前 via Android
    @Braisdom #30 主要是一个性价比过低的渠道其实就没啥必要发了,扯皮的时间成本和情绪成本拿去跟潜在客户多聊聊,说不定都能多聊出个订单或者是聊出一些目标客户群体会有的潜在需求。
    Braisdom
        51
    Braisdom  
    OP
       275 天前
    @locoz 非常同意
    Braisdom
        52
    Braisdom  
    OP
       275 天前
    V2EX 里的朋友,从开始心态就有一些偏激,一类是过度追捧,一类是过度自我,难得有一些客观的评论,
    lichao
        53
    lichao  
       274 天前
    @Braisdom 既然 V 站网友有这么多问题,是不是可以考虑不在 V 站频繁发推广了
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   991 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 29ms · UTC 22:12 · PVG 06:12 · LAX 14:12 · JFK 17:12
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.