【数据蒋堂】第25期:有序分组

发布时间:2017-10-10 分类:数据蒋堂 Tag:,

sjjt-25

我们知道,SQL延用了数学上的无序集合概念,所以SQL的分组并不关注过待分组集合中成员的次序。我们在前面讨论过的等值分组和非等值分组,也都没有关注过这个问题,分组规则都是建立在成员取值本身上。但如果我们要拓展SQL,以有序集合为考虑对象时,那就必须考虑成员次序对分组的影响了,而且,现实业务中有大量的有序分组应用场景。

1. 序号分组

一个简单的例子:将一个班的学生平均分成三份(假定人数能被3整除)。按我们在前面所说的分组定义,这也可以看成是一种分组,但这个运算在SQL中却很难写出来,因为分组依据和成员取值没有关系。

如果使用我们在前面讲有序遍历语法时的#符号,这个问题就很容易解决了。

A.group( (#-1)*3\A.len() )   // 按序号分成前1/3,中1/3,后1/3

A.group( (#-1)%3 )             // 还可以按序号每三个中取一个构成分组子集

用SQL实现这个运算就麻烦很多,需要先用子查询造出一个序号,然后再执行类似的分组规则。

 

上面这个例子中其实还没有真正关注成员的次序,只是说明了序号的作用,待分组集合的成员是其它次序时也可以得到可用的结果。

我们再看更多例子。

处理文本日志时,有些日志的基本单位不是1行,而可能是3行,即每个事件总是写出3行文本,这并不是多罕见的情况。对付这种日志时,就需要把文本每3行拆成一个分组子集,然后针对每个分组再进行详细的分析处理。这时要正确的分组运算就必须依赖于待分组集合中成员(文本日志的行)的次序了。

入学考试之后,把学生按成绩排序蛇行分拆成两个班,即名次1,4,5,8,…在一个,而2,3,6,7,…在另一个班,这样能保证两个班的平均名次是相同的。这个分组也可以用序号做出来:

A.sort@z(score).group(#%4<2)

这里用的分组值不再是常见的普通数值,而是一个布尔量,相当于按“真“值和“假”值分成两个组,真值对应第一个班,假值对应另一个班。本质上讲,这还是个等值分组,只是用到的分组值可以是任意泛型。

显然,这个分组的正确性也严重依赖于待分组集成的成员次序。

顺便说一句,这又是一个只关注分组子集而不关心聚合值的例子。

按序号分组在很多情况下就是用序号来计算出分组依据,然后就变成普通的等值分组了。那么有没有不能简单地转换成等值分组的情况呢?

2. 值变化分组

有一组婴儿出生记录,是按出生次序排序的,我们现在关心连续出生的同性别婴儿数量超过5的有多少批?

简单想,这就是先GROUP,计算每组COUNT值,然后数出有几个大于5的。后两步很简单,问题是怎么GROUP?

直接按婴儿性别分组当然是不对的,必须考虑次序,依次扫描记录,当婴儿性别发生变化时则产生一个新组。这种分组显然没法直接用等值分组做出来了。

我们可以提供一个有序分组方法来实现这种分组:当考察值发生变化时就产生一个新的分组。

A.group@o(gender).count(~.len()>5)   // @o选项表示分组值变化时将产生新分组。

用SQL就麻烦很多,需要先造成中间标志和变量来生成组的序号,大概是这样

SELECT COUNT(*) FROM

(SELECT ChangeNumber FROM

(SELECT SUM(ChangeFlag) OVER (ORDER BY birthday) ChangeNumber FROM

(SELECT CASE WHEN gender=LAG(gender) OVER ( ORDER BY birthday) THEN 0 ELSE 1 END ChangeFlag FROM A))

GROUP ChangeNumber HAVING COUNT(*)>5)

这样的SQL,看懂都不是很容易的。而且必须借助birthday这种字段来形成次序,而前述的有序分组写法在原数据有序时根本用不着这个信息。

这种场景同样可能出现在文本分析中。每个用户的事件日志可能多行,而且行数不确定,但写日志时会在每个行开始处写上用户号。这样我们可以按这个用户号进行有序分组,它变化时就说明是另一个用户的事件了。

即使是普通的等值分组,如果事先知道原集合对分组字段有序,也可以使用这种方案来实施,这将获得更高的性能,比数据库常用的HASH分组方案要快得多,而且特别适合大数据遍历的情况。

3. 条件变化分组

再看一个著名的问题:一支股票最长连续上涨了多少天?

这个问题当然可以直接遍历去解决,不过我们现在用分组的思路来处理,至少在SQL体系下只能这么做(严格些说,这是目前找到的最简单可行的办法)。

将股票收盘价按日期排序,然后将连续上涨的日期分到同一组,这样只要考虑哪一组成员数最多即可。更明确地说,就是当某天上涨了,就把这一天和前一天分到一个组中,某天下跌了,则产生一个新组。

用SQL实现这个思路,同样需要用中间标志和变量来生成组序号:

SELECT MAX(ContinuousDays) FROM

(SELECT COUNT(*) ContinuousDays FROM

(SELECT SUM(RisingFlag) OVER (ORDER BY TradingDate ) NoRisingDays FROM

(SELECT TradingDate,

CASE WHEN ClosingPrice>LAG(ClosingPrice) OVER (ORDER BY TradingDate THEN 0 ELSE 1 END) RisingFlag

FROM A))

GROUP BY NoRisingDays)

如果有专门的有序分组方法以及以前说过的有序遍历语法,这个运算就很简单了:

A.sort(TradingDate).group@i(ClosingPrice<ClosingPrice[-1]).max(~.len())  //选项@i表示当条件成立时产生新分组

与SQL不同,虽然实现思路完全一样,但写出来是分步的,而不是一个多层嵌套语句,书写和理解都要容易得多。

 

同样地,这种场景也会在文本分析中有用。不确定行数的日志中,有时会在事件分始时写一个标志串,当扫描到这个标志串的时候就产生一个新的分组,有序分析的条件可设定为当前扫描行和指定文字相同,这样就能保证同一事件的日志信息在同一个组中。

后两种有序分组的情况,理论上当然也可以转换成等值分组来处理(用SQL就要这么做,这也能从另一个侧面说明SQL运算体系的完备性),但确实是相当麻烦的,所以我们一般不把它再当成等值分组来处理了。

到目前为止的分组讨论,都是假定待分组集合已经准备好,其成员可以被随机访问到。但如果数据量巨大而不能全部读入时,如果继续做这种假定,会导致频繁的外存交换而性能极差,这时需要再设计以流方式边读入边分组并且边聚合的运算体系。事实上日志分析中更常见的是这种情况,这些问题我们将再撰文研究,但基本方法思路仍然离不开上面这些内容。

更多《数据蒋堂》文章