4.1 Hadoop生态系统
狭义的Hadoop VS 广义的Hadoop
- 广义的Hadoop:指的是Hadoop生态系统,Hadoop生态系统是一个很庞大的概念,hadoop是其中最重要最基础的一个部分,生态系统中每一子系统只解决某一个特定的问题域(甚至可能更窄),不搞统一型的全能系统,而是小而精的多个小系统;
Hive:数据仓库
R:数据分析
Mahout:机器学习库
pig:脚本语言,跟Hive类似
Oozie:工作流引擎,管理作业执行顺序
Zookeeper:用户无感知,主节点挂掉选择从节点作为主的
Flume:日志收集框架
Sqoop:数据交换框架,例如:关系型数据库与HDFS之间的数据交换
Hbase : 海量数据中的查询,相当于分布式文件系统中的数据库
Spark: 分布式的计算框架基于内存
- spark core
- spark sql
- spark streaming 准实时 不算是一个标准的流式计算
- spark ML spark MLlib
Kafka: 消息队列
Storm: 分布式的流式计算框架 python操作storm
Flink: 分布式的流式计算框架
Hadoop生态系统的特点
- 开源、社区活跃
- 囊括了大数据处理的方方面面
- 成熟的生态圈
4.2HDFS 读写流程& 高可用
- HDFS读写流程
- 客户端向NameNode发出写文件请求。
- 检查是否已存在文件、检查权限。若通过检查,直接先将操作写入EditLog,并返回输出流对象。
(注:WAL,write ahead log,先写Log,再写内存,因为EditLog记录的是最新的HDFS客户端执行所有的写操作。如果后续真实写操作失败了,由于在真实写操作之前,操作就被写入EditLog中了,故EditLog中仍会有记录,我们不用担心后续client读不到相应的数据块,因为在第5步中DataNode收到块后会有一返回确认信息,若没写成功,发送端没收到确认信息,会一直重试,直到成功) - client端按128MB的块切分文件。
- client将NameNode返回的分配的可写的DataNode列表和Data数据一同发送给最近的第一个DataNode节点,此后client端和NameNode分配的多个DataNode构成pipeline管道,client端向输出流对象中写数据。client每向第一个DataNode写入一个packet,这个packet便会直接在pipeline里传给第二个、第三个…DataNode。
(注:并不是写好一个块或一整个文件后才向后分发) - 每个DataNode写完一个块后,会返回确认信息。
(注:并不是每写完一个packet后就返回确认信息,个人觉得因为packet中的每个chunk都携带校验信息,没必要每写一个就汇报一下,这样效率太慢。正确的做法是写完一个block块后,对校验信息进行汇总分析,就能得出是否有块写错的情况发生) - 写完数据,关闭输输出流。
- 发送完成信号给NameNode。
(注:发送完成信号的时机取决于集群是强一致性还是最终一致性,强一致性则需要所有DataNode写完后才向NameNode汇报。最终一致性则其中任意一个DataNode写完后就能单独向NameNode汇报,HDFS一般情况下都是强调强一致性)
- HDFS如何实现高可用(HA)
- 数据存储故障容错
- 磁盘介质在存储过程中受环境或者老化影响,数据可能错乱
- 对于存储在 DataNode 上的数据块,计算并存储校验和(CheckSum)
- 读取数据的时候, 重新计算读取出来的数据校验和, 校验不正确抛出异常, 从其它DataNode上读取备份数据
- 磁盘故障容错
- DataNode 监测到本机的某块磁盘损坏
- 将该块磁盘上存储的所有 BlockID 报告给 NameNode
- NameNode 检查这些数据块在哪些DataNode上有备份,
- 通知相应DataNode, 将数据复制到其他服务器上
- DataNode故障容错
- 通过心跳和NameNode保持通讯
- 超时未发送心跳, NameNode会认为这个DataNode已经宕机
- NameNode查找这个DataNode上有哪些数据块, 以及这些数据在其它DataNode服务器上的存储情况
- 从其它DataNode服务器上复制数据
- NameNode故障容错
- 主从热备 secondary namenode
- zookeeper配合 master节点选举
dary namenode
- zookeeper配合 master节点选举