ICode9

精准搜索请尝试: 精确搜索
首页 > 数据库> 文章详细

数据分析【分类2】数据库

2019-08-18 20:03:14  阅读:379  来源: 互联网

标签:数据分析 map 倾斜 数据库 分类 reduce table 数据 分区


文章目录

【数据库及hive】

(1) 用过什么数据库?

(2) 数据库三范式?

1 第一范式(1NF)

在任何一个关系数据库中,第一范式(1NF)是对关系模式的基本要求,不满足第一范式(1NF)的数据库就不是关系数据库。
所谓第一范式(1NF)是指数据库表的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复
出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。在第一范式(1NF)中表的每一行
例的信息。简而言之,第一范式就是无重复的列。
那么符合第一模式的特点就有
1)有主关键字
2)主键不能为空,
3)主键不能重复,
4)字段不可以再分
在这里插入图片描述

2 第二范式(2NF)

第二范式(2NF)是在第一范式(1NF)的基础上建立起来的,即满足第二范式(2NF)必须先满足第一范式(1NF)。第二范式(2NF)要求数据库表
例或行必须可以被惟一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。这个惟一属性列被称为主关键字或主键、主码。
第二范式(2NF)要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性,如果存在,那么这个属性和主关键
应该分离出来形成一个新的实体,新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列,以存储各个实例的惟一标识。简而言之
是非主属性非部分依赖于主关键字。
在这里插入图片描述

3 第三范式(3NF)

满足第三范式(3NF)必须先满足第二范式(2NF)。简而言之,第三范式(3NF)要求一个数据库表中不包含已在其它表中已包含的非主关键字信息
一个部门信息表,其中每个部门有部门编号(dept_id)、部门名称、部门简介等信息。那么在员工信息表中列出部门编号后就不能再将部门名称、部门
门有关的信息再加入员工信息表中。如果不存在部门信息表,则根据第三范式(3NF)也应该构建它,否则就会有大量的数据冗余。简而言之,第三范
依赖于其它非主属性。(我的理解是消除冗余)
在这里插入图片描述

(3) 增量表和全量表的优缺点?

在这里插入图片描述
全量表更新逻辑缺点:
优点:
(1)能够较快地查找到目前的总量,而不用像增量表一样需要加总。
缺点:
(1)全量表,有无变化,都要报
(2)每次上报的数据都是所有的数据(变化的 + 没有变化的)
(3)读取速度较慢
(4)占用的物理空间较大

增量表的特点:
优点:
(1)记录每次增加的量,而不是总量;——这样存入的速度较快
(2)方便用于某天某月的流量的计算——日报,月报
(3)增量表,只报变化量,无变化不用报(更新可以更小幅度)
缺点:
(1)获得总量,相比全量表需要更多的计算

(4) 内部表和外部表区别?

在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
Hive的分区

添加分区

ALTER TABLE table_name ADD PARTITION (partCol = ‘value1’) location>’loc1’; //示例

ALTER TABLE table_name ADD IF NOT EXISTS PARTITION (dt=’20130101’)> LOCATION ‘/user/hadoop/warehouse/table_name/dt=20130101’; //一次添加一个分区

ALTER TABLE page_view ADD PARTITION (dt=’2008-08-08’, country=’us’) location ‘/path/to/us/part080808’ PARTITION (dt=’2008-08-09’, country=’us’) location ‘/path/to/us/part080809’; //一次添加多个分区

删除分区

ALTER TABLE login DROP IF EXISTS PARTITION (dt=’2008-08-08’);

ALTER TABLE page_view DROP IF EXISTS PARTITION (dt=’2008-08-08’, country=’us’);

修改分区

ALTER TABLE table_name PARTITION (dt=’2008-08-08’) SET LOCATION “new
location”;

ALTER TABLE table_name PARTITION (dt=’2008-08-08’) RENAME TO PARTITION
(dt=’20080808’);

添加列

ALTER TABLE table_name ADD COLUMNS (col_name STRING);
//在所有存在的列后面,但是在分区列之前添加一列

