BI研发反思

所有人都告诉我Canary是一款玩具,但是没人要告诉我为什么,该怎么做。

Canary从诞生到现在已经有1年多了,从最初的单纯的数据映射工具到自助分析功能,中间改版过无数次、无论是交互的大的调整还是架构的重新设计都经历了很多。但Canary从来没有创造过价值,从来没有在真实的落地场景中为客户发现问题、带来增益

在导师那里打工时,一直告诉我,他希望我能做一款真正可以投入使用的产品出来,像tableau一样有着强大的自助分析功能。当我问到,Canary和tableau差在哪里时,我并没有得到答案*。其实差在哪里我内心是清楚的,但是是从技术的角度、从理论的角度:二者的OLAP计算方式不同、图形语法的设计不同、对于不同输入的计算视图也不同。至于数据库连接,数据清洗等当然也是,但这部分可以不作为tableau的主要模块来讨论。我最终希望得到的答案,是从一个真正的使用者的角度,告诉我Canary差在哪里,应该怎么改进

年初的时候在看Wilkinson的The Grammar of Graphics,整个人有点重心偏移,希望Canary的设计是完全的图形语法的交互界面实现。后来冷静下来才意识到,无论做什么,底层使用什么技术,最终都是要辅助数据分析的,辅助业务人员理解数据的。图形语法的理念采用多少、交互上怎么权衡,都是要结合使用者在真实场景下的分析操作来实现的。

举例而言,Canary在实际数据集的测试时遇到过两个主要问题,一个是维度成员数过多带来的分面爆炸,一个是维度数过多带来的选取困难。

维度成员过多与分面爆炸

这个我们从两方面来讲,一方面是从技术角度的性能问题,一方面是从数据分析角度讲的分面的有效数据含义表达的问题。首先性能上,Canary早在18年的4月份开发出了n分面的可视化,但解决方案是每一个子分面都对应一张canvas,在第一次给导师演示完时便被要求接入实际数据试一下,最终直接导致整个页面的卡死。也是当时以此为契机研究了Cube的优化算法,由维度进行cross的思路改为了nest操作。后续发现分面爆炸问题基本上是无解的,于是便设计了基于聚合树的局部渲染的交互操作,但被认为是废物功能,看着很花哨,不知道在干什么。但是没有一个人静下心来接一个真实的数据集分析一下,感受一下的。只是因为没有见过,不是主流,便不接受。虽然从我本人的角度来讲也并不看好这个新的设计,但是希望对方的给出的反馈是能够基于了解分面爆炸问题、了解分面爆照带来的数据表意不准确的问题、了解性能瓶颈,了解用户分析数据时的分析思路的情况下给我的反馈。否则在我看来,这个问题就犹如有人告诉我“React很垃圾,因为它不是用PHP写的”内心感受是相似的。

第二方面是数据表意上。当用户想要看一个高维空间的数据集的特性时,怎么让用户能够直观感知高维空间的数据,分面系统只是将高维空间的立方体进行了切片展示,而如果使用了nest作为Cube的计算方式,则甚至空间的结构都会被压缩,变成单纯代数意义上的高维空间。Vega-Lite就是一种很好的让用户理解感知高维数据自变量与因变量变化关系的方式。data-voyager也是一种尝试,通过先进行单变量分析来感知在单变量上的变化情况,当出现非线性关系时,可以加上related field来分析这种非线性关系的原因,能否被分解为几个线性关系。

维度过多导致的选取困难

当维度数量过多时,已经不是提供一个可以随意拖拽来展示高维空间数据的问题了,而是用户根本无从下手,根本不知道如何选取一个子空间来观察数据的映射。这时候就要求系统具备维度分析与子空间推荐的能力。这就要求先将维度(自变量)与度量(因变量)的大致关系可视化出来,让用户能够通过可视化进行快速的筛选,引导子空间的构建。当然这一步显然是可以自动化掉的,根据用户在筛选时视觉上的筛选模式,可以通过p-value直接算出与期望值模式的差异,这也是MSRA17年做的top-k insights的思路。当然MSRA的论文存在着较大的局限性,p-value的方法智能给出异常值与趋势的分析,而趋势必须要求维度为oridinal scale。所以一般情况下会参考Semi-Automated Exploration of Data Warehouses一文中的分布差异的计算方式。传统的方法会在数据源到自助分析的流程间通过数据预处理来解决,如tableau prep以及比较智能化的 Trifacta Wrangler。甚至许多国内的小公司的BI都是在这个环节上投入了很多的精力,这也是在研究BI智能化之前我自己侧重的一种方式。

