电商项目之用户交易宽表分析|学习笔记

简介: 快速学习电商项目之用户交易宽表分析

开发者学堂课程【新电商大数据平台2020最新课程电商项目之用户交易宽表分析】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址https://developer.aliyun.com/learning/course/640/detail/10545


电商项目之用户交易宽表分析

 

用户交易宽表分析

上节讲到用户关注表,通过公共维度实现了数据的聚合,为之后内容做准备。接着我们来讲解用户交易宽表。

那么用户交易的宽表我们应该去哪里寻找?

应该在交易主体域。首先看我们要求的值如用户 id、地区编码、订单数量、订单金额、订单运费金额、订单优惠金额、产生时间。

createexternaltableifnotexists dws_nshop.dws_nshop_user_orders(

user_id string comment '用户id',

area_code string comment '地区编码',

orders_count int comment'订单数量',

orders_pay DECIMAL (10,1) comment '订单金额',

orders_shipping DECIMAL(10,1) comment'订单运费金额',

orders_district DECIMAL(10,1)comment '订单优惠金额',

ct bigint comment '产生时间’

) partitioned by (bdp_day string)

stored as parquet

location '/data/nshop/dws/user/dws_nshop_user_orders/ '

这些都在交易订单明细流水表中,它都是在交易主体域下,

如图

image.png

那么现在就首先需要有交易订单明细流水表

dwd_nshop.dwd_nshop_orders_details,该表中有订单 id,也有用户 id,但是在这里取值时,尽量不要取customer_id。

用户交易宽表中的地区编码不存在,需要到用户基本信息表中查找,地区编码就是下图中的所在地区customer_natives string COMMENT

image.png

所以可以修改一下用户交易宽表

customer_natives string comment '地区编码'

此处地区编码可加可不加,但是此处取到就需要加,另外在用户基本信息表中取不到地区编码,它存在用户行为日志表中,所以在写用户交易宽表时写为所在区域。

即 customer_natives string comment '所在区域'

接下来来取值,现在用到的表中有用户基本信息表,订单明细流水表中没有所在地区,需要到用户基本信息表中寻找,就需要将两者的用户 id 连接才能取到。

其它的例如订单数量可以去求对应的 count,可以对 order 进行 count,再对用户进行分组,因为一个用户可能有多个订单。

订单金额运费金额优惠金额等等在交易订单明细流水表中已经存在,直接 sum 就可以。

相关文章
|
监控 开发者
网站流量日志分析—数据入库—宽表、窄表由来概述|学习笔记
快速学习网站流量日志分析—数据入库—宽表、窄表由来概述
255 0
网站流量日志分析—数据入库—宽表、窄表由来概述|学习笔记
|
SQL 监控 数据库
网站流量日志分析—数据入库—宽表具体表现1—时间拓宽|学习笔记
快速学习网站流量日志分析—数据入库—宽表具体表现1—时间拓宽
206 0
网站流量日志分析—数据入库—宽表具体表现1—时间拓宽|学习笔记
|
SQL 监控 HIVE
网站流量日志分析--数据入库--宽表具体实现2—解析 url|学习笔记
快速学习网站流量日志分析--数据入库--宽表具体实现2—解析 url
151 0
网站流量日志分析--数据入库--宽表具体实现2—解析 url|学习笔记
|
SQL 大数据 数据处理
电商项目之用户交易宽表 SQL 实现|学习笔记
快速学习电商项目之用户交易宽表 SQL 实现
166 0
电商项目之用户交易宽表 SQL 实现|学习笔记
|
SQL 大数据 开发者
电商项目之商家用户交互记录宽表总结|学习笔记
快速学习电商项目之商家用户交互记录宽表总结
134 0
电商项目之商家用户交互记录宽表总结|学习笔记
|
大数据 开发者
电商项目之商家用户交互记录宽表分析|学习笔记
快速学习电商项目之商家用户交互记录宽表分析
169 0
电商项目之商家用户交互记录宽表分析|学习笔记
|
19天前
|
存储 关系型数据库 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 多对一和多对多
【6月更文挑战第7天】该文探讨数据模型,比较了“多对一”和“多对多”关系。通过使用ID而不是纯文本(如region_id代替"Greater Seattle Area"),可以实现统一、避免歧义、简化修改、支持本地化及优化搜索。在数据库设计中,需权衡冗余和范式。文档型数据库适合一对多但处理多对多复杂,若无Join,需应用程序处理。关系型数据库则通过外键和JOIN处理这些关系。文章还提及文档模型与70年代层次模型的相似性,层次模型以树形结构限制了多对多关系处理。为克服层次模型局限,发展出了关系模型和网状模型。
24 6
|
21天前
|
XML NoSQL 数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 概念 + 数据模型
【6月更文挑战第5天】本文探讨了数据模型的分析,关注点包括数据元素、关系及不同类型的模型(关系、文档、图)与Schema模式。查询语言的考量涉及与数据模型的关联及声明式与命令式编程。数据模型从应用开发者到硬件工程师的各抽象层次中起着简化复杂性的关键作用,理想模型应具备简洁直观和可组合性。
15 2
|
18天前
|
SQL 人工智能 关系型数据库
【DDIA笔记】【ch2】 数据模型和查询语言 -- 文档模型中Schema的灵活性
【6月更文挑战第8天】网状模型是层次模型的扩展,允许节点有多重父节点,但导航复杂,需要预知数据库结构。关系模型将数据组织为元组和关系,强调声明式查询,解耦查询语句与执行路径,简化了访问并通过查询优化器提高效率。文档型数据库适合树形结构数据,提供弱模式灵活性,但在Join支持和访问局部性上不如关系型。关系型数据库通过外键和Join处理多对多关系,适合高度关联数据。文档型数据库的模式灵活性体现在schema-on-read,写入时不校验,读取时解析,牺牲性能换取灵活性。适用于不同类型或结构变化的数据场景。
19 0
|
20天前
|
SQL JSON NoSQL
【DDIA笔记】【ch2】 数据模型和查询语言 -- 关系模型与文档模型
【6月更文挑战第6天】关系模型是主流数据库模型,以二维表形式展示数据,支持关系算子。分为事务型、分析型和混合型。尽管有其他模型挑战,如网状和层次模型,但关系模型仍占主导。然而,随着大数据增长和NoSQL的出现(如MongoDB、Redis),强调伸缩性、专业化查询和表达力,关系模型的局限性显现。面向对象编程与SQL的不匹配导致“阻抗不匹配”问题,ORM框架缓解但未完全解决。文档模型(如JSON)提供更自然的嵌套结构,适合表示复杂关系,具备模式灵活性和更好的数据局部性。
20 0

热门文章

最新文章