1.大数据笔试真题集锦---第五章:Hive面试题
2.TiKV 源码解析系列文章（十四）Coprocessor 概览
3.zookeeper开山篇-编译安装与zk基础命令使用
4.LevelDB 源码剖析1 -- 原理
大数据笔试真题集锦---第五章:Hive面试题
我会不间断地更新维护，码下希望对正在寻找大数据工作的码下朋友们有所帮助。 第五章目录 第五章 Hive 5.1 Hive 运行原理（源码级） 1.1 reduce端join 在reduce端，码下对两个表的码下数据分别标记tag，发送数据。码下根据分区分组规则获取相同key的码下猫头鹰源码数据，再根据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。 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"。egrimace源码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函数基于标准格式截断，hart源码识别时截取前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的区别、交易表查询示例、登录用户数量查询、动态分区与静态分区的gerberview源码区别。TiKV 源码解析系列文章（十四）Coprocessor 概览
本文将简要介绍 TiKV Coprocessor 的基本原理。TiKV Coprocessor 是 TiDB 的一部分，用于在 TiKV 层处理读请求。通过引入 Coprocessor，TiKV 可以在获取数据后进行计算，从而提高性能。
传统处理方式中，TiDB 向 TiKV 获取数据，然后在 TiDB 内部进行计算。而 Coprocessor 则允许 TiKV 进行计算，将计算结果直接返回给 TiDB，减少数据在系统内部的传输。
Coprocessor 的概念借鉴自 HBase，其主要功能是对读请求进行分类，处理包括 TableScan、IndexScan、Selection、Limit、TopN、Aggregation 等不同类型请求。其中，DAG 类请求是最复杂且常用的类型，本文将重点介绍。
DAG 请求是由一系列算子组成的有向无环图，这些算子在代码中称为 Executors。DAG 请求目前支持两种计算模型：火山模型和向量化模型。在当前的 TiKV master 上，这两种模型并存，但火山模型已被弃用，因此本文将重点介绍向量化计算模型。blast源码
向量化计算模型中，所有算子实现了 BatchExecutor 接口，其核心功能是 get_batch。算子类型包括 TableScan、IndexScan、Selection、Limit、TopN 和 Aggregation 等，它们之间可以任意组合。
以查询语句“select count(1) from t where age>”为例，展示了如何使用不同算子进行处理。本文仅提供 Coprocessor 的概要介绍，后续将深入分析该模块的源码细节，并欢迎读者提出改进意见。
zookeeper开山篇-编译安装与zk基础命令使用
随着软件开发规模逐渐增大，单体服务难以解决并发流量问题，分布式改造成为趋势。Apache Zookeeper，作为成熟的分布式协调组件，提供配置维护、域名服务、分布式同步、组服务等功能，是Hadoop和Hbase的重要组成部分。本篇开始，我们将深入了解Zookeeper的学习之旅。
Zookeeper是什么？它是一款分布式协调服务，由Google Chubby开源实现。作为一款热门的开源组件，Zookeeper在分布式应用中提供一致性服务，包括配置维护、域名服务、分布式同步、组服务等。
接下来，我们了解Zookeeper的下载与安装。有多种下载方式，包括Zookeeper官网下载和GitHub搜索下载。官网下载地址为mirrors.tuna.tsinghua.edu.cn，GitHub中搜索Zookeeper进入页面，选择releases进入正式发布的版本，下载对应版本。下载后，解压至常用安装目录，并将conf目录下的zoo_sample.cfg文件复制重命名为zoo.cfg。在zoo.cfg文件中，修改dataDir为zookeeper安装目录下的data文件夹（安装后需手动创建data文件夹和存放日志的目录），并添加dataLogDir（日志存放目录）。完成配置后，启动Zookeeper服务，双击运行bin目录下的zkServer.cmd文件。
除了直接下载Zookeeper正式版，我们还可以选择下载源码进行编译，自定义代码和启动类，但此过程较为繁琐。首先，需要下载Ant进行编译，下载地址为ant.apache.org/bindownload，根据当前开发环境的jdk版本及需要编译的zk源码版本选择对应版本。下载完成后，解压并配置环境变量。进入cmd窗口，执行命令验证Ant版本信息。然后，使用GitHub下载zk源码，找到对应分支进行git下载。进入下载的zk源码目录，启动cmd窗口，输入编译命令，等待编译成功输出。编译完成后，将代码导入开发工具，完成源码编译。
Zookeeper编译源码分为几个步骤：下载Ant、配置环境变量、GitHub下载源码、编译源码、导入开发工具。编译成功后，可以查看源码目录。Zookeeper3.5版本起，模块分离，包括文档说明、基础数据结构类定义、客户端和服务端代码等分别在不同工程下。启动类如ZooKeeperServerMain、QuorumPeerMain分别位于特定包下，实现单机版和集群版Zookeeper的启动。
在启动单机版Zookeeper过程中，若遇到编译失败问题，可能是由于编译时使用了资源文件git.properties配置，而实际代码中不存在此文件。通过配置插件properties-maven-plugin和exec-maven-plugin解决编译失败问题，修改插件配置，将{ build.time}参数改为自己的值。编译成功后，配置zoo.cfg文件启动单机服务。
Zookeeper客户端命令学习：双击zkCli.cmd进行本地连接操作，使用help命令查看所有支持的命令。命令操作包括查看路径内容（ls命令）、创建节点（create命令）、获取节点内容（get命令）、节点更新（stat命令）、整合ls与stat操作（ls2命令）以及删除节点（delete命令）。每个命令执行后，将返回相应的属性和操作结果，如节点的cZxid、ctime等属性。
至此，Zookeeper编译安装与基础命令使用的学习内容结束。通过本篇内容，我们深入了解了Zookeeper的安装、编译及常用命令的使用，为后续的深入学习打下基础。感谢您的阅读与关注！
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），即基于级别的文件合并策略。这不仅减少了最坏情况下需要访问的文件数量，还减少了单次压缩的副作用，同时提供更好的读取性能。分级合并与基本合并的主要区别在于文件合并的策略，这使得工作负载扩展合并的影响更高效，同时减少总空间需求。
