1.如何更改 datax 以支持hive 的源码 DECIMAL 数据类型?
2.Hive 编程专题之 - 自定义函数 Java 篇
3.mimikatz源码分析-lsadump模块（注册表）
4.大数据笔试真题集锦---第五章:Hive面试题
5.Hive Server2对execute和executeQuery的处理
6.Hive MetaStore 的挑战及优化方案
如何更改 datax 以支持hive 的 DECIMAL 数据类型?
在处理数据时，我们经常需要将数据从一种数据类型转换为另一种数据类型。源码在数据迁移任务中，源码如果涉及到使用datax进行数据迁移，源码且源数据或目标数据中出现了Hive的源码DECIMAL数据类型，那么如何确保数据迁移的源码谐波形态源码准确性和完整性就成为了一个关键问题。本文将详细介绍如何更改datax以支持Hive的源码DECIMAL数据类型。
在JAVA中，源码主要使用float/double和BigDecimal来存储小数。源码其中，源码float和double在不需要完全精确的源码计算结果的场景下，可以提供较高的源码运算效率，但当涉及到金融等场景需要精确计算时，源码必须使用BigDecimal。源码
Hive支持多种数字类型数据，源码如FLOAT、DOUBLE、DECIMAL和NUMERIC。DECIMAL数据类型是后加入的，允许设置精度和标度，适用于需要高度精确计算的场景。
若要使datax支持Hive的DECIMAL数据类型，关键在于修改datax源码，增强其对DECIMAL数据的读取和写入能力。主要通过以下几个步骤：
1. **修改HDFS Reader**：在处理Hive ORC文件时，需要修改HDFS Reader插件中的相关类和方法，如DFSUtil#transportOneRecord。通过该步骤，确保能正确读取到ORC文件中的DECIMAL字段。datax的Double类型可以通过其内部的rawData字段存储数据的原始内容，支持Java.math.BigDecimal和Java.lang.Double，因此可以实现不修改HDFS Reader代码，直接读取并处理DECIMAL数据的目标。配置作业时，将Hive的DECIMAL字段指定为datax的Double类型，HDFS Reader在底层调用Hive相关API读取ORC文件中的宝塔主机销售源码DECIMAL字段，将其隐式转换为Double类型。datax的Double类型支持Java.math.BigDecimal和Java.lang.Double，确保后续写入操作的精度。
2. **修改HDFS Writer**：为了支持写入数据到Hive ORC文件中的DECIMAL字段，同样需要在HDFS Writer插件中进行相应的代码修改。修改后的代码确保能够将datax的Double字段正确写入到Hive ORC文件中的DECIMAL字段。使用方法com.alibaba.datax.common.element.DoubleColumn#asBigDecimal，基于DoubleColumn底层rawData存储的原始数据内容，将字段值转换为合适的外部数据类型。这一过程不会损失数据精度。
综上所述，通过修改datax的HDFS Reader和Writer插件，实现对Hive DECIMAL数据类型的读取和写入支持，确保数据迁移过程的准确性和完整性，从而满足复杂数据迁移场景的需求。
Hive 编程专题之 - 自定义函数 Java 篇
Hive函数分为内置函数与自定义函数，内建函数包括字符、数值、日期与转换等类型。
自定义函数类似于传统商业数据库中的编译函数，如SQL Server中使用C#解决内建函数无法解决的问题，Oracle中则使用Java编写的Jar扩展功能，Hive中的自定义函数同样依赖Jar，提供Java编写程序以处理内置函数无法达到的功能。
使用Java编写Hive自定义函数步骤包括：
1. 常看所有内置与自定义函数。
2. Java或Scala编写自定义函数。
3. 使用Eclipse或其他Java编辑工具生成JAR文件。
4. 将生成的JAR文件放置于HDFS中，Hive即可应用。
5. 使用Java编写简单的Hive自定义函数，步骤如下：
5.1 使用Eclipse建立Maven项目。
5.2 引入特定的Hive/Hadoop JAR。
5.3 从Hive源代码或Hadoop基类库中寻找所需库。
5.4 编写简单的大写转换函数。
5.5 导出Eclipse，网页视频平台源码导入Hive类路径。
5.6 定义Hive函数，需带上全路径，即类的包路径。
5.7 修改Java代码，再执行相关步骤。
通过以上步骤，成功使用Java编写一个供Hive调用的函数。
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的php 押金管理源码获取，mimikatz需要解密加密的数据，使用syskey作为解密密钥。解密过程根据加密算法（rc4或aes）有所不同，但在最终阶段，mimikatz会调用系统函数对数据进行解密，从而获取用户哈希。
在完成用户哈希的解析后，mimikatz还提供了一个额外的功能：获取SupplementalCreds。这个功能可以解析并解密获取对应用户的SupplementalCredentials属性，包括明文密码及哈希值，为用户提供更全面的哈希信息。
综上所述，mimikatz通过解析注册表，实现了从系统中获取用户哈希的高效功能，为内网渗透提供了强大的工具支持。通过深入理解其解析流程和关键结构体的定义，可以更好地掌握如何利用mimikatz进行深入的安全分析和取证工作。
大数据笔试真题集锦---第五章: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"。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的区别、交易表查询示例、登录用户数量查询、动态分区与静态分区的区别。Hive Server2对execute和executeQuery的处理
实现SparkSQL的SQL Server服务时，需兼容Hive的JDBC Driver，以便通过beeline连接服务。Java的JDBC标准提供execute和executeQuery两类接口。execute用于DDL（数据定义语言）操作，返回true/false，而executeQuery则处理查询，返回ResultSet结果集。
在thrift接口实现中，对DDL操作，直接将结果置空并设置setHasResultSet为false。然而，beeline客户端始终显示错误，因为其使用了beeline的JDBC驱动。通过源码调试发现，在Hive的JDBC实现中，executeQuery直接调用execute。如果返回false，则抛出异常：The query did not generate a result set!
在执行SQL后，beeline客户端会通过GetOperationStatus获取操作状态。在类似while true的循环中，直到操作结束，开始获取结果集。关键在于，如果isHasResultSet为false，execute会直接抛出异常。因此，isHasResultSet必须返回true，后端在封装thrift结果集时，需调整逻辑。
通常，设置setHasResultSet为false且设置setHasResultSetIsSet为true即可。但实践中发现，两者关联影响结果。最终解决方案是，对无结果集的DDL执行，手动生成相应返回。
Hive在处理execute和executeQuery时，存在实现上的不完美之处。
Hive MetaStore 的挑战及优化方案
Hive，作为Apache Hadoop上的数据仓库工具，提供了强大的SQL查询能力，处理大规模数据。核心组件Hive MetaStore负责存储和管理Hive表、分区和数据库的元数据，如表名、列信息和存储位置。元数据的结构复杂，涉及多张关联表，如DBS、TBLS、PARTITIONS和SDS，用于细致管理。
然而，随着业务扩展，元数据量爆炸式增长，尤其是在互联网公司，Hive表的分区数可能达到百万甚至亿级，导致MetaStore和MySQL服务面临严峻挑战。查询延迟增加，并发请求过多时，MetaStore查询会阻塞，进而影响整个大数据查询性能。
针对这些挑战，有几种优化策略：首先，分库分表可以分散MetaStore的负载，但涉及到Hive源代码的大幅调整，风险和成本较高，且后期维护复杂。其次，读写分离通过创建只读MetaStore集群，降低主库压力，但无法根本解决数据量大的问题，快手等公司已实践。分布式数据库如TiDB，提供更好的扩展性和性能，但需注意兼容性和运维风险，VIVO和知乎已采用。MetaStore API的优化可以解决部分问题，但需要持续改进。WaggleDance和MetaStore Federation通过代理和路由技术，减少了元数据操作的复杂性，但可能带来配置管理和数据迁移的挑战，滴滴和腾讯已采用或类似方法。
总的来说，优化选择需权衡开发成本、运维难度、业务影响等因素，流量控制和降级也是应对高峰流量的辅助手段。在实际应用中，需要根据具体情况进行定制化解决方案，关注"大数据小百科"获取更多技术分享。