跳至正文

【致敬Tableau20周年】分析工具篇SQL、DAX、VizQL(上)

标签:

说明:本文适合与BI同行、产品经理、高级业务分析师等用户学习。本文分为上下两篇,本文介绍SQL和DAX,下篇介绍Tableau 专利技术VizQL(数据分析,绕不过SQL、DAX、VizQL(下)

喜乐君

今天在读者群中,有人问为“何为DAX”?“既生SQL、何生DAX”?而我更想延伸说明的是,“Tableau何以20年宝刀不老,最重要的技术相比SQL、DAX有何不同?

每个工具都顺应了特定的需求,每个工具也自有最佳的实践场景,无需厚此薄彼、相互抨击。同时,工具是时代的产物,只有理解工具产生的时代和企业需求背景,才能理解它的相对价值。

一、何为SQL和DAX

总结而言,SQL和DAX生于不同的时代,对应不同的背景,专注于差异化的任务,适用于不同的群体

1)

SQL的全称是Structured Query Language ,由IBM在70年代开发,作为IBM关系数据库原型System R的原型关系语言,实现了关系数据库中的信息检索。它伴随关系型数据库而生,是定义和操纵关系数据的基本工具。这里的重点是“定义Define”和“操作Manipulate”,其中后者通往计算。

SQL is a standardized language for defining and manipulating data in a relational database.

IBM Document

SQL的目的是定义和操作数据,其中权限控制是特殊的操作项目,因此SQL常常被分为三种类型:

  • DDL 数据定义语言(Data Definition Language):创建、删除数据表,包括Create、Drop、Alter命令。
  • DML数据操作语言(Data Manipulation Language):查询和变更数据,包括Select、Update、Insert、Delete。
  • DCL数据控制语言(Data Control Language):权限控制,包括Commit、rollback、grant、revoke。

看到这里,数据分析师会发现自己使用的SELECT仅仅是SQL的功能之一,很多SQL命令都未曾耳闻。当然,在实际应用中,90%以上的SQL语言都是数据操作类型的。

分析师要注意,并没有单独的专用于分析的SQL命令,因为SQL在设计之初,分析并非它的主要功能。聚合的查询、计算、转换,都被设计在了SELECT之中。

换句话说,SQL的设计初衷是与数据库的增删改查,而非多变的抽象查询分析。

2)

反观DAX,它出生于21世纪,此时几千万、几亿行的数据已经稀松平常,它要解决的问题是,如何更高效地完成数据查询和分析,特别是处理多个操作的嵌套转换。

从SQL Server 2012开始,微软推出了SSAS Tabular Model(表模型),DAX被用于从表模型中分析数据,全称Data Analytical eXpression (数据分析表达式)。它出生就肩负了分析的重任,而不是用于创建、删除、修改数据表及其数据,也不能用于数据库层面的权限控制,事实上,这些数据库“硬交互”领域已经被SQL垄断。

和SQL类编程的思路不同,DAX是函数式、公式式语言,比如SUMMARIZE、SUMMARIZECOLUMNS的名称就充分体现了“聚合是分析本质”,经典的度量值计算函数CALCULATE则体现了“所有数据操作都是计算”的特征。

可见,“年轻派”DAX的基因是分析,“中年大叔”SQL则垄断数据库“增删改”的硬交互。如下图所示。

二、SQL和DAX在分析中的对比

SQL作为专业的数据库交互语言,它本身具有强大的分析能力,特别是嵌套查询、窗口函数、变量、视图等多种功能的组合使用,可以发挥不亚于任何一个分析工具的爆发力。既然于此,在新生代DAX面前,它又哪些优势,又有哪些不足?

同样的逻辑,新生代的DAX在分析上具有天然的优势,易于理解的函数、强大的功能组合,和可视化POWER BI/Pivot等前端的天然结合,让它拥有越来越多的用户。但是,它也存在“入门难”“函数纷繁复杂”的不足。应该如何取舍?

1、二者的基础:数据表交互的差异

首先,SQL和DAX都是基于表table的,更准确的说,都是基于集合的,这是关系数据库的理论基础之一。

其次,SQL和DAX有一个关键的差异,SQL基于单表操作,DAX则天生置于模型之中。 从这个角度看,DAX天然面向业务主题——业务主题不是单表的分析,而是围绕业务事实表构建的多表关系。

