做了几年大数据开发，面试过不少候选人，也在社区里帮人做过模拟面试辅导。要说哪一块最容易被反复问到，Hive绝对排得上号。明明是数据仓库工具，表面看就是把SQL翻译成分布式任务，可一旦往深处追问，Metastore、执行引擎、存储格式、数据倾斜，每个点都能筛掉一批人。很多开发者能背出“Hive是基于Hadoop的数据仓库工具”这种标准答案，但被追问“一条SQL到底经历了什么”或者“内部表和外部表删表有什么区别”的时候，就开始含糊其辞。
这篇是Hive面试题系列的第一篇，我按面试官提问的逻辑来整理，从架构、表设计、底层存储到性能优化，把高频考点和背后的原理一次说透。内容偏实战，适合正在准备大数据岗位面试的朋友，也适合日常写Hive但想补原理的开发者。看的同时最好自己动手模拟一遍回答，比单纯“看会了”要有效得多。
1. 面试官为什么第一个聊Hive
1.1 一句话说清Hive的定位
Hive本质上是把类SQL语句翻译成分布式计算程序的数据仓库工具，最初由某公司开源，用来解决海量结构化数据的统计和分析问题。它建立在Hadoop之上，默认把SQL转换成MapReduce任务执行，后来也支持Tez、Spark作为执行引擎。
这里有个非常常见的误区。很多候选人把Hive说成“数据库”，面试官心里就会打一个问号。Hive不是关系型数据库，它没有行级更新、事务支持也很弱（虽然现在有ACID能力），它核心的定位是“离线批处理的分析引擎”。你可以理解为：MySQL是做在线交易、实时读写的，而Hive是做海量历史数据的批量扫描与统计的。前者像便利店，随时零买；后者像大型仓库，一次性处理整批货。
能讲清楚这个定位，就已经过了第一道门槛。面试官接下来会顺着问架构，看你是否理解Hive背后那套完整的执行链路。
1.2 Hive在大数据生态里到底承担了什么角色
在一个典型的大数据平台架构里，数据往往经过采集、存储、计算、查询四个环节。Hive处在“存储”和“计算/查询”之间的位置：数据以文件形式存在HDFS上，Hive提供一层“元数据映射”加“SQL化访问”的能力，让分析师不需要直接写MapReduce代码就能完成统计。
举一个最直观的例子。没有Hive的时候，想统计某张日志表里每个城市独立访客数，你需要手动编写MapReduce程序，自己实现map阶段的解析和reduce阶段的去重计数，代码量基本在百行以上，而且每次需求变化都要改代码重新提交。有了Hive，一条SQL就能搞定，Hive把这条SQL自动拆成Map任务和Reduce任务，程序员不需要关心中间细节。这种“把复杂留给自己，把简单留给用户”的思路，正是Hive能成为数仓标配的根本原因。
从面试角度看，能说出这句话，说明你不是只会调接口，而是理解Hive解决的是什么层面的问题。
2. 架构类高频题：一条SQL在Hive里经历了什么
2.1 Hive的五个核心组件，逐个说清楚
Hive的架构其实不复杂，我习惯把它拆成五块来讲，面试时按这个顺序说既清晰又有条理。
第一是用户接口层。早期主要是CLI命令行，后来公司里更多用Hue、Zeppelin或者JDBC/ODBC接口。这里需要提一下Beeline，它是基于HiveServer2的轻量客户端，生产环境里基本都推荐用Beeline而不是老旧的CLI，原因在于HiveServer2支持多用户并发、权限控制和JDBC连接，更符合实际使用场景。
第二是元数据存储Metastore。这是Hive的灵魂组件，它保存了表结构、分区信息、字段类型、存储路径、SerDe信息等元数据，底层通常用关系型数据库存储，常见的有内嵌的Derby（仅用于测试）、MySQL或者PostgreSQL。面试官问你“Hive为什么查询快”，其实快的就是元数据访问，真正的数据计算依然要走分布式引擎。
第三是编译器Compiler。当用户提交一条SQL，Hive会调用编译器把它抽象语法树（AST）转成逻辑计划，再优化成物理计划。这块常考点在于：Hive怎么知道你的SQL要扫描哪些文件、走哪些Map和Reduce。
第四是优化器Optimizer。它负责对执行计划进行优化，包括列剪枝、分区剪枝、谓词下推、MapJoin转换等。候选人如果能说出几种常见优化手段，会非常加分。
第五是执行引擎Execution Engine。物理计划最终提交给MR、Tez或Spark执行，默认引擎可以配置。现在大厂面试几乎必聊“为什么公司把执行引擎从MR换成Tez或Spark”，原因很简单，MR的每次计算都要落盘，而Tez通过DAG减少中间结果写盘，Spark更是大量使用内存计算，执行效率完全不同。
2.2 SQL到MapReduce的六步链路，模拟面试官追问
面试官最爱的套路是让你“描述一条SQL从提交到返回结果的完整流程”。从MSTR到返回结果，完整链路大致有六步：
- 用户通过CLI或JDBC提交HiveQL。
- Hive调用Compiler的Parse阶段，用Antlr对SQL进行语法解析，生成抽象语法树。
- Semantic Analyzer进行语义分析，验证表名、字段名是否存在于元数据中，并生成逻辑计划。
- 逻辑计划生成器把抽象语法树转换成操作符树，比如TableScanOperator、FilterOperator、ReduceSinkOperator等。
- 优化器对操作符树做优化，比如合并多个ReduceSink、调整Join顺序、提前过滤数据。
- 物理计划生成器把优化后的操作符树转成一系列MapReduce任务（或者Tez/Spark任务），提交到集群执行。
我面过不少候选人，能把前四步说清楚的人一半都不到，很多人卡在“执行计划生成”这一步，回答得特别模糊。这里有一个好用的类比：整个过程就像点外卖。你下单时只说了“来一份宫保鸡丁”（SQL），餐厅后厨需要拆解成“洗菜、切菜、备调料、炒制”（逻辑计划），然后确定用什么锅、什么火、多长时间（物理计划），最后才有外卖员把成品送到你手里（返回结果）。Hive的编译器干的就是这个拆解和规划的活。
面试官如果继续追问“Join在MapReduce里怎么实现”，你就需要指出Common Join（Reduce Join）和MapJoin的区别：Common Join将两张表按关联键分发到同一个Reducer做拼接，代价是网络传输；MapJoin则把小表加载到每个MapTask的内存中，在Map阶段直接完成关联，省掉了Reduce这一层。判断依据是参数Hive中自动优化开关是否开启，小表大小低于阈值时Hive会自动选择MapJoin。
2.3 为什么自研Hive版本的面试题都是这些点
大厂面试官提Hive的问题，并不是真想考你背诵，而是想通过架构型问题判断你有没有真正在工程里用过它。比如问“Metastore为什么要用MySQL存”，是看你是不是知道Derby是单进程的，只能本地访问，而生产环境需要多个客户端并发访问元数据，所以必须外置元数据库。
问“Hive和传统SQL有什么区别”，表面考对比，实际是考你对Hive底层执行模式的理解。Hive是批处理，延迟高但吞吐大；传统数据库在线事务处理能力强，但面对几千亿行数据的全表扫描基本无能为力。回答时不要背定义，用“面向批处理的分析工具”和“面向事务的存储系统”去讲，再补一句两者的数据存储方式完全不同，Hive的数据独立于表结构存在普通文件里，而关系型数据库的数据由存储引擎管理，这句话就说明你真去理解了。
3. 建表与存储高频题：内部表、外部表、分区与分桶
3.1 内部表还是外部表，一句话点破
建表问题是Hive面试的必考点，最简单的问法是“内部表和外部表有什么区别”。很多人能背出“内部表数据由Hive管理，外部表数据由HDFS管理”，但要往深了问就卡住。
我总结一个答题框架：内部表在删除表时，元数据和HDFS上的数据文件会一起删除；外部表在删除表时，只删除元数据，HDFS上的数据文件原封不动。因此，内部表适合临时表或中间表，外部表适合存放原始数据、共享数据，特别是日志、业务库同步过来的ODS层数据。
面试官一定会追问“为什么生产环境多用外部表”。答案在于数据安全性：原始数据是所有下游任务的源头，如果某天误执行了DROP TABLE，内部表会把数据文件一并清掉，事故级别直接拉满；外部表则只丢元数据，重跑一句DDL就能重新映射，数据毫发无损。我在实际项目中见过一次误删内部表的事故，全组花了大半天从备份恢复，从此我们立了一条规矩：所有ODS层表一律建外部表，内部表仅限临时结果表。
3.2 分区表的分区字段该怎么设计
分区是Hive面试的另一大核心点。分区的作用是把数据按某个维度拆分成子目录，查询时通过分区剪枝只扫描需要的目录，大幅减少I/O。
经常被问到的有这几点：
- 分区字段必须是伪列，不能在表中重复定义；
- 分区值会体现在HDFS目录名里；
- 静态分区使用PARTITION (dt='2025-01-01')，动态分区用SET hive.exec.dynamic.partition=true，并按动态分区字段顺序填写；
- 动态分区容易产生大量小文件，需要设置
hive.exec.max.dynamic.partitions和hive.exec.max.dynamic.partitions.pernode防止失控； - 多级分区可以带多个分区键，HDFS会生成嵌套目录，例如
/warehouse/table/dt=2025-01-01/city=beijing/。
你还需要回答“分区字段和时间字段有什么区别”。很多人以为在WHERE里写dt > '2025-01-01'就是在用分区，其实只有当它作为分区字段时才会触发分区剪枝，如果它是普通业务字段，Hive照样全表扫描。用的过程中我踩过一个坑：为了省事把日期字段直接保留为普通字段，结果每次查询都全表扫，数据量一大任务就跑半小时以上，后来改成分区字段，同样查询降到两分钟以内。
3.3 分桶和抽样，别再把两者搞混
分桶比分区更难理解。分桶是根据某个字段的哈希值取模，把数据分散到固定数量的文件里。它有两个主要用途：一个是join时提升效率，两个表按同一字段分桶时，可以在桶级别执行join而不必全表扫描；另一个是便于抽样，使用TABLESAMPLE语句可以快速从桶中取一部分数据做探查。
面试官常问“分桶和分区的区别”，回答时可以说：分区是目录级别的切分，按业务维度（如日期、城市）把数据隔开，查询时按目录跳过；分桶是文件级别的散列，按字段哈希把数据均匀打散到不同文件，同一种数据不保证在同一目录，但相同哈希值的一定落在同一桶内。分区像是图书馆按大类分成不同书架，分桶像是同一书架内再按书名的拼音首字母分到不同格子，各司其职。
这里要提醒一点，分桶字段的选择很关键，尽量选值分布均匀的字段。如果选性别这种只有两个值的字段，实际上只会产生两个桶，完全起不到均匀打散的效果。另外，分桶表在写入时必须显式指定CLUSTERED BY，并且往分桶表插入数据时最好启用强制分桶，否则Hive不会自动帮你做分桶操作。
4. 底层存储高频题：文件格式与压缩方案怎么选
4.1 五种常见文件格式的对比与选择逻辑
Hive支持多种文件格式，每种都有自己的适用场景，面试官常用“你们生产环境用的是什么格式”来考察你的实际经验。
- TextFile：默认格式，纯文本存储，最大优点是通用，但压缩率低、查询性能差，生产环境一般只作为临时落地的数据源。
- SequenceFile：以二进制KV对存储，支持块级压缩，但写入和读取性能一般，现在用得少了。
- RCFile：行列混合存储方案，先按行分块再按列存储，能有效减少读取时的数据量，是早期主流之一。
- ORC：对RCFile的改进，使用更高效的压缩编码、谓词下推与列剪枝能力，目前是离线数仓最主流的格式之一。
- Parquet：列式存储，主打跨平台兼容，在Spark、Impala、Hive、Flink之间无缝交换数据，如果公司有比较多Spark计算任务，Parquet往往是更好的选择。
面试官会追问“ORC和Parquet选哪个”。我的看法是：如果数据主要跑Hive或Impala，优先选ORC，它的压缩比和读取性能都更优；如果计算引擎比较多样，需要跨Spark、Flink、Hive协作，Parquet的生态兼容性更稳妥。这类问题从来没有标准答案，关键是能说清楚自己的选型理由和权衡点。
4.2 压缩方式不只是选个格式那么简单
讲完文件格式，面试官大概率会顺带问压缩格式，主要围绕gzip、bzip2、Snappy、LZO几种。回答的核心是权衡压缩比和压缩/解压速度，很少有一种压缩算法能在所有维度上做到最优。
压缩比从高到低大致是：bzip2 > gzip > LZO > Snappy，压缩速度从快到慢大致是：Snappy > LZO > gzip > bzip2。实际使用中我一般这样选：对于需要长期冷存的历史归档数据，用gzip或bzip2，追求高压缩比以节省存储成本；对于计算密集型任务，HDFS上和计算中间结果用Snappy，它解压速度快，对CPU负担小；LZO有一个特点是块级可切分，适合需要并行扫描大文件的场景，但需要额外安装索引工具，运维成本偏高。
需要特别强调的是，选压缩格式要同时考虑文件是否支持切分。gzip压缩文件本身不可切分，如果一个大文件超过一个块大小，MapTask只能启动一个任务去读，就会产生严重的数据倾斜；而Snappy和LZO在Container文件中是可以切分的。面试里能说出这一点，面试官会觉得你有真实调优经验。
4.3 一个场景题：统计数据量超过几十TB的表怎么定位慢查询
实际面试时，场景题比知识题更能拉开差距。面试官可能给你一个场景：某个表有几十TB的数据，每天凌晨跑任务，经常要跑三四个小时，怎么定位和优化。
答这道题的思路是分层排查。
第一步，看执行计划。Hive里用EXPLAIN查看执行计划，先确认有没有走全表扫描，有没有触发分区剪枝和列剪枝。这一步能排除“SQL写得烂”的大部分问题。
第二步，看数据倾斜。检查是否有某个ReduceTask运行时间远高于其他Task，如果有，大概率是数据倾斜。需要找到倾斜的键，可能是单独的Null值过多，也可能是某个热点Key（比如日活统计里的某个超级App）。
第三步，看文件格式和压缩。如果表还是TextFile，先改成ORC加Snappy。只这一步，往往是几十TB数据表提速最明显的操作。
第四步，看JVM参数和并行度。检查Map和Reduce数量是否合理，容器内存是否够用，避免小文件过多导致MapTask数量爆炸。
我把这套排查逻辑总结成了一张速查表，面试时可以按顺序说：
| 排查项 | 检查方法 | 常用手段 |
|---|---|---|
| SQL层 | EXPLAIN查看计划和扫描路径 | 分区剪枝、列剪枝、谓词下推 |
| 数据层 | 查看Task执行时间分布 | 定位倾斜键，清洗空值或加随机盐 |
| 存储层 | 检查表文件格式 | 改用ORC/Parquet加Snappy |
| 资源层 | 观察Map/Reduce数量与内存 | 合并小文件、调大容器内存 |
5. 数据倾斜与并发高频题：优化经验才是真正的分水岭
5.1 数据倾斜的三种典型场景
数据倾斜是Hive面试中区分普通开发者和资深开发者的核心考点。它的本质是：数据分布极度不均，导致部分节点承担的计算量远超其他节点，整体任务被拖慢到跑完为止。
最常见的三种倾斜场景分别是：
- GROUP BY倾斜：某类键特别多，比如统计用户行为时，某几个超级用户贡献了绝大部分记录，对应ReduceTask数据量巨大。
- JOIN倾斜：两个表关联时，某个关联键在表中出现次数极多，导致单个Reducer处理的数据量远超其他Reducer。
- 动态分区写入倾斜：数据写入动态分区时，某个目标分区数据特别多，对应的写任务变成了长尾任务。
面试官通常不会直接问“什么是数据倾斜”，而是问“你遇到过数据倾斜吗，怎么排查和解决的”。这时不要只背概念，要结构化成“用什么现象判断+怎么定位+最终用了什么方案”来回答。
5.2 解决倾斜的核心手段：改SQL、加盐、开优化
针对GROUP BY倾斜，最常用的办法是先按某个随机值拆开再聚合，也就是“两阶段聚合”。第一步给倾斜键附上随机前缀，把原本聚在一个Reduce的任务分散到多个Reduce做局部聚合，第二步去掉随机前缀再做一次全局聚合。这个方案能极大缓解单一Reducer的压力。
针对JOIN倾斜，如果是一张大表关联小表，优先确认是否走了MapJoin。如果大表关联大表，可以使用倾斜JOIN优化，Hive的hive.optimize.skewjoin参数可以在运行时把倾斜键单独处理。还有一种做法是给空值键加随机数，让空值不再堆积到同一个Reducer，同时保留原本的空值语义。
针对动态分区倾斜，可以在写入前先按分区字段做一次数据分布探查，必要时对热点分区单独处理。
还需要提一下Hive的自动优化开关，像hive.auto.convert.join=true、hive.optimize.skewjoin=true、hive.groupby.skewindata=true这些参数往往能省掉很多手动调优工作。不过参数不是万能的，自动优化对极端倾斜场景帮助有限，还是要根据数据情况手动改SQL。
5.3 趁热打铁：一道经典倾斜场景面试题的完整答法
我模拟一个面试官的真实题：某张订单表有个字段叫user_id，有大量用户为空或者为同一个测试账号，这张表和用户维度表做JOIN统计人均购买金额的时候，任务跑了2小时还没完成，你会怎么处理。
一个可复用的答法是：
第一步，先看执行计划，确认JOIN是否走了ReduceJoin，以及是否触发了自动MapJoin优化。
第二步，统计关联键分布，用一条GROUP BY语句确认空值、测试账号和热点用户的数据量占比。
第三步，针对空值做特殊处理，因为关联不上维度表，保留或丢弃都不影响最终统计口径，给user_id为空的记录打上一个随机数前缀，让它们均匀分配到不同Reducer。
第四步，对热点测试账号单独过滤，或者在SQL里用CASE WHEN把热点键拆分到多路，配合UNION ALL合并结果。
第五步，重新执行并对比任务耗时的变化。如果仍然有长尾，就检查文件格式和单个Mapper/Reducer处理的数据量是否合理。
这套思路不仅能解决问题，还充分展示了“排查-定位-实施-验证”的工程闭环能力，比只回答“加随机盐”三个字的候选人强太多。
5.4 并发与隔离：Hive生产环境的真实挑战
除了倾斜，并发问题也是面试官喜欢深入问的点。一个几百人共用的大集群，同时跑几十个Hive任务，一旦出现了资源争抢，任务跑到一半被杀，建表语句并发执行报错，这些问题都很常见。
Hive提供了几种资源管控手段：简单的是通过hive.exec.parallel控制同一SQL内部并行执行多个Job，但这只是单任务级别；更体系化的是通过hive.server2.tez.sessions.per.default.queue和YARN队列配置来做多租户隔离，把不同业务线的任务分到不同资源队列，避免互相拖垮。
面试官问到“怎么避免两个任务同时写同一张表”，可以回答：离线任务调度是有向无环图，能保证依赖关系，但如果存在人工临时反复跑数，就可能出现覆盖写入现象。最稳妥的办法有两个，一个是重跑前先做表级备份，另一个是采用INSERT OVERWRITE到临时表，最终通过LOAD或原子切换的方式更新目标表。线上无数事故都来自直接覆盖全表，宁可多一步也别省。
6. 模拟面试问答实录：如何用五分钟证明你懂Hive
6.1 “请介绍一下Hive”——别只背定义，用结构化回答
一个典型的开场问题。如果五分钟的自我介绍环节里面试官让你展开说Hive，你该怎么答？
我会推荐“三层递进”的回答结构。
第一层是什么：Hive是一个构建在Hadoop之上的数据仓库工具，用来对海量结构化数据进行离线分析，核心是将SQL转为MapReduce、Tez或Spark任务。
第二层是架构：分开讲用户接口层、Metastore层、编译优化层、执行层四部分，提到元数据用MySQL存储，执行计划会走六步转化流程。
第三层是场景：说明它适合批量历史数据统计、不适合实时查询，与存储引擎的对接主要基于HDFS上的数据文件完成。
这样回答最大的好处是让面试官感受到你有体系化思维。大多数候选人在第一层就停了，而深入讲架构和场景，等于主动展示了你对Hive的完整认知。
6.2 一组连环追问，看你能否接住
面试官很可能会顺着你的回答连续追问，我整理一组常见连环追问，大家可以自己先心里回答一遍再看答案要点：
问：Hive为什么不能用索引来做快速查询？ 答：Hive的表是基于HDFS文件存储的，数据量巨大，索引维度很难做到细粒度维护；本质上是为全表扫描设计的，通过分区和列式存储实现扫描优化，而不是像数据库那样靠二级索引定位行。
问：你们公司Hive执行引擎是MR还是Tez，为什么？ 答：早期是MR，后来切到Tez。原因是Tez能通过DAG图把多个MR阶段串联，节点间减少数据落盘和重复读取，典型ETL任务在Tez上比MR快30%以上。如果计算任务需要更强实时性，还可以选Spark引擎。
问：往一个分区表里插入数据的时候，partition字段的顺序错了会怎么办？ 答：如果SQL没有按建表语句的分区字段顺序写，动态分区的字段位置就必须严格保持一致，否则Hive会报错或把数据写进错误的分区目录。生产环境我最常见的问题是有人在SELECT最后多写了一个字段，结果被当成分区值，数据全写到了奇怪的分区路径上。
问：如何优化一条要跑几小时的GROUP BY？ 答：先确认是否使用了hive.groupby.skewindata，再看数据倾斜的情况，必要时改两阶段聚合。还要查看Reducer并行度设置，不要把并发参数设得太高导致小文件爆炸。
这些追问并没有标准答案，面试官更看重你的思考路径和工程判断力。
6.3 一个完整的“技术方案题”：某天凌晨全公司数仓报表慢了
某公司数仓凌晨ETL任务经常超时，所有报表延后，你怎么排查。这个问题本质上是多地综合考点，能在一道题里包含架构、参数、存储、资源多个维度。
我的建议答案框架：
- 先看任务流依赖，确认是源头任务超时还是下游排队堵塞；
- 再看慢任务的执行计划，检查是否有全表扫描和无效Join；
- 再查数据倾斜，看是否有单Reducer处理大量数据；
- 再看资源队列，确认是否多个团队在同时抢资源；
- 最后看存储层，确认是否有大量小文件导致Task启动开销过大。
答题时不要慌，按“依赖-执行计划-数据分布-资源-存储”五步排查来展开。
7. 避坑经验与面试准备建议
7.1 我这些年踩过的Hive坑清单
面试时踩坑不可怕，关键是踩完坑要能提炼出经验。这些真实场景表达出来，比简历上写“精通Hive”有说服力得多。
第一个坑是动态分区的默认参数踩雷。早期用动态分区往结果表写数据时没设hive.exec.max.dynamic.partitions，结果分区数超过上限直接报错。后来配置了足够大的上限，同时在写入前按天检查数据范围，避免生成过多无意义分区。
第二个坑是内外部表混用事故。某次用内部表做临时结果表，跑完后手工DROP，结果下游引用了其中某份数据，别人找不到了，数据也没了。从此我们规范了建表规范，所有中间层和ODS层必须外部表，所有临时表加TMP_前缀并设置生命周期策略。
第三个坑是ORC表的结构变更。把表从TextFile转成ORC之后，用ALTER TABLE ADD COLUMNS加列往往不生效，必须先确认表是否开启列式存储的结构化变更。这个问题在面试里很少被问到，但在活动中遇到会非常头疼。
第四个坑是Hive中大量使用COUNT(DISTINCT)很慢。COUNT(DISTINCT)在数据量大时会极大消耗内存和计算，优先改成“GROUP BY后再COUNT”的方式执行，性能可以快出好几十倍。
7.2 准备Hive面试的节奏建议
我给准备面试的朋友一个实际可操作的复习节奏规划。
前三天先把基础架构和表设计问题过一遍，能用纸笔画下Hive的架构流程图，能流畅讲出SQL到MR的六步执行链路。中间花两天整理文件格式、压缩方式、常用函数和UDF相关的对比表。最后两天集中练数据倾斜和场景题，最好找朋友模拟面试，用录音功能回听自己哪里卡壳，把卡壳点标记出来补强。
如果时间充裕，建议去某个开源Demo环境里真正建几张表、跑几句SQL、用EXPLAIN看执行计划的变化。我自己带过一些新人，脱稿能画出架构图、说出数据倾斜三种场景解决手段的，基本都能在面试中稳稳拿下Hive部分。
7.3 分享一个最后的个人实战技巧
我在实际面试中还有一个自己总结的话术习惯：回答Hive问题时，永远带上一句“这是我们生产环境里踩过的真实坑”。这句话本身不是套路，而是提醒自己回答不要只停留在理论层。比如讲到外部表时补一句“我们ODS层全用外部表，就是为了防止误删元数据把原始文件一起删掉”，讲到文件格式时补一句“我们TB级大表从TextFile改成ORC之后，任务时间缩短了一半”。这类来自一线的细节，才是让面试官真正记住你的地方。
掌握Hive不是靠背诵几十道题，而是靠把架构原理、存储机制、优化经验串成一套自己的思考框架。下一篇文章我会继续整理Hive的高阶函数、UDF开发和更多实战场景题，有兴趣的可以先按今天这篇的思路，把基础部分踏踏实实练一遍。
