网站流量日志分析—数据入库—宽表、窄表由来概述|学习笔记

简介: 快速学习网站流量日志分析—数据入库—宽表、窄表由来概述

开发者学堂课程【大数据分析之企业级网站流量运营分析系统开发实战(第三阶段)网站流量日志分析—数据入库—宽表、窄表由来概述】学习笔记,与课程紧密联系,让用户快速学习知识。

课程地址:https://developer.aliyun.com/learning/course/695/detail/12203


网站流量日志分析—数据入库—宽表、窄表由来概述


这个概念背后所反映的正是面向分析的最高标准,一切有利于分析即可。在搞清楚概念之前,首先想一下,之前经过操作已经把数据导入到 ods 当中,接下来经过 etl 把它导入到 dw 层即可完成最后的入库操作。当然在 etl 过程当中需要抽取什么字段,转化成什么字段是根据需求相关,如果它比较 不 etl 也行,所以说本质把握住清楚。为什么 etl 过程当中会出现窄表宽表,为了更好理解它,通过一个简单的需求去感受一下什么是宽表什么是窄表,有什么区别,什么好处。

统计分析今天每个小时有多少访问量,首先第一个,宽表窄表的引入,这时候要统计访问量,今天当然是数据的一天,在 origin 原始表当中,这当中正好是今天的20181101,要统计今天当中哪个小时背后需求,要根据小时 hour 进行分组, group by 分组之后统计每个组内的个数 count ,怎么统计不是重点,重点在于分组,要统计每个小时分组,在表当中有关小时的字段,

image.png

确定一下,能跟时间相关的就是这个字段叫做 time local ,发现这字段当中包含的属性很多,有年月日时分秒,需要跟当中的06这几个记录来到同一分组,不管是六点四十九分还是六点五十分,都属于六点,只要属于六点,就应该来到同一小时当中,如果在当下的数据当中要开展分析,因为数据小时如何在字段当中一部分,需要对字段进行截取,当下的情况 group by 当中并不能而是进行截取,叫做 substring ,这是个截取符号。如何截取,从一二三四五六七八九十空格十一,从第12位开始截取两位就是这里也需要做一个相关的具体操作从第12位开始截取两位叫做 time local 字段,如果这样写,在信任有什么问题,首先要解释下到底能不能截取出来,复制做测试,select from这个表origin原始日志表,这么操作到底问题在哪里,

image.png

截取出来的是06,截取字段一样来到同一个分组问题在哪里?首先这样可以做告诉你这样做没问题,但它缺点在于每一条记录在分组之前都需要进行所谓的结局操作,截取操作完成之后截取字段一样的才能来到同一个分组,那你想一下这个数据如果有100万需要截取100万次,有3就截取3次,那么为什么会造成这种原因,有个字段叫做 time local,看上去它是一个字段,实际上它里面包含的属性非常多,刚才易解读出来了里面有什么,有年月日时分秒左边这叫做日期右边叫做时间,比如说一个字段当中如何了很多个字段属性,那么根据里面某一个字段进行操作的时候,当然就需要进行截取,虽很简单,在描写一下为什么会写下的原因叫做表中的字段看似一个字段实则糅杂了多个属性在一起,就比如时间,看似是一个字段实则糅杂了年月日时分秒还有日期时间字段,那么后边分析是不是就要进行截取唯一不方便,那这时候明白原因之后,

下一个问题怎么解决,既然是多个属性结合在一起,那接下来就要进行拆分,把糅合在一起的属性拆分出来变成单独独立的新字段,比如拆除一个新的字段就叫做 hour,在分组说直接进行 group by hour,这样分组是非常方便就不需要截取了。所以解决它之后就产生了一个结果,原来表当中的字段一个拆分出来变成多个字段变多了,表的字段变多了,所以这个表成为什么,因为表的字段相比较之前变多了,所以把它称之为宽表,相对应原来没有拆分之前原来对应的表称之为叫做窄表,所以为什么有宽表窄表,原因就在这。

