1.大数据笔试真题集锦---第五章:Hive面试题
2.离线编译 Velox 小记
3.译：一文科普 RocksDB 工作原理

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

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

       第五章目录

       第五章 Hive

       5.1 Hive 运行原理（源码级）

       1.1 reduce端join

       在reduce端，库源对两个表的码s码数据分别标记tag，发送数据。库源根据分区分组规则获取相同key的码s码mmap 源码数据，再根据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建表

       通过复制已有表的xweibo微博源码结构来创建新表。

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的php smarty 网站源码原理和应用场景。

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 进行数据处理。

       在编译网络环境良好的查看php内核源码机器上，只需根据 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 是构建高性能数据库模块的优秀选择，能够帮助开发者专注于上层业务逻辑实现，而无需从零开始设计底层存储系统。