大数据术语之Hive

HQL是如何翻译成MapReduce的
    HQL解析(生成AST语法树) => 语法分析(得到QueryBlock) => 生成逻辑执行计划(Operator) => 逻辑优化(Logical Optimizer Operator) => 生成物理执行计划(Task Plan) => 物理优化(Task Tree) => 构建执行计划(QueryPlan) => 表以及操作鉴权 => 执行引擎执行

根据事实表和维度表的关系，可将常见的模型分为星型模型和雪花型模型。在设计逻辑型数据的模型的时候，就应考虑数据是按照星型模型还是雪花型模型进行组织。
星星模型
    当所有维表都直接连接到“ 事实表”上时，整个图解就像星星一样，故将该模型称为星型模型。
星型架构是一种非正规化的结构，多维数据集的每一个维度都直接与事实表相连接，不存在渐变维度，所以数据有一定的冗余。

雪花模型
    当有一个或多个维表没有直接连接到事实表上，而是通过其他维表连接到事实表上时，其图解就像多个雪花连接在一起，故称雪花模型。雪花模型是对星型模型的扩展。
因此在冗余可以接受的前提下，实际运用中星型模型使用更多，也更有效率。

数仓分层
    分层优点：复杂问题简单化、清晰数据结构(方便管理)、增加数据的复用性、隔离原始数据(解耦)。
    ods        原始数据层    存放原始数据，保持原貌不做处理。
    dwd        明细数据层    对ods层数据清洗（去除空值，脏数据，超过极限范围的数据）。
    dws        服务数据层    轻度聚合。
    ads        应用数据层    具体需求。

Hive与关系型数据库的而区别
    Hive和数据库除了拥有类似的查询语言，再无相似之处。
    1）数据存储位置
    Hive存储在HDFS。数据库将数据保存在设备或者本地文件系统中。
    2）数据更新
    Hive中不建议对数据的改写。数据库通常需要进行修改。
    3）执行延迟
    Hive执行延迟高，数据库的延迟较低。当然是有条件的，即数据规模较小，当数据规模大到数据库的处理能力的时候，Hive并行计算显然能体现出优势。
    4）数据规模
    Hive支持很大规模的数据计算；数据库可以支持的数据规模较小。
内部表与外部表
    内部表：当我们删除一张表时，Hive也会删除这个表种数据。管理表不适合和其他工具共享数据。
    外部表：删除表不会删除原始数据，删除的是表的元数据。
Sort By、Order By、Distribute By、Cluster By的区别
    1）Sort By：分区内有序；
    2）Order By: 全局排序，只有一个Reducer；
    3）Distrbute By：类似MR中Partition，进行分区，与sort by结合使用；
    4）Cluster By：当Distribute by和Sorts by字段相同时，可以使用Cluster by方式。Cluster by除了具有Distribute by的功能外还兼具Sort by的功能。但是排序只能是升序排序，不能指定排序规则为ASC或者DESC。
常见函数
    NEXT_DAY('2022-01-11','MO') 下周一
    DATE_SUB('2022-01-11',1) 一天前
    explode()函数用于打散行的函数
    lateral view explode(集合) 
    RANK() 排序相同时会重复，总数不会变；
    DENSE_RANK() 排序相同时会重复，总数会减少；
    ROW_NUMBER() 会根据数据计算；
    OVER()：指定分析函数工作的数据窗口大小，这个数据窗口大小可能会随着行的变而变化
    CURRENT ROW：当前行
    n PRECEDING：往前n行数据
    n FOLLOWING：往后n行数据
    UNBOUNDED：起点，UNBOUNDED PRECEDING 表示从前面的起点， UNBOUNDED FOLLOWING表示到后面的终点
    LAG(col,n)：往前第n行数据
    LEAD(col,n)：往后第n行数据
    NTILE(n)：把有序分区中的行分发到指定数据的组中，各个组有编号，编号从1开始，对于每一行，NTILE返回此行所属的组的编号。注意：n必须为int类型。
UDF、UDTF
    自定义UDF：继承UDF，重写evaluate方法
    自定义UDTF：继承自GenericUDTF，重写3个方法：initialize(自定义输出的列名和类型)，process（将结果返回forward(result)），close
Hive优化
1）MapJoin
    如果不指定MapJoin或者不符合MapJoin的条件，那么Hive解析器会将Join操作转换成CommonJoin，
即：在Reduce阶段完成join。容易发生数据倾斜。可以用MapJoin把小表全部加载到内存在Map端进行join，避免reducer处理。
常用参数：
set hive.map.aggr = true; //是否在Map端进行聚合，默认为true
set hive.groupby.skewindata = true; //有数据倾斜的时候进行负载均衡，默认是false
2）行列过滤
    列处理：在SELECT中，只拿需要的列，如果有，尽量使用分区过滤，少用SELECT *。
    行处理：当使用外关联时，先过滤在关联。
