大数据修炼之路（一）----Hadoop 生态圈架构

Hadoop等于大数据吗？

Hadoop 是 Apache 下的一个开源项目，说起 Hadoop，通常都会跟“大数据”这几个字联系在一起，但大数据并不等于 Hadoop，大数据本身是个很宽泛的概念，你可以把大数据理解为 Hadoop 的生态圈（或者泛生态圈）。
Hadoop 生态圈好比家里的厨房，厨房里有锅、碗、瓢、盆、勺等各种做饭用具，这些用具类似 Hadoop 生态圈里的各种软件，比如 HDFS、Hive、Pig、Spark、Storm 等，这些软件各有各的用途，相互配合而又具有自己的独立特性。比如，可以用汤锅熬汤、也可以用炒锅熬汤，熬好的汤可以直接在锅里喝，也可以用碗配合勺子喝；我们用盆子洗菜，用厨刀切菜，将切好的菜放入炒锅里炒。可以看到，厨房里面的每个餐具各有用途，功能相互配合而又重合，并且具有自己的独立特性，用炒锅熬汤虽然可行，但味道并不一定最好。
因此，在生态圈中，各种软件堆叠组合也能工作，但未必是最佳选择。而对于大数据运维来说，就是要实现 Hadoop 生态圈各种软件的最优组合，熬出一碗最好喝的汤。

Hadoop生态圈

Hadoop 生态圈的常用组件，能够对 Hadoop 生态圈有一个基本的了解和认知，至于这些组件的具体应用场景和使用细节，笔者也还在学习中，有机会分享给大家。Hadoop 生态圈的技术点有很多，但并非每个技术点都要求掌握，学习过程中只需要掌握一套成熟的技术框架即可。
下图展示了 Hadoop 生态圈常见的软件和应用场景：

可以看出，Hadoop 的基础是 HDFS 和 Yarn，在此基础上有各种计算模型，如 MapReduce、Spark、HBase 等；而在计算模型上层，对应的是各种分布式计算辅助工具，如 Hive、Pig、Sqoop 等。此外，还有分布式协作工作 ZooKeeper 以及日志收集工具 Flume，这么多工具如何协作使用呢？这就是任务调度层 Oozie 的存在价值，它负责协调任务的有序执行。最顶层是 Hadoop 整个生态圈的统一管理工具，Ambari 可以为 Hadoop 以及相关大数据软件使用提供更多便利。
下面我来依次介绍图中的技术点。

标题1. HDFS（Hadoop 分布式文件系统）

HDFS，一个分布式文件系统HDFS，它是 Hadoop 技术体系中的核心基石，负责分布式存储数据，你可以把它理解为一个分布式的文件系统。此文件系统的主要特征是数据分散存储，一个文件存储在 HDFS 上时会被分成若干个数据块，每个数据块分别存储在不同的服务器上。
假如你有 100 台服务器，那么所有数据会平均分担在这 100 台机器上。而且，为了保证数据安全，每个存储在 HDFS 上的文件，可以设置不同的备份数。假如你设置了 3 个文件备份，只要你的服务器不是同时坏 3 个，那 HDFS 上面的数据都是安全的。
HDFS 是 Hadoop 生态圈中提供分布式存储支持的系统，上层的很多计算框架（Hbase、Spark 等）都依赖于 HDFS 存储。
若要构建 HDFS 文件系统，不需要特有的服务器，普通 PC 即可实现，它对硬件和磁盘没有任何特殊要求，也就是说，HDFS 可在低成本的通用硬件上运行。前面的介绍中，我们也看到了，它不但解决了海量数据存储问题，还解决了数据安全问题。
为了更好的理解它的作用，我们来看一个 HDFS 分布式文件系统的实现原理图：

可以看出，HDFS 主要由 NameNode 和 DataNode 两部分组成。
NameNode 是 HDFS 的管理节点，它存储了元数据（文件对应的数据块位置、文件大小、文件权限等）信息，同时负责读、写调度和存储分配；
DataNode 节点是真正的数据存储节点，用来存储数据。另外，在 DataNode 上的每个数据块会根据设置的副本数进行分级复制，保证同一个文件的每个数据块副本都不在同一个机器上。

