220413数据分析总结

Nborh

已于 2022-05-27 16:33:25 修改

阅读量136

点赞数

文章标签：数据分析 hive 数据挖掘

于 2022-05-27 13:47:37 首次发布

本文链接：https://blog.csdn.net/Nborh/article/details/124312913

版权

前言

220413数据分析中, 所得出的分析结论包括: 居家办公期间对于洗浴和清洁的需求降低, 使用厨房场景的次数增多, 并且用餐时间相对于平时发生了一些变化. 除此之外我对220413的数据分析工作进行了经验的总结, 包括获取数据的环节以及探索业务的环节.

一、数据洞察

1. 获取数据

使用大数据工具进行查询, 我们使用的工具有哪些特点?
还可以使用哪些工具来查询分析数据?
总结查询代码的实践经验和犯过的错误
通过什么方式系统地提升优化查询的能力?

我使用的的HUE可以在浏览器端的Web控制台上查询数据, HUE可以与其他框架集成, 例如企业提供了与IMPALA和HIVE的两个集成. 总结一下实践过程中 Impala 和 Hive 的对比: Impala 更快, 使用了其他的优化技术, 例如 Impala 没有像 Hive 一样使用 MapReduce 进行并行计算. Impala 在查询过程中没有容错逻辑, 如果执行过程中发生故障则直接返回错误, 这时候我们重新再查一次就好了. Hive 适合长时间的批处理查询分析, Impala 适合交互式SQL查询.

目前对于其他工具的了解: 第一, Navicat是类似与HUE的工具. 第二, MySql一类的数据库, 通过给各个用户不同的权限来决定用户能够进行哪些操作. 第三, 开发人员可以使用JDBC的接口来操作不同的数据库, 也可以通过Python的接口来查询数据.

总结实践SQL代码的经验 , 不过这只限于我所使用的工具, 不一定适用其他的工具.

--0
select day, count(id) 
from DWS 
where city_name= 'bj'
and appname='bj' 
and day between "2022-01-01" and "2022-04-01" 
GROUP BY day  
order by day asc;

--1
select day, count(id) 
from DWS 
where day between "2022-01-01" and "2022-04-01" 
and appname='bj' 
and city_name= 'bj'
GROUP BY day  
order by day asc;

数据仓库架构往往会有时间分区, 数据分区包括范围分区, 列表分区和哈希分区. 例如, 按照数据表中时间值的范围进行分区, 就是范围分区. 按照各个离散的新闻标签对新闻数据进行分类, 就是列表分区. 哈希分区能自动完成数据在分区上均匀分布.

--不使用子查询
SELECT base.day, count(base.id) 
FROM      
    DWD as base
    INNER JOIN
    DWS notbase
    ON base.id = notbase.id
WHERE 
base.day between "2022-01-01" and "2022-04-01" 
AND notbase.appname = 'bj'
AND notbase.city_name= 'bj'
GROUP BY base.day  
order by base.day asc;

--使用子查询
with sub_id
AS( SELECT id
    FROM DWS as notbase
    WHERE appname = 'bj'
    AND city_name = 'bj'
)
SELECT base.day, count(base.id) 
FROM 
    DWD as base
    INNER JOIN 
    sub_id
    ON 
    base.id = sub_id.id 
WHERE
base.day between "2022-01-01" and "2022-04-01" 
GROUP BY base.day  
order by base.day asc;

在进行联表操作的时候, how join 问题最常用的还是 inner join. 其实我认为子查询是非常适合人的阅读的, 但我在最开始使用子查询其实是因为 join 条件中解决 " id = (SELECT id FROM ...... ) " 一对多的错误暂时不会处理, 后来我发现这可以用简单的 WHERE 条件解决.

--数据去冗余 
with sub_id
AS( SELECT distinct id
    FROM DWS as notbase
    WHERE appname = 'bj'
    AND city_name = 'bj'
)
SELECT distinct base.day, base.use_duration, base.begin_hour, base.end_hour
FROM 
    DWD as base
    INNER JOIN 
    sub_id
    ON 
    base.id = sub_id.id 
WHERE
base.day between "2022-01-01" and "2022-04-01" 
AND
base.use_duration > 600
GROUP BY base.day  
order by base.day asc;

去重: 在查询一部分数据的时候, 由于数据的特点发现存在很多完全一样的数据. 去重逻辑在于, 日期和小时存在重复很正常, 但是我们通过引入开始和结束时间(精确到秒这个维度), 很大概率上不会存在四个指标完全相同但是数据却不相同的情况, 直接用 distinct 的方式做到去重.

要系统的学习如何优化SQL代码, 首先SQL的基础知识从《SQL必知必会》开始尽量做到规范，接着深入体系《Oracle架构体系》和《高性能MySQL》, 了解分布式也很重要《维度建模》和《大数据之路》

2. 探索业务

数据在分析之前, 用数据来探索业务行为时要注意哪些工作? 探索时, 如果发现数据质量不理想的话要做哪些工作?

有的时候我们对于数据表中字段的含义并不理解, 自然就不可能展开分析, 理解数据含义除了咨询内部的数据开发人员, 更重要的方法是自己尝试理解整个业务场景, 站在用户的角度用经验来寻找对字段的合理解释.

要理解数据再深一层次的意义, 需要借助描述性统计的方法. 我们使用了excel 中的一些方法, 比如说日数据变动不明显的情况下, 我通过求每天的变化率, 正负值标以红绿两色来帮助找到规律, 我们发现了周末和工作日存在的明显不同. 比如说对多个维度(小时段, 日期, 次数)的数据进行描述性统计, 需要对原始数据做数据透视表.

我们在挖掘数据的时候可能发现数据在某个地方可能出现了很大的错误, 不能够理解这样的错误, 这个时候挽救的办法是根据数据表的血缘分析, 找到这个数据表的上游来找到可能正确的数据. 不过很大的可能是, 你没办法找到正确的上游数据表, 或者所有的上游数据表都不满足你对数据质量的要求, 这个时候建议抛弃异常值或者对其做平滑处理.

我用到了一些可视化的经验方法: 第一, 超过三维的数据作图是比较困难的, 最好是降维处理方便理解. 第二, 可以使用前端开发常用的工具作图, 但是建议在分析的后期使用, 前期尽量使用简单的绘图办法, 以免绘图需求变动带来不必要的工作量. 第三, 企业内部以往的分析报告往往具有很好的参考价值, 对于企业内部人员来说大家可能更习惯某些可视化方法.