javaweb大作业_大数据开发入门基础知识

在了解了JavaSE、Mysql、JavaWeb、Linux等知识后。可以开始了解大数据开发相关的知识。

首先了解一下Hadoop生态圈。

1.HDFS(Hadoop 分布式文件系统)

HDFS 是 Hadoop 生态圈中提供分布式存储支持的系统，上层的很多计算框架(Hbase、Spark 等)都依赖于 HDFS 存储。若要构建 HDFS 文件系统，不需要特有的服务器，普通 PC 即可实现，它对硬件和磁盘没有任何特殊要求，也就是说，HDFS 可在低成本的通用硬件上运行。它不但解决了海量数据存储问题，还解决了数据安全问题。

HDFS 分布式文件系统的实现原理图：

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

2.MapReduce(分布式计算模型)离线计算

离线计算，其实就是非实时计算。实时计算也不是完全实时，它一定有一个延时，只不过这个延时很短而已。

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 是一个基于工作流引擎的调度器，它其实就是一个运行在 Java Servlet 容器(如 Tomcat)中的 Javas Web 应用，可以在它上面运行 Hadoop 的 Map Reduce 和 Pig 等任务。

对于 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(分布式消息队列)

现在是个大数据时代，各种商业、社交、搜索、浏览都会产生大量的数据。那么如何快速收集这些数据，如何实时的分析这些数据，是一个必须要解决的问题，同时，这也形成了一个业务需求模型，即生产者生产(Produce)各种数据、消费者(Consume)消费(分析、处理)这些数据。那么面对这些需求，如何高效、稳定的完成数据的生产和消费呢？这就需要在生产者与消费者之间，建立一个通信的桥梁，这个桥梁就是消息系统。从微观层面来说，这种业务需求也可理解为不同的系统之间如何传递消息。

Kafka 是 Apache 组织下的一个开源系统，它的最大特性就是可以实时的处理大量数据以满足各种需求场景：比如基于 Hadoop 平台的数据分析、低时延的实时系统、Storm/Spark 流式处理引擎等。Kafka 现在已被多家大型公司作为多种类型的数据管道和消息系统使用。

使用场景：

日志收集：一个公司可以用Kafka可以收集各种服务的log，通过kafka以统一接口服务的方式开放给各种consumer，例如hadoop、Hbase、Solr等。

消息系统：解耦和生产者和消费者、缓存消息等。

用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网页、搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖掘。

运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产各种操作的集中反馈，比如报警和报告。

流式处理：比如spark streaming和storm

事件源。

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 可以实现统一部署、统一管理、统一监控，可极大提高运维工作效率。

此外，还要学习分布式缓存Redis技术、容器化技术Docker、负载均衡Nginx、分布式流处理框架Flink、消息中间件MQ、开源分布式服务框架Dubbo等。

任重而道远!