- 博客(9)
- 收藏
- 关注
RSS订阅原创 SparkCore、SparkSQL 数据读取方式及 Hive 数据来源详解
在大数据处理领域，Apache Spark 和 Apache Hive 是两款至关重要的工具。Spark 凭借其高效的内存计算能力，成为数据处理的热门选择，而 Hive 则在数据仓库构建和 SQL 分析方面发挥着重要作用。本文将详细介绍 SparkCore 和 SparkSQL 读取数据的多种方式，以及 Hive 中数据的主要来源，帮助读者更好地理解和运用这些工具进行数据处理。
2025-11-03 19:23:47
639
原创 一文读懂 ZooKeeper 选举算法：基于 ZAB 协议的核心逻辑拆解
规则：同一任期内，ZXID 越大越优先（数据新），ZXID 相同则 SID 越大越优先；场景：初始化时 “从零开始投票”，leader 故障时 “基于现有 ZXID 重新投票”；保障：通过 “过半机制” 避免脑裂，通过 “任期” 避免过期 leader 干扰。理解这一算法，就能明白 zk 为何能在分布式环境中稳定提供 “统一协调” 服务 —— 即使部分节点故障，也能快速选出新 leader，保障数据一致和服务不中断。
2025-09-16 19:40:58
798
原创 深度解析 HDFS 纠删码技术：从原理到架构的全方位探索
参考菜单模板：奶茶店有 “自定义选项表”（对应 Hadoop 的模板文件）；告知需求：顾客说 “三分糖、少冰”（用户修改 XML 文件，设置 k=8、m=2、条带大小 1024k）；制作生效：店员按需求做奶茶（将自定义 XML 文件放入 conf 目录，配置，重启集群生效）。根据业务需求（如可靠性、存储成本、文件大小），参考模板修改参数，让 EC 策略适配具体场景。
2025-09-16 19:32:28
703
原创 深入 Hadoop HDFS：分布式存储核心，海量数据存储难题全解决！
另外，假如你的 java 版本有问题，也会报这个错误，比如我们需要 64 位的操作软件，你安装了一个 32 位的，请卸载 jdk，并重新安装和配置环境变量。Yarn : 计算的资源基础，所有的MR任务需要运行在Yarn上。位置： /opt/installs/hadoop/etc/hadoop。9870：是 hdfs 的 web 端口，用于访问 hdfs 的页面的。路径：/opt/installs/hadoop/etc/hadoop。假如你的环境是伪分布式模式，那么本地模式直接被替换了，回不去了。
2025-09-15 20:08:08
1255
原创 一文搞懂 ZooKeeper：从核心概念到实战应用，分布式协调不再难！
动物园管理员。zk就是一个分布式文件系统，不过存储数据的量极小。这个技术虽然比较小和简单，但是大数据领域还是离不开它的，比如： 1 hadoop集群 2 kafka集群 3 hbase 等都需要zk的支持1. zookeeper是一个为分布式应用程序提供的一个分布式开源协调服务框架。是Google的Chubby的一个开源实现，是Hadoop和Hbase的重要组件。主要用于解决分布式集群中应用系统的一致性问题。2. 提供了基于类似Unix系统的目录节点树方式的数据存储。
2025-09-15 20:03:37
1238
原创 深入解析HDFS：从架构核心到实践痛点的深度剖析
分块存储实现了数据的分布式管理，突破单节点存储上限；副本机制通过冗余换取高可用性，适应分布式环境的节点故障常态；元数据与数据分离，让NameNode专注于索引管理，DataNode专注于存储；安全模式与心跳机制确保了集群状态的一致性与可监控性。然而，理解其局限性同样重要——小文件问题、不适合低延迟访问、写入后修改困难（仅支持追加），这些特性决定了HDFS更适合"一次写入、多次读取"的批处理场景（如日志分析、数据仓库），而非实时交互场景。
2025-09-08 20:17:01
749
原创 深入剖析 Java 集合底层实现：ArrayList、HashSet 与 HashMap 的核心原理
ArrayList 展示了动态数组的实现艺术，通过扩容机制平衡了空间利用率和操作效率HashSet 巧妙地利用了 HashMap 的特性，用极少的代码实现了高效的去重集合HashMap 则是哈希表思想的完美实践，通过数组 + 链表 / 红黑树的混合结构，在平均情况下实现了 O (1) 的操作复杂度理解这些集合的底层实现，不仅能帮助我们在实际开发中选择合适的集合，更能让我们学到如何将基础数据结构与实际需求结合，设计出高效的算法和数据结构。
2025-09-03 20:43:47
755
原创 深入理解 Linux 系统中的 inode 与 block：文件存储的核心基石
inode 的全称是 “Index Node”（索引节点），每个文件在创建时都会自动分配一个唯一的inode 编号（inode number），这个编号是 Linux 系统识别文件的 “唯一 ID”—— 甚至比文件名更重要。为什么文件名不重要？因为文件名只是给用户看的 “别名”，系统真正识别文件靠的是 inode 编号。比如，当我们创建一个硬链接（ln 源文件 链接文件）时，链接文件和源文件其实共享同一个 inode，系统会认为它们是 “同一个文件的不同名字”；
2025-09-01 19:37:23
1008
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人