Hadoop权威指南读书笔记（一）——RDB为什么不适合MapReduce

大数据组件原理及源码系列

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（关系型数据库）的区别及为什么传统的关系型数据库不能应用于大规模的数据读写。这是在阅读本章时重点发现的一个问题。在本文标题部分也提出了这个问题，这里说说我自己的理解：

1. RDB的数据（表）之间存在高耦合性，且集中在一个服务器上，无法实现分布式处理。如果是分别存储在不同的服务器上，则数据互相之间无法关联；
2. 集中的数据读写会在硬盘寻址上耗费大量时间；
3. RDB不具备灵活的可扩展性（比如新增字段等更改表结构操作时）；

详细的内容可以参加这篇博客：关系型数据库与非关系型数据库的对比分析（优缺点，应用，区别等）

这里既然提到了NoSql，它作为大数据存储的主要载体，顺便也补充下当前比较流行的几种NoSql类型：

1. K-V型：如Redis（兼具缓存和持久化）
2. 列式存储：如HBase，与普通的数据库不同，这里以列为单位进行数据存储，以列族（列限定符）+行键定位到具体数据单元。列式存储在读写时都有很大的效率优势（只针对少量列，大量行进行操作），它把数据存储为未经解释的字符串，不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、清空等，有良好的水平扩展性。
3. 面向文档的数据库（即可以存放xml、json、bson类型的数据）：如MangoDB，面向文档的数据库可以通过复杂的查询条件来获取数据，虽然不具备事务处理和Join这些关系型数据库所具有的处理能力，但除此以外的其他处理基本上都能实现（通过松散的数据结构，如类似json，而不是表来存储数据）。

本章后续还介绍了一些如网格计算的概念，在工作中接触不多，在此不作进一步总结。