标题2. MapReduce（分布式计算模型）离线计算

Hadoop 中的计算引擎，其有多种计算引擎，MapReduce 是第一代计算引擎，Tez 和 Spark 是第二代。MapReduce 的强大在于分布式计算，也就是将计算任务分布在多个服务器上，因此服务器数量越多，计算速度就越快。
MapReduce 主要分为两阶段：Map 阶段和 Reducer 阶段。比如，要读取 HDFS 上一个大文件中某个 IP 出现的频次，那么 Map 阶段就是多台机器同时读取这个文件内容的一个部分，然后分别统计出各自读到的内容中此 IP 出现的频次，这相当于是分散读取；Reducer 阶段是将 Map 阶段的输出结果作为输入，然后进行整合、汇总，最终得到一个此 IP 出现次数的结果。
由此可以看出，MapReduce 的过程就是一个分分合合的过程，而这个分布式计算功能完美解决了在 MySQL 中查询效率低下的问题。
MapReduce 到现在已经 15 年了，这种 Map 加 Reduce 的简单计算模型，解决了当时单机计算的缺陷，时至今日还有很多场景仍在使用这种计算模型，但已经慢慢不能满足我们的使用需求了。大数据时代的今天，数据量都在 PB 级甚至 EB 级别，对数据的分析效率有了更高的要求。
于是，第二代计算模型产生了，如 Tez 和 Spark，它们通过大量使用内存、灵活的数据交换，更少的磁盘读写来提高分析效率。

标题3. Yarn（分布式资源管理器）

计算模型层出不穷，这么多计算模型如何协同工作、如何做好资源管理，就显得至关重要了。于是，在 MapReduce 基础上演变出了 Yarn 这个资源管理器，它的出现主要就是为了解决原始 Hadoop 扩展性较差、不支持多种计算模型的问题。
在YARN中，支持CPU和内存两种资源管理，资源管理由ResourceManager（RM）、ApplicationMaster（AM）和NodeManager（NM）共同完成。其中，RM负责对各个NM上的资源进行统一管理和调度。而NodeManager则负责资源的供给和隔离。当用户提交一个应用程序时，会创建一个用以跟踪和管理这个程序的AM，它负责向RM申请资源，并要求NM启动指定资源的任务。这就是YARN的基本运行机制。
最后，Yarn 作为一个通用的分布式资源管理器，它可以管理多种计算模型，如 Spark、Storm、MapReduce 、Flink 等都可以放到 Yarn 下进行统一管理。

标题4. Spark（内存计算）

Spark 提供了内存中的分布式计算能力，相比传统的 MapReduce 大数据分析效率更高、运行速度更快。总结一句话：以内存换效率。
说到 Spark，不得不提 MapReduce。传统的 MapReduce 计算过程的每一个操作步骤发生在内存中，但产生的中间结果会储存在磁盘里，下一步操作时又会将这个中间结果调用到内存中，如此循环，直到分析任务最终完成。这就会产生读取成本，造成效率低下。
而 Spark 在执行分析任务中，每个步骤也是发生在内存之中，但中间结果会直接进入下一个步骤，直到所有步骤完成之后才会将最终结果写入磁盘。也就是说 Spark 任务在执行过程中，中间结果不会“落地”，这就节省了大量的时间。
在执行一个分析任务中，如果执行步骤不多，可能看不出 MapReduce 和 Spark 执行效率的区别，但是当一个任务有很多执行步骤时，Spark 的执行效率就体现出来了。

标题5. HBase（分布式列存储数据库）

