浅谈ODPS SQL聚合计算与联结

简介: 本文针对ODPS SQL以及相应数据表开发进行介绍,主要topic为统计表聚合计算,涉及的内容包括:统计聚合计算样本代码示例,group by筛选痛点介绍,rank与dense_rank函数区别解析,结果输出时联结的运用join, left outer join, right outer join和full outer join的解析。

最近接触到比较多的频率、计数的结果生成问题,比较典型的问题就是统计用户在过去某段时间内产生记录的条数,例如有五个用户A、B、C、D、E,过去五天分别产生了5、3、3、2、1条记录。那么频率计数产生的结果便是A-5,B-3,C-3,D-2,E-1。而在实际情况中,经常需要对用户信息进行统计和聚合计算才能得到上述结果,本文就来详细分析如何在这类统计和聚合计算中运用现有函数达到预期效果。

假设有已知数据源表包含了所有用户记录信息,包含了时间字段,单条记录所应涵盖的内容,以及用户的身份认证信息(如ID),此阶段可用简单的group by加count聚合函数完成用户计数的统计:(样本代码如下)

insert into/overwrite table middle_table1
select count(*) as user_count 
from source_table 
group by user_id

需要注意的是,这里除了被group的维度user_id,以及聚合计数的项外,其他维度的项如也需筛选入输出表中,则需对此维度进行聚合计数,类似max(),min(),avg(),sum()等,在保证原有信息价值尽量保留的前提下,选择合适的函数聚合,如date_modified,对应行的修改时间,可取最近的时间点作为参考,则可用max(date_modified)。若不实施对输出维度的聚合,则会出现bug导致脚本无法运行。(在最开始使用ODPS SQL或类似SQL时作者经常卡在这一块,在网上也找不到不聚合情况下的筛选维度解决方案,这里特此提出,望大家避免在此浪费时间)

统计计数完成后,对频率进行聚合计数,则到了下一阶段。对频率聚合的前提是,用户信息已经不重要,只要求得到出现次数与相应计数,结合之前提到的ABCDE例子,频率聚合得到的(次数,计数)结果是3-2,5-1,2-1,1-1,后三者其实为并列关系。出现三次的ID有两个,出现五次的ID有一个,以此类推。

在这一块聚合时会涉及到额外的点,如何让结果看起来直白明了,符合需求者统计分析的要求呢?这里我们便可以引入rank函数的概念,对所有聚合计数进行排名,这样结果更清晰明了,而且rank函数的作用也不止于此,之后会再提到。样本代码如下:

select user_count 
          ,rank() over(order by user_count desc) as rank_num
          ,count(*) as freq_count
from middle_table1

这里需要介绍的是,可以用到的rank函数有两种,rank和dense_rank,rank是泛用的排名,12345以此类推,遇到并列时,试做同排名而后排名往后顺延,如之前的例子,3-1-2,5-2-1,2-2-1,1-2-1,第一位为user_count,第二位为排名计数,第三位为频率计数,这里若0次user count被允许,则它会以0-5-0的形式出现。而dense_rank与rank的区别是,并列之后的排名计数,不会往后顺延那么多位,如上述例子,dense_rank与rank的区别会体现在:0-5-0会输出为0-3-0,可酌情或根据自己喜好来选择相应函数。

在进行完频率计数后,多个时间范围的输出表可形成,如过去三十天,过去一周,过去两周,过去一天,过去三天等,也可是其他维度的范围。在这,如果输出成多个表并不比单个表方便或者便于阅览的话,则会用到联结的句法,而这里会涉及到一些结果输出展示的问题。

例如,结果要求我们把过去三十天,过去一周和过去三天的输出结果整合到一张表中,我们可以用简单的join,把三张表联结到一起,联结的维度最初可能为当天的日子,但是,这样直观明了的做法可能会导致一些问题。在联结后,会出现不同表频率计数不一的情况,过去三十天可能有几百行频率计数,而过去三天可能只有十几条,而这样会导致过去三天的数据到十几条之后开始重复,甚至在第一遍重复之前,每一行的记录都被重复,这就是结果显示的问题。

要解决这一问题,则需对各个表内有的统一维度进行联结,而这里,rank_num作为之前生成的结果,可以起到很好的联结效果。

这里,为了避免信息的流失,不建议用join语句,而改用join的其他类型,如left outer join,right outer join,假设开发者对过去30天的数据频率计数一定超过7天,7天一定超过3天有信息,可用left outer join,但是也可能会出现频率计数超过,但恰巧都一样的情况,如ABCDE都出现了10000次,每个用户的频率计数结果都归属于一条10000-1-5,那么此时,最稳妥的选择应是full outer join,不管之前的表还是之后的表行数更多,都可以保留信息输出完整结果。样本示例如下:

select t1.user_count as user_count_30
          ,t1.rank_num as rank_num_30
          ,t1.freq_count as freq_count_30
          ,t2.user_count as user_count_7
          ,t2.rank_num as rank_num_7
          ,t2.freq_count as freq_count_7
          ,t3.user_count as user_count_3
          ,t3.rank_num as rank_num_3
          ,t3.freq_count as freq_count_3
