一、hive join过程中大表小表的放置顺序
将最大的表放置在join语句的最右边,或直接使用/* + streamtable(table_name) */指出哪个表采用流式传输,如果省略streamtable提示,则hive将流式传输最右边的表。在编写带有join操作的代码语句时,应该将条目少的表/子循环放在join操作符的左边。因为在reduce阶段,位于join操作符左边的表的内容会被加载进内存,载入条目较少的表可以有效减少OOM(out of memory)即内存溢出。所以对于同一个key来说,对应的value值小的放前,大的放后,这便是"小表放前"原则。若一条语句中有多个join,依据join的条件相同与否,有不同的处理方法。
二、所有的hive任务都会有mepreduce的执行吗?
不是,从hive1.10.0版本开始,对于简单的不需要聚合的类似select <col> from <table> limit n 语句,不需要启动mapreduce job,直接通过Fetch task获取数据,在 MapReduce 的工作流程里,Map 任务处理完数据后,会将结果写入本地磁盘。Reduce 任务需要从多个 Map 任务节点获取相关的数据,执行这个获取数据操作的任务就是 Fetch task 。
三、窗口函数用过哪些,举个例子
rank() 排序相同时会重复,总数不会变
示例:
学生 | 分数 | rank () over (order by 分数 desc) |
---|---|---|
张三 | 90 | 1 |
李四 | 90 | 1 |
王五 | 80 | 3 (跳过了 2,因为前两名并列) |
dense_rank() 排序相同时会重复,总数会减少
示例:
学生 | 分数 | dense_rank () over (order by 分数 desc) |
---|---|---|
张三 | 90 | 1 |
李四 | 90 | 1 |
王五 | 80 | 2 (不跳过,直接排 2) |
row_number() 会根据顺序计算
示例:对学生分数排序(分数相同随机分配序号)
学生 | 分数 | row_number () over (order by 分数 desc) |
---|---|---|
张三 | 90 | 1 |
李四 | 90 | 2 |
王五 | 80 | 3 |
-
over():指定分析函数工作的数据窗口大小,这个数据窗口大小可能会随着行的变而变化
-
current row():当前行
-
n preceding:往前n行数据(含当前行)
-
n following:往后n行数据(含当前行)
5)unbounded:起点,unbounded preceding 表示从分区的第一行(起点)到当前行,unbounded following表示从当前行到分区的最后一行(终点)
-
lag(col,n):往前第n行数据(n默认是1,无则返回null)
-
lead(col,n):往后第n行数据(n默认是1,无则返回null)
示例:
日期 | 销售额 | lag (销售额,1) as 前 1 天销售额 | lead (销售额,1) as 后 1 天销售额 |
---|---|---|---|
1 月 1 日 | 100 | null (无前一天) | 200 |
1 月 2 日 | 200 | 100 | 150 |
1 月 3 日 | 150 | 200 | null (无后一天) |
- ntile(n):把有序分区中的行分发到指定数据的组中,各个组有编号,编号从1开始,对于每一行,ntile返回此行所属的组的编号。注意:n必须为int类型。
四、对hive物化视图如何理解
物化视图(materialized view)是一个包括查询结果的数据库对象,它将查询结果物理存储在磁盘上,而非普通视图(View)那样仅存储查询定义、每次访问时动态计算结果,可以用于预先计算并保存表连接或聚集等耗时较多的操作的结果。在执行查询时,就可以避免进行这些耗时的操作,从而快速的得到结果
hive3.0开始尝试引入物化视图,并提供对于物化视图的查询自动重写机制(基于Apache Calcite实现);
物化视图的查询自动重写机制(Query Rewrite)是数据库或数据仓库(如 Hive、Oracle 等)的一种智能优化能力:当用户提交一条查询时,系统会自动分析查询逻辑,判断是否存在已有的物化视图可以直接复用(即物化视图的预计算结果能满足当前查询需求),如果匹配成功,系统会自动用物化视图替代原查询的数据源,从而跳过对源表的全量扫描和计算,直接返回结果。
hive的物化视图还提供了物化视图存储选择机制,可以本地存储在hive,也可以通过用户自定义storage handlers存储在其他系统(如Druid);
hive引入物化视图的目的就是为了优化数据查询访问的效率,相当于从数据预处理的角度优化数据访问;
hive从3.0丢弃了index索引的语法支持,推荐使用物化视图和列式存储文件格式来加快查询的速度;
为什么丢弃索引?
1、索引的核心作用是加速点查询 (如where id = 123
)或范围查询 (如where age > 30
),但在 Hive 的典型场景中:
数据通常按分区(Partition)或分桶(Bucket)进行粗粒度划分,查询时优先通过分区过滤(如按日期、地区)即可排除大部分数据,无需细粒度索引;
多数查询是全表扫描或大规模聚合(如group by
、join
),索引对这类操作的加速效果微乎其微,反而会增加额外的存储和维护成本。
2、索引的有效运作依赖于实时维护:当源数据发生变化(新增、修改、删除)时,索引必须同步更新,否则会导致查询结果错误。但在 Hive 中:
数据批量写入时,索引需要全量重建或大量追加,耗时且消耗资源;
若数据频繁更新(尽管 Hive 不鼓励这种场景),索引的维护成本会远高于其带来的收益。
五、union all 和 union有什么区别
UNION
:
合并结果集时会自动去除重复的行 (即完全相同的记录),只保留唯一的行。
例如:两个查询都返回(1, 'a')
,UNION
最终只会保留一行(1, 'a')
。
UNION ALL
:
直接合并所有结果集,不会去除重复行 ,包括完全相同的记录。
例如:两个查询都返回(1, 'a')
,UNION ALL
会保留两行(1, 'a')
。
示例对比
假设存在两个表table1
和table2
,数据如下:
table1 | table2 | ||
---|---|---|---|
id | name | id | name |
1 | a | 1 | a |
2 | b | 3 | c |
UNION
查询:
SELECT id, name FROM table1
UNION
SELECT id, name FROM table2;
结果(去重后):
id | name
1 | a
2 | b
3 | c
UNION ALL
查询:
sql
SELECT id, name FROM table1
UNION ALL
SELECT id, name FROM table2;
结果(保留重复):
id | name
1 | a
2 | b
1 | a
3 | c
六、补充 写sql语句
1、会写,基本语法 子查询 关联语句 join 、union all 、union这些都是
2、把基础常用的函数背一背
3、多尝试写伪代码,逻辑思维习惯减少依赖,只要你能写伪代码,面试官让你过去