1.大数据笔试真题集锦---第五章:Hive面试题
2.LevelDB 源码剖析1 -- 原理

大数据笔试真题集锦---第五章:Hive面试题

       我会不间断地更新维护，源译希望对正在寻找大数据工作的码编朋友们有所帮助。

       第五章目录

       第五章 Hive

       5.1 Hive 运行原理（源码级）

       1.1 reduce端join

       在reduce端，源译对两个表的码编数据分别标记tag，发送数据。源译根据分区分组规则获取相同key的码编qq邮箱源码数据，再根据tag进行join操作，源译完成实际连接。码编

       1.2 map端join

       将小表复制到每个map task的源译内存中，仅扫描大表，码编对大表中key在小表中存在时进行join操作。源译使用DistributedCache.addCacheFile设置小表，码编通过标准IO获取数据。源译

       1.3 semi join

       先将参与join的码编表1的key复制到表3中，复制多份到各map task，源译过滤不在新表3的表2数据，最后进行reduce。51报修源码

       5.2 Hive 建表

5.3.1 传统方式建表

       定义数据类型，如：TINYINT, STRING, TIMESTAMP, DECIMAL。

       使用ARRAY, MAP, STRUCT结构。

5.3.2 CTAS查询建表

       创建表时指定表名、存储格式、数据来源查询语句。

       缺点：默认数据类型范围限制。

5.3.3 Like建表

       通过复制已有表的结构来创建新表。

5.4 存储格式和压缩格式

       选择ORC+bzip/gzip作为源存储，ORC+Snappy作为中间存储。

       分区表单文件不大采用gzip压缩，桶表使用bzip或lzo支持分片压缩。

       设置压缩参数，如"orc.compress"="gzip"。

5.5 内部表和外部表

       外部表使用external关键字和指定HDFS目录创建。

       内部表在创建时生成对应目录的预订平台源码文件夹，外部表以指定文件夹为数据源。

       内部表删除时删除整个文件夹，外部表仅删除元数据。

5.6 分区表和分桶表

       分区表按分区字段拆分存储，避免全表查询，提高效率。

       动态分区通过设置参数开启，根据字段值决定分区。

       分桶表依据分桶字段hash值分组拆分数据。

5.7 行转列和列转行

       行转列使用split、explode、laterview，列转行使用concat_ws、collect_list/set。

5.8 Hive时间函数

       from_unixtime、unix_timestamp、周瑜源码精髓to_date、month、weekofyear、quarter、trunc、current_date、date_add、date_sub、datediff。

       时间戳支持转换和截断，标准格式为'yyyy-MM-dd HH:mm:ss'。

       month函数基于标准格式截断，识别时截取前7位。

5.9 Hive 排名函数

       row_number、dense_rank、rank。答案源码

5. Hive 分析函数：Ntile

       效果：排序并分桶。

       ntile(3) over(partition by A order by B)效果，可用于取前%数据统计。

5. Hive 拉链表更新

       实现方式和优化策略。

5. Hive 排序

       order by、order by limit、sort by、sort by limit的原理和应用场景。

5. Hive 调优

       减少distinct、优化map任务数量、并行度优化、小文件问题解决、存储格式和压缩格式设置。

5. Hive和Hbase区别

       Hive和Hbase的区别，Hive面向分析、高延迟、结构化，Hbase面向编程、低延迟、非结构化。

5. 其他

       用过的开窗函数、表join转换原理、sort by和order by的区别、交易表查询示例、登录用户数量查询、动态分区与静态分区的区别。

LevelDB 源码剖析1 -- 原理

       LSM-Tree，全称Log-Structured Merge Tree，被广泛应用于数据库系统中，如HBase、Cassandra、LevelDB和SQLite，甚至MongoDB 3.0也引入了可选的LSM-Tree引擎。这种数据结构旨在提供优于传统B+树或ISAM（Indexed Sequential Access Method）方法的写入吞吐量，通过避免随机的本地更新操作实现。

       LSM-Tree的核心思想基于磁盘性能的特性：随机访问速度远低于顺序访问，三个数量级的差距。因此，简单地将数据附加至文件尾部（日志或堆文件策略）可以提供接近理论极限的写入吞吐量。尽管这种方法足够简单且性能良好，但它有一个明显的缺点：从日志中随机读取数据需要花费更多时间，因为需要按时间顺序从近及远扫描日志直至找到所需键。因此，日志策略仅适用于简单的数据访问场景。

       为了应对更复杂的读取需求，如基于键的搜索、范围搜索等，LSM-Tree引入了一种改进策略，通过创建一系列排序文件来存储数据，每次写入都会生成一个新的文件，同时保留了日志系统优秀的写性能。在读取数据时，系统会检查所有文件，并定期合并文件以减少文件数量，从而提高读取性能。

       在LSM-Tree的基本算法中，写入数据按照顺序保存到一组较小的排序文件中。每个文件代表了一段时间内的数据变更，且在写入前进行排序。内存表作为写入数据的缓冲区，用于保持键值的顺序。当内存表填满后，已排序的数据刷新到磁盘上的新文件。系统会周期性地执行合并操作，选择一些文件进行合并，以减少文件数量和删除冗余数据，同时维持读取性能。

       读取数据时，系统首先检查内存缓冲区，若未找到目标键，则以反向时间顺序检查各个文件，直到找到目标键。合并操作通过定期将文件合并在一起，控制文件数量和读取性能，即使文件数量增加，读取性能仍可保持在可接受范围内。通过使用内存中保存的页索引，可以优化读取操作，尤其是在文件末尾保留索引块，这通常比直接二进制搜索更高效。

       为了减少读取操作时访问的文件数量，新实现采用了分级合并（Leveled Compaction），即基于级别的文件合并策略。这不仅减少了最坏情况下需要访问的文件数量，还减少了单次压缩的副作用，同时提供更好的读取性能。分级合并与基本合并的主要区别在于文件合并的策略，这使得工作负载扩展合并的影响更高效，同时减少总空间需求。