QuickBI 自评 & Gartner 评价
在搜索引擎搜 QuickBI，很自然地就会进入它的“阿里巴巴”网站，它属于阿里巴巴旗下瓴羊智能的一部分，按照官方说法，QuickBI 整合于2017年，并在2022年成为瓴羊智能一部分。https://dp.alibaba.com/product/quickbi（老版）
很惊讶的是，今年是 QuickBI 入围 Gartner 第五年（准确的说，是“Alibaba Cloud”入围），官方网站竟然还是“连续两年”，是觉得后面几年应该进入 Leader 象限吗？还是觉得心中有愧（鬼），不想宣传了？
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
- 销售网络很广、价格弹性很高（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）
看到这里，你再去看看瓴羊自以为的“独特优势”，是不是觉得明显自我标榜太多啦。
当然，产品评价是很主观的，让我们看一下产品的几个使用普遍、关键的细节！
数据源：过度约束影响易用性
说完“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 文件默认是 UTF-16格式，而 QuickBI 目前仅仅支持 UTF-8格式！在帮助中给出了介绍，但在上传过程中，遇到问题会缺少必要的引导。
https://help.aliyun.com/zh/quick-bi/user-guide/add-a-file-to-a-data-source我把 csv 文件另存为 xlsx ，然后再次上传，秒传成功。
这可是标准的 Tableau 超市示例文件呀，你竟不兼容？？【补充】有人说不应该用“Tableau 示例数据源”来测试 QuickBI，其实仔细看QBI帮助文章中给出的官方数据示例，也是从 Tableau “超市示例”文件改改而来的罢了。https://help.aliyun.com/zh/quick-bi/user-guide/add-a-file-to-a-data-source
只可惜，示例数据本可以“照抄”（就像其他一些工具一样，只是个数据而已！），你 QuickBI却非要魔改，好还改也行，却又改到面目全非，字段名称和数据详细级别不符合，数据值也质量也大幅度下降（一个公司只卖一个产品，产品类别还不同？ ），以至于失去业务分析的价值。如下所示：
因为QuickBI 设置了异常过分的字段名称限制性条件！不能有特殊字符，比如：不能有空格、不能有斜线。
此时我想很多人都开始凌乱了，那 “Order ID” 是不是必须手动改为 OrderID 或者 Order_ID？ Order-ID 也是不行的！
如果你想表示“省/自治区”，或者“Country/Region”呢？不好意思，你很可能要委屈一下，表示为“省或自治区”，或者“Country_OR_Region”了！我于是一个又一个地修改字段名称，足足改了九个字段：把空格和短横改为下划线（_），斜线（/）只能改为"_OR_"了。【补充】点击报错的叹号，有一个“一键修复”，可把所有特殊字符变更为下划线。我以为就能上传了，结果弹出来一个协议，哎……
一边口口声声说“Quick BI 产品作为一款工具产品……不触碰任何用户数据”，一边又说“……任何侵犯 Quick BI ……合法权益的数据……Quick BI 有权删除相关数据……”。惊奇地发现，我在年初批评的一些问题被修改了，但不彻底。比如数据库字段名称，年初时是所有字段完全重命名为 Col_x 格式，如今只把包含特殊字符的做了处理，何必呢。你把 Order Date 也改为 Order_date 不就好了？？这里的“数据库字段名称”，其实是 Quick BI 自己映射出来的名字，一个本应该只用在引擎内部的逻辑字段名，竟然会在事后被用于数据连接（见，简直不可理喻。
当然，过于简单的“数据类型”也是问题，这也导致后易用性下降。一个好产品，经得起仔细琢磨；不好的产品敲一下都是裂缝。构建数据集：“似马非马乃驴”
QuickBI 的“数据集”其实可以理解为最低阶的“物理数据模型”，但却给人一种“高阶逻辑模型”的错觉！比如，概念、术语非常具有迷惑性，关联、关系、连接混淆在一起，作为老司机的我甚至差点被它迷惑了。
当拖入另一个数据表时，默认出现一条线（我以为是关系来了）。放下之后，默认出现了 COl_1= Col_2的“关系条件”，我也以为挺好。一方面，因为它竟然用自己映射出来的字段做关联，而非业务用户可以理解的字段！要知道 Col_1/2/3……这样的映射其实也是完全不应该的，这样既无法保证多个数据表之间字段的唯一性，也难以在更大范围中构建数据的世系关系。也正因为此，Tableau 等其他工具中虽然也会把字段映射为内部名称，但都是 GUID 这样的几十位编码，而且是不对分析用户开放的！
用自己映射出来的、不规范的、用于数据底层存储的“自定义字段名”作为关联条件推荐，简直是不可理喻！另一方面，它有意遮挡了“join 连接”的条件逻辑，给人一种关系的误解。我花了点时间，终于确认应该是 Order_id 等于 Order_id，然后找到了它们对应的“数据库字段”，于是选择 Col_4 = Col_2。折腾呀。
如果不支持其他的关联条件，那就直接用“=”多好呢？？如果你支持其他的逻辑方式，你再补上。锁链代表个鬼？
好了，我们终于弄了一个模型，其实只是一个行级别的、低阶的 Join。根本没有关系模型！！却用“关系”（relationship）混淆视听。数据集评价：理论的“贫困”
看看上面的“连接 join 模型结果”，千疮百孔、不忍直视，选择性批评一二。如果只是分类检索方便，不如直接分“字符串和数字”。这里的矛盾在于错误地理解 “数据存储类型”和“字段问题类型”的不同，虽然有默认的关联。比如，表示“年龄”的数值永远都是数字格式，但既可以作为分析的维度（不同年龄的人数），也可以作为分析的度量（不同科室的平均年龄）。你永远都可以说 24、36是数字，但不能说它们必然是度量。“年龄”默认是“维度”，不意味着永远是“维度”，也可以作为度量出现“平均年龄”。就像在西方，男人默认是“男人”，但也可以是“其他”，此时“生理性别”就需要和“法定性别”分开。如今在上海，洗手间已经有“男、女、第三性”之分了。在这个癫狂的年代，自称“男人”看似是“男”，不一定是“男人”。其次，把图片、日期格式、地理角色等完全视为“维度类型切换”之中，简直也是懒惰到了极点。假设有经度、纬度两个字段，由于它们是小数，默认就视为“度量”，此时想要把它们的角色设置为“经度和纬度”，就要先把“度量改为维度”，再设置“维度类型切换”。其实维度和度量完全不应该是字段角色设置的前提呀。连分类都没弄清楚，还“维度类型切换”呢？
比如默认度量的“profit”可以“度量类型切换”改为“文本”，但由于数据类型和维度/度量到底又是分离的，所以默认聚合方式就变成了“计数”。
当“新建计算字段”时，光怪陆离的分类问题在这里都凑齐了。
写一个 Year 函数，默认的数据类型是“度量”？ 疯了吗？！函数之所以称之为“函数”，是因为要完成特定的功能，函数英文 Function ，函数一定是预设了输入和输出的、预设好的最优算法。比如 Rank 的实现有冒泡、选择、插入等等，不同算法的难度、性能各不相同，程序需要设置好最优算法并封装起来，确保业务分析师可以忽略底层逻辑、快速完成任务。从程序上看， Year 函数返回的就一定是数字，没有第二个可能。QuickBI 的函数帮助中，BI_year 的说明就是“以整数形式返回给定的年份”。那为什么还要多此一举，让人选择结果是“数值”呢？？？
如果说 YEAR 的结果想要返回文本，可以设置另一个函数（比如 Tableau 中的 Datename，就是 datepart 的文本化），也可以嵌套类型转换（比如 STR(YEAR(OrderDate)) )——如果一个人误操作点击了“文本”，也不过是这个逻辑而已，但同时也堵死了后续加减计算的可能！
不从根本上思考函数的本意，却为每个函数设置事后的三个选择：维度/度量、文本/数字，还有自定义格式的设计。此处设计有百害无一益！！！是 QuickBi 产品经理“理论贫乏”的最完美体现！计算如此，函数的语法都没搞清楚。以这样的产品教育客户，只会让客户的“数据素养”越来越差罢了。
数据源和数据集尚且如此，可视化我更不想吐槽了，有兴趣的可以去B 站看看我的吐槽视频（充电，非同行没必要看，徒增烦恼）。
Quick BI 算是“国产 BI代表作”吗？
Quick BI 作为国产 BI 的“新势力”之一，又是唯一入围 Gartner 魔力象限的产品，那它是当之无愧的“国产 BI 代表作”吗？如果我说“是的”，一众国产 BI 大哥、小弟肯定不同意，包括 BI 的前辈帆软、永洪，也有这几年的新势力观远、DataWind。如果说是“不是”，那何以入围 Gartner 魔力象限、站在一众巨人肩膀上的 QuickBI 不仅马失前蹄，还似乎居高自傲？让我说，外部有 Tableau、PowerBI、Qlik、Gooddata可供“模仿”，内部有帆软、永洪、观远等产品可供参考，QuickBI 背靠阿里的大树，却设计成这个鬼样子，这简直就是中国国产 BI 的“耻辱”，是行业的倒退，也是中国用户BI 素养的“试金石”。也正是因为这个，让我对“Gartner 魔力象限”的权威性都有所动摇。
粤ICP备17114055号
支持私有云部署