from
(select user_count 
          ,rank() over(order by user_count desc) as rank_num
          ,count(*) as freq_count
from middle_table1 
where date_modified between (30_days_ago) and (today)
) t1 
full outer join
(select user_count 
          ,rank() over(order by user_count desc) as rank_num
          ,count(*) as freq_count
from middle_table1 
where date_modified between (7_days_ago) and (today)
) t2 on t1.rank_num = t2.rank_num
full outer join
(select user_count 
          ,rank() over(order by user_count desc) as rank_num
          ,count(*) as freq_count
from middle_table1 
where date_modified between (3_days_ago) and (today)
) t3 on t1.rank_num = t3.rank_num
;
相关实践学习
基于MaxCompute的热门话题分析
Apsara Clouder大数据专项技能认证配套课程:基于MaxCompute的热门话题分析
目录
相关文章
|
8月前
|
存储 SQL 分布式计算
大数据之路:阿里巴巴大数据实践——元数据与计算管理
本内容系统讲解了大数据体系中的元数据管理与计算优化。元数据部分涵盖技术、业务与管理元数据的分类及平台工具,并介绍血缘捕获、智能推荐与冷热分级等技术创新。元数据应用于数据标签、门户管理与建模分析。计算管理方面,深入探讨资源调度失衡、数据倾斜、小文件及长尾任务等问题,提出HBO与CBO优化策略及任务治理方案,全面提升资源利用率与任务执行效率。
641 0
|
7月前
|
SQL 存储 分布式计算
【万字长文,建议收藏】《高性能ODPS SQL章法》——用古人智慧驾驭大数据战场
本文旨在帮助非专业数据研发但是有高频ODPS使用需求的同学们(如数分、算法、产品等)能够快速上手ODPS查询优化,实现高性能查数看数,避免日常工作中因SQL任务卡壳、失败等情况造成的工作产出delay甚至集群资源稳定性问题。
1474 36
【万字长文,建议收藏】《高性能ODPS SQL章法》——用古人智慧驾驭大数据战场
|
存储 负载均衡 算法
大数据散列分区计算哈希值
大数据散列分区计算哈希值
294 4
|
8月前
|
SQL 分布式计算 大数据
SparkSQL 入门指南:小白也能懂的大数据 SQL 处理神器
在大数据处理的领域,SparkSQL 是一种非常强大的工具,它可以让开发人员以 SQL 的方式处理和查询大规模数据集。SparkSQL 集成了 SQL 查询引擎和 Spark 的分布式计算引擎,使得我们可以在分布式环境下执行 SQL 查询,并能利用 Spark 的强大计算能力进行数据分析。
|
10月前
|
SQL 人工智能 分布式计算
别再只会写SQL了!这五个大数据趋势正在悄悄改变行业格局
别再只会写SQL了!这五个大数据趋势正在悄悄改变行业格局
222 0
|
11月前
|
SQL 存储 大数据
Dataphin V5.0:支持创建异步调用API,实现慢 SQL 复杂计算的直连消费
本文介绍了数据服务产品中异步调用的应用场景与优势,包括大数据引擎查询、复杂SQL及大规模数据下载等场景,解决了同步调用可能导致的资源浪费和性能问题。通过创建异步API、测试发布以及权限申请等功能,实现高效稳定的服务提供。以电商订单查询为例,展示了如何利用异步调用提升系统性能与用户体验。
437 9
|
SQL 大数据 数据挖掘
玩转大数据:从零开始掌握SQL查询基础
玩转大数据:从零开始掌握SQL查询基础
441 35
|
SQL 关系型数据库 MySQL
大数据新视界--大数据大厂之MySQL数据库课程设计:MySQL 数据库 SQL 语句调优方法详解(2-1)
本文深入介绍 MySQL 数据库 SQL 语句调优方法。涵盖分析查询执行计划,如使用 EXPLAIN 命令及理解关键指标;优化查询语句结构,包括避免子查询、减少函数使用、合理用索引列及避免 “OR”。还介绍了索引类型知识,如 B 树索引、哈希索引等。结合与 MySQL 数据库课程设计相关文章,强调 SQL 语句调优重要性。为提升数据库性能提供实用方法,适合数据库管理员和开发人员。
|
关系型数据库 MySQL 大数据
大数据新视界--大数据大厂之MySQL 数据库课程设计:MySQL 数据库 SQL 语句调优的进阶策略与实际案例(2-2)
本文延续前篇,深入探讨 MySQL 数据库 SQL 语句调优进阶策略。包括优化索引使用,介绍多种索引类型及避免索引失效等;调整数据库参数,如缓冲池、连接数和日志参数;还有分区表、垂直拆分等其他优化方法。通过实际案例分析展示调优效果。回顾与数据库课程设计相关文章,强调全面认识 MySQL 数据库重要性。为读者提供综合调优指导,确保数据库高效运行。