mn_kw的博客

Hive 统计信息自动收集是指在执行某些 DML 操作（如 INSERT、LOAD 等）时，Hive 自动收集并更新表的统计信息，无需手动执行命令。自动收集机制在 INSERT/LOAD 等操作时自动触发只收集基本统计信息（行数、大小、文件数）零维护成本，适合大多数场景元数据库查询统计信息存储在 TABLE_PARAMS 和 PARTITION_PARAMS 表列统计存储在 TAB_COL_STATS 和 PART_COL_STATS 表可以通过 SQL 直接查询和监控最佳实践。

Spark Shuffle 是分布式计算中数据重分布的关键环节，本文深度解析了其核心原理与优化策略。主要内容包括：1) Shuffle 的两种实现方式（Hash Shuffle 和 Sort Shuffle）及演进历程；2) 完整的 Shuffle 生命周期，包含 Write 和 Read 两阶段；3) 三种写入模式（Bypass/Sort/Unsafe）的适用场景；4) 内存管理机制与文件生成过程；5) 数据拉取优化策略，包括连接复用、重试机制和直接内存缓冲区。文章还提供了详细的参数配置指南和性能优化建议

Spark SQL统计信息收集深度解析 统计信息是Spark SQL优化查询性能的核心元数据，包括表级(行数、大小)、列级(基数、空值、极值)和分区统计。收集方法分为全量(ANALYZE TABLE)和增量(针对分区)，建议优先收集JOIN列和过滤列。统计信息通过CBO优化执行计划，可提升性能2-10倍，但需权衡收集开销(数据扫描+计算+元数据写入)。最佳实践包括：分区表增量收集、关键列优先收集、定期更新策略。合理使用统计信息可显著优化JOIN顺序、过滤估算和资源分配。

Spark SQL CBO（基于成本的优化器）深度解析了其核心概念、工作流程及关键参数配置。CBO通过收集统计信息（行数、列统计等）计算不同执行计划的成本，选择最优方案，相比规则优化器能显著提升性能（可达5-10倍）。重点参数包括：总开关spark.sql.cbo.enabled、JOIN重排序spark.sql.cbo.joinReorder.enabled及其阈值控制spark.sql.cbo.joinReorder.dp.threshold。特别针对星型模式优化，分析了事实表与维度表的JOIN特点。C

Spark 早期：128MB（HDFS 块大小）Spark 2.0+：根据集群资源动态调整Spark 3.0+：64MB 作为平衡点考虑因素1: 并行度64MB 分区 → 100GB 数据 = 1563 个任务128MB 分区 → 100GB 数据 = 781 个任务→ 64MB 提供更好的并行度考虑因素2: 调度开销任务数过多 → 调度开销大任务数过少 → 资源利用率低→ 64MB 是平衡点考虑因素3: 内存使用每个任务需要内存：分区数据 + 处理开销。

本文档从 Hive 源码角度详细解析 Hive on Spark 在开启和不开 combine 的情况下，如何根据 split 分配 task，以及如何向 YARN 申请 executor。参数默认值说明InputFormat 类型1最小 split 大小（字节）最大 split 大小（字节）Task 数量不开 combine：Task 数量 = HDFS block 数量开启 combine：Task 数量 = ceil(数据总量 / max(block大小, split.minsize))

→ Driver JVM 堆内存 1 GB→ 存储：Spark 内部结构、Task 元数据、用户数据→ Driver 堆外内存 1 GB→ 存储：Metaspace、RPC 缓冲区、线程栈等YARN Container 总内存 = 1g + 1g = 2g→ YARN 为 Driver 分配 2 GB 物理内存。

1. 集群模式部署一般奇数节点，因为你5台机器可以挂2台，6台机器也是挂2台，不能超过一半的机器挂掉，所以5台和6台效果一致，那奇数节点可以减少机器开销，小集群部署，读多写少2. 主从架构： Leader 、 Follower 、 Observer （一般刚开始没必要用）3. 内存数据模型：Znode，多种节点类型4. 客户端跟 ZooKeeper 进行长连接，TCP，心跳，维持 Session5. Zxid ，高32位，低32位。

hive在工作中的使用技巧