在介绍 HBase 之前，我们首先了解两个概念：面向行存储和面向列存储。
面向行存储，这个应该接触比较多，比如我们熟悉的 MySQL、Oracle 等就是此种类型的。面向行存储的数据库主要适合于事务性要求严格的场合，这种传统关系型数据库为了实现强一致性，通过严格的事务来进行同步，这就让系统在可用性和伸缩性方面大大折扣。
面向列存储的数据库也叫非关系型数据库（NoSQL），比如Cassandra、HBase等。这种数据库通常将不同数据的同一个属性值存在一起，在查询时只遍历需要的数据，实现了数据即是索引。因此，它的最大优点是查询速度快，这对数据完整性要求不高的大数据处理领域，比如互联网，犹为重要。
Hbase继承了列存储的特性，它非常适合需对数据进行随机读、写操作、比如每秒对PB级数据进行几千次读、写访问是非常简单的操作。 其次，Hbase构建在HDFS之上，其内部管理的文件全部存储在HDFS中。这使它具有高度容错性和可扩展性，并支持Hadoop mapreduce程序设计模型。
如果你的应用是交易历史查询系统、查询场景简单，检索条件较少、每天有千万行数据更新、那么Hbase将是一个很好的选择。其实，行存储和列存储只是不同的维度而已，没有天生的优劣，而大数据时代大部分的查询模式决定了列式存储优于行式存储。

标题6. Hive（数据仓库）

Hive 定义了一种类似 SQL 的查询语言（HQL），它可以将 SQL 转化为 MapReduce 任务在 Hadoop 上执行。不熟悉 MapReduce 程序，只要会写标准的 SQL 语句，也能对 HDFS 上的海量数据进行分析和计算。

标题7. Oozie（工作流调度器）

对于 Oozie 来说，工作流就是一系列的操作（如 Hadoop 的 MR，Pig 的任务、Shell 任务等），通过 Oozie 可以实现多个任务的依赖性。也就是说，一个操作的输入依赖于前一个任务的输出，只有前一个操作完全完成后，才能开始第二个。
Oozie 工作流通过 hPDL 定义（hPDL 是一种 XML 的流程定义语言），工作流操作通过远程系统启动任务。当任务完成后，远程系统会进行回调来通知任务已经结束，然后再开始下一个操作。

标题8. Sqoop 与 Pig

把原来存储在 MySQL 中的数据导入 Hadoop 的 HDFS 上，是否能实现呢？这当然可以，通过 Sqoop（SQL-to-Hadoop）就能实现，它主要用于传统数据库和 Hadoop 之间传输数据。数据的导入和导出本质上是 MapreDuce 程序，充分利用了 MR 的并行化和容错性。
通过 Hive 可以把脚本和 SQL 语言翻译成 MapReduce 程序，扔给计算引擎去计算。Pig 与 Hive 类似，它定义了一种数据流语言，即 Pig Latin，它是 MapReduce 编程的复杂性的抽象，Pig Latin 可以完成排序、过滤、求和、关联等操作，支持自定义函数。Pig 自动把 Pig Latin 映射为 MapReduce 作业，上传到集群运行，减少用户编写 Java 程序的苦恼。

标题9. Flume（日志收集工具）

Flume 是将数据从产生、传输、处理并最终写入目标路径的过程抽象为数据流，在具体的数据流中，数据源支持在 Flume 中定制数据发送方，从而支持收集各种不同协议数据。
同时，Flume 数据流提供对日志数据进行简单处理的能力，如过滤、格式转换等。此外，Flume 还具有能够将日志写往各种数据目标（文件、HDFS、网络）的能力。在 Hadoop 平台，我们主要使用的是通过 Flume 将数据从源服务器写入 Hadoop 的 HDFS 上。

标题10. Kafka（分布式消息队列）

相信我们都乘坐过地铁，正常情况下先安检后刷卡，最后进站上车，如果遇到上下班高峰期，地铁的人流会很多，坐地铁的顺序就变成了先进入引流系统排队，然后进行安检，最后进站上车，从这里可以看出，在地铁人流量大的时候会多一个“引流系统排队”，通过这个引流系统，可以保证在人多的时候乘坐地铁也能有条不紊的进行。
这个引流系统就跟我们要介绍的 Kafka 的作用非常类似，它在人和地铁中间作为一个缓存，实现解耦合的作用。
专业术语来描述一下，现在是个大数据时代，各种商业、社交、搜索、浏览都会产生大量的数据。那么如何快速收集这些数据，如何实时的分析这些数据，是一个必须要解决的问题，同时，这也形成了一个业务需求模型，即生产者生产（Produce）各种数据、消费者（Consume）消费（分析、处理）这些数据。那么面对这些需求，如何高效、稳定的完成数据的生产和消费呢？这就需要在生产者与消费者之间，建立一个通信的桥梁，这个桥梁就是消息系统。从微观层面来说，这种业务需求也可理解为不同的系统之间如何传递消息。
Kafka 是 Apache 组织下的一个开源系统，它的最大特性就是可以实时的处理大量数据以满足各种需求场景：比如基于 Hadoop 平台的数据分析、低时延的实时系统、Storm/Spark 流式处理引擎等。Kafka 现在它已被多家大型公司作为多种类型的数据管道和消息系统使用。