修改列

CREATE TABLE test_change (a int, b int, c int);

// will change column a’s name to a1

ALTER TABLE test_change CHANGE a a1 INT;

// will change column a’s name to a1, a’s data type to string, and put it after 、column b. The new table’s structure is: b int, a1 string, c int

ALTER TABLE test_change CHANGE a a1 STRING AFTER b;

// will change column b’s name to b1, and put it as the first column. The new table’s structure is: b1 int, a string, c int

ALTER TABLE test_change CHANGE b b1 INT FIRST;

修改表属性

alter table table_name set TBLPROPERTIES (‘EXTERNAL’=’TRUE’); //内部表转外部表
alter table table_name set TBLPROPERTIES (‘EXTERNAL’=’FALSE’); //外部表转内部表

表的重命名

ALTER TABLE table_name RENAME TO new_table_name

原文:https://blog.csdn.net/silentwolfyh/article/details/50931696

(5) 数据倾斜怎么办?——hadoop数据倾斜

1.数据倾斜是进行大数据计算时,最常遇到的问题之一,当我们在执HiveQL 或者运行MR作业时,如果遇到一直卡在map 100% ,reduce99%,最后的1% 花了几个小时都没有跑完,这种情况一般就是遇到了数据倾斜的问题.

2.数据倾斜其实是进行分布式计算的时候,某些节点计算的能力较差,或者由于此节点需要计算的数据比较多,导致出现其他节点的reduce阶段任务执行完成,但是这种节点的数据处理任务还没有执行完成。

简单来说数据倾斜就是key的分化严重不均,造成一部分数据很多,一部分数据很少的局面。

举个例子:
比如wordCount,它的map阶段,形成了(“aaa”,1)的形式,然后在reduce阶段进行value相加,得出"aaa"出现的次数。若进行wordCount的文本有100G,其中80G全部是"aaa",剩下20G根据key不同分散到不同的reduce,进行相加的情况,如此造成了数据倾斜。
在这里插入图片描述
通过上面这个图,能清楚的看到,数据经过map之后,由于key的数据量分布不均,在Shuffle阶段中,通过分组将相同的key的数据打在同一个reducer的标记,然后开始spill(一些到磁盘),最后么个人成最终map阶段输出文件。

造成数据倾斜的原因
1.key分布不均
2.业务数据本身的特性
3.建表时考虑不周
4.某些SQL语句本身就有数据倾斜

数据倾斜的影响
hadoop中数据倾斜会极大影响性能和效率

数据倾斜的表现
任务进度长时间维持在99%,查看任务监控页面,发现只有少量(1个或者几个),处理的数据量和其它reduce差异过大

单一reduce的记录数于平均记录数差异过大,通常可能达到3倍甚至更多,最长时长大于平时时长。

