大数据运维实战第一课 大话 Hadoop 生态圈
你好，欢迎来到《大数据运维实战》专栏。
入行以来，我从事大数据运维也有十多年了，期间我做过系统运维、DBA，也做过大数据分析师，最后选择了大数据运维方向，曾设计并管理超过千台、PB 级的数据平台。在这期间， 我见证并目睹了国内大数据行业发展的历程，也看到了目前大家在大数据学习、工作、发展等方面的一些问题，比如：
做传统运维（网络运维、系统运维、DBA等）多年，但受到云计算、虚拟化的冲击，竞争力日渐低下，要升职加薪变得异常困难；
企业没有专职大数据运维，开发兼职运维，大数据平台经常出问题，没有专人解决；
想进入大数据领域，但不知道学习什么知识，如何系统地去学习，以及就业方式等诸多问题。
这可能是大部分人面临的问题，在我个人的运维从业过程中，也同样经历了职业方向选型时的迷茫期、职业高速发展时的提升期、职业定型时的运筹帷幄期 3 个阶段。
迷茫期，平台搭建经常出问题，也不知道怎么解决，只能根据错误提示进行搜索查找，而在找到答案后，也不清楚这样修改是否正确，只能尝试修改，发现不行就回滚恢复。也就是在这种模棱两可的状态下，我发现：要能处理故障和问题，一定要对大数据每个组件的运行机制、原理有清晰的认识，这样才能够知道故障是如何发生的，以及如何避免再次发生。
提升期，在慢慢摸清了大数据的门道后，思路逐渐清晰了，此时已经慢慢捋清了大数据运维的难点和重点，比如掌握每个组件的内部原理后，再进行有目的的故障排错和修改。现在遇到大数据平台的基础问题，基本能马上定位问题，进而快速解决问题。
运筹帷幄期，此阶段接触更多的是对大数据平台的调优、架构优化，这也是大数据运维最难的一个部分，不同的应用场景和需求，注定了调优不是一成不变的，它也有一套思路和方法。而大数据应用架构也是在企业应用需求变化中不断进行调整，因此这个阶段要求的是业务需求和大数据平台之间的一个平衡，你需要了解业务模式和特点，然后有针对性地对大数据平台进行架构调整、资源优化。
大数据人才紧缺
如今，大数据已经广泛应用于各行各业，阿里、腾讯、京东、美团、字节跳动等互联网公司都有自己的大数据平台，大数据运维职业的平均薪资在 20K 或以上（北上深杭广）。而且，由于国家大力倡导实施大数据战略，这就出现了企业对大数据分析、开发人才的需求量激增，进而导致大数据运维人才也非常紧缺。
大数据战略的落地，必然会有大批技术人员涌入大数据领域，传统运维人员由于具有多年的运维基础，转型大数据运维是顺理成章的事情，并随之带来翻倍的高额薪资。目前，国内大数据市场还是一片蓝海，全面大数据化还有相当长的路要走，所以未来职业发展不可限量。
2019 年大数据人才就业趋势报告显示，中国当下大数据从业人才约有 30 万，未来 3 ~ 5 年人才需求量将达到 180 万。下图中是拉勾网对大数据运维职位的招聘信息，从中我们可以看出企业招聘的实际需求以及薪资情况。
大数据运维是一个新兴职业，在整个国家都在倡导和实施大数据应用落地建设之际，大数据运维必然有更多的职位需求和更大的发展前景。
如果你现在是一名 Linux 运维工程师、DBA、网络运维工程师、IT 支持工程师，正苦于薪资太少、竞争力差，或者徘徊在职业转型的苦恼中，那么大数据运维这个职位绝对是你的首选：
因为你已经有了一定的技能积累，而这些技能可以直接拿来运用到大数据运维中；
其次，这个职位不需要太多开发技能，所以你不用去单独学习一门语言；
最后，大数据运维是整个运维行业中薪资最高的，这在一定程度上也代表了运维的发展方向。
很多想转行大数据运维的都有个疑问：大数据需要会开发，而我没做过开发，也不想去学开发，那能学大数据运维吗？
实际上，大数据运维根本不需要很多高深的技能，懂一点 Linux、网络和自动化运维的知识，基本就可以学大数据运维课程了，而开发能力非必选项。
此外，学大数据运维，注重的是理论与实践相结合，也就是首先要理解概念、原理，有了这些理论作为支撑，才能进入实践阶段，实践过程就是动手实战、反复操作的过程。但如果没有实践经验，企业是不会贸然让你上手去操作，这种困境怎么破呢？
如何有效学习和入手？
缺少相关学习资料，是第一个难题。现在市面上的大数据类书籍或者课程，大部分都是基于大数据开发、大数据分析方向的，其核心就是教你如何通过一门编程语言来分析数据。而讲到大数据运维方向（架构设计、运维监控、性能调优）的资料就非常匮乏了。
究其原因，这主要是开发方向的技术点相对简单，而运维方向需要更多的经验积累，比如什么架构才能支撑这个数据量、什么资源配置才能满足分析需求，这需要你实际接触过、操作过才能给出答案，而不是靠理论或者猜测。
学习大数据运维的难点，非常重要的一点，就在于接触不到实际的环境，没有现成可学习的架构和案例。而大数据运维中的架构设计、容量规划、性能调优是要和具体的业务需求结合起来综合考虑的，所以获取这部分经验很难，仅靠自学是无法实现的。
这个专栏帮你很好地解决了以上问题。
我在专栏中，详细讲解了大数据运维平台的各种运维架构和实施案例，而且每个案例都基于企业实际的应用环境来讲解。对运维人员因为刚入行或没实际经验而接触不到的架构设计、容量规划，性能调优，我也都是以企业实际应用需求来展开介绍的。可以说，这个专栏基本解决了你学习大数据运维的最大难题。
课程设置
本课程共计七大模块， 26 个课时。主要介绍大数据运维平台的架构设计与部署、大数据平台的监控告警、大数据平台的性能调优三大部分内容。
首先从大数据生态圈基础讲起；然后教你如何构建大数据平台；接着是如何运维这个平台，以及讲解跟这个平台相关的一些大数据组件；最后从大数据架构实现、调优方向，教你如何做一个质的提升。纵观全局，整个课程是一个由点及线、由线及面、循序渐进的一个学习过程，非常容易上手。
下图是本专栏内容的一个思维导图，你可以从中了解更多运维技术内容和细节。
模块一，Hadoop 大数据平台的规划与部署。该模块主要讲解了 Hadoop 大数据平台的搭建与基础配置， 以及两种 Hadoop 集群部署方式，分别是手动部署和 Ambari 自动部署。
掌握这些内容，可以帮助你快速为企业部署大数据平台。这是大数据运维的第一步，此部分内容要求熟练掌握。
模块二，Hadoop 分布式架构解析。该模块主要讲解了分布式文件系统 HDFS 和分布式资源管理器 Yarn 的运行机制，以及内部实现细节。
掌握后，对于大数据平台出现的一些简单故障，你可以快速定位并解决。这是大数据运维的第二步，此时你已经具备了处理大数据平台故障的能力。
模块三，Hadoop 外围应用整合实战。该模块主要讲解了大数据平台下如何整合一些外围应用，主要是 Spark、Flink 与 Yarn 的整合应用，以及 HBase 集群的部署。
掌握后，你的大数据运维能力将得到质的提升。这是大数据运维的第三步，大数据平台从离线计算扩展到内存计算（Spark）和实时计算（Flink）。
模块四，Hadoop 大数据平台数据收集应用实践。该模块主要讲解了 ELK/EFK 应用套件如何实现日志数据收集以及快速查询。首先介绍了 Filebeat 和 Logstash 两款日志收集工具的功能，接着介绍了如何实现日志的收集、过滤和传输，最后介绍了如何通过 Elasticsearch 实现数据的快速检索。
掌握此模块内容后，你就可以根据企业需求去收集需要的业务数据，从而实现快速查询。这是大数据运维的第四步，如何获取数据并对数据进行过滤、分析，最后存储到 HDFS 上。
模块五，大数据平台日志传输与可视化应用实践。该模块主要讲解了海量数据环境中如何实现数据的实时传输，并通过 Kibana 实现可视化展示。
掌握了这部分内容，你就已经具备了设计大数据平台下实时查询、实时展示架构的能力。这是大数据运维的第五步，至此，你已经掌握了大数据生态链中的数据收集、数据传输、数据存储、数据分析四个方向的所有运维技术。
模块六，大数据平台运维监控体系的构建。该模块主要讲解了如何对大数据平台下每个组件的运行状态、服务状态进行监控。
作为大数据运维中最重要的一个环节，监控告警是你必须掌握的内容，也是运维质量的保障。
模块七，大数据平台性能调优与运维经验汇总。该模块主要讲解了大数据运维中常见的故障处理方法、集群扩缩容、集群调度策略选型、集群资源分配与权限管理等，还从全局的角度介绍了如何从零开始构建一个大数据平台，以及集群参数调优、内存调优等经验和技巧。
掌握后，你对大数据平台的运维基本上可以做到游刃有余。这是大数据运维的终极步骤，至此，你已经学完了大数据运维的所有相关内容了。
本专栏虽然是大数据运维实战专栏，但除了大数据运维人员，专栏中的第二、三、四、五、七模块内容，对大数据开发人员也有极高的学习和参考价值，这些内容能够帮助开发人员在数据架构、数据可视化展示、大数据调优等方面拓展视野，同时帮助其建立宏观思维，从而在工作中提高开发效率。
课程寄语
当今社会，正在经历一场创新的技术变革。物联网、智慧城市、区块链、语音识别、人工智能是未来趋势，而这些技术方向的核心就是大数据，掌握了大数据，也就把握住了自己的未来。我依据自身十余年的从业经验，来设计了这个课程，希望能够帮到你。
无论你是想从事大数据方向的系统工程师、大数据开发工程师、大数据运维工程师等，还是目前在从事传统运维相关工作（Web 运维、DBA、系统运维、网络运维），我都强烈建议你学习本课程，技不压身，身处快速发展的技术潮流中，我们也都需要具备不断刷新自身的能力。
未来应该掌握在自己的手中，我们应该学会设计自己的技能栈与职业发展路径，而你要做的就是把握现在，从当下开始。
最后，也欢迎你在留言区分享你的困惑和成长，与我交流，与大家探讨。
社群福利
加入社群获得以下福利：
① 讲师交流： 订阅后可加入「 大数据运维交流群 」与讲师直面交流
② 独家资料： 进群后领取 「 大数据运维课程PPT」
③ 加餐内容： 不定期社群专属直播、福利包
—— > 仅限 500 人，戳此加入 <——
所谓大数据是相对于小数据、传统数据来说的，大数据要解决的就是大规模数据存储、大规模数据计算、大规模数据处理，而 Hadoop 生态系统就是用来实现这些功能的。
要讲清大数据的原理，我们还要从一个故事讲起。
从故事开始：一个电商平台的用户行为分析需求
最近，就职于一家电商公司的小李遇到了一些麻烦事，因为领导突然给他布置了一个任务，要把他们电商平台里所有的用户在 PC 端和 App 上的浏览、点击、购买等行为日志都存放起来集中分析，并形成报表，以供老板每天查看。
最初，小李觉得这个任务比较简单，他的基本思路是将日志数据全部存入 MySQL 库中，然后通过不同条件进行查询、分析，得到老板想要的结果即可，但在具体实施过程中，小李遇到了前所未有的麻烦。
- 首先，这些数据量太大了，每天网站产生近 500G 的数据，这么大量的日志存储到一个单机的 MySQL 库中，已经难度很大了，磁盘空间经常告警；
- 其次，老板要的报表展示维度有 20 个之多，过多的维度会导致数据库查询 SQL 非常庞大，SQL 查询效率极度低下，一个 SQL 查询要跑十几个小时，这导致前一天的分析报表，老板第二天无法准时看到，因为这件事，老板已经开始怀疑小李的工作能力了；
- 最后，老板要求这些电商数据至少保留一年时间，以供跨年分析、对比，而目前的架构，数据都存储在 MySQL 库中，还是单机，这显然无法满足老板的需求。
小李已经从事技术工作 3 年多了，还是有一定知识储备的，经过查阅资料，他决定改造目前的技术架构。
首先，他将数据库服务器增加到 5 台，并在每台服务器上配置了大容量 SSD 磁盘组，以解决存储能力不足的问题；其次，对 MySQL 进行分库分表处理，以解决单表过大，数据集中存储查询效率低下的问题。技术架构调整以后，小李觉得分库分表坑太多，一个几百行的大 SQL，加上跨库 Join，以及各种复杂的计算，实现快速查询，根本不现实。因此，仍然无法满足老板的需求，更可怕的是，老板提出以后会增加实时查询、分析的功能，这种需求，通过 MySQL 来实现，完全是不可能的。
难道就没有能实现老板需求的技术方案吗？无奈之下，小李又开始查阅各种资料，无意中发现了一个叫 Hadoop 的东西，好像这个东西能完成老板提出的功能需求。
Hadoop 与大数据之间到底是什么关系？
Hadoop 是 Apache 下的一个开源项目，说起 Hadoop，通常都会跟“大数据”这几个字联系在一起，但大数据并不等于 Hadoop，大数据本身是个很宽泛的概念，你可以把大数据理解为 Hadoop 的生态圈（或者泛生态圈）。
Hadoop 生态圈好比家里的厨房，厨房里有锅、碗、瓢、盆、勺等各种做饭用具，这些用具类似 Hadoop 生态圈里的各种软件，比如 HDFS、Hive、Pig、Spark、Storm 等，这些软件各有各的用途，相互配合而又具有自己的独立特性。比如，可以用汤锅熬汤、也可以用炒锅熬汤，熬好的汤可以直接在锅里喝，也可以用碗配合勺子喝；我们用盆子洗菜，用厨刀切菜，将切好的菜放入炒锅里炒。可以看到，厨房里面的每个餐具各有用途，功能相互配合而又重合，并且具有自己的独立特性，用炒锅熬汤虽然可行，但味道并不一定最好。
因此，在生态圈中，各种软件堆叠组合也能工作，但未必是最佳选择。而对于大数据运维来说，就是要实现 Hadoop 生态圈各种软件的最优组合，熬出一碗最好喝的汤。
接着，我们来分析一下，Hadoop 生态圈架构是否能解决小李当前的困难：海量数据的存储问题和数据查询效率问题。
1、数据存储：HDFS，一个分布式文件系统
HDFS，它是 Hadoop 技术体系中的核心基石，负责分布式存储数据，你可以把它理解为一个分布式的文件系统。此文件系统的主要特征是数据分散存储，一个文件存储在 HDFS 上时会被分成若干个数据块，每个数据块分别存储在不同的服务器上。
假如你有 100 台服务器，那么所有数据会平均分担在这 100 台机器上。而且，为了保证数据安全，每个存储在 HDFS 上的文件，可以设置不同的备份数。假如你设置了 3 个文件备份，只要你的服务器不是同时坏 3 个，那 HDFS 上面的数据都是安全的。
很帅气吧？这个 HDFS 就解决了小李的两个问题：存储容量和数据安全。
2. 数据分析：MapReduce 计算引擎
数据存储问题解决了，接下来数据该如何分析处理呢？
单机处理的话，已经证明过是不可能的，必须用多台服务器并行处理，那么就要考虑如何分配计算任务到多台机器。如果一台机器挂了，该如何重新启动相应的分析任务，以及机器之间如何互相通信、交换数据以完成复杂的计算等。这就是马上要讲的 Hadoop 中的计算引擎，其有多种计算引擎，MapReduce 是第一代计算引擎，Tez 和 Spark 是第二代。
MapReduce 的强大在于分布式计算，也就是将计算任务分布在多个服务器上，因此服务器数量越多，计算速度就越快。
MapReduce 主要分为两阶段：Map 阶段和 Reducer 阶段。比如，你要读取 HDFS 上一个大文件中某个 IP 出现的频次，那么 Map 阶段就是多台机器同时读取这个文件内容的一个部分，然后分别统计出各自读到的内容中此 IP 出现的频次，这相当于是分散读取；Reducer 阶段是将 Map 阶段的输出结果作为输入，然后进行整合、汇总，最终得到一个此 IP 出现次数的结果。
由此可以看出，MapReduce 的过程就是一个分分合合的过程，而这个分布式计算功能完美解决了小李在 MySQL 中查询效率低下的问题。
那老板提出的实时查询分析功能，Hadoop 这个生态圈能实现吗？当然可以。
Hadoop 生态圈
我先带你来了解下 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 是 Hadoop 生态圈中提供分布式存储支持的系统，上层的很多计算框架（Hbase、Spark 等）都依赖于 HDFS 存储。
若要构建 HDFS 文件系统，不需要特有的服务器，普通 PC 即可实现，它对硬件和磁盘没有任何特殊要求，也就是说，HDFS 可在低成本的通用硬件上运行。前面的介绍中，我们也看到了，它不但解决了海量数据存储问题，还解决了数据安全问题。
为了更好的理解它的作用，我们来看一个 HDFS 分布式文件系统的实现原理图：
可以看出，HDFS 主要由 NameNode 和 DataNode 两部分组成。
- NameNode 是 HDFS 的管理节点，它存储了元数据（文件对应的数据块位置、文件大小、文件权限等）信息，同时负责读、写调度和存储分配；
- DataNode 节点是真正的数据存储节点，用来存储数据。另外，在 DataNode 上的每个数据块会根据设置的副本数进行分级复制，保证同一个文件的每个数据块副本都不在同一个机器上。
2. MapReduce（分布式计算模型）离线计算
何为离线计算，其实就是非实时计算。
比如，老板让小李今天出昨天电商网站的报表数据，这其实是对数据做离线计算；老板要马上看到来自北京 App 端用户的实时访问数据，这就是实时计算。当然实时计算也不是完全实时，它一定有一个延时，只不过这个延时很短而已。
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将是一个很好的选择。其实，行存储和列存储只是不同的维度而已，没有天生的优劣，而大数据时代大部分的查询模式决定了列式存储优于行式存储。
讲到这里，突然发现，小李遇到的技术难题，其实用 HBase 也能实现。
6. Hive（数据仓库）
小李打算在 Hadoop 生态平台上完成公司电商数据的存储和分析了，但又遇到了难题，MapReduce 的程序写起来很麻烦，如果通过写 MapReduce 程序来实现老板的需求，不但要重新学习，而且功能实现也繁琐。该怎么办呢？
经过调研与查阅资料，一款 Hive 工具出现在他面前。Hive 定义了一种类似 SQL 的查询语言（HQL），它可以将 SQL 转化为 MapReduce 任务在 Hadoop 上执行。这样，小李就可以用更简单、更直观的语言去写程序了。
因此，哪怕你不熟悉 MapReduce 程序，只要会写标准的 SQL 语句，也能对 HDFS 上的海量数据进行分析和计算。
7. Oozie（工作流调度器）
小李现在已经能够熟练使用 Hive 对数据进行各种维度的分析了，由于老板要求定时给出报表数据，所以小李就将数据分析任务写成脚本，然后放到操作系统的定时任务（Crontab）中定期执行。刚开始这种方式完全满足了老板的要求，但随着报表任务的增多，一个脚本已经无法满足。
于是，小李根据不同的任务需求，写了多个脚本程序，然后放到操作系统定时任务中去执行。这种方法大多时候都能正常完成分析任务，但也遇到了任务分析错误或失败的情况，小李最终发现这是定时任务出现了问题。
原来在小李写的多个脚本中，个别脚本有相互依赖性，也就是说，假定有脚本 A 和脚本 B，脚本 B 要执行的话，必须等待脚本 A 完成，否则脚本 B 启动就没有意义了。因此，他在操作系统定时任务中，通过设置脚本开始执行时间的差别来避免这种依赖性。
比如，脚本 A 凌晨 6 点执行，小李预估此脚本最多执行到 8 点就完成了，所以设置脚本 B 在 8:30 时启动执行。可是，仔细一想，就觉得这种设置肯定存在问题，比如脚本 A 执行失败，或者在 8:30 没有完成怎么办？
小李发现，某次任务执行失败是因为他认为脚本 C 2 个小时肯定执行完，但事实上却执行了 4 个多小时，由于当天的日志量非常大，分析时间也相应延长了，脚本 C 在预估的时间内没有完成，而下个脚本 D 如约启动，脚本 D 的执行要依赖于脚本 C 的输出结果，因此脚本 D 肯定执行失败。
如何解决这个问题呢？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（日志收集工具）
现在小李已经基本解决了老板提出的各种数据分析需求，数据分析任务在 Hadoop 上有条不紊的进行。现在电商平台的数据是通过 rsync 方式定时从电商服务器上同步到 Hadoop 平台的某台机器，然后通过这台机器 put 到 HDFS 上，每天定时同步一次，由于数据量很大，同步一次数据在一个小时左右，并且同步数据的过程会消耗大量网络带宽。小李想，有没有更合适的数据传输机制，一方面可以保证数据传输的实时性、完整性，另一方面也能节省网络带宽。
通过 Flume 可以圆满完成小李现在的困惑，那么什么是 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 可以实现统一部署、统一管理、统一监控，可极大提高运维工作效率。
总结
到这里，已经介绍完了 Hadoop 生态圈常用的组件，相信你对它们的用途也有了大致了解，后面的课程中，我会详细讲解这些组件的应用与实践，以便于你牢记掌握这些组件的使用。
今天的内容比较多，这源于大数据生态圈组件繁多以及应用的复杂性，但这都值得。如果说今天我希望你看完文章后，还能记住些什么，简单的一句话就是：经典的大数据架构以及常用组件的功能。
最后，我想请你思考一个问题，你所在的企业里都用到了哪些大数据组件呢？也非常欢迎你在留言区和我们分享你眼中的大数据技术以及大数据应用架构。
精选评论
*健：
比其他某些随便贴几百个字就是一讲的专栏实在多了！
*宁：
老师，请教一下，通过zookeeper实现namenode ha，如果active namenode异常宕机了，standby namenode是不会自动切换为active的，如果强制把它切换为active状态，那么等宕机的机器恢复以后需要做什么操作呢？
讲师回复：
问题非常好，如果active namenode异常宕机了，并且配置了自动切换，那么standby namenode会自动切换为active，当然也可以手动切换，让备机变成active，切换完成，如果宕机的机器恢复以后，会自动变成standby状态，作为备机角色存在。继续同步元数据信息，等待下次的故障切换。
**9134：
终于对Hadoop大数据生态有了认识，讲的太棒了。谢谢。不过pig latin没听懂
编辑回复：
谢谢夸奖，可以多看些基础书籍哦~
**0787：
讲的比较白话，让小白能理解的更透彻
**恒：
听老师讲完后，思路变得更清晰了，期待老师的更新
**全：
感觉和微服务架构系统的整体感觉很像
大数据运维实战第一课 大话 Hadoop 生态圈相关推荐
- 大数据运维实战第十七课 日志收集、分析过滤工具 Logstash应用实战
本课时主要讲解"日志收集.分析过滤工具 Logstash 应用实战". Logstash 介绍与安装 Logstash 是一款轻量级的.开源的日志收集处理框架,它可以方便地把分散的 ...
- 大数据运维实战第十九课 Kafka 应用场景、集群容量规划、架构设计应用案例
Kafka 基础与入门 1. Kafka 基本概念 Kafka 官方的定义:是一种高吞吐量的分布式发布/订阅消息系统.这样说起来可能不太好理解,这里简单举个例子:现在是个大数据时代,各种商业.社交.搜 ...
- 【大数据科普系列之二】大数据运维工程师
大数据系列岗位要求,大数据运维可能是"技术含量最高"的职位之一,这里说的大数据运维主要是指hadoop生态体系方面的运维,在一些小公司或者传统行业的大公司也会使用oracle.db ...
- 大数据运维架构师培训（1）：Zookeeper，Hadoop（HDFS,MR,Yarn）
一.风哥大数据运维架构师实战培训专题2.0介绍 课程背景: 为满足想学习和掌握大数据运维与体系架构的学员,风哥特别设计的一套比较系统的大数据库运维培训课程. 课程目标: 本套风哥大数据运维架构师实战培 ...
- 大数据运维 | 集群_监控_CDH_Docker_K8S_两项目_云服务器
说明:大数据时代,传统运维向大数据运维升级换代很常见,也是个不错的机会.如果想系统学习大数据运维,个人比较推荐通信巨头运维大咖的分享课程,主要是实战强.含金量高.专注度高,有6个专题+2个大型项目+腾 ...
- python大数据运维工程师待遇_什么是大数据运维工程师
一.运维三板斧 三板斧可以解决90%以上的故障处理工作.1>.重启 重启有问题的机器或经常,使其正常工作.2>.切换 主备切换或主主切换,链接正常工作的节点.3>.查杀 查杀有问题的 ...
- 大数据运维工作（Linux，OGG，链路监控，Hadoop运维等）
大数据运维工程师工作内容 Linux运维手册 1. 启动/关闭集群组件 1.1 负载均衡 1)Nginx 运维命令 Copy to clipboard cd /usr/nginx/sbin #进入 s ...
- python大数据运维工程师待遇_大数据运维工程师具体是做什么的？
大数据运维的工作职责 一.集群管理 大数据需要分布式系统,也就是集群:Hadoop,Hbase,Spark,Kafka,Redis等大数据生态圈组建. 二.故障处理 1>.商用硬件使用故障是常态 ...
- python大数据运维工程师待遇_大数据运维工程师的工作职责
大数据需要负责公司产品的技术支持.安装调试.客户使用培训及相关硬件的安装调试.下面是学习啦小编为您精心整理的大数据运维工程师的工作职责. 大数据运维工程师的工作职责1 职责: 1.负责和参与公司大数据 ...
最新文章
- Xamarin Essentials教程构建共享请求
- linux 系统邮件 查看清空
- python系统-python系统介绍
- Mysql创建、删除用户
- STM32的RTC简单操作
- Java-Web JSTL标签库、自定义标签库和MVC设计模式
- 科大星云诗社动态20210309
- [BUUCTF-pwn]——picoctf_2018_can_you_gets_me
- JAVA 泛型中的通配符 T，E，K，V，？
- 模板：割点、桥与双连通
- win10用不了php_WIN10用不了
- Word文档编辑技巧（一）
- MPPT算法（恒定电压、扰动观察、电导增量）介绍与实现过程
- 微信消息推送渠道建设
- windows android ndk开发,Windows系统下配置Android NDK开发环境
- CODESYS Visualization
- thinkpad卡在logo界面_win7系统开机卡在Thinkpad LOGO画面无法进入桌面的解决方法
- 盘点阿里巴巴 15 款开发者工具 侵删
- oracle apex global,Oracle Apex 实用笔记系列 1 - Oracle Apex 调试技巧
- 蚁群算法 python
热门文章