大数据组件原理及源码系列
Hadoop权威指南读书笔记(一)——RDB为什么不适合MapReduce
最近决定开始用博客记录自己的学习之路,有两点希望:一是希望以输出为指向的学习能够促使自己加深对知识的理解;二是希望能够将自己的一些见解分享给需要的人。好了,铺垫的话就不多说了,早点进入正题为宜。由于很多知识是初学,有理解得不到位/错误的地方,欢迎指出/讨论。
Hadoop权威指南第一章内容总结
第一章以铺垫为主,基本介绍了Hadoop产生的背景与一些大数据的基本概念。已经有一部分基础的同学不建议细读,快速带过即可。其中1.2、1.4、1.5节可以停下来稍微关注一下。
1.2节对分布式存储的产生背景进行了介绍,引出了HDFS。之前确实一直没有关注到这个很基本的点,即为什么分布式存储能带来这么大的优势。这里的描述比较形象,以硬盘读写为例,传输速率跟不上存储容量的发展,导致在大数据的场景下,对大批量数据的读写变得非常耗时。而分布式存储是如何解决这一问题的呢?这里应该大多数同学都已经知道,对分布在多个“硬盘”上的大批量数据进行“同时”(并行)读写,是肯定能够提高时间效率的。但也带来两个问题:一是硬件故障,即使用的硬件数量越多(分布式集群),则出现硬件故障的概率越大(一般集群中都是性能普通的机器);二是分布式的存储导致数据的“分散”。复杂的数据分析场景往往需要多表关联,如何在关联不同数据源的数据时保证其正确性,这也是一个大问题(这里MapReduce通过k-v存储的方式解决)。
1.4节提到Hadoop的定位是一个批处理系统,无法进行交互式的数据分析(即席分析)。因此,大致提到了“Hadoop生态圈”中其他与Hadoop协同工作的大数据组件。基本对应如下几种场景:交互式SQL(Hive/Spark SQL)、迭代处理(Spark)、流处理(Flink/Storm)、搜索(ES)。
1.5节的内容涉及到Hadoop与RDB(关系型数据库)的区别及为什么传统的关系型数据库不能应用于大规模的数据读写。这是在阅读本章时重点发现的一个问题。在本文标题部分也提出了这个问题,这里说说我自己的理解:
- RDB的数据(表)之间存在高耦合性,且集中在一个服务器上,无法实现分布式处理。如果是分别存储在不同的服务器上,则数据互相之间无法关联;
- 集中的数据读写会在硬盘寻址上耗费大量时间;
- RDB不具备灵活的可扩展性(比如新增字段等更改表结构操作时);
详细的内容可以参加这篇博客:关系型数据库与非关系型数据库的对比分析(优缺点,应用,区别等)
这里既然提到了NoSql,它作为大数据存储的主要载体,顺便也补充下当前比较流行的几种NoSql类型:
- K-V型:如Redis(兼具缓存和持久化)
- 列式存储:如HBase,与普通的数据库不同,这里以列为单位进行数据存储,以列族(列限定符)+行键定位到具体数据单元。列式存储在读写时都有很大的效率优势(只针对少量列,大量行进行操作),它把数据存储为未经解释的字符串,不存在复杂的表与表之间的关系,只有简单的插入、查询、删除、清空等,有良好的水平扩展性。
- 面向文档的数据库(即可以存放xml、json、bson类型的数据):如MangoDB,面向文档的数据库可以通过复杂的查询条件来获取数据,虽然不具备事务处理和Join这些关系型数据库所具有的处理能力,但除此以外的其他处理基本上都能实现(通过松散的数据结构,如类似json,而不是表来存储数据)。
本章后续还介绍了一些如网格计算的概念,在工作中接触不多,在此不作进一步总结。