开发者学堂课程【大数据分析之企业级网站流量运营分析系统开发实战（第四阶段）： 网站流量日志分析--统计分析--基础指标统计分析（pv、uv）】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/696/detail/12213
网站流量日志分析--统计分析--基础指标统计分析（pv、uv）
内容介绍：
一、模块开发-统计分析
二、基础指标多维统计分析
一、模块开发-统计分析
1、数据仓库建设好以后，用户就可以编写 Hive SQL 语句对共进行访问并对共中数据进行分析。
2、在实际生产中，企业实际开发过程中，究竞需要哪些统计指标通常由数据需求相关部门人员提出，而且会不断有新的统计需求产生，以下为网站流量分析中的一些典型指标示例。
3、对于开发者，要做的就是正确解读理清指标背后的业务含义，不要出现歧义，思考在书上哪些表可以支撑指标的计算以及思考编写 Hive SQL 时怎么能够计算出来指标。
二、基础指标多维统计分析
1、基础指标统计
对于指标业务含义的解读是关键。基础指标又称为骨灰级指标，是任何一家公司开展网站分析中必须要计算的，大家都要来计算的，指标很简单，但是要理清它背后的含义，并且思考该通过怎样的数据和方式把它计算出来。
（1）PageView 浏览次数(pv)。
一天之内网站页面被加载的总次数，一天之内请求一次页面 pv+1，请求多次pv累加。
数据表：确定数据所在的表是哪个，通过哪个表可以计算指标，如果直接有表就直接用，如果没有考虑要怎么把它变出来。
分组字段：在实际的开发中有大量的分组统计，分组可能不只一个，根据需求进行确定，分组就是 geluba 后面的字段。
度量值：取值还是取个数，取最大值还是最小值，平均值还是 top n。
打开 hive 服务器，show tables 查看当前数据中有几种表，一个宽表，一个origin窄表，当有宽表和窄表存在的情况下，窄表将会退出历史舞台，它俩的数据完全冗余，并且宽表的信息更加的明确，明细，还有两份典型业务模型的延伸表，里面往往是业务延伸，点击流用户的会话筛除相关的轨迹线，当下不做考虑，t dim time 时间唯独表，在计算一些指标情况下，如果不出意外，绝大多数所依赖的表都是宽表，其他的可能需要延伸表或其他的表进行计算。
数据表：dw_ weblog_ detail
分组字段：根据指标梳理一下，一天之内网站页面被加载的总次数，天像是分组字段，比如数据是每天每天的数据，1号2号3号4号5号，达到每一天要做分组，通过解读需求感觉到分组字段有时间唯独的分组，时间（day），查看宽表的结构，用desc formatted dw weblog detail；查看，宽表是分区表，分区字段是datestr，
输入show partitions dw weblog detail；查看分区信息，可以看到当前宽表中有一个分区，而分区的时间恰好是20181101，意味着数仓后期维护，数据将按照天进行划分，一天一分区，day 比较特殊，还是表的分区字段，通过分区过滤就可以找到这一天，通过 where 分区过滤即可。
度量值：可以把宽表数据打出来，可以在hive的终端用星显示，也可以复制出来放在笔记中，下图是宽表的数据结构，如果不加任何考虑，就可以把一条日志当作一个点击行为，一个页面加载行为，但是这样计算不精准，不加任何考虑就是 count（*），有多少个日志就有多少个pv。
查询语句关键字 select，from 后面查询操作表，宽表 detail 表，为了方便，起个别名t，通过上述分析知道过滤是分区过滤，要找一天之内的，根据分区字段进行过滤，分区是字符串类型，用引号括起来，其他天指令即可，输入代码，结果是13770，这样计算不精准。
select
count(*) as pv
From dw _weblog_ detail t where t. datestr="20181101"; --不精准
当中所有的请求都当作页面点击的次数，但是只有请求界面才可以称之为有效的数据，这样 count(*)是把所有的请求当作页面点击的次数，对指标进行梳理发现一天之内网站页面被加载的总次数，只有请求页面才能称之上是有效的数据，在request字段发现，有的请求 png，有的请求 jpg，有的请求页面，有的请求是静态资源的，为了更加准确精准是页面被加载的次数，应该把静态资源的请求过滤掉，在数据预处理时通过valid的校验服务，标记位，把没有包含在静态资源的，或者不合法的复制，过滤一下，所以针对 pv 指标想要精准的计算，应该在 select 基础上加一个过滤静态资源，and 后面加条件，valid 要确定是什么类型的，打开 hive 看表是什么类型的，后面是 string，字符串类型。
select
count(*) as pv
From dw_ weblog. detail t where t . datestr="20181101" and t.valid = "true";
--精准过滤了静态资源的请求 贴近实战
在 hive 中执行，pv76，明显更贴近于实际，比较准确。要注意它的准确度，在项目中因为数据量比较小，所以以第一个作为 pv 值，但是背后要搞清楚哪一个更贴近于实战。
（2）Unique Visitor 独立访客(UV)
一天之内不管来多少次都只算一次，独立访客数，指标理解很简单，难点在于怎么确定人。
一天之内不重复的访客数，
计算的关键是对访客的识别，就是怎么识别是不同的人，在数据中有两个字段比较特殊，一个是 remote addr，一个是 remote user，但是在项目中比较尴尬，用户标识字段是一个丢失的字段，数据没有收集到，因此如果以 cookie 表示用户，当然是非常精准的，但是数据丢失又不能计算，这时产生一个问题，可以不可以用 ip 表示用户，如果可以，它与真是用户数据之间有什么区别，ip可以代表人，一个 ip 代表一个用户，区别在于用 ip 代表用户，它不精准不准确，在当下的现实中，一个公司一层楼或者一个小区，都是不同的用户不同的人，都上网，但是上网时公网ip可能只有一个，用 nvp 转换技术，保证上网。
看图中两 个 ip 像同一个 ip，可能是同一个人，也可能是两个人，因此比较明确，以项目给的 ip 作为标识。
计算的关键是对访客的识别。以 ip 作为判断标识不精准技术上是一一样的。
数据表：宽表，没有涉及到点击流相关的概念。dw_ weblog_ detail
分组字段：统计的是 ip 不重复，时间( day) day 比较特殊 还是表的分区字段通过where 分区过滤即可。
度量值：统计一天之内不重复的访客数，如果直接 count ip 就会出现重复值，在 sql 层面进行去重统计。count(distinct remote_ addr)
select
count (distinct remote_ addr) as uv
from dw_weblog_ detail t where t .datestr="20181101"; --以 i p 计算 uv 不精准
放在 hive 中执行，结果是1027，结果不准确。
不是 count remode，而是 count remode user，假如 cookie id 用户标记存在，会更加的精准。
select
count(distinct remote_ user) as uv
from dw_weblog_ detail t where t. datestr="20181101";-以 user ID 计算 准确