**Hive中产生数据倾斜的原因和解决办法

  1. group by**
    我使用Hive对数据做一些类型统计的时候遇到过某些类型的数据量特别多,而其他类型数据的数据量特别少,当 按照类型进行group by的时候,会将相同的group by 字段reduce的任务需要的数据拉取到同一个节点进行聚合,而当其中每一组的数据量过大的时候,会出现其他组的计算已经完成而这里计算还没有完成,其它节点的一直等待这个节点 的任务执行完成,所以会一直看到map 100% reduce 99%的情况。
    解决办法:
    set hive.map.aggr=true
    set hive.groupby.skewindata = true [skjuː]
    原理:hive.map.aggr = true 这个配置代表是否在map端进行聚合
    hive.groupby.skewindata = true 当选项设定为true,生成的查询计划会有两个MR Job。第一个MR Job中,Map 的输出结恶果集合会随机分布到Reduce中,每个Reduce做部分聚合操作,并输出结果,这样处理的结果是Group By key有可能被分到不同的Reduce中,从而达到负载均衡的目的,第二个MR Job在根据预处理的数据结果按照Group By Key 分布到Reduce中(这个过程可以保证相同的Group By Key 被分布到Reduce中),最后完成最终的聚合操作。

  2. map和 reduce优化
    1.当出现小文件过多,需要合并小文件,
    解决: set hive.merge.mapfiles=true
    2.单个文件大小稍稍大于配置的block的大小,此时需要适当增加map的个数
    解决:set mapred.map.tasks个数
    3.文件大小适中,但是map端的计算量非常大,如select id,count(*),sum(case when),sum(case when) 需要增加map 个数
    解决:set mapred.reduce.tasks个数

  3. 当HiveQL中包含count(distinct)时,
    如果数据量非常大,执行
    select a,count(distinct b) from group by a;
    类型的SQL时,会出现数据倾斜的问题
    解决办法:使用sum…group by 代替,eg:select a,sum(1) from (select a,b from t group by a,b) group by a;

  4. 当遇到一个大表和一个小表join操作时。
    解决办法:使用mapjoin将小表加载到内存中。
    select /*+MAPJOIN(a) * / a.c1,b.c1,b.c2 from a join b where a.c1 = b.c1

  5. 遇到需要进行join的但是关联字段有数据为空,如表一的id,需要和表二的id进行关联
    解决办法1:id为空的不参与关联
    eg:
    select * from log a
    join users b on a.id is not null and a.id = b.id
    union all
    select * from log a
    where a.id is null
    解决办法2:给空值分配随机的key值
    eg:select * from log a left outer join users b on
    case when a.user_id is null
    then concat(‘hive’,rand())
    else a.user_id end b.user_id

(6) 数据倾斜怎么办?——spark数据倾斜

0x02 数据倾斜怎么判断——长什么样子
笔者大部分的数据倾斜问题都解决了,而且也不想重新运行任务来截图,下面会分几个场景来描述一下数据倾斜的特征,方便读者辨别。
由于Hadoop和Spark是最常见的两个计算平台,下面就以这两个平台说明:

一、Hadoop中的数据倾斜
Hadoop中直接贴近用户使用使用的时Mapreduce程序和Hive程序,虽说Hive最后也是用MR来执行(至少目前Hive内存计算并不普及),但是毕竟写的内容逻辑区别很大,一个是程序,一个是Sql,因此这里稍作区分。

Hadoop中的数据倾斜主要表现在、ruduce阶段卡在99.99%,一直99.99%不能结束。

这里如果详细的看日志或者和监控界面的话会发现:

 有一个多几个reduce卡住;
 各种container报错OOM;读写的数据量极大,至少远远超过其它正常的reduce;
 伴随着数据倾斜,会出现任务被kill等各种诡异的表现。

经验:Hive的数据倾斜,一般都发生在Sql中Group和On上,而且和数据逻辑绑定比较深。

二、Spark中的数据倾斜
Spark中的数据倾斜也很常见,这里包括Spark Streaming和Spark Sql,表现主要有下面几种:

 Executor lost,OOM,Shuffle过程出错
 Driver OOM
 单个Executor执行时间特别久,整体任务卡在某个阶段不能结束
 正常运行的任务突然失败

补充一下,在Spark streaming程序中,数据倾斜更容易出现,特别是在程序中包含一些类似sql的join、group这种操作的时候。 因为Spark Streaming程序在运行的时候,我们一般不会分配特别多的内存,因此一旦在这个过程中出现一些数据倾斜,就十分容易造成OOM。

0x03 数据倾斜的原理
一、数据倾斜产生的原因
我们以Spark和Hive的使用场景为例。他们在做数据运算的时候会设计到,countdistinct、group by、join等操作,这些都会触发Shuffle动作,一旦触发,所有相同key的值就会拉到一个或几个节点上,就容易发生单点问题。

二、万恶的shuffle
Shuffle是一个能产生奇迹的地方,不管是在Spark还是Hadoop中,它们的作用都是至关重要的。关于Shuffle的原理,这里不再讲述,看看Hadoop相关的论文或者文章理解一下就ok。这里主要针对,在Shuffle如何产生了数据倾斜。

Hadoop和Spark在Shuffle过程中产生数据倾斜的原理基本类似。

大部分数据倾斜的原理就类似于,因为数据分布不均匀,导致大量的数据分配到了一个节点。

三、从数据角度来理解数据倾斜
我们举一个例子,就说数据默认值的设计吧,假设我们有两张表:

 user(用户信息表):userid,register_ip
 ip(IP表):ip,register_user_cnt

这可能是两个不同的人开发的数据表,如果我们的数据规范不太完善的话,会出现一种情况,user表中的register_ip字段,如果获取不到这个信息,我们默认为null,但是在ip表中,我们在统计这个值的时候,为了方便,我们把获取不到ip的用户,统一认为他们的ip为0。

两边其实都没有错的,但是一旦我们做关联了会出现什么情况,这个任务会在做关联的阶段,也就是sql的on的阶段卡死。

四、从业务计角度来理解数据倾斜
数据往往和业务是强相关的,业务的场景直接影响到了数据的分布。

再举一个例子,比如就说订单场景吧,我们在某一天在北京和上海两个城市多了强力的推广,结果可能是这两个城市的订单量增长了10000%,其余城市的数据量不变。

然后我们要统计不同城市的订单情况,这样,一做group操作,可能直接就数据倾斜了。

0x04 如何解决
数据倾斜的产生是有一些讨论的,解决它们也是有一些讨论的,本章会先给出几个解决数据倾斜的思路,然后对Hadoop和Spark分别给出一些解决数据倾斜的方案。

注意: 很多数据倾斜的问题,都可以用和平台无关的方式解决,比如更好的数据预处理, 异常值的过滤等,因此笔者认为,解决数据倾斜的重点在于对数据设计和业务的理解,这两个搞清楚了,数据倾斜就解决了大部分了。

一、几个思路
解决数据倾斜有这几个思路:

 业务逻辑,我们从业务逻辑的层面上来优化数据倾斜,比如上面的例子,我们单独对这两个城市来做count,最后和其它城市做整合。
 程序层面,比如说在Hive中,经常遇到count(distinct)操作,这样会导致最终只有一个reduce,我们可以先group 再在外面包一层count,就可以了。
 调参方面(看同问题上一篇),Hadoop和Spark都自带了很多的参数和机制来调节数据倾斜,合理利用它们就能解决大部分问题。

二、从业务和数据上解决数据倾斜
很多数据倾斜都是在数据的使用上造成的。我们举几个场景,并分别给出它们的解决方案。

数据分布不均匀:

前面提到的“从数据角度来理解数据倾斜”和“从业务计角度来理解数据倾斜”中的例子,其实都是数据分布不均匀的类型,这种情况和计算平台无关,我们能通过设计的角度尝试解决它。

 有损的方法:
找到异常数据,比如ip为0的数据,过滤掉
 无损的方法:
对分布不均匀的数据,单独计算
先对key做一层hash,先将数据打散让它的并行度变大,再汇集
 数据预处理

三、Hadoop平台的优化方法
列出来一些方法和思路,具体的参数和用法在官网看就行了。
 mapjoin方式
 count distinct的操作,先转成group,再count
 万能膏药:hive.groupby.skewindata=true
 left semi join的使用
 设置map端输出、中间结果压缩。(不完全是解决数据倾斜的问题,但是减少了IO读写和网络传输,能提高很多效率)

四、Spark平台的优化方法
列出来一些方法和思路,具体的参数和用法在官网看就行了。
 mapjoin方式
 设置rdd压缩
 合理设置driver的内存
 Spark Sql中的优化和Hive类似,可以参考Hive

(7) 会不会建表?

导入sql文件
source d:/work/文件名.sql;(此处为正斜杠"/")
CREATE TABLE <表名>
(
列名1 数据类型 [列级别约束条件][默认值],
列名2 数据类型 [列级别约束条件][默认值],
……
[表级别约束条件]
);

查看数据表的基本结构:
法一:SHOW COLUMNS FROM tbl_name;
法二:DESCRIBE <表名>/简写:DESC <表名>;

下一步便是在这个数据库中建表,一个数据库可以建立很多个表,在这里我建3个表。
首先我建立一个学生信息表,建表语句为
create table student
( sno char(12) primary key,/列级完整性约束条件, sno为主码/
sname char(20),
ssex char(10),
sage char(3),
sdept char(20) );

我们再建一个带有外码的课程表(如果每一门课需要有个入门课,前提条件,需要设定为外键;)
create table course
( cno char(5) primary key,
cname char(20),
cpno char(5),
ccredit char(3),
foreign key (cpno) references course(cno));
//这里我们将外码设为cpno(先行课),那么被参照的是course表中的cno列,被参照的表可以不是自己。

我们再建立一个主码由两个属性构成的学生选课表sc
create table sc
( sno char(12),
cno (3),
grade char(3),
primary key (sno, cno),
foreign key (sno) references student(sno),
foreign key (cno) references course(cno) );
//外码的意义在于保证两个表之间的数据的一致性,并且必须是另一个表的主码,比如我们在学生选课表的学号,
这列的信息,学生信息的学号类必须要有这个人;课程表中的先行课一列中,课程表的课程中有这门课。

show tables;
show columns from student;
show columns from course;
show columns from sc;

insert into student values (“11111”, “chen”, “female”,“20”,“math”);
insert into student values (“11112”, “chen”, “female”,“20”,“math”); # 唯独sno主键不一样,即可

select * from student;
select distinct(sname) from student;

修改数据类型——把性别的数据类型改大一些
alter table student modify column ssex char(100);
show columns from student;

我们现在输入课程表,在课程表中存在约束条件,则应该先输入没有先行课的课程,那么我们便执行语句
insert into course values (“5”, “数据结构”, null, “2”);

再将以“5”号课程为先行课的课程输入进去
insert into course values (“1”, “数据库”, “5”, “4”);
select * from course;

如果想于先行课(第2课)之前加入该课程(第3课), 可以先把它设置为null, 之后再更新ALTER
insert into course values(“3”,“数学”,null,“2”);
insert into course values(“2”, “基础数学入门”,null,“4”);
select * from course;

再更新ON DUPLICATE KEY UPDATE
update course set cpno = “2” where cno = “3”;
select * from course;

数据库建表-- 一对多/多对一/一对一/多对多 关系
关联映射:一对多/多对一:存在最普遍的映射关系,简单来讲就如球员与球队的关系;一对多:从球队角度来说一个球队拥有多个球员 即为一对多多对一:从球员角度来说多个球员属于一个球队 即为多对一数据表间一对多关系如下图:
在这里插入图片描述
注:一对多/多对一关系简记:“多”的要记住“一”的主键,即每个球员表都要通过外键来记住球队表。

关联映射:一对一关系就如球队与球队所在地址之间的关系,一支球队仅有一个地址,而一个地址区也仅有一支球队。数据表间一对一关系的表现有两种,一种是外键关联,一种是主键关联。图示如下:
一对一外键关联:
在这里插入图片描述
一对一主键关联:要求两个表的主键必须完全一致,通过两个表的主键建立关联关系
在这里插入图片描述

关联映射:多对多
多对多关系也很常见,例如学生与选修课之间的关系,一个学生可以选择多门选修课,而每个选修课又可以被多名学生选择。 数据库中的多对多关联关系一般需采用中间表的方式处理,将多对多转化为两个一对多。
数据表间多对多关系如下图:
在这里插入图片描述

(8) 数据仓库

ETL
数据抽取(Extract)、转换(Transform)、清洗(Cleansing)、装载(Load)的过程。是构建数据仓库的重要一环,用户从数据源抽取出所需的数据,经过数据清洗,最终按照预先定义好的数据仓库模型,将数据加载到数据仓库中去。

(9) 如果一个数据维度很多,如何展示?

《数据挖掘导论(人大)》
矩阵:图像可以看做像素的矩形阵列,其中每个像素用它的颜色和亮度刻画。
平行坐标系:

(10) 星型模型和雪花模型的优缺点

https://blog.csdn.net/nyotengu/article/details/81362025
描述的是数据仓库的建模两种形式。在多维分析的商业智能解决方案中,根据事实表和维度表的关系,又可将常见的模型分为星型模型和雪花型模型。

星型模型

当所有的维表都直接连接到“事实表”上时,整个图解就好像星型一样,所以称为星型模型。多维的数据集的每一个维度都直接和事实表相连接,不存在渐变的维度,所以数据有一定的冗余。比如在地区的维度表中,如果存在着A国家的B省的C市,以及A国家的B省的D市,那么A和B分别储存了两次,存在着冗余。
在这里插入图片描述
优点:因为数据的冗余(缺点),所以很多的统计查询不用做外部的连接,因此一般情况下,效率要比雪花模型要高。
缺点:数据的冗余。

雪花模式

当一个或者多个的维表没有直接链接到事实表上,而是通过其他的维表连接到事实表上时,其图解就好像多个雪花连接到一起,称为雪花模型。它是对星型模型的扩展,以及进一步的层次化。原来的维表都可以进一步地被扩展为小的事实表,形成局部的层次。比如刚才那个国家、省市的例子,雪花模型就可以把它们分解到国家、省份、城市等维表。
在这里插入图片描述
优点:(1)通过最大限度的减少数据的储存量,以及联合较小的维表,来改善查询性能。去除了数据的冗余。
缺点:(1)由于相比较星型模型没有冗余,所以查找的时候,需要通过表的连接来完成,所以效率不一定有星星模型高。(2)数据库的正规化也是较为复杂,同时数据库的设计、维护等成本要高一些。(因此如果冗余可以一定程度接受的话,实际上运用星星模型更多,效率也更高。)

(11) 缺失值达到一个阈值则对该列属性进行删除,这个阈值怎么确定呢?

缺失值处理方法:
http://www.baidu.com/link?url=O9ozKLTsWRbyuMuZJ57HtXAvugY_oaXxUcfvoLIdQk1160PDc1RVe9nnRHP6LsU0-jWssI-X6Lm6c8VgwfDlQ_&wd=&eqid=d37fac3e00066449000000065cc6d7d2

https://www.cnblogs.com/bjwu/articles/9077299.html

缺失值比率
该方法基本的思想就是基于包含太多缺失值的数据列所包含有用信息的可能性也就应当越少。所以,我们可以将数据缺失值大于某个阈值的列去掉。阈值越高,降维方法更为积极,即降维越少。一般地,数据缺失值大于90%的时候,我们可以考虑把这列去掉。在某些特定的行业如信用评分建模时,我们可以考虑把缺失值大于90%的变量设置成特殊规则。scikit-learn中没有类似的函数,但我们可以考虑使用pandas包的dropna方法:

import pandas as pd
df=pd.read_csv(‘your_data_file’)
rowsOfTotal= len(df)
rowsOfNonMiss = rowsOfTotal * (1-0.9) #假定缺失值比例的阀值为90%,若缺失值大于90%的列将被去除
df.dropna(thresh=rowsOfNonMiss,axis=1,inplace=True)

确定的方法:

(12) 对连续变量进行离散特征的计算时,什么时候用等量划分?什么时候用等值划分?如果划分的话划分为多少份?

离散化的好处:
 离散化后可以进行特征交叉,由M+N个变量变为M*N个变量,进一步引入非线性,提升表达能力。
 特征离散化后,模型会更稳定,比如如果对用户年龄离散化,20-30作为一个区间,不会因为一个用户年龄长了一岁就变成一个完全不同的人。
 逻辑回归属于广义线性模型,表达能力受限;单变量离散化为N个后,每个变量有单独的权重,相当于为模型引入了非线性,能够提升模型表达能力,加大拟合
 稀疏向量内积乘法运算速度快,计算结果方便存储,容易扩展
 离散化后的特征对异常数据有很强的鲁棒性:比如一个特征是年龄>30是1,否则0。如果特征没有离散化,一个异常数据“年龄300岁”会给模型造成很大的干扰

我认为需要依照变量的特征来判断。
 从异常值的避免来看,如果有个极大的异常值,那么等值划分可以把它归到最前面一类或者最后面一类,减少模型的误差;连续变量和等量化分则做不到。比如异常值年龄300岁,等值划分比其它两种情况要好。
 从模型的稳定性来看。比如在游戏公司,如果用户有年龄这个连续变量,那么最好进行等值划分(比如把年轻人化为一类,把成立家庭时间较少的中年人划为一类),这样子不会因为年龄增加一岁而产生较大的变化。
 从数据本身来看。如果大量数据的重复值较多,那么等量划分是可以考虑的。如果分布非常分散,则最好考虑等值分布。
 考虑变量对模型预测的影响:如果XY为近乎严格的线性关系,那么可以用等量;如果在一个区间内,变量的变化不足以引起较大的Y 的变量,那么可以用等值划分。

分段的策略:
 分段策略足以使得每个X的分段中,样本的分布尽量均匀。

(13) AB实验的实验时长如何控制?一天不够长,为什么?十天会不会太长,为什么?如果出现了A版本前三天点击率上升,后七天由于用户热情退却点击率下降,怎么向你的老板汇报?

AB实验的介绍:
我们可以做个实验,把a和B方案同时放到线上的生产环境,让一部分用户使用 A 方案,另一部分用户使用 B 方案,记录下用户的使用报表如下图,通过大自然的优胜劣汰法则,我们可以通过CTR(Click-Through-Rate)即点击通过率,或下单率等指标看哪个方案更符合设计目标。

专家建议运行测试至少要7天,最佳时间是两周。数据样本越大,信息就越准确、真实。

A版本前三天点击率上升,后七天由于用户热情退却点击率下降,怎么向你的老板汇报?
对于游戏来说,无论是移动端还是PC,线上或者单机,都需要保持较高的用户留存率。出现这样的情况,说明用户可能是因为最开始经历了新颖的版本而有一定的新鲜感,但是长期使用会显示出用户真正的需求方向,需要对比B版本来进行讨论。这也照应了前一题的实验时长的题目,需要保持足够的时间跨度收集足够的信息。

(14) 怎么发现异常值? (逻辑回归)异常数据处理(假设年龄和性别缺失,应该怎么处理)

 检测一元正态分布的离群点:三个标准差之外的概率极低
 多元正态分布的离群点:点到基础分布的均值距离和点发生的概率是直接相关的。
其他:
 K近邻:基于邻近度的离群点检测。优点是,方案简单。缺点是,时间是样本数量的平方
 基于密度的离群点检测。

异常数据的处理:
估算:用平均值、中值、分位数、众数、随机值等替代
直接删除

(15) python中三个函数(reduce,map,filter)

map

使用定义的函数
def fun(x):
return x**2
list(map(fun,l1))

使用匿名函数
list(map(lambda x:x**2, l1))
list(map(lambda x, y:x+y, l1, l2))

转换类型
list(map(int,l4))

filter
filter ,筛选 sequence中的每一个元素
filter (function, sequence)
python 2. 中返回list,python 3. 需加list()转换
‘’’

筛选元素,filter() 与 map() 返回值不同
list(filter(lambda x: x>2, l1))
#[3, 4, 5]
list(map(lambda x: x>2, l1))
[False, False, True, True, True]

reduce 求积累运算
函数将一个数据集合(链表,元组等)中的所有数据进行下列操作:用传给 reduce 中的函数 function(有两个参数)先对集合中的第 1、2 个元素进行操作,
得到的结果再与第三个数据用 function 函数运算,最后得到一个结果。
reduce(function, sequence)
‘’’
from functools import reduce
reduce(lambda x,y: x+y, l1)

(16) map reduce 和 hadoop中的mapreduce一样。map是对迭代元素的逐个操作,是并行的,reduce是对迭代结果参数的汇总,可以理解为串行的。

(17) mapreduce详细原理

map是指对指定序列做指定函数的相关映射
python2返回的是列表
python3返回的是元组

def f(x):
return x**2
map(f,[1,2,3,4])

out:[1,4,9,16]

map(lambda x,y:x+y,[1,2,3],[4,5,6])
out:[5,7,9]

reduce函数
在python2中reduce函数是一个内置函数,但是python3中是一个类,需要导入
from functools import reduce
reduce[function,sequence,[inital]]
reduce依次从sequence中取一个元素,和上一次调用function的结果做参数再次调用function。inital是和function的作用的值,这里理解为function不能为一个参数的函数。
def f(x,y):
return x+y
reduce(f,[1,2,3,4])
out:10
reduce(f,[1,2,3,4],100)
out:110

filter:过滤,不满足函数条件的元素被过滤掉,只返回符合条件的元素
filter(function,interable)
function是返回布尔值的函数
def is_odd(x):
return x%2==1
filter(is_odd,[1,2,3,4])
out:[1,3] #这是python2的返回结果
python3返回的是一个迭代器,可迭代,但不是列表。

(18) mapreduce对数据实现从大到小排序

(19) hdfs和别的数据库的区别,hdfs的特点

(20) Hivesql内置函数

(21) SPARK,hadoop的原理

(22) 数据库的建立、维护问题

(23) 索引的工作原理及其种类(见另外一份整理)

(24) 数据库优化的思路(看另外一份整理过来)

(25) hive分区了解吗

https://blog.csdn.net/albg_boy/article/details/77970615 基础
一、什么是分区,以及为什么分区?
1、分区是储存位置的物理区别,表实质上被分割了;而group by等只是对表进行查询时的非显示区别,实质表并未被分割。
2、在Hive Select查询中一般会扫描整个表内容,会消耗很多时间做没必要的工作。有时候只需要扫描表中关心的一部分数据,因此建表时引入了partition概念【注意partition与group by distribute by的区别】。
3、分区表指的是在创建表时指定的partition的分区空间。
4、如果需要创建有分区的表,需要在create表的时候调用可选参数partitioned by,详见表创建的语法结构。

二、技术细节
1、一个表可以拥有一个或者多个分区,每个分区以文件夹的形式单独存在表文件夹的目录下。
2、表和列名不区分大小写。
3、分区是以字段的形式在表结构中存在,通过describe table命令可以查看到字段存在,但是该字段不存放实际的数据内容,仅仅是分区的表示。
4、建表的语法(建分区可参见PARTITIONED BY参数):
5、分区建表分为2种,一种是单分区,也就是说在表文件夹目录下只有一级文件夹目录。另外一种是多分区,表文件夹下出现多文件夹嵌套模式。
a、单分区建表语句:create table day_table (id int, content string) partitioned by (dt string);单分区表,按天分区,在表结构中存在id,content,dt三列。
b、双分区建表语句:create table day_hour_table (id int, content string) partitioned by (dt string, hour string);双分区表,按天和小时分区,在表结构中新增加了dt和hour两列。

https://blog.csdn.net/cry970795248/article/details/83214750
https://blog.csdn.net/cry970795248/article/details/83214750

分区的目的:hive为了避免全表扫描,从而引进分区技术来将数据进行划分。减少不必要数据的扫描,从而提高效率。
分区的根据:
只要是某个标识就可以把数据区分开来,比如年月日,或者地区,性别。
分区关键字:
Portioned by 字段

Hive分区——二级分区

代码:
Create table if not exists u2(
Id int,
Name string,
Age int
)
Partitioned by (month int, day int)
Row format delimited fields terminated by ‘ ‘
Stored as textfile;

导入的数据情况——按照月和日分开

(26)

标签:数据分析,map,倾斜,数据库,分类,reduce,table,数据,分区
来源: https://blog.csdn.net/iven2166/article/details/89785614

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有