从我个人的视角,是希望智能化的方式来解决这些问题,这也是我不愿意再做一个和canary一样甚至不如cananry的MVP出来。如果Canary是玩具,不能落地到实际分析场景中,那一定要亲自去和使用者聊,去观察他们在实际业务中的分析习惯,思维的侧重点,这些是需要用Canary或者tableau来验证的,而不是用一个比canary差的MVP来验证。业务人员到底需要什么样的分析能力,到底什么样的设计能够帮助到用户的分析,这必须要收集真实的意见与用例,而不是拍脑袋定的。Canary里已经有太多拍脑袋定的东西,不需要更多了,也不需要一个拍脑袋而定的新的东西。如果Canary是玩具,那么我在重写一个也会是玩具,不会有任何的提升。Canary已经被喊了一年多的玩具了,我始终也没有打破这一点,这就说明过去的大量工作都是脱离实际需求与场景的,都是一些技术投机,如果不能深入到实际场景,那么不管有再多的思路,不过写过再多的代码,都是偏移了客观需求的

Canary是一款设计上有很多理论层面缺陷的可视化系统,但是如果不去修复这些问题,为什么还要重写一个Canary?

随便BB一下

去年七月份见到数盒也是另外一个契机,让我反思自助分析应用的落地问题。也得到了一个重要的结论,由于业务人员对于自己负责的业务场景非常熟悉,自助分析的操作会很快被完成、分析模式也非常固定,整个产品的生命周期会非常短。由此通过将这些分析结果与模式存储下来,沉淀出如报表、指标之类的包含领域知识的模型,从而延长产品创造价值的周期。

我可以接受任何人骂Canary里的任何一行代码写的垃圾,因为这样我知道自己哪里做的不好,哪里需要改进。但是单纯的被说是玩具根本就没有任何头绪,根本不知道要怎么进步,根本不知道要怎么成长。我就这样永远活在梦里,Canary经历过两位导师的指导,一位是数据科学家,一位是BI领域的专家,但是除了被说是玩具,不够成熟,没有过任何实际的建议。甚至写论文时给的建议都是,这个字体格式不对,绪论的部分再多些一点。从底层的计算优化、VSP、到可视化的声明(specification)、拼接(assembly)到展示(display),再到智能化/insights。都是在黑暗中一点一点摸索,一篇论文一篇论文的扒出来。去年做的时候会经常和某位大佬聊,每次有新的发现都会被认为“这很显然啊”,但每次求一些新的思路和建议的时候倒都是些“来聊聊这个东西的商业模式吧”。

其实还有一点需要反思,就是表达能力与感染能力。怎么组织自己想表达的内容,怎么让听众理解自己的想法是一个很重要的能力。去年Canary第一次做pre的时候效果奇差无比,究其原因可以认为是有很多想法,但是没有串成一条故事。如果不能在5min的时间里打动一个相同领域的陌生人,那pre着实有些失败。日常交流也应是如此。

归根到底还是自己主动性差,很多事情完全可以通过提高自己做事的主动性来解决,这一点应重点反思。要多去做一些由于自己惰性思维导致不太想做的事情,多去挑战自己才能成长。

从多维数据集可视化的本质来讲,可视化本是将高维空间中的数据分布投影在某个子空间上(一般是先投影到某个子空间再做二维的切片),以便用户研究自变量与因变量之间的关系,发现规律。其目的是以启发式搜索的方式缩小建立最终精准描述模型的不确定范围,避免暴力建模。所以要多回归数学,多从一些统计、建模领域的经典领域的现有研究中寻求一些指导与帮助。

以后还是要多思考,多尝试,多挑战自我,大概就是如此。

Author: Lobay Kanna
Link: http://lobay.moe/2019/05/16/2019-5-16-1/
Copyright Notice: All articles in this blog are licensed under CC BY-NC-SA 4.0 unless stating additionally.