又因为字段变多之后,信息变得更加具体的变得更加详细了,比如这里想看年看年,先看月看月,也把宽表看成了一个什么,叫做明细表明细的单词叫做 detail明细详细表。所以再回头调剂,又因为变宽之后信息更加详细具体,所以也可以称之为叫作明细表。这就是这个标题支点的由来,为什么会有宽表窄表明细表,原因就在于此。表当中的字段组合在一起分析的时候需要截取效率极低不利于分析,为了分析方便给它做一个拆分,那么这时候感受到宽表数据是完全来自于窄表通过我们的窄表进行截取操作,那么这时候背后能够感觉到一个忧患点一个隐藏的忧患,这两份表的数据是不是完全重复,总和度极高,答案是非常正确的融合度极高几乎百分之百融入。那么为什么还可以允许它?说到树上领域的最高标准叫什么一切有利于分析即可为。宽表的出现叫做为了分析的方便,当为了分析方便就可以把宽表给它拆分出来变成所谓的明细表,这样即使两个表的数据冗余度很高那么也可以只要费一方面就可以操作。那么这就是宽表窄表的概念,什么宽字段变多了较宽什么窄以前的相对应的层次窄表。这就是我们宽表摘窄表一个概念描述。

相关实践学习
通过日志服务实现云资源OSS的安全审计
本实验介绍如何通过日志服务实现云资源OSS的安全审计。
相关文章
|
4月前
|
SQL 人工智能 监控
SLS Copilot 实践:基于 SLS 灵活构建 LLM 应用的数据基础设施
本文将分享我们在构建 SLS SQL Copilot 过程中的工程实践,展示如何基于阿里云 SLS 打造一套完整的 LLM 应用数据基础设施。
834 68
|
4月前
|
数据采集 运维 监控
不重启、不重写、不停机:SLS 软删除如何实现真正的“无感数据急救”?
SLS 全新推出的「软删除」功能,以接近索引查询的性能,解决了数据应急删除与脏数据治理的痛点。2 分钟掌握这一数据管理神器。
276 32
|
8月前
|
存储 缓存 Apache
StarRocks+Paimon 落地阿里日志采集:万亿级实时数据秒级查询
本文介绍了阿里集团A+流量分析平台的日志查询优化方案,针对万亿级日志数据的写入与查询挑战,提出基于Flink、Paimon和StarRocks的技术架构。通过Paimon存储日志数据,结合StarRocks高效计算能力,实现秒级查询性能。具体包括分桶表设计、数据缓存优化及文件大小控制等措施,解决高并发、大数据量下的查询效率问题。最终,日志查询耗时从分钟级降至秒级,显著提升业务响应速度,并为未来更低存储成本、更高性能及更多业务场景覆盖奠定基础。
|
5月前
|
存储 缓存 Apache
StarRocks+Paimon 落地阿里日志采集:万亿级实时数据秒级查询
A+流量分析平台是阿里集团统一的全域流量数据分析平台,致力于通过埋点、采集、计算构建流量数据闭环,助力业务提升流量转化。面对万亿级日志数据带来的写入与查询挑战,平台采用Flink+Paimon+StarRocks技术方案,实现高吞吐写入与秒级查询,优化存储成本与扩展性,提升日志分析效率。
645 1
|
9月前
|
SQL 监控 数据挖掘
SLS 重磅升级:超大规模数据实现完全精确分析
SLS 全新推出的「SQL 完全精确」模式,通过“限”与“换”的策略切换,在快速分析与精确计算之间实现平衡,满足用户对于超大数据规模分析结果精确的刚性需求。标志着其在超大规模日志数据分析领域再次迈出了重要的一步。
596 117
|
5月前
|
存储 关系型数据库 数据库
【赵渝强老师】PostgreSQL数据库的WAL日志与数据写入的过程
PostgreSQL中的WAL(预写日志)是保证数据完整性的关键技术。在数据修改前,系统会先将日志写入WAL,确保宕机时可通过日志恢复数据。它减少了磁盘I/O,提升了性能,并支持手动切换日志文件。WAL文件默认存储在pg_wal目录下,采用16进制命名规则。此外,PostgreSQL提供pg_waldump工具解析日志内容。
470 0
|
5月前
|
数据采集 运维 监控
|
7月前
|
存储 NoSQL MongoDB
Docker中安装MongoDB并配置数据、日志、配置文件持久化。
现在,你有了一个运行在Docker中的MongoDB,它拥有自己的小空间,对高楼大厦的崩塌视而不见(会话丢失和数据不持久化的问题)。这个MongoDB的数据、日志、配置文件都会妥妥地保存在你为它精心准备的地方,天旋地转,它也不会失去一丁点儿宝贵的记忆(即使在容器重启后)。
848 4
|
10月前
|
人工智能 运维 监控
一招高效解析 Access Log,轻松应对泼天流量
一招高效解析 Access Log,轻松应对泼天流量
190 0
一招高效解析 Access Log,轻松应对泼天流量