标题11. ZooKeeper（分布式协作服务）

对集群技术应该并不陌生，就拿最简单的双机热备架构来说，双机热备主要用来解决单点故障问题，传统的方式是采用一个备用节点，这个备用节点定期向主节点发送 ping 包，主节点收到 ping 包以后向备用节点发送回复信息，当备用节点收到回复的时候就会认为当前主节点运行正常，让它继续提供服务。而当主节点故障时，备用节点就无法收到回复信息了，此时，备用节点就认为主节点宕机，然后接替它成为新的主节点继续提供服务。
这种传统解决单点故障的方法，虽然在一定程度上解决了问题，但是有一个隐患，就是网络问题，可能会存在这样一种情况：主节点并没有出现故障，只是在回复响应的时候网络发生了故障，这样备用节点就无法收到回复，那么它就会认为主节点出现了故障；接着，备用节点将接管主节点的服务，并成为新的主节点，此时，集群系统中就出现了两个主节点（双 Master 节点）的情况，双 Master 节点的出现，会导致集群系统的服务发生混乱。这样的话，整个集群系统将变得不可用，为了防止出现这种情况，就需要引入 ZooKeeper 来解决这种问题。
ZooKeeper 是如何来解决这个问题的呢，这里以配置两个节点为例，假定它们是“节点 A”和“节点 B”，当两个节点都启动后，它们都会向 ZooKeeper 中注册节点信息。我们假设“节点A”锁注册的节点信息是“master00001”，“节点B”注册的节点信息是“master00002”，注册完以后会进行选举，选举有多种算法，这里以编号最小作为选举算法，那么编号最小的节点将在选举中获胜并获得锁成为主节点，也就是“节点A”将会获得锁成为主节点，然后“节点B”将被阻塞成为一个备用节点。这样，通过这种方式 ZooKeeper 就完成了对两个 Master 进程的调度。完成了主、备节点的分配和协作。
如果“节点A”发生了故障，这时候它在 ZooKeeper 所注册的节点信息会被自动删除，而 ZooKeeper 会自动感知节点的变化，发现“节点 A”故障后，会再次发出选举，这时候“节点 B”将在选举中获胜，替代“节点 A”成为新的主节点，这样就完成了主、被节点的重新选举。
如果“节点A”恢复了，它会再次向 ZooKeeper 注册自身的节点信息，只不过这时候它注册的节点信息将会变成“master00003”，而不是原来的信息。ZooKeeper 会感知节点的变化再次发动选举，这时候“节点 B”在选举中会再次获胜继续担任“主节点”，“节点 A”会担任备用节点。
通俗的讲，ZooKeeper 相当于一个和事佬的角色，如果两人之间发生了一些矛盾或者冲突，无法自行解决的话，这个时候就需要 ZooKeeper 这个和事佬从中进行调解，而和事佬调解的方式是站在第三方客观的角度，根据一些规则（如道德规则、法律规则），客观的对冲突双方做出合理、合规的判决。

标题12. Ambari（大数据运维工具）

Ambari 是一个大数据基础运维平台，它实现了 Hadoop 生态圈各种组件的自动化部署、服务管理和监控告警，Ambari 通过 puppet 实现自动化安装和配置，通过 Ganglia 收集监控度量指标，用 Nagios 实现故障报警。目前 Ambari 已支持大多数 Hadoop 组件，包括 HDFS、MapReduce、Oozie、Hive、Pig、 Hbase、ZooKeeper、Sqoop、Kafka、Spark、Druid、Storm 等几十个常用的 Hadoop 组件。
作为大数据运维人员，通过 Ambari 可以实现统一部署、统一管理、统一监控，可极大提高运维工作效率。

以上内容来自课程学习，想参加的一起点击报名