1.大数据笔试真题集锦---第五章:Hive面试题
2.离线编译 Velox 小记
3.译：一文科普 RocksDB 工作原理
大数据笔试真题集锦---第五章:Hive面试题
我会不间断地更新维护，库源希望对正在寻找大数据工作的码s码朋友们有所帮助。 第五章目录 第五章 Hive 5.1 Hive 运行原理（源码级） 1.1 reduce端join 在reduce端，库源对两个表的码s码数据分别标记tag，发送数据。库源根据分区分组规则获取相同key的码s码文件上传 源码下载数据，再根据tag进行join操作，库源完成实际连接。码s码 1.2 map端join 将小表复制到每个map task的库源内存中，仅扫描大表，码s码对大表中key在小表中存在时进行join操作。库源使用DistributedCache.addCacheFile设置小表，码s码通过标准IO获取数据。库源 1.3 semi join 先将参与join的码s码表1的key复制到表3中，复制多份到各map task，库源过滤不在新表3的表2数据，最后进行reduce。 5.2 Hive 建表5.3.1 传统方式建表
定义数据类型，如：TINYINT, STRING, TIMESTAMP, DECIMAL。 使用ARRAY, MAP, STRUCT结构。5.3.2 CTAS查询建表
创建表时指定表名、存储格式、数据来源查询语句。 缺点：默认数据类型范围限制。5.3.3 Like建表
通过复制已有表的wpf游戏源码结构来创建新表。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、php 社区 源码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的区别、交易表查询示例、登录用户数量查询、动态分区与静态分区的区别。离线编译 Velox 小记
Velox 定义为 C++ 编写的数据库执行加速 library，目标是实现流处理、批处理和 AI/ML 领域计算的统一化，它不提供 parser 和 optimizer，旨在让各类计算引擎通过接入同一套 Native Engine 进行数据处理。
在编译网络环境良好的git源码配置机器上，只需根据 GitHub 文档执行 scripts 目录的 setup 脚本，正常编译即可。也可以参考 .circleci 目录下的 CI 执行脚本了解详细的环境准备、编译、测试流程。目前 Velox 支持在 Ubuntu ./.、Centos8 和 MacOS Intel/M1 下编译，推荐在 Ubuntu 环境下学习。
对于网络环境恶劣的情况，可以参考以下步骤。以 Centos8 为例，在 scripts/setup-centos8.sh 脚本中，所有 dnf_install 安装的基础依赖都通过 Centos8 系统镜像源下载，dnf 是新版的 yum，需要进行换源操作。wget_and_untar 安装的是 Velox 依赖的项目，用户只需在本地下载后传至 Linux 服务器解压即可。其余代码则负责将依赖下载、编译并安装至 Linux 环境中作为系统库使用。
如果不想手动下载、解压、编译和安装依赖，Velox 的编译流程设计了查找依赖的优先级。首先在系统库中查找，其次通过 CMake 下载编译。每个依赖对应有 DEPENCENCY_SOURCE 变量，值为 AUTO 表示按照优先级顺序查找，SYSTEM 表示仅从系统库查找，BUNDLED 表示通过 CMake 下载编译。
Velox 的编译流程还支持在编译源码时同时编译依赖。用户需在 third_party/CMakeLists.txt 和 CMake/resolve_dependency_modules 中定义依赖，通过简单修改依赖的 URL 为本地 tar 包路径，可实现 Velox 从本地路径完成依赖的解压和编译。
处理 submodule 时，Velox 通过 git submodule 包含了 xsimd 和 googletest，对于无法访问 https 协议的网络环境，可以将 .gitmodules 中的 URL 更改为对应的 git 协议地址。若无法访问任何协议，Velox 也提供了通过 CMake 编译的选项。
处理 Arrow 时，需要对编译时的依赖进行预处理。在 thrid_party/CMakeLists.txt 中定义了 Arrow 编译所需的依赖，例如 `-DARROW_WITH_SNAPPY=ON` 表示同时编译 Snappy。用户可通过手动下载依赖放在指定路径下，通过 export ARROW_XXX_URL=/opt/3rd_tars/xxx.tar.gz 在当前会话中指定依赖路径，实现 Offline Build。若不关注 parquet 格式的相关代码，则无需特别关注 Arrow 的编译。
Velox 依赖管理与 Arrow 类似，但不支持通过环境变量指定 tar 包路径。目前存在一个 Bug，使得通过 VELOX_XXX_URL 指定依赖路径时无法编译，具体查看 Issue 。
完成所有环境依赖准备工作后，即可进行源码编译与测试。确定编译时是通过网络下载依赖还是从本地路径加载，可通过查看 CMake 日志中是 Using SYSTEM xxx 还是 Using BUNDLED xxx，以及 _build/release/_deps 和 _build/release/thrid_party/arrow_ep/src/arrow_ep_install 是否存在 tar 包来判断。
译：一文科普 RocksDB 工作原理
RocksDB 是一种可持久化的、内嵌型的键值存储（KV 存储）。它旨在存储大量 key 及其对应的 value，常被用于构建倒排索引、文档数据库、SQL 数据库、缓存系统和消息代理等复杂系统。RocksDB 在 年从 Google 的 LevelDB 分叉而来，针对 SSD 服务器进行了优化，并目前由 Meta 开发和维护。它以 C++ 编写，支持 C、C++ 及其他语言（如 Rust、Go、Java）的嵌入。如果你熟悉 SQLite，可以认为 RocksDB 是一种内嵌式数据库，需依赖应用层实现特定功能。
RocksDB 使用日志结构合并树（LSM-Tree）作为核心数据结构，这是一种基于多个有序层级的树形数据结构，可用于应对写密集型工作负载。LSM-Tree 的顶层是 MemTable，一个内存缓冲区，用于缓存最近的写入数据。较低层级的数据存储在磁盘上，以 L0 层为例，存储从内存移动到磁盘的数据，其他层级存储更旧的数据。当某一层级的数据量过大时，会通过合并操作转移到下一层。
为了保证数据持久化，RocksDB 将所有更新写入磁盘上的预写日志（WAL）。当应用重启时，可以通过回放 WAL 来恢复 MemTable 的原始状态。WAL 是一个只允许追加的文件，包含一组更改记录序列，每个记录包含键值对、操作类型和校验和。
当 MemTable 变满时，会触发刷盘（Flush）操作，将不可变的 MemTable 内容持久化到磁盘，并丢弃原始 MemTable，同时开始写入新的 WAL 和 MemTable。MemTable 默认基于跳表实现，以提高查询和插入效率。RocksDB 支持各种压缩算法，如 Zlib、BZ2、Snappy、LZ4 或 ZSTD，用于存储 SST 文件。
SST 文件是 MemTable 刷盘后生成的，包含了有序的键值对。每个 SST 文件由数据部分和索引块组成，数据部分包含一系列有序的键值对，而索引块存储了数据块中最后一个键的偏移量，便于快速定位键值对。RocksDB 还支持布隆过滤器，用于快速检测某个键是否存在于 SST 文件中。
当数据库大小增加时，空间放大（存储数据所用实际空间与逻辑大小的比值）和读放大（用户执行一次逻辑读操作所需实际 IO 次数）的问题变得明显。为了解决这些问题，RocksDB 实现了 Compaction 机制，通过合并 SST 文件来降低空间和读放大，同时增加写放大。Leveled Compaction 是默认策略，它会在不同层级之间进行选择性合并，以优化空间使用。
RocksDB 的读路径相对简单，主要涉及从 MemTable 开始，下探到 L0 层，然后继续向更低层级查找，直到找到目标键或检查完整个树。合并（merge）操作允许用户在内存中对键值进行聚合操作，适用于需要对已有值进行少量更新的场景。然而，这种操作增加了读时的复杂性，因为读操作需要在多次调用 merge 函数后才能得到最终结果。
使用 RocksDB 需要针对特定工作负载进行配置调优，因为它提供了许多可配置项，但理解其内部原理并调整这些配置通常需要深入研究源代码。RocksDB 是构建高性能数据库模块的优秀选择，能够帮助开发者专注于上层业务逻辑实现，而无需从零开始设计底层存储系统。