1.从线上某应用多作业并发创建同一HIVE表分区偶现失败问题聊起-深度剖析下HIVE创建表分区的源码内部逻辑
2.beehive 源码阅读- go 语言的自动化机器
3.Flink深入浅出：JDBC Connector源码分析
4.大数据笔试真题集锦---第五章:Hive面试题
5.mimikatz源码分析-lsadump模块（注册表）
6.spark sql源码系列 | with as 语句真的会把查询的数据存内存嘛？
从线上某应用多作业并发创建同一HIVE表分区偶现失败问题聊起-深度剖析下HIVE创建表分区的内部逻辑
在大数据领域，早期版本的分析原生HIVE由于缺乏锁和事务机制，不支持并发写操作。源码多作业并发创建同一表分区或写数据到同一表分区时，分析易遇报错或数据不一致问题。源码HIVE1.X版本开始加强事务和锁支持，分析三浪源码指标大幅降低并发写问题。源码实践中，分析避免同一表分区的源码并发写以确保应用一致性。本文分享线上多作业并发写同一表分区时报错问题，分析提供解决方法。源码
公司内部使用数据同步工具datago，分析用于增强datax并自动清理表分区、源码创建表分区。分析在使用星环TDH平台时，源码某客户生产环境在多分片并发采集时，datago作业运行失败。问题偶发，需查明底层原因及优化措施。具体报错为HDFS目录不存在。
问题出现在datago采集作业初始化阶段，涉及自动清理旧文件和自动创建表分区配置。异常堆栈与datago源码分析揭示问题原因。解决策略需避免并发创建同一表分区，并避免创建时list分区目录文件。由于无法调整HIVE表分区创建逻辑，需在自动创建表分区上进行调整。
本文深入剖析HIVE创建表分区内部逻辑，直播如何源码录制提供解决问题的思路。对HIVE源码感兴趣者可进一步探索相关方法。
beehive 源码阅读- go 语言的自动化机器
beehive源码深入解析：Go语言中的自动化机器设计
beehive的核心模块系统在包<p>bees</p>中体现其独特的解耦设计，这使得系统操作简便且易于扩展。只需要少量的学习，就能扩展自己的beehive功能。这里的"bee"代表Worker，执行具体任务，类似于采蜜的工蜂；而"hive"则是一个WorkerPool的工厂，通过简单配置（如一个token）即可创建针对特定任务的bee。
"chain"是连接事件和处理的关键，它将事件（如博客更新）与响应（如发送邮件）关联起来，通过事件通道（eventChan）触发并执行相应的action。WebBee的实现展示了如何在Run方法中接收事件并唤醒相应的bee，同时ServeHTTP函数负责press"="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的区别、交易表查询示例、登录用户数量查询、动态分区与静态分区的区别。mimikatz源码分析-lsadump模块（注册表）
mimikatz是一款内网渗透中的强大工具，本文将深入分析其lsadump模块中的sam部分，探索如何从注册表获取用户哈希。
首先，简要了解一下Windows注册表hive文件的结构。hive文件结构类似于PE文件，爱推文源码包括文件头和多个节区，每个节区又有节区头和巢室。其中，巢箱由HBASE_BLOCK表示，巢室由BIN和CELL表示，整体结构被称为“储巢”。通过分析hive文件的结构图，可以更直观地理解其内部组织。
在解析过程中，需要关注的关键部分包括块的签名（regf）和节区的签名（hbin）。这些签名对于定位和解析注册表中的数据至关重要。
接下来，深入解析mimikatz的解析流程。在具备sam文件和system文件的情况下，主要分为以下步骤：获取注册表system的句柄、读取计算机名和解密密钥、获取注册表sam的句柄以及读取用户名和用户哈希。若无sam文件和system文件，mimikatz将直接通过官方API读取本地机器的注册表。
在mimikatz中，会定义几个关键结构体，包括用于标识操作的注册表对象和内容的结构体（PKULL_M_REGISTRY_HANDLE）以及注册表文件句柄结构体（HKULL_M_REGISTRY_HANDLE）。这些结构体包含了文件映射句柄、映射到调用进程地址空间的位置、巢箱的起始位置以及用于查找子键和子键值的键巢室。
在获取注册表“句柄”后，接下来的任务是获取计算机名和解密密钥。密钥位于HKLM\SYSTEM\ControlSet\Current\Control\LSA，通过查找键值，将其转换为四个字节的密钥数据。利用这个密钥数据，mimikatz能够解析出最终的密钥。
对于sam文件和system文件的操作，主要涉及文件映射到内存的过程，通过Windows API（CreateFileMapping和MapViewOfFile）实现。这些API使得mimikatz能够在不占用大量系统资源的情况下，方便地处理大文件。
在获取了注册表系统和sam的句柄后，mimikatz会进一步解析注册表以获取计算机名和密钥。对于密钥的获取，mimikatz通过遍历注册表项，定位到特定的键值，并通过转换宽字符为字节序列，最终组装出密钥数据。
接着，解析过程继续进行，获取用户名和用户哈希。在解析sam键时，mimikatz首先会获取SID，然后遍历HKLM\SAM\Domains\Account\Users，解析获取用户名及其对应的哈希。解析流程涉及多个步骤，包括定位samKey、获取用户名和用户哈希，以及使用samKey解密哈希数据。
对于samKey的获取，mimikatz需要解密加密的数据，使用syskey作为解密密钥。解密过程根据加密算法（rc4或aes）有所不同，但在最终阶段，mimikatz会调用系统函数对数据进行解密，从而获取用户哈希。
在完成用户哈希的解析后，mimikatz还提供了一个额外的功能：获取SupplementalCreds。这个功能可以解析并解密获取对应用户的SupplementalCredentials属性，包括明文密码及哈希值，为用户提供更全面的哈希信息。
综上所述，mimikatz通过解析注册表，实现了从系统中获取用户哈希的高效功能，为内网渗透提供了强大的工具支持。通过深入理解其解析流程和关键结构体的定义，可以更好地掌握如何利用mimikatz进行深入的安全分析和取证工作。
spark sql源码系列 | with as 语句真的会把查询的数据存内存嘛？
在探讨 Spark SQL 中 with...as 语句是否真的会把查询的数据存入内存之前，我们需要理清几个关键点。首先，网上诸多博客常常提及 with...as 语句会将数据存放于内存中，来提升性能。那么，实际情况究竟如何呢？
让我们以 hive-sql 的视角来解答这一问题。在 hive 中，有一个名为 `hive.optimize.cte.materialize.threshold` 的参数。默认情况下，其值为 -1，代表关闭。当值大于 0 时（如设置为 2），with...as 语句生成的表将在被引用次数达到设定值后物化，从而确保 with...as 语句仅执行一次，进而提高效率。
接下来，我们通过具体测试来验证上述结论。在不调整该参数的情况下，执行计划显示 test 表被读取了两次。此时，我们将参数调整为 `set hive.optimize.cte.materialize.threshold=1`，执行计划显示了 test 表被物化的情况，表明查询结果已被缓存。
转而观察 Spark SQL 端，我们并未发现相关优化参数。Spark 对 with...as 的操作相对较少，在源码层面，通过获取元数据时所做的参数判断（如阈值与 cte 引用次数），我们可以发现 Spark 在这个逻辑上并未提供明确的优化机制，来专门针对 with...as 语句进行高效管理。
综上所述，通过与 hive-sql 的对比以及深入源码分析，我们得出了 with...as 语句在 Spark SQL 中是否把数据存入内存的结论，答案并不是绝对的。关键在于是否通过参数调整来物化结果，以及 Spark 在自身框架层面并未提供特定优化策略来针对 with...as 语句进行内存管理。因此，正确使用 with...as 语句并结合具体业务场景，灵活调整优化参数策略，是实现性能提升的关键。
通过深挖Clickhouse源码，我精通了数据去重！
数据去重的Clickhouse探索
在大数据面试中，数据去重是一个常考问题。虽然很多博主已经分享过相关知识，但本文将带您深入理解Hive引擎和Clickhouse在去重上的差异，尤其是后者如何通过MergeTree和高效的数据结构优化去重性能。Hive去重
Hive中，distinct可能导致数据倾斜，而group by则通过分布式处理提高效率。面试时，理解MapReduce的数据分区分组是关键。然而，对于大规模数据，Hive的处理速度往往无法满足需求。Clickhouse的登场
面对这个问题，Clickhouse凭借其列存储和MergeTree引擎崭露头角。MergeTree的高效体现在它的数据分区和稀疏索引，以及动态生成和合并分区的能力。Clickhouse：Yandex开源的实时分析数据库，每秒处理亿级数据
MergeTree存储结构：基于列存储，通过合并树实现高效去重
数据分区和稀疏索引
Clickhouse的分区策略和数据组织使得去重更为快速。稀疏索引通过标记大量数据区间，极大地减少了查询范围，提高性能。优化后的去重速度
测试显示，Clickhouse在去重任务上表现出惊人速度，特别是通过Bitmap机制，去重性能进一步提升。源码解析与原则
深入了解Clickhouse的底层原理，如Bitmap机制，对于优化去重至关重要，这体现了对业务实现性能影响的深度理解。总结与启示
对于数据去重，无论面试还是日常工作中，深入探究和实践是提升的关键。不断积累和学习，即使是初入职场者也能在大数据领域找到自己的位置。