在SQL中,如果想要从另一个表中查询数据,必须使用JOIN、UNION、Natural JOIN等方式完成多表合并,然后方可查询,也就是说合并是查询的一部分;而在DAX中,分析师需要实现构建好模型(通常是其他team的专业用户完成),而在查询过程中,只需要RELATED指定另一个表的字段,表之间的合并关系(SQL join后的 on的条件)事先已经被设定了。

换个角度看,可以认为DAX基于更高级的劳动分工分析中至关重要的数据建模(合并、关系),和数据查询分开了。这个重要性,不亚于SQL和数据库实现了数据存储、查询的分离。这也是DAX在分析方面明显领先于SQL的关键所在。

再者,作为数据库操纵工具,SQL可以可以实现数据表的写入、删除和反向查询,而Viz QL和DAX这种专用于分析任务的语言,基本都是单向查询,不能完成数据表写入、删除任务。

所以说,SQL是数据库的数据存储、操纵和检索工具(store, manipulate and retrieve data in databases),而VizQL和DAX则是更高级的数据检索和操作处理工具。从分析角度看,它们都可以完成相同的工具,只是方式有所不同,喜乐君在之前的【分析通识】篇中系统介绍过。

2、高度灵活:作为编程语言的SQL

相比DAX,SQL其实是一个编程语言,只是相比C++、Python这种专门的语言显得不那么强大。

作为编程语言,每次我们都要用完整的结构表述查询分析的需求,单独一个命令无法完成任何工作,只有组合才能发挥强大的作用。在编程的设计理念下,分析师要使用使用命令(commends)、子句(clause)、运算符(operators)和函数(functions)组合完成想要的任务。这种足够细分的设计,让SQL仅需要不多的功能,就能像乐高积木一样组合无限的完整语句。

高度灵活的背后,是会出现很多重复性工作,好在有了view视图,分析师可以把各种嵌套的子查询保存下来,然后在后续直接引用。这就好比我只需要告诉读者《数据可视化分析》第一版第三章3.1小节,读者就能心神领会一样。

以Mysql为例,喜乐君用一个简单的图片,就能概括绝大多数和查询、分析有关的命令、函数。它们的组合,也都符合SELECT查询的约定编程规范,可谓大道至简,一朝吃遍。

相比SQL的高度灵活,DAX更像是高度专业的分析工具,不管是函数的理解,还是相互组合而来的高度专业表达式。

3、高度专业:作为函数、公式语言的DAX

相比SQL的编程,DAX是函数、公式,函数和公式的无尽组合就是表达式(expression,DAX的X)。

函数完成数据查询和分析,会让分析中普遍存在的分组、聚合、筛选、排序、TOP等常见分析场景变得简单,但也会让一些组合变得困难。因为它缺乏像SQL一样清晰的操作次序,上下文的分类及其转换成为很多分析师难以逾越的大山。

同时,函数太多了,让如何选择最佳函数也成为了一件难事,这在SQL中本来不是问题,只要你想要分组聚合,你就必须用GROUP BY,但在DAX,你会面临SUMMARIZE、SUMMARIZECOLUMNS、ADDCOLUMNS、ALL、VALUES等多个选择。下图是喜乐君正在整理的DAX函数清单,还没有写完的清单。

DAX是函数、公式语言,设计初衷就是分析,而非查询。你可以把它视为是一大段SQL被封装的函数(比如addcolumns)。封装让函数之间的组合,提升了工具的专业性,作为代价,一定程度上失去了SQL的超级灵活性,甚至于何时使用FILTER,合适使用CALCULATETABLE都变成了难题。

当然,DAX的复杂,是专业的“副作用”,是高级的代价。唯有如此,才能适应纷繁复杂的分析需求,比如客户RFM分析、多遍聚合、复杂上下文、上下文转换、扩展表等等。

下一次,我们会介绍Tableau背后的Viz QL,看看它如何在SQL和DAX中间,走出了优雅的“第三路线”。

by 喜乐君
Jun 13, 2023 V1.0
Jun 16, 2023 V1.1


推荐阅读:

《【致敬Tableau20周年】分析工具篇SQL、DAX、VizQL(上)》有2个想法

  1. Pingback: 数据分析,绕不过SQL、DAX、VizQL(下) - 喜乐君

  2. Pingback: 【产品对比】非对称之战:Tableau VS. FINE BI – 喜乐君

评论已关闭。