组件理解

news/2025/11/6 20:41:35/文章来源:https://www.cnblogs.com/OpenSourceSite/p/19197693

HDFS（Hadoop分布式文件系统）的思路特别实在：切分+多节点备份

DataNode：多节点存，还怕丢数据？切好的小数据块，会分散存到集群里的“DataNode”（存储节点）上。
NameNode：“大脑”记位置，不用瞎找，这么多DataNode和数据块，咋知道哪个块在哪？HDFS有个“指挥中心”叫NameNode，它专门记两件事：每个文件由哪些块组成，每个块在哪个DataNode上。

MapReduce：切任务+分布式算+汇总结果。

Map阶段：各算各的，先出局部结果
MapReduce先把要算的数据切成多个“分片”（Split），每个分片对应一个“Map任务”，分给不同的计算节点。比如统计消费能力，每个Map任务就负责自己分片里的订单，算出“这个分片里，程序员花了多少钱、设计师花了多少钱”——先搞出局部结果。
Reduce阶段：汇总一下，出最终答案
所有Map任务算完，会冒出一堆局部结果。这时候“Reduce任务”登场，把相同key的结果凑到一起算总账。比如把所有分片里“程序员”的消费金额加起来，就是程序员的总消费；再除以程序员用户数，平均消费能力就出来了。

YARN（Yet Another Resource Negotiator），本质是一个集群资源管理与作业调度框架

Container：给任务画个“资源圈”
YARN会把每台服务器的CPU、内存，打包成一个个“容器”（Container）——其实就是个限制了资源的JVM进程。比如给一个Map任务分配1核CPU、2GB内存，它就只能在这个圈里跑，别想多占资源，保证其他任务也能正常干活。
按需分配：该给谁就给谁
你提交个MapReduce任务，YARN先看任务要多少资源，再在集群里找空闲的服务器，分配对应的Container，把任务塞进去跑。要是某台服务器崩了，YARN还能把任务转移到其他节点，保证计算不中断。
简单说，MapReduce只管“咋算”，YARN只管“给资源让你算”，分工明确，互不耽误。

Hive
为了让数据分析人员能够像使用 SQL 一样方便地查询大数据，我们需要一个工具来简化这个过程。它就是 Hive。你可以将它理解为 sql 和 mapreduce 的一个中间层。
它可以将用户输入的类似 SQL 的查询语言解析转换成一个个复杂的 mapreduce 任务，运行并最终输出计算结果。

Spark：高效的“批量流水线”

核心比喻：一辆拥有超大货柜的“高速货运列车”

工作方式：这辆列车不会为每一个包裹（数据）单独出发。它会先花点时间把一分钟内到达的所有包裹都装上车（这是一个微批处理的过程），然后关上门，风驰电掣般地开往目的地。在车上，工人们（CPU核心）可以同时、高效地对这一整批包裹进行分拣、贴标等复杂操作。

优势：吞吐量巨大。对于一大批固定的包裹（历史数据、海量日志分析），它能以极高的效率一次性处理完，非常强大和稳定。

短板：有轻微的延迟。即使最快的列车，也要等装完货才能出发。所以它无法实现“一个包裹刚到，下一秒就处理完”的极致实时。

一句话总结Spark：它是为处理海量批量数据而生的“高速货运列车”，追求极高的吞吐量，适合做离线数据分析、机器学习等任务。

Flink：敏捷的“实时流水线”
核心比喻：一条永不停歇的“包裹处理传送带”

工作方式：传送带上的每个包裹（数据）都是独立的。包裹一放上传输带，它就立刻开始移动，经过每一个处理节点（如扫码、称重、分拣）时都立刻被处理，真正做到“来一个，处理一个”（这就是真正的流处理）。

优势：延迟极低，达到毫秒级。对于需要即时反应的应用（如欺诈交易检测、实时监控告警），它能做到事件一发生，结果立刻就出来。

短板：在吞吐量达到极限时，要维持这种“一件一件”处理的极低延迟，对系统资源的协调能力要求更高。

一句话总结Flink：它是为处理无界实时数据流而生的“高速传送带”，追求极致的低延迟，适合做实时风控、实时推荐、实时监控等任务。

Hbase是什么
虽然现在大数据存算问题及处理问题都解决了。但用hive从海量数据里读写一两条数据，依然是接近分钟级别的操作， flink虽然实时性高，但一般面向数据处理，而不是在线读写场景。有办法像mysql那样，在毫秒级别完成实时在线读写吗？基于这个痛点，大佬们又设计了分布式数据库Hbase，用于在海量数据中高并发读写数据的场景。

流程
1、写数据
在大数据场景下，我们将数据写入到 hdfs 中的多个 datanode 中。