“唯有知识，让我们免于平庸”
WARNING：近期有厂家举报我的文章，说是伤害了“国产 BI”，网信办的工作人员很无奈地打电话来让我写个说明。有这个闲情，不会好好做做产品吗？ 另外，我的 wordpress是付费服务，托管在境外，不属于国内管辖。即便如此，我也没有捏造谣言吧。 请某些产品自重！否则我就免费给你们做做宣传，把你们地产品拆解一下，让所有用户都看看是什么情况 ！文末附 公众号评论截图。
又是一个漫长的高铁之旅，用了旅途四个多小时，新开一个评测对象：QuickBI。这是我2024年春节录制“测评系列”视频时的首个产品。
私下里，我常把“帆软 BI”比作“抠脚大汉”，而把QuickBI 视为“失足少年”，它没有像观远等其他新势力产品一样慢工出细活，后发不见优势，如同“没妈的孩子”，在技术细节、关键逻辑上尽显粗鄙之相，像极了城市自以为武功天下第一的街头少年。
接下来，让我们快速了解这个产品的真实实力吧。
注：本文未经任何相关方审议，仅为个人观点，仅供有趣之人参考。
国产 BI 的“耻辱”：QuickBI 的“后发优势”（上） 2024/09/30
国产BI的“耻辱”：QuickBI 图表功能测评（中） 2024/10/19
国产BI的“耻辱”：QuickBI 计算功能测评（下） 2024/11/10
国产BI测评·吐槽大会：QuickBI、永洪、观远、帆软 2024/04
一、QuickBI 的真实实力
搜索 QuickBI，很自然地就会进入它的“阿里巴巴”网站，它属于阿里巴巴旗下瓴羊智能的一部分，按照官方说法，QuickBI 整合于2017年，并在2022年成为瓴羊智能一部分。
https://dp.alibaba.com/product/quickbi （已经偷偷改正）
很惊讶的是，今年是 QuickBI 入围 Gartner 第五年（准确的说，是“Alibaba Cloud”入围），官方网站竟然还是“连续两年”，是觉得后面几年应该进入 Leader 象限吗？还是觉得心中有愧（鬼），不想宣传了？
【最新】近日，瓴羊一边举报我“侵犯商誉”，一边偷偷修改了上面的文章，改为了“连续5年中国唯一入选 Gartner ABI 魔力象限的 BI 产品”。
QuickBI 标榜自己入围ABI，这就好像明明 Microsoft 入围了 Gartner ABI 象限，但是PBI圈子统一口径说“PowerBI 入围”一样魔幻。先看一下瓴羊自己如何解读的 Gartner 报告，它总结了 QuickBI 的“独特优势”，如下所示：
https://www.lydaas.com/2024gartner不知道你有没有找到“独特”之处，是还不靠谱的问答、“中国特色复杂报表”，还是“内置的查询引擎”，集成能力？不知道隔壁各位友商如何看。我们再来看看 Gartner 报告的原文，看看官方怎么说的：https://www.gartner.com/doc/reprints?id=1-2HW1JC8Q&ct=240620
首先是官方“很官方、很通稿”的介绍。
然后是三个Strengths优势，解读概要如下：
– 销售网络很广、价格弹性很高 （Broad sales channels and flexible pricing model）
– 独立型可分解的分析：售卖方式多样，可单卖stand-alone，可以作为云服务（LYDaaS ）一部分，也可以集成（embedded）（Composable analytics）
– 阿里巴巴持续推广的数据素养项目，有助于发展（Data literacy program）如果是内行人看，应该都能看出来这种评价很是不痛不痒，甚至有些“违心”。翻译一下就是：（产品不知道好不好，但）销售渠道广、销售方式多样、阿里巴巴的行业“洗脑”很成功，未来前景广阔。
这种介绍“很阿里”，只字没提产品的关键能力，比如可视化是否易用、引擎是否够好、工具是否专业，这才是分析师更关注的内容吧。
说到对 Alibaba Cloud 的担忧（Cautions），Gartner 倒是没有遮掩。
– 区域限制，生态受限：阿里云局限于中国区域，QuickBI 所依赖的“数据中台”（Data Middle Office）在阿里之外接受度有限。
– 投入不足：阿里云虽大，但 QuickBI并非战略核心，研发只有100人，明显低于（ significantly lower than）其他头部产品。
– 竞争激烈：局限于中国的同时，还要迎接来自其他知名同行的激烈竞争，包括帆软、永洪、思迈特、观远（FanRuan Software, Yonghong Tech, Smartbi Software and GuanData）
看到这里，你再去看看瓴羊自以为的“独特优势”，是不是觉得明显自我标榜太多啦。加上这几年“数据中台”快成了人人喊打的“过街老鼠”，quickbi 也受到了不少影响。
当然，产品评价是很主观的，让我们看一下产品的几个使用普遍、关键的细节，一起吐槽起来吧！
二、数据源：简单的地方“快不起来”
说完“Gartner权威评测”，让我们来用一下 QuickBI 具体使用吧。QuickBI 的关键流程如下所示，我们先新建一个数据源，一探究竟。
https://www.alibabacloud.com/help/zh/quick-bi/product-overview/introduction-to-quick-bi-1
从上传文件开始，使用 Tableau 的默认数据源（这里使用 csv 文件，避免合并单元格等非结构化情况）。
上传 CSV 文件后，默认会进入预览模式，马上你就开始进入疯狂阶段啦。我在操作系统、Chrome 、Csv 文件都是中文简体的前提下，导入之后的预览竟然是这样的：完全乱码！
于是我只好找一个英文版的csv文件重新来过。不知道为什么，上传好几次都提示上传失败，我以为是网络问题呢。
刚刚导入后的预览是这样的，我瞬间感觉不好了。
恕我直言，我直接要崩溃了。我记得春节前评测都没这样的呀！！
几个月过去，退步不少呀，CSV 都支持不好了？？
我只好再把 csv 文件另存为 xlsx ，然后再次上传。这次可以说是秒传成功，不过点击“确认并上传”提示错误。
这可是标准的 Tableau 示例文件呀，你竟然敢不兼容？？仔细一看，因为QuickBI 设置了异常过分的字段名称限制性条件，不能有特殊字符，比如：不能有空格、不能有斜线。此时我想很多人都开始凌乱了，那 “Order ID” 是不是必须手动改为 OrderID 或者 Order_ID？ Order-ID 也是不行的！
如果你想表示“省/自治区”，或者“Country/Region”呢？不好意思，你很可能要委屈一下，表示为“省或自治区”，或者“Country_OR_Region”了！
疯狂吧。
我于是一个又一个地修改字段名称，足足改了九个字段：把空格和短横改为下划线（_），斜线（/）只能改为”_OR_”了。
无力吐槽，只想骂人。
我以为就能上传了，结果弹出来一个协议，瞬间又恶心到我了。
一边口口声声说“Quick BI 产品作为一款工具产品……不触碰任何用户数据”，一边又说“……任何侵犯 Quick BI ……合法权益的数据……Quick BI 有权删除相关数据……”。
说了不听，但你不偷听，怎么知道我在骂你？
莫非“偷听”不属于“听”的范围？？
平复一下心情，继续。
接下来，我们再点开上传的数据源，看看它目前可好。惊奇地发现，我在年初批评的一些问题被修改了，但不彻底（比如数据库字段名称）；真正的薄弱地方依然存在（比如字段类型）。
一个好产品，应该经得起仔细琢磨；不好的产品敲一下都是裂缝。
特别注意的是，你要注意这里的“数据库字段名称”，其实是 Quick BI 自己映射出来的名字，稍等还讲一个大大的陷阱，正是这里埋下的地雷炸出来的！！
三、最重要的地方“好不起来”
数据源之后，是数据集 。
QuickBI 的“数据集”其实可以理解为最低阶的“数据模型”。
先引用数据源中的一个数据表，然后按照说明，可以加入第二个。注意，它这里的概念、术语非常具有迷惑性（关联、关系、连接混淆在一起），作为老司机的我甚至差点被它迷惑了——我以为真是数据关系模型的阵地，事后发现只是一个幌子。
当拖入另一个数据表时，默认用字段名称相同的字段关联——这很好理解，普天之下，莫非如此；但是，这个原则到了 QuickBI 中竟然出问题了！
因为它竟然用自己映射出来的字段做关联，而非业务用户可以理解的字段！要知道 Col_1/2/3……这样的映射其实也是完全不应该的，这样无法保证多个数据表之间字段的唯一性，就难以在更大范围中构建数据的世系关系。也正因为此，Tableau 等其他工具中虽然也会把字段映射为内部名称，但都是 GUID 这样的几十位编码，而且是不对分析用户开放的！
什么是 Col_1，什么是 Col_2？
不好意思，你必须自己去找找……
找不到，那就慢慢找吧。
用自己映射出来的、不规范的、用于数据底层存储的“自定义字段名”作为关联条件推荐，简直是天理难容、闻所未闻！
好吧，我花了点时间，用 Col_4 = Col_2，哎，“等于”号呢？？
你说“等于号”就是中间的 那个锁链呀！
可是锁链也可以是“不等于”，甚至＞呀？？
如果你不支持其他的关联条件，那就显示“等于”多好呢？你看看 Tableau 的关联方式，直接学习挺好的。
好了，我们终于弄了一个模型，其实只是一个行级别的 Join。
根本没有关系模型！！却敢用“关系”（relationship）混淆视听。
平复一下，看看模型的结果。依然千疮百孔，不忍直视，我这里选择性批评一二。
首先，维度和度量不应该用在字段类型的分类，如果只是分类检索方便，不如直接分“字符串和数字。这里的矛盾在于错误地理解 “数据存储类型”和“字段问题类型”的不同，虽然有默认的关联。
同理，表示“年龄”的数值永远都是数字格式，但既可以作为分析的维度（不同年龄的人数），也可以作为分析的度量（不同科室的平均年龄）。你永远都可以说 24、36是数字，但不能说它们必然是度量。默认关系，不是必然关系。
就像在西方，男人默认是“男人”，但也可以是“其他”，此时“生理性别”就需要和“法定性别”分开。在这个癫狂的年代，“真男人”是真，但不一定是“男人”。
其次，把图片、日期格式、地理角色等完全视为“维度类型切换”之中，简直也是懒惰到了极点。
假设有经度、纬度两个字段，由于它们是小数，默认被视为“度量”，此时想要把它们的角色设置为“经度和纬度”，就要先把“度量改为维度”，再设置“维度类型切换”。其实维度和度量完全不应该是字段角色设置的前提呀。
连分类都没弄清楚，还“维度类型切换”呢，切个毛线啊。
在这种混乱的逻辑之下，就会出现一些癫狂的事情，比如默认度量的“profit”可以“度量类型切换”改为“文本”，但由于数据类型和维度/度量到底又是分离的，所以默认聚合方式就变成了“计数”。
再者，最大的问题其实还是计算。
当“新建计算字段”时，光怪陆离的分类问题在这里都凑齐了。
写一个 Year 函数，默认的数据类型是“度量”？ 疯了吗？ 这是把“数据中台”的癌症要散播到分析阶段吗？
函数之所以称之为“函数”，是因为要完成特定的功能，函数英文 Function ，函数一定是预设了输入和输出的、预设好的最优算法。比如 Rank 的实现有 冒泡、选择、插入等等，不同算法的难度、性能各不相同，程序需要设置好最优算法并封装起来，确保业务分析师可以忽略底层逻辑、快速完成任务。
从程序上看， Year 函数返回的就一定是数字，没有第二个可能；如果说想要返回文本，可以设置另一个函数（比如 Tableau 中的 Datename，就是 datepart 的文本化），也可以嵌套类型转换（比如 STR(YEAR(OrderDate)) )。
不从根本上思考函数的本意，却为每个函数设置事后的三个选择，简直是糟糕透顶、不可理喻。
计算如此，函数的语法都没搞清楚。以这样的产品教育客户，只会让客户的“数据素养”越来越差罢了。
我都不想说了。
数据源和数据集尚且如此，可视化我更不想吐槽了，有兴趣的可以去B 站看看我的吐槽视频（充电，非同行没必要看，徒增烦恼）。
国产BI测评·吐槽大会：QuickBI、永洪、观远、帆软
四、Quick BI 算是“国产 BI代表作”吗？
最后，假设有人问：Quick BI 作为国产 BI 的“新势力”之一，又是唯一入围 Gartner 魔力象限的产品，那它是当之无愧的“国产 BI 代表作”吗？
如果我说“是的”，一众国产 BI 大哥、小弟肯定不同意，包括 BI 的前辈帆软、永洪，也有这几年的新势力观远、DataWind。
而且从上面简单的测评来看，坦诚地说，帆软虽烂，QuickBI尚不及帆软。
如果说是“不是”，那何以入围 Gartner 魔力象限、站在一众巨人肩膀上的 QuickBI 不仅马失前蹄，还似乎居高自傲？
我只能说，背后不是有故事，就一定有“事故”。
让我说，外部有 Tableau、PowerBI、Qlik、Gooddata可供“模仿”，内部有帆软、永洪、观远等产品可供参考，QuickBI 背靠阿里的大树，却设计成这个鬼样子，这简直就是中国国产 BI 的耻辱，是行业的倒退，也是中国用户BI 素养的“试金石”。
也正是因为这个，让我对“Gartner 魔力象限”的权威性甚至都有所动摇。
2024/10/10
————
分享到：
点击分享到 Facebook （在新窗口中打开）
点击以分享到 X（在新窗口中打开）
X
点击分享到 LinkedIn（在新窗口中打开）
点击通过电子邮件将链接发送给朋友（在新窗口中打开）
电子邮件
点击分享到Pocket（在新窗口中打开）
相关文章