Hadoop的优点及需要考虑的问题

Hadoop是分布式系统，就是从多个硬盘中同时读取数据，假如还是从一个硬盘里读数据就浪费资源了，这些数据可能还需要拼接起来，所以优点1：并行读写数据速度快，解决的读写速度慢的问题。并行读写对保证数据的正确性是一个挑战。还有一个问题是所有系统需要考虑的问题，硬件故障，所以需要数据备份，怎么备份需要一个合适的解决方案，比如一份数据需要备份几份，备份的数据需要放在那里，Hadoop的方案是我们大多都能想到的方案，就是备份3份，分别放在不同的硬盘上。假如你有更好地方案也可以提出来，但是我想假如你凭空想是不会有什么好的方案，除非你有一套分析的逻辑，好的方案更多是在实践过程中总结出来的，纸上谈兵是不可取的。那如何保证数据的正确性呢？，我们设想一下，拼接需要一个结合点，假如结合点匹配的话那可以，结合点不同那就遍历找到匹配的一个，结合点的数据应该是键值对的形式，保存在数据库或者数据中。正规说法把这个解决方案说成是编程模型，好吧，就叫模型吧，希望下次不会再换个名词。总结了几点，从读写效率，数据正确性，数据安全性方面的问题都得到了解决，然后我们得出Hadoop是一个可靠的共享存储和分析系统，好吧，可能我把一个程序想得太复杂了，原来备份一下，然后正确拼接数据，就可以说它是可靠的。总而言之，分布式系统的优点是，速度快，缺点是需要保证正确性。

大数据的应用，比如，获取用户的地理位置，方便总结用户分布，哪里需要增加服务点，可能以前是靠着人的感觉来判断的，现在有了具体的数据，怎么分配到时候一目了然。大量数据可能会隐藏其他数据，比如用户喜欢点击什么，用它来改善服务，而不要做一些调查问卷。你的行为暴露了你的内心。题外话，其实我现在这么总结很轻松，甚至怀疑总结的必要性，但是实际上就是得到了好的效果。假如这样也能做好编程，那我是不是有点屈才？比如上一篇从古论今，调用了不少脑细胞，其实还不如结合现实来得结论有效。快速有效，要有这个意识。实践出真知。

为什么不能用数据库来对大量硬盘上的大规模数据进行批量分析呢？我们为什么需要Mapreduce？

这两个问题的答案来自于计算机的另一个发展趋势：寻址时间的提升远远不敌传输速率的提升。所以分析数据之前先把数据拿出来，放在寻址快的机器上进行搜索？数据库相比mapreduce什么区别？接下来再看，寻址是将磁头移动到特定的硬盘位置进行读写操作的过程。它是导致硬盘操作延迟的主要原因，而传输速率取决于硬盘的带宽。如果数据访问模式中需要大量的硬盘寻址操作，那么读取大量数据集就必然会花更长的时间（相较于流数据的读取模式，流读取主要取决于传输速率）。另一方面，如果数据库系统只更新一小部分记录，那么传统的B树就更有优势（关系型数据库中使用的一种数据结构，受限于寻址的比例）。但数据库系统如果有大量的数据更新时，B树的效率就明显落后于mapreduce，因为需要使用“排序/合并”（sort/merge）来重建数据库。

在许多情况下，可以将mapreduce视为关系型数据库的补充。

mapreduce比较适合以批处理方式处理需要分析整个数据集的问题，尤其是动态分析。RDBMS适用于点查询和更新，数据集被索引之后，数据库系统能够提供低延迟的数据检索和快速的少量数据更新。Mapreduce适合一次写入、多次读取数据的应用，关系型数据库则更适合持续更新的数据集。

MapReduce是一种线性的可伸缩编程模型。程序员要写两个函数map函数和reduce函数，每个函数定义从一个键值对集合到另一个键值对集合的映射。这些函数不必关注数据集及其所用集群的大小，可以原封不动地应用于小规模数据集或大规模的数据集。更重要的是，如果输入的数据量是原来的两倍，那么运行时间也需要两倍。但如果集群是原来的两倍，作业的运行速度不变。SQL查询一般不具备该特性。