3）采用分区、分桶技术
4）小文件合并
    在Map执行前合并小文件，减少Map数：CombineHiveInputFormat具有对小文件进行合并的功能。HiveInputFormat没有对小文件合并功能。
5）合理设置Map个数
（1）通常情况下，作业会通过input的目录产生一个或者多个map任务。
    主要的决定因素有：input的文件总个数，input的文件大小，集群设置的文件块大小。
（2）是不是map数越多越好？
    答案是否定的。如果一个任务有很多小文件（远远小于块大小128m），则每个小文件也会被当做一个块，用一个map任务来完成，而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费。而且，同时可执行的map数是受限的。
（3）是不是保证每个map处理接近128m的文件块，就高枕无忧了？
    答案也是不一定。比如有一个127m的文件，正常会用一个map去完成，但这个文件只有一个或者两个小字段，却有几千万的记录，如果map处理的逻辑比较复杂，用一个map任务去做，肯定也比较耗时。
针对上面的问题2和3，我们需要采取两种方式来解决：即减少map数和增加map数；
6）合理设置Reduce个数
Reduce个数并不是越多越好
（1）过多的启动和初始化Reduce也会消耗时间和资源；
（2）另外，有多少个Reduce，就会有多少个输出文件，如果生成了很多个小文件，那么如果这些小文件作为下一个任务的输入，则也会出现小文件过多的问题；
在设置Reduce个数的时候也需要考虑这两个原则：处理大数据量利用合适的Reduce数；使单个Reduce任务处理数据量大小要合适；
7）常用参数
SET hive.merge.mapfiles = true; -- 默认true，在map-only任务结束时合并小文件
SET hive.merge.mapredfiles = true; -- 默认false，在map-reduce任务结束时合并小文件
SET hive.merge.size.per.task = 268435456; -- 默认256M
SET hive.merge.smallfiles.avgsize = 16777216; -- 当输出文件的平均大小小于该值时，启动一个独立的map-reduce任务进行文件merge.

外连接 FULL OUTER JOIN
    外连接返回的记录数=在左表不在右表的记录+在右边不在左表的记录+既在左表又在右表中的记录。
内连接 JOIN
    返回表中满足条件的记录。
左连接 left join
    左外连接返回的记录等于左表的记录数，右边不符合的记录标记为null。
右连接 right join 
    右外连接返回的记录数等于右表的记录数

union 与 union all 
    union 对两个结果集进行并集操作，不包括重复行，同时进行默认规则的排序；
    union all 对两个结果集进行并集操作，包括重复行，不进行排序；

用户活跃：在启动日志中统计不同设备id出现次数。
用户新增：活跃表join新增表，新增表为设备编号为空的是新增。
留存用户：前一天新增 join 今天活跃。
用户留存率：留存用户/前一天新增。
沉默用户：定义标准登录时间为7天前,且只出现过一次。日活表根据设备分组登录次数为1，且在一星期前登录。
本周回流用户：本周活跃left join本周新增 left join上周活跃，且本周新增id和上周活跃id都为null。
流失用户： 登录时间为7天前。
连续三周登录的用户：周一对前三周的数据进行统计。
七天内连续三天活跃用户数：
    1.查询出最近7天的活跃用户，并对用户活跃日期进行排名；
    2.计算用户活跃日期及排名之间的差值；
    3.对同用户及差值分组，统计差值个数；
    4.将差值相同个数大于等于3的数据取出，然后根据设备标识去重，即为连续3天及以上活跃的用户；
新增占日活转换率：新增/日活跃    
订单拉链表：
    1.创建订单表拉链表，字段跟订单表一样，只增加了有效开始日期和有效结束日期；
    初始日期，从订单变化表ods_order_info导入数据，且让有效开始时间=当前日期，有效结束日期=9999-99-99
    （从mysql导入数仓的时候就只导了新增的和变化的数据ods_order_info，dwd_order_info跟ods_order_info基本一样，只多了一个id的判空处理）
    2.建一张拉链临时表dwd_order_info_his_tmp，字段跟拉链表完全一致；
    3.新的拉链表中应该有这几部分数据
        （1）增加订单变化表dwd_order_info的全部数据
        （2）更新旧的拉链表左关联订单变化表dwd_order_info，
        关联字段：订单id, where过滤出end_date只等于9999-99-99的数据，如果旧的拉链表中的end_date不等于9999-99-99，说明已经是终态了，不需要再更新
        如果dwd_order_info.id is null , 没关联上，说明数据状态没变，让end_date还等于旧的end_date
        如果dwd_order_info.id is not null , 关联上了，说明数据状态变了，让end_date等于当前日期-1
        把查询结果插入到拉链临时表中
    4.把拉链临时表覆盖到旧的拉链表中；