本文主要介绍与大数据相关的技术和项目
1.文章介绍介绍
1.2
项目介绍
1.3 项目指标
1.3.1离线指标
1.3.2实时指标
1.3.最难的两个指标
1.4项目遇到问题
1.4.1 Sqoop
1.4.2Flume
1.4.3Kafka
1.4.4Hadoop
1.5 项目相关流程问题
1. 如何确保你写的 sql 正确性？
2. 测试数据从哪里来？
3. 测试环境如何？
4. 测试后如何上线？
5. 你的项目工作流程是什么？
6. 项目实际工作流程？
7.公司项目版迭代多久一次，多久一次 ，迭代到哪个版本？
8.项目开发中每天做什么？
9.DWD层层做了什么？
DWD层做了哪些事？
项目收获？
第2章 涉及技术
2.1 Linux&Shell
2.1.1 Linux常用的高级命令
2.1.2 Linux常用的工具和写脚本
2.1.3 Shell单引号和双引号的区别
2.2 Hadoop
2.2.1 Hadoop基本概念
2.2.2 Hadoop常用端口号
2.2.3 Hadoop 配置文件和简单Hadoop 集群搭建
2.2.4 HDFS 读写过程
2.2.5 NameNode工作机制SecongdaryNameNode恢复工作流程
2.2.6 HDFS组成架构及主要作用
2.2.7 Hadoop集群启动时要启动哪些进程？作用？
2.2.8 MapReduce工作原理
2.2.9 MapReduce中shuffer机制
2.2.10 MapReduce中切片机制
2.2.11 Yarn工作机制
2.2.12 hadoop的调Yarn调度器，你们使⽤的是哪种策略，为什么？
2.2.13Hadoop、MapReduce数据倾斜怎么处理？
2.2.14HDFS小文件处理
2.2.15Hadoop宕机
2.2.16Hadoop项目经验之基准测试
2.2.16 HDFS在上传文件时,其中一个 DataNode 突然挂掉怎么办
2.2.18 项目经验之压缩
2.2.19 Hadoop优化
2.3 ZooKeeper
2.3.1 ZooKeeper概述
2.3.2 ZooKeeper选举机制
2.3.3 ZooKeeper常用命令
2.3.4 ZooKeeper监听器原理
2.3.5 ZooKeeper 部署方式有哪几种？集群中角色有哪些？最少要几台机器？
2.4 Flume
2.4.1 Flume概述
2.4.2 Flume组成，Put事务，Take事务
2.4.3 Flume拦截器
2.4.4 Flume 监控器
2.4.5 Flume 采集数据会丢失吗？
2.4.6 Flume 参数调优
2.4.7 Flume 优化
2.5 Kafka
2.5.1 Kafka概述
2.5.2 为什么使用kafka
2.5.3 kafka消息队列与传统消息队列区别
2.5.4 kafka主备模式
2.5.5 kafka高吞吐量
2.5.6 kafka架构
2.5.7 kafka机器数量、副本设定、日志保存时间、硬盘大小
2.5.8 kafka中数据量计算
2.5.9 kafka的ISR副本同步队列
2.5.10 kafka挂掉
2.5.11 kafka数据重复
2.5.12 kafka消息数据积压， Kafka消费能力不足怎么处理？
2.5.13 Kafka 消费过的消息如何再消费？
2. 5.14 kafka 的数据是放在磁盘上还是内存上，为什么速度会快？
2.5.15 为什么 Kafka 不支持读写分离？
2.65 MySQL
2.65.1 DDL,DML,DQL,DCL
2.65.1 索引
2.65.2 存储结构
2.65.3 b-tree 和b+tree 的区别
2.65.3 MySQL 的事务要素ACID以及并发问题，脏读幻读和隔离级别等
2.6 Hive
2.6.1 Hive概述
2.6.2 Hive和数据库的比较
2.6.3 Hive内部表和外部表区别
2.6.4 4个by区别
2.6.5 系统函数
2.6.6 窗口函数
2.6.7 自定义UDF、UDTF函数
2.6.8 Union与Union all区别
2.6.9 Hive有哪些计算引擎，区别？
2.6.10 Hive索引吗？
2.6.11 运维如何对hive进行调度
2.6.12 使用hive解析过JSON串吗？
2.6.13 sort by 和 order by，group by, distribute by区别？
2.6.14 hive分区和分桶
2.6.15 hive数据倾斜处理？
2.6.16 hive中表有几类？
2.6.17 hive有哪些数据类型及类型转换？
2.6.18 hive 中drop、truncate和delete区别
2.6.19 hive表的连接方式
2.6.20 hive中count(*)count(1)和count(字段区别)
2.6.21 hive中like_和like%区别
2.6.22 hive性能优化
2.6.23 sql性能优化以及in和exist区别？
子查询语句可以通过in关键字实现，一个查询语句的条件落在另一个select语句的查询结果中。程序先运行在嵌套在最内层的语句，再运行外层的语句。但缺点是mysql执行子查询时，需要创建临时表，查询完毕后，需要再删除这些临时表，有一些额外的性能消耗。
2.7 Hbase
2.7.1 Hbase概述
2.7.2 Hbase与hadoop的关系
2.7.3 Hbase读流程
2.7.4 Hbase写流程
2.7.5 Hbase数据flush过程
2.7.6 Hbase中rowkey原则
2.7.7. 热点现象（数据倾斜）怎么产生的，以及解决方法有哪些
2.7.8. HBase 中 compact 用途是什么，什么时候触发，分为哪两种？
2.8 Spark
2.8.1 Spark概述与运行流程
2.8.2 Spark有哪几种部署方式？请分别简要论述
2.8.3 Spark提交任务参数
2.8.3 如何理解Spark 中的血统概念（RDD）
2.8.4 简述 Spark的宽窄依赖，以及 的宽窄依赖，以及 Spark如何划分 stage，每个 ，每个 stage又根据什么决定 又根据什么决定 task个数 ?
2.8.5 请列举 Spark的 transformation算子
2.8.6 请列举 Spark的active算子
2.8.7 请列举 Spark的引起shuffer的算子
2.8.8 spark中shuffer机制
2.8.9 spark和mapReduce中shuffer区别
2.8.10 简述 Spark中共享变量（广播和累加器）的基本原理与用途
2.8.11 如何使用Spark实现TopN的获取（描述思路或使用伪代码）
2.8.11 spark如何保证宕机迅速恢复？
2.8.12 hadoop 和 spark 的相同点和不同点？
2.8.12 RDD 持久化原理？
2.8.13 checkpoint 检查点机制？
2.8.14 RDD 机制理解吗？
2.8.15 SparkStreaming以及基本工作原理
2.8.16 DStream以及基本工作原理
2.8.17 spark 有哪些组件？
2.8.18 Spark 主备切换机制原理知道吗？
2.8.19 spark 解决了 hadoop 的哪些问题？
2.8.20 数据倾斜的产生和解决办法？
2.8.21 RDD 中 reduceBykey 与 groupByKey 哪个性能好，为什么
2.8.22 Spark Streaming 优雅关闭
2.8.23 SparkStreaming有哪几种方式消费 Kafka中的数据，区别？
2.8.23 介绍一下 cogroup rdd 实现原理，你在什么场景下用过这个 rdd？
2.8.24 Spark 中的 OOM 问题？
2.8.25 Spark SQL 是如何将数据写到 Hive 表的？
2.8.26 通常来说，Spark 与 MapReduce 相比，Spark 运行效率更高。请 说明效率更高来源于 Spark 内置的哪些机制？
2.8.27 Spark Master HA 主从切换过程不会影响到集群已有作业的运行， 为什么？
2.9 Flink
2.9.1 Flink概述
2.9.2 Flink 集群有哪些角色？各自有什么作用
2.9.3 介绍一下Flink的容错机制
2.9.4 Flink 相比 Spark Streaming 有什么区别
2.9.5 Flink 常用的算子有哪些
2.9.6 如何处理生产环境中的数据倾斜问题
2.9.7 Flink 中的 Time 有哪几种
2.9.8 Flink 中 window 出现数据倾斜怎么解决
2.9.9 Flink有没重启策略？说说有哪几种？
2.10 Sqoop
2.10.1 Sqoop概述
2.10.2 Sqoop常用命令
2.10.3 Sqoop导入导出Null存储一致性问题
2.10.4 Sqoop底层运行的任务是什么 底层运行的任务是什么
2.10.5 Sqoop一天导 一天导 入多少数据
2.10.6 Sqoop数据导出的时候一次执行多长间?
2.10.7 Sqoop在导入数据的时候倾斜在导入数据的时候倾斜
2.10.8 Sqoop数据导出Parquet（项目中遇到的问题）
第3章 数据仓库
3.1 概念
3.1.1 数据集市与数据仓库的概念
3.1.2 数仓分层和如何设计数据仓库？
3.1.3 关系型数据库范式理论
3.1.4 数据模型
3.1.5 SKU&SPU
3.2 数仓建模
3.2.1 关系建模与维度建模
3.2.2 维度表和事实表
3.2.3 拉链表、全量表、增量表、流水表
3.2.4 数仓建模流程
3.2.5 数仓环境之hive引擎
3.2.6 即席查询数据仓库
3.2.7 数据仓库每天跑多少张表，大概什么时候运行，运行多久？
3.2.8 活动的话,数据量会增加多少？ 怎么解决？
3.2.9 数仓中使用的哪种文件存储格式 数仓中使用的哪种文件存储格式？
3.2.10 你感觉数仓建设中最重要的是什么
第3章 代码
3.1 电商指标
3.1.1 指标体系
3.1.2 数据分析
3.2 手写代码
3.2.1 手写 Spark-WordCount
3.2.2 冒泡排序
3.2.3 sql语句连续7天登录的用户信息
3.2.4 用一条 SQL 语句显示所有可能的比赛组合
3.2.5 用Scala编写Spark程序实现TopN
3.2.6 找出所有科目成绩都大于某一学科平均成绩的学生
3.2.7 用一条 SQL 语句查询出每门课都大于 80 分的学生姓名
虚拟的项目
日活、月活、周活、留存、留存率、新增（日、周、年）、转化率、流失、回流、七天内连续3天登录（点赞、收藏、评价、购买、加购、下单、活动）、连续3周（月）登录、GMV、复购率、复购率排行、点赞、评论、收藏、领优惠价人数、使用优惠价、沉默、值不值得买、退款人数、退款率topn 热门商品
日活/周活/月活统计
（每日的根据 key 聚合，求 key 的总数）
我们先根据用户ID和访问日期去重，再统计每天的访问用户数。
SELECT COUNT(DISTINCT user_id) AS user_cnt,DATE(create_ts) AS view_day FROM user_trace GROUP BY DATE(create_ts);2. 用户新增
每日新增（每日活跃设备 left join 每日新增表，如果 join 后，每日新
增表的设备 id 为空，就是新增） 方法1：
select r.date1,ifull(r2.count_num,0) from
record r left join(
select r1.date1,count(*) count_num
from record r1 where r1.date1=(select min(date1) from record group by id)) r2 on r.date1=r2.date1
group by r1.date1
order by r1.date1方法2：
select date1,sum(case when date_num=1 then 1 else 0 end) from (select date1,row_number()over(partition by user_id order by date) date_num
from login)
group by date1
order by date13. 用户留存率
（一周留存）10 日新增设备明细 join 11日活跃设备明细表，就是 10日留存的。注意每日留存，一周留存 。所谓留存，就是指某日创建的账号在后续自然日登录的比例。
比如3月1日新增账号创建数为100，在3月2日这部分用户登录数为51，那么3月1日新增用户的次日留存率为51/100=51%。
1.考虑到用户每天登录的次数不一定只有一次，为了方面后续的数据处理，可以先对登录数据按照日期和用户id进行去重DISTINCT处理；
2.为了计算某条登录日志是该用户创建账号后的第几天登录，我们可以用用户登录日志和账号创建日志进行inner join（这里考虑到不在统计周期内的创建账号的用户数据也会记录在用户登录日志里，所以去掉）；
3.然后用登录日期字段和创建账户字段进行差值DATEDIFF获取第几天登录；
4.对于第0天登录的数据则可以理解为新增用户数，第N（≥1)天登录的数据则为这批新增用户后续有登录的用户数；
5.用第N天登录的数据 / 新增用户数 就是对应第N天留存率。
SELECT
create_date
, 新增用户数
, concat(CAST(ROUND((100 * 次日留存) / 新增用户数,2) AS char), '%') 次日留存率
, concat(CAST(ROUND((100 * 3日留存) / 新增用户数,2) AS char), '%') 3日留存率
, concat(CAST(ROUND((100 * 7日留存) / 新增用户数,2) AS char), '%') 7日留存率
FROM
(
SELECT
create_date
, count((CASE WHEN (day_diff = 0) THEN role_id END)) 新增用户数
, count((CASE WHEN (day_diff = 1) THEN role_id END)) 次日留存
, count((CASE WHEN (day_diff = 2) THEN role_id END)) 3日留存
, count((CASE WHEN (day_diff = 7) THEN role_id END)) 7日留存
FROM
(
SELECT
login_log.role_id
, create_date
, DATEDIFF(login_date, create_date) day_diff
FROM
((
SELECT DISTINCT
STR_TO_DATE($part_date, '%Y-%m-%d') login_date
, role_id
FROM
role_login
) login_log
INNER JOIN (
SELECT DISTINCT
STR_TO_DATE($part_date, '%Y-%m-%d') create_date
, role_id
FROM
role_create
) create_log ON (login_log.role_id = create_log.role_id))
) temp_1
GROUP BY create_date
) temp_2
ORDER BY create_date ASC4. 流量指标分析
观测每日、每小时的访问量（PV）、访问人数（UV）、平均访问量（PV/UV），针对性的开展不同的营销活动，吸引更多的优质流量。
行为转化分析：统计用户不同行为间的转化情况，关注转化率低的环节，优化交易流程，提高转化率
产品贡献定量分析：根据产品贡献程度，调整产品结构，策划营销主题，助力爆款产品
用户价值分析：对用户进行价值分层，针对不同层级的用户施行不同的营销策略
通过对用户价值的细分，进行差异化的惊喜运营，从而提升运营效率和用户体验。RFM模型是衡量客户价值和客户创利能力的重要工具。
一般挽留客户占比34.36%，占比最高。这类用户交易时间间隔长，交易频率低，交易金额小，存在流失风险。可以及时与用户取得联系，明确流失原因或了解用户需要，想办法挽回用户。
一般发展用户占比31.29%，占比排名第二。这类用户交易时间间隔短，但交易频率和交易金额低。可以利用推荐系统推荐其平时浏览的同类商品，或者是与此类用户有相同购买属性人群购买的商品，发送优惠券等，避免用户流失。
重要价值客户占比23.86%。这类用户交易时间间隔短，交易频率高，交易金额大，是高质量用户。应加强交流互动，深入了解用户需求，提供个性化服务，增加用户粘性
R（Recency）：最后一次消费时间间隔。R值越小，用户价值越高。
F（Frequency）：消费频率。F值越大，用户价值越高。
M（Monetary）：消费金额。M值越大，用户价值越高。
用户每打开一个页面算作一个浏览，用户对同一个页面多次点击pv累计多次
同一个用户多次访问只计算一个uv
每个用户平均浏览次数
1.流量指标分析
每日PV、UV、人均浏览量、成交量、销售额
select日期,sum(behavior_type="pv") as 浏览量，
count(distinct user_id) as 访客数,
sum(behavior_type="pv")/count(distinct user_id) as 人均浏览量,
sum(behavior_type="buy") as 成交量,
sum(if(behavior_type="buy",amount,0)) as 销售额from UserBehavior_newgroup by 日期;注意：不能用count。count函数是对非空记录进行计数，不区分返回结果。count(behavior_type="pv")与count(behavior_type)是一样的效果,得出的是每日所有行为的统计数。
按日期分组，按用户行为类别计数（即按条件计数）。如果把条件放在where语句中，是先执行where语句后执行select求和，没法动态筛选。考虑把条件放在select语句中作为逻辑判断条件，返回的是1和0的结果，再对返回的结果分组进行聚合运算。
2.行为转化分析
统计每个行为类别的人数
select
behavior_type,
count(distinct user_id) as 用户数from UserBehavior_new group by behavior_type;行与行之间没法相除，用开窗函数当前行的上一行数据，即获取上一行为人数。lag（需要返回的字段，1）over（order by ...) 字符串是没法直接排序的，可以对字符进行重编码，用if函数赋值，对数值进行排序。
select
behavior_type,
count(distinct user_id) as 用户人数,
lag(count(distinct user_id),1) over (order by if(behavior_type="pv",0,if(behavior_type="fav",1,if(behavior_type="cart",2,3)))) as 上一行为人数,
count(distinct user_id)/lag(count(distinct user_id),1) over (order by if(behavior_type="pv",0,if(behavior_type="fav",1,if(behavior_type="cart",2,3)))) as 转化率from UserBehavior_newgroup by behavior_type;浏览—加购—购买的转化率
select 7
behavior_type,
count(distinct user_id) as 用户人数,
lag(count(distinct user_id),1) over (order by if(behavior_type="pv",0,if(behavior_type="cart",1,2))) as 上一行为人数,
ifnull(count(distinct user_id)/lag(count(distinct user_id),1) over (order by if(behavior_type="pv",0,if(behavior_type="cart",1,2))),1) as 转化率from UserBehavior_newwhere behavior_type in ("pv","cart","buy")group by behavior_type;3.产品贡献定量分析（帕累托分析）
产生购买行为的商品类目
select
item_category,
sum(amount) as 销售额from UserBehavior_newwhere behavior_type="buy"group by item_category;累计销售额百分比=当前类目商品的累计销售额/所有类目商品的总销售额
select item_category,
sum(amount) as 销售额,
sum(sum(amount)) over (order by sum(amount) desc) as 累计销售额,
sum(sum(amount)) over (order by sum(amount) desc)/(select sum(amount) from UserBehavior_new where behavior_type="buy") as 累计销售额百分比from UserBehavior_newwhere behavior_type="buy"group by item_category;筛选贡献80%的类目
select *from(select
item_category,
sum(amount) as 销售额,
sum(sum(amount)) over (order by sum(amount) desc) as 累计销售额,
sum(sum(amount)) over (order by sum(amount) desc)/(select sum(amount) from UserBehavior_new where behavior_type="buy") as 累计销售额百分比
from UserBehavior_new
where behavior_type="buy"
group by item_category) as twhere 累计销售额百分比<=0.8;4.用户价值分析
每个用户消费时间间隔、消费频次、消费金额/* 消费时间间隔R：距离分析时间节点的最后消费时间。 timestampdiff() 消费频次F：对这段时间内的消费次数计数 消费金额M：求和消费金额
select user_id,
max(日期) as 最近一次消费日期,
timestampdiff(day,max(日期),"2014-12-19") as 间隔天数,
count(*) as 消费频次,
sum(amount) as 消费金额from UserBehavior_newwhere behavior_type="buy"group by user_id;RFM评分/* 实际业务中会根据用户数量分布，制定评分标准。
select
user_id,
timestampdiff(day,max(日期),"2014-12-19") as 间隔天数,
count(*) as 消费频次,
sum(amount) as 消费金额,
case when timestampdiff(day,max(日期),"2014-12-19")<=6 then 5
when timestampdiff(day,max(日期),"2014-12-19")<=12 then 4
when timestampdiff(day,max(日期),"2014-12-19")<=18 then 3
when timestampdiff(day,max(日期),"2014-12-19")<=24 then 2
else 1
end as R评分,
if(count(*)=1,1,if(count(*)=2,2,if(count(*)=3,3,if(count(*)=4,4,5)))) as F评分,
if(sum(amount)<100,1,if(sum(amount)<200,2,if(sum(amount)<300,3,if(sum(amount)<400,4,5)))) as M评分from UserBehavior_newwhere behavior_type="buy"group by user_id;RFM均值（根据评分计算均值）
select
avg(R评分) as R均值,
avg(F评分) as F均值,
avg(M评分) as M均值from(
select user_id,
case when timestampdiff(day,max(日期),"2014-12-19")<=6 then 5
when timestampdiff(day,max(日期),"2014-12-19")<=12 then 4
when timestampdiff(day,max(日期),"2014-12-19")<=18 then 3
when timestampdiff(day,max(日期),"2014-12-19")<=24 then 2
else 1
end as R评分,
if(count(*)=1,1,if(count(*)=2,2,if(count(*)=3,3,if(count(*)=4,4,5)))) as F评分,
if(sum(amount)<100,1,if(sum(amount)<200,2,if(sum(amount)<300,3,if(sum(amount)<400,4,5)))) as M评分
from UserBehavior_new
where behavior_type="buy"
group by user_id ) as t;结果：3.5984, 2.1039, 2.2051-- RFM重要程度
select *,
if(R评分>3.5984,"高","低") as R程度,
if(F评分>2.1039,"高","低") as F程度,
if(M评分>2.2051,"高","低") as M程度from(select
user_id,
timestampdiff(day,max(日期),"2014-12-19") as 间隔天数,
count(*) as 消费频次,
sum(amount) as 消费金额,
case when timestampdiff(day,max(日期),"2014-12-19")<=6 then 5
when timestampdiff(day,max(日期),"2014-12-19")<=12 then 4
when timestampdiff(day,max(日期),"2014-12-19")<=18 then 3
when timestampdiff(day,max(日期),"2014-12-19")<=24 then 2
else 1
end as R评分,
if(count(*)=1,1,if(count(*)=2,2,if(count(*)=3,3,if(count(*)=4,4,5)))) as F评分,
if(sum(amount)<100,1,if(sum(amount)<200,2,if(sum(amount)<300,3,if(sum(amount)<400,4,5)))) as M评分from UserBehavior_newwhere behavior_type="buy"group by user_id) as t;RFM用户价值
select * ,
case
when R程度='高' and F程度='高' and M程度='高' then '重要价值用户'
when R程度='高' and F程度='低' and M程度='高' then '重要发展用户'
when R程度='低' and F程度='高' and M程度='高' then '重要保持用户'
when R程度='低' and F程度='低' and M程度='高' then '重要挽留用户'
when R程度='高' and F程度='高' and M程度='低' then '一般价值用户'
when R程度='高' and F程度='低' and M程度='低' then '一般发展用户'
when R程度='低' and F程度='高' and M程度='低' then '一般保持用户'
else '一般挽留用户'
end as 用户价值分类 from(select *,
if(R评分>3.5984,"高","低") as R程度,
if(F评分>2.1039,"高","低") as F程度,
if(M评分>2.2051,"高","低") as M程度from(select
user_id,
timestampdiff(day,max(日期),"2014-12-19") as 间隔天数,
count(*) as 消费频次,
sum(amount) as 消费金额,
case when timestampdiff(day,max(日期),"2014-12-19")<=6 then 5
when timestampdiff(day,max(日期),"2014-12-19")<=12 then 4
when timestampdiff(day,max(日期),"2014-12-19")<=18 then 3
when timestampdiff(day,max(日期),"2014-12-19")<=24 then 2
else 1
end as R评分,
if(count(*)=1,1,if(count(*)=2,2,if(count(*)=3,3,if(count(*)=4,4,5)))) as F评分,
if(sum(amount)<100,1,if(sum(amount)<200,2,if(sum(amount)<300,3,if(sum(amount)<400,4,5)))) as M评分from UserBehavior_newwhere behavior_type="buy"group by user_id) as t1) as t2;1. 每日日活实时统计
2. 每日订单量实时统计
3. 一小时内日活实时统计
4. 一小时内订单数实时统计
5. 一小时内交易额实时统计
6. 一小时内广告点击实时统计
7. 一小时内区域订单数统计
8. 一小时内区域订单额统计
9. 一小时内各品类销售 top3 商品统计
我们经常会算活跃用户，活跃用户是指至少连续 5 天登录账户的用户，返回的
结果表按照 id 排序。
思路：
1. 去重：由于每个人可能一天可能不止登陆一次，需要去重
2. 排序：对每个 ID 的登录日期排序
3. 差值：计算登录日期与排序之间的差值，找到连续登陆的记录
4. 连续登录天数计算：select id， count(*) group by id， 差值（伪代码）
5. 取出登录 5 天以上的记录
6. 通过表合并，取出 id 对应用户名
SELECT DISTINCT b.id， name
FROM
(SELECT id， login_date，
DATE_SUB(login_date，ROW_NUMBER() OVER(PARTITION BY id ORDER BY login_date)) AS
diff
FROM(SELECT DISTINCT id， login_date FROM Logins) a) b
INNER JOIN Accounts ac
ON b.id = ac.id
GROUP BY b.id， diff
HAVING COUNT(b.id) >= 5注意点：
1. DATE_SUB 的应用：DATE_SUB (DATE，X)，注意，X 为正数表示当前日期的前 X 天；
2. 如何找连续日期：通过排序与登录日期之间的差值，因为排序连续，因此若登录日期连续，则差值一致；
3. GROUP BY 和 HAVING 的应用：通过 id 和差值的 GROUP BY，用 COUNT 找到连续天数大于 5 天的 id，注意 COUNT 不是一定要出现在 SELECT 后，可以直接用在 HAVING 中。
原因：Hive 中的 Null 在底层是以“\N”来存储，而 MySQL 中的 Null 在底层就是Null，为了保证数据两端的一致性。
解决：在导出数据时采用--input-null-string 和 input-null-non-string 两个参数。导入数据时采用--null-string 和 --null-non-string。
当 Sqoop 导出数据到 MySql 时，使用 4 个 map 怎么保证数据的一致性
原因：因为在导出数据的过程中 map 任务可能会失败，可以使用—staging-table
– clear-staging
解决：任务执行成功首先在 tmp 临时表中，然后将 tmp 表中的数据复制到目标表中（这个时候可以使用事务，保证事务的一致性）
Ads 层数据用 Sqoop 往 MySql 中导入数据的时候，如果用了 orc（Parquet）不能导入，需转化成 格式
原因：
1.元数据层面：每个小文件都有一份元数据，其中包括文件路径，文件名，所有者，所属组，权限，创建时间等，这些信息都保存在Namenode内存中。所以小文件过多，会占用Namenode服务器大量内存，影响Namenode性能和使用寿命。
2.计算层面：默认情况下MR会对每个小文件启用一个Map任务计算，非常影响计算性能。同时也影响磁盘寻址时间。
解决：
（1）采用har 归档方式，将小文件归档
（2）采用CombineTextInputFormat
（3）有小文件场景开启JVM 重用；如果没有小文件，不要开启JVM 重用，因为会一直占用使用到的task 卡槽，直到任务完成才释放。
JVM 重用可以使得JVM 实例在同一个job 中重新使用N 次，N 的值可以在Hadoop 的mapred-site.xml 文件中进行配置。通常在10-20 之间
flume ng 1.7版本后提供Taildir Source 可以读取多个文件最新追加写入的内容！
Taildir Source是可靠的，即使flume出现了故障或挂掉。Taildir Source在工作时，会将读取文件的最后的位置记录在一个json文件中，一旦agent重启，会从之前已经记录的位置，继续执行tail操作！Json文件中，位置是可以修改，修改后，Taildir Source会从修改的位置进行tail操作！如果JSON文件丢失了，此时会重新从每个文件的第一行，重新读取，这会造成数据的重复！
1、调整Flume进程的内存大小，建议设置1G~2G，太小的话会导致频繁GC因为Flume进程也是基于Java的，所以就涉及到进程的内存设置，一般建议启动的单个Flume进程(或者说单个Agent)内存设置为1G~2G，内存太小的话会频繁GC，影响Agent的执`行效率。
2、在一台服务器启动多个agent的时候，建议修改配置区分日志文件
1) Flume 记录
2) 日志有记录
3) 短期没事
1) 如果是 Kafka 消费能力不足，则可以考虑增加 Topic 的分区数，并且同时提升消费组的消费者数量，消费者数=分区数。（两者缺一不可）
2) 如果是下游的数据处理不及时：提高每批次拉取的数量。批次拉取数据过少（拉取数据/处理时间<生产速度），使处理的数据小于生产的数据，也会造成数据积压。
幂等性+ack-1+事务
Kafka数据重复，可以再下一级：SparkStreaming、redis或者hive中dwd层去重，去重的手段：分组、按照id开窗只取第一个值；
Ack=0，相当于异步发送，消息发送完毕即offset增加，继续生产。
Ack=1，leader收到leader replica 对一个消息的接受ack才增加offset，然后继续生产。
Ack=-1，leader收到所有replica 对一个消息的接受ack才增加offset，然后继续生产。
Kafka对于消息体的大小默认为单条最大值是1M但是在我们应用场景中，常常会出现一条消息大于1M，如果不对Kafka进行配置。则会出现生产者无法将消息推送到Kafka或消费者无法去消费Kafka里面的数据，这时我们就要对Kafka进行以下配置：server.properties
replica.fetch.max.bytes: 1048576 broker可复制的消息的最大字节数, 默认为1M
message.max.bytes: 1000012 kafka 会接收单个消息size的最大限制， 默认为1M左右
搭建完Hadoop集群后需要对HDFS读写性能和MR计算能力测试。测试jar包在hadoop的share文件夹下。
1）如果MR造成系统宕机。此时要控制Yarn同时运行的任务数，和每个任务申请的最大内存。调整参数：yarn.scheduler.maximum-allocation-mb（单个任务可申请的最多物理内存量，默认是8192MB）
2）如果写入文件过快造成NameNode宕机。那么调高Kafka的存储大小，控制从Kafka到HDFS的写入速度。例如，可以调整Flume每批次拉取数据量的大小参数batchsize。。
）提前在进行，减少传输的数据量
在Mapper加上combiner相当于提前进行reduce，即把一个Mapper中的相同key进行了聚合，减少shuffle过程中传输的数据量，以及Reducer端的计算量。
如果导致数据倾斜的key大量分布在不同的mapper的时候，这种方法就不是很有效了。
- 导致数据倾斜的大量分布在不同的
（1）局部聚合加全局聚合。
第一次在map阶段对那些导致了数据倾斜的key 加上1到n的随机前缀，这样本来相同的key 也会被分到多个Reducer中进行局部聚合，数量就会大大降低。
第二次mapreduce，去掉key的随机前缀，进行全局聚合。
思想：二次mr，第一次将key随机散列到不同reducer进行处理达到负载均衡目的。第二次再根据去掉key的随机前缀，按原key进行reduce处理。
这个方法进行两次mapreduce，性能稍差。
（2）增加Reducer，提升并行度JobConf.setNumReduceTasks(int)
（3）实现自定义分区
根据数据分布情况，自定义散列函数，将key均匀分配到不同Reducer
集群有30台机器，跑mr任务的时候发现5个map任务全都分配到了同一台机器上，这个可能是由于什么原因导致的吗？
解决方案：yarn.scheduler.fair.assignmultiple 这个参数默认是开的，需要关掉。
我一般是造一些特定的测试数据进行测试。
另外离线数据和实时数据分析的结果比较。
一部分自己写 Java 程序自己造，一部分从生产环境上取一部分。
测试环境的配置是生产的一半
上线的时候，将脚本打包，提交 git。先发邮件抄送经理和总监，运维。通过之
后跟运维一 起上线。
1. 先与产品讨论，看报表的各个数据从哪些埋点中取
2. 将业务逻辑过程设计好，与产品确定后开始开发
3. 开发出报表 SQL 脚本，并且跑几天的历史数据，观察结果
4. 将报表放入调度任务中，第二天给产品看结果。
5. 周期性将表结果导出或是导入后台数据库，生成可视化报表
第步：确定指标的业务口径
由产品经理主导，找到提出该指标的运营负责人沟通。首先要问清楚指标是怎么定义的，比如活跃用户是指启动过APP的用户。设备id 还是用户id。
第步：需求评审
由产品经理主导设计原型，对于活跃主题，我们最终要展示的是最近天的活跃用户数变化趋势，效果如下图所示。此处大数据开发工程师、后端开发工程师、前端开发工程师一同参与，一起说明整个功能的价值和详细的操作流程，确保大家理解的一致。
第步：大数据开发
大数据开发工程师，通过数据同步的工具如Flume、Sqoop等将数据同步到ODS层，然后就是一层一层的通过SQL计算到DWD、DWS层，最后形成可为应用直接服务的数据填充到ADS
第步：后端开发
后端工程师负责，为大数据工程师提供业务数据接口；
同时还负责读取ADS层分析后，写入MySQL中的数据。
第步：前端开发
前端工程师负责，前端埋点。
对分析后的结果数据进行可视化展示。
第步：联调
此时数据开发工程师、前端开发工程师、后端开发工程师都要参与进来。此时会要求大数据开发工程师基于历史的数据执行计算任务，大数据开发工程师承担数据准确性的校验。前后端解决用户操作的相关BUG保证不出现低级的问题完成自测。
第步：测试
测试工程师对整个大数据系统进行测试。测试的手段包括，边界值、等价类等。
提交测试异常的软件有：禅道、（测试人员记录测试问题1.0，输入是什么，结果是什么，跟预期不一样->需要开发人员解释，是一个bug，下一个版本解决1.1->测试人员再测试。测试1.1ok->测试经理关闭bug）
第步：上线
运维工程师会配合我们的前后端开发工程师更新最新的版本到服务器。此时产品经理要找到该指标的负责人长期跟进指标的准确性。重要的指标还要每过一个周期内部再次验证，从而保证数据的准确性。