经过前面的章节，学习了大数据最经典、最主流的一些技术和产品，今天再回过头来梳理一下这些技术和产品。 从上面这张图来看大数据技术的分类，我们可以分为存储、计算、资源管理三大类。 最基本的存储技术是 HDFS。比如在企业应用中，会把通过各种渠道得到的数据，比如关系数据库的数据、日志数据、应用程序埋点采集的数据、爬虫从外部获取的数据，统统存储到 HDFS 上，供后续的统一使用。 HBase 作为 NoS

你可能还记得，我们在讲 HDFS 和 HBase 架构分析时都提到了 ZooKeeper。在分布式系统里的多台服务器要对数据状态达成一致，其实是一件很有难度和挑战的事情，因为服务器集群环境的软硬件故障随时会发生，多台服务器对一个数据的记录保持一致，需要一些技巧和设计。 这也就是我们今天要讨论的分布式系统一致性与 ZooKeeper 的架构。 在讲分布式系统一致性前，我们先回顾一下 HDFS。HDF

前面介绍的大数据技术主要是处理、计算存储介质上的大规模数据，这类计算也叫大数据批处理计算。顾名思义，数据是以批为单位进行计算，比如一天的访问日志、历史上所有的订单数据等。这些数据通常通过 HDFS 存储在磁盘上，使用 MapReduce 或者 Spark 这样的批处理大数据计算框架进行计算，一般完成一次计算需要花费几分钟到几小时的时间。 此外，还有一种大数据技术，针对实时产生的大规模数据进行即时计

我们知道，Google 发表 GFS、MapReduce、BigTable 三篇论文，号称“三驾马车”，开启了大数据的时代。那和这“三驾马车”对应的有哪些开源产品呢？我们前面已经讲过了 GFS 对应的 Hadoop 分布式文件系统 HDFS，以及 MapReduce 对应的 Hadoop 分布式计算框架 MapReduce，今天我们就来领略一下 BigTable 对应的 NoSQL 系统 HBas

上一讲我们讨论了Spark的编程模型，这讲我们聊聊 Spark 的架构原理。和 MapReduce 一样，Spark 也遵循移动计算比移动数据更划算这一大数据计算基本原则。但是和 MapReduce 僵化的 Map 与 Reduce 分阶段计算相比，Spark 的计算框架更加富有弹性和灵活性，进而有更好的运行性能。 Spark 的计算阶段 我们可以对比来看。首先和 MapReduce 一个应用一次

Hadoop MapReduce 虽然已经可以满足大数据的应用场景，但是其执行速度和编程复杂度并不让人们满意。于是 UC Berkeley 的 AMP Lab 推出的 Spark 应运而生，Spark 拥有更快的执行速度和更友好的编程接口，在推出后短短两年就迅速抢占 MapReduce 的市场份额，成为主流的大数据计算框架。 读到这里请你先停一下，请给这段看似“没毛病”的引子找找问题。 不知道你意

前面我们讲过，MapReduce 的出现大大简化了大数据编程的难度，使得大数据计算不再是高不可攀的技术圣殿，普通工程师也能使用 MapReduce 开发大数据程序。但是对于经常需要进行大数据计算的人，比如从事研究商业智能（BI）的数据分析师来说，他们通常使用 SQL 进行大数据分析和统计，MapReduce 编程还是有一定的门槛。而且如果每次统计和分析都开发相应的 MapReduce 程序，成本也

今天的主题是：我们能从Hadoop学到什么？ 很多时候，我们不是不够努力，可是如果方向错了，再多努力似乎也没有用。阿里有句话说的是“方向对了，路就不怕远”，雷军也说过“不要用你战术上的勤奋，掩盖你战略上的懒惰”。这两句话都是说，要找好方向、找准机会，不要为了努力而努力，要为了目标和价值而努力。而王兴则更加直言不讳：“很多人为了放弃思考，什么事情都干得出来”。 说了那么多，我们再回过来看看 Hado