Hadoop生态简介，Hive、Spark、HBase等
1. Hadoop1.1 Hadoop简介
Hadoop如今已经是大数据领域究竟上的标准，基本提到大数据，大家起首想到的就是Hadoop。
在本文中，笔者会联合本身的实际使用履历，力求以简朴易懂的语言讲清楚Hadoop及其衍生生态下各个组件产生的配景，以及它们之间的关系，除了简述它们的作用之外，还会先容它们各自的缺点，这个世上没有万金油，每项技术都有它适用的场景，也有它们的范围性。
https://img-blog.csdnimg.cn/direct/eeba4b2a05a042cb8aa4142fd0bdb795.png#pic_center
1.2 大数据产生的时代配景
在21世纪初互联网技术井喷式发展，人类进入互联网时代，各类电商网站、博客、微博、消息流派层出不穷，大家似乎无时无刻都在产生数据，数据开始野蛮增长，随之而来就是如此体量的数据如何存储和计算的问题，这也是大数据技术诞生的配景。
实在以Hadoop为代表的大数据技术主要办理了以下2个问题：
[*]海量数据存储的问题，在Hadoop出现之前，各业务系统将业务数据单独存储，存储不下就分库分表，各种数据库中央件、插件大行其道，系统架构复杂且费用昂贵，很轻易出现数据孤岛，无法发挥数据真正的代价，Hadoop的出现让海量数据存储成为了可能。
[*]海量数据计算的问题，海量的存储就须要海量的计算，Hadoop的MapReduce则为大数据处理提供了可能，MapReduce是一个分布式的并行处理框架，用户只须要实现简朴map()和reduce()函数就可以完成海量数据的并行计算。
1.3 Hadoop产生的配景
Hadoop诞生于Nutch项目，项目目的是构建一个大型的全网搜索引擎，随着抓取的数据量越来越多，Nutch项目遇到了严重的可扩展性问题，几乎与此同时，Google发表了闻名的3篇论文，为Nutch提供了办理思绪。
Google的3篇论文发表于2003 ~ 2006年间，内容分别对应GoogleFileSystem、MapReduce和BigTable，前2项分别对应Hadoop中的HDFS和MapReduce，在最初的Hadoop设计中并没有BigTable的实现（这篇论文发布较晚），BigTable背面由HBase实现，并捐献给了Apache社区。
1.4 Hadoop的焦点组件
[*]HDFS：分布式文件系统，以文件形式将数据分布式存储在差异服务器上，HDFS集群具有良好的扩展性，得当存储超大规模数据集，得当一次写入多次读取的场景。
[*]MapReduce：分布式并行计算框架，主要用于处理存储在HDFS上的大规模数据集，也可以处理数据库和本地文件系统中的数据，MapReduce主要用于开辟计算任务。
[*]YARN：分布式资源管理和调理框架，Hadoop2.X引入的新组件，主要用于集群资源统一管理（内存、CPU、网络、磁盘等）和计算任务的调理运行，YARN不但可以运行MapReduce任务，还可以运行Spark、Tez等任务。
1.5 Hadoop存在的问题
实在Hadoop焦点的3个组件中，HDFS和YARN仍在大规模使用，存在问题较大还是MapReduce：
[*]开辟难度大，MapReduce开辟须要掌握Java语言，对DBA或运维人员不友爱，简朴map()和reduce()虽然简化了处理流程，但也降低了任务开辟的灵活性，任务编排组织使得代码非常痴肥，使用MapReduce只能实现简朴逻辑，复杂任务使用MapReduce开辟简直就是灾难。
[*]执行服从低下，MapReduce执行过程中须要频繁IO和落盘，任何任务执行都必须颠末Map=>Shuffle=>Reduce这3个基本流程，在这个过程中会颠末多次的磁盘读写，导致服从难以提升。
[*]算子能力太弱，MapReduce()只提供了map()和reduce()两个最基本的接口，其它任何操作都须要开辟人员基于这2个固定流程开辟，哪怕是一个简朴的left join都须要写一堆代码实现。
2. Spark
2.1 简介
正是由于MapReduce存在种种问题，以是才出现了Spark，Spark是一款用于处理大规模数据集的通用计算引擎，我们通常用它来更换Hadoop中MapReduce，Spark专注于的领域是计算，通用计算引擎的寄义是它不依靠任何存储，既可以对HDFS上数据进行计算，也可以对关系型数据库、Kafka、S3中的数据进行运算。
https://img-blog.csdnimg.cn/direct/20576dd8b59c41b184435553eda4ab56.jpeg#pic_center
2.2 Spark办理了什么问题
相比于MapReduce，我觉得Spark主要有如下优点：
[*]内存计算：Spark没有像MapReduce那样频繁读写磁盘，而是优先使用内存，节流了数据从内存到磁盘，然后再从磁盘到内存的资源斲丧。
[*]计算路径的优化：Spark使用DAG（有向无环图）来规划任务执行路径，它会将DAG划分为多个Stage，每个Stage都可以并发执行，相比于MapReduce，Spark设计更加精密，它会选择最佳路径执行计算任务。
[*]丰富的算子：差异于MapReduce简朴的map()和reduce()操作，Spark提供了海量的內置算子，例如leftJoin()、group()等，几乎涵盖了传统数据库支持的全部计算操作。
[*]开辟较为简朴：Spark提供了SQL、Scala、Java、Python等多种接口，满足差异配景的开辟人员使用。
[*]丰富的数据源：Spark内置许多现成的数据读写能力，例如常用的jdbc、orc、parquet、csv、hbase等。
2.3 Spark在Hadoop生态中的作用
Spark通常用于更换MapReduce，作为集群的计算引擎存在。
2.4 Spark的缺点
虽然Spark已经非常强大了，基本可以满足大数据场景下的计算需求，但是它还是有许多不敷的地方：
[*]Spark擅长的领域是批处理，尽管Spark Streaming可以进行流计算，但相比于Flink，Spark Streaming的吞吐量稍显不敷，延迟性也比Flink高，Spark追求的是流批一体，Flink只专注于流处理。
[*]Spark虽然执行服从高，但占用大量内存轻易导致步伐不稳定，在稳定性和并发性方面确实不如MapReduce，特别是数据堆栈数万任务运行的场景，这种问题就会被放大，这也是许多数仓仍使用hive-on-mapreduce的缘故原由。
[*]Spark通常运行在YARN上用于计算HDFS上的数据，这导致Spark的优化还是围绕Hadoop模型展开，其计算服从相比于ClickHouse、Doris等OLAP新势力还是有所差距。
3. Hive
2.1 简介
前面已经提到MapReduce有开辟难度较大，复杂任务编排困难的问题，Hive就是为了办理这些问题而诞生的。
Hive是一款数据堆栈管理工具，也可以把它当成一种数据统计工具，Hive以数据库形式管理HDFS上的目录和文件，Hive可以将结构化数据映射成数据表，并使用雷同SQL的脚本语言（HiveQL）操作数据，Hive会将这些SQL翻译为一连串的MapReduce任务运行。
虽然Hive跟传统数据库很像，但它确实不是数据库，它仅仅是一个工具，如果以MySQL的4层架构（毗连层/服务层/引擎层/存储层）作为对比，那么Hive也仅仅是实现到了服务层，Hive本身不具备任何计算能力和存储能力，Hive依靠MapReduce或Spark作为其计算引擎，而Hive处理的巨大部分数据都是HDFS上的文件。
https://img-blog.csdnimg.cn/direct/5097a6bc114b4050853650fe34d1fcf9.jpeg#pic_center
2.2 Hive的优点
[*]操作简朴：以SQL方式操作数据，而且提供JDBC驱动，大大降低了大数据的使用门槛，不论是开辟人员还是DBA都能快速上手。
[*]任务优化：Hive会将SQL翻译为一连串的MapReduce任务，优化器会主动选择最佳的执行路径查询数据。
[*]多执行引擎：Hive不但支持MapReduce引擎，还支持使用Spark和Tez作为其计算引擎。
2.3 Hive在Hadoop生态中的作用
在Hadoop生态中，Hive通常作为SQL执行引擎存在，后续出现的SparkSQL也兼容Hive语法规范。
Hive常用于构建数据堆栈，以是Hive也可以作为集群数据文件的管理工具。
2.4 Hive的缺点
[*]执行服从低，虽然Hive已支持Spark引擎，但现在仍有许多Hive任务运行在MapReduce上，MapReduce的执行服从会影响SQL的执行。
[*]SQL的好处是使用简朴，但是表达能力较弱，复杂分析任务须要嵌套多层子查询，可读性就会变得非常差，复杂的嵌套查询也给调优带来了一定挑战。
[*]调优复杂，Hive不像传统数据库那样颠末简朴调优便可稳定运行，Hive调优涉及方面较多，参数冗杂，调优须要一定的使用履历。
2.5 Hive和SparkSQL对比
[*]SparkSQL的执行服从要优于Hive，虽然Hive支持Spark作为计算引擎，但hive-on-spark底层使用的是RDD API，而不是DataFrame API，SparkSQL使用的最新的DataFrame API，自然使用Spark作为计算引擎，执行服从比Hive要高一些。
[*]Hive的稳定性要优于SparkSQL，由于Spark优先使用内存计算，占用资源相对较多，相较于Hive稳定性会差一些。
[*]Hive的并发性要优于SparkSQL，Spark相较于Hive占用的内存资源较多，在集群资源一定的情况下，能同时运行的任务数就会淘汰。
2.6 Hive和Spark该如何选择
实在在实际生产过程中，Hive和Spark使用都比较多，它们各自有本身适用的场景。
[*]如果须要构建复杂的分析或处理任务，Spark更为符合，Hive SQL嵌套多层之后可读性会变差，而且会给调优带来一定的挑战。
[*]在数据堆栈或业务系统中的查询任务，Hive更为符合，因为业务查询须要稳定执行，而且须要更高的并发性能，前文也提到了，Hive在稳定性和并代性方面要优于Spark。
[*]平凡分析查询任务，发起使用Spark，因为它确实比Hive要快许多。
2.7 Pig
前文提到MapReduce存在种种问题，实在早在Hive出现之前，Pig就尝试办理这些问题，Pig采用一种雷同SQL的PigLatin语言来编排MapReduce任务，相比于直接编写MapReduce任务，Pig已经可以节流许多人力。
但是Apache Pig却没有大规模使用起来，主要是后来者Hive和Spark比它更为良好。PigLatin相较于SQL还是具有一定的学习本钱，HiveQL接近于MySQL方言，只要会使用SQL的人员都可以快速上手。与Spark相比，Pig更加不具备任何上风，Spark誊写更加简朴，且代码可读性更强，不论是简朴的查询还是复杂的分析任务，Spark都可以轻松搞定，在执行服从方面，Spark更是显着快于Pig。
无论从哪种方面来看，Apache Pig都像是上个时代的产物，该项目已经很久没有更新了。
https://img-blog.csdnimg.cn/direct/078291a5f46641df9f25943172a4c83b.jpeg#pic_center
3. HBase
3.1 简介
HBase是Hadoop Database的缩写，意为Hadoop数据库，是Google经典3篇论文中BigTable的开源实现，它是一个功能完整的K-V数据库，主要用于存储海量的结构化和半结构化数据。
HBase将数据存储在HDFS上，HDFS保证了HBase数据的安全性和扩展性，理论上HDFS上能存多少数据，HBase就能存下多少数据，实在HBase的真正瓶颈在于RootRegion的大小（存储元数据信息的Region），只要元数据信息能存下，HBase中的数据量就可以无限增长。
在计算方面，HBase使用本身RegionServer实现计算，并不依靠其它组件。关于HBase的知识恐怕几篇文章都先容不完，这里不再深入先容，大家只需简朴了解HBase是个什么即可，后续有时间单独开篇博客先容。
https://img-blog.csdnimg.cn/direct/d081c247075d45f794b307fc870d8e9d.png#pic_center
3.2 HBase的适用场景
[*]得当实时增删改查的场景，存在HDFS上的数据通常以批处理为主，如果想要插入的数据立马可以就能读取到，那么HBase就比较符合。HDFS上的数据通常是一次写入多次读取，更新和删除操作困难，如果业务系统中须要对数据进行更新或删除，那么可以思量使用HBase做实时查询系统。
[*]得当简朴查询的场景，实在理论上HBase的索引只有1个就是row_key，如果想要在HBase中快速检索数据，就须要将干系数据设计到row_key中，但这种row_key长度毕竟有限，如果想要实现更为复杂的检索，就必须依靠Elasticsearch品级三方检索工具。
[*]也可以作为数据堆栈的底层存储，如果数仓中的数据存在删除或更新的需求，可以思量使用HBase，但不发起完全使用HBase作为数据堆栈，因为建设数仓的目的是为了分析统计，HBase不得当大规模统计分析，再者大规模扫表也会对HBase服务造成巨大压力，只发起将有删改需求的表数据存储在HBase中。
实在在笔者的工作过程中，HBase使用的频率远远不如Hive和Spark，只有少量须要实时检索的场景才会用到HBase。
3.3 HBase的缺点
[*]检索困难：只有row_key检索较快，row_key之外的Scan较慢，HBase得当围绕row_key的简朴检索，复杂查询的优化可能须要依靠Phoenix品级三方组件组件提供二级索引服务。
[*]只支持单表操作：HBase无法实现多表操作，多表操作须要依靠Hive或Phoenix的第三方组件。
[*]统计分析困难：HBase主要用于K-V检索，统计分析须要应用步伐在内存中本身处理，或者使用Hive或Phoenix品级三方组件。
3.4 HBase的SQL方案
3.4.1 Phoenix
Phoenix是HBase的SQL引擎插件，使得用户可以以SQL方式操作HBase，Phoenix支持多表查询，并提供了多种二级索引方案。
https://img-blog.csdnimg.cn/direct/5abf1f4c554f41c7871f7acc52cac953.png#pic_center
Phoenix的优点：
[*]提供标准SQL和完整的变乱支持，并提供JDBC驱动供应用使用，Phoenix会将SQL转换成原生Scan，服从与原生API差距不大。
[*]提供完整的二级索引方案，补充了原生HBase只能根据row_key检索的缺点。
[*]支持复杂查询和分析统计，支持例如join、group by等常用操作。
[*]Phoenix创建的表与原生HBase完全兼容，可以直接使用HBase API查询。
Phoenix的缺点：
[*]数据精度的损失，HBase原来设计的列族/限定词/时间戳的三维结构被逼迫拉伸成一维列结构。
[*]复杂查询和分析统计效果不是太理想，尽管Phoenix内部做了许多的优化，但是HBase本身就不是一款分析型数据库，不论怎么优化，其效果始终差能人意。
[*]Phoenix的索引方案会新建索引表或利用本地存储，会浪费许多存储空间，以空间换时间，索引那部分数据会存多份。
3.4.2 HBaseStorageHandler
HBaseStorageHandler是Hive提供的用于查询HBase的处理器，通过这个处理器，就可以在Hive中以SQL形式查询HBase表。
HBaseStorageHandler的优点：
[*]可以直接使用标准Hive查询HBase数据库，并与Hive中其它表进行关联，而Phoenix则只能在HBase库内计算，我们在构建数仓时也会将部分表数据存储到HBase中。
HBaseStorageHandler的缺点：
[*]底层使用MapReduce全表扫描，查询服从较低，纵然添加了过滤条件，也会全表扫描，而Phoenix则会将SQL转换为原生Scan，将过滤条件转换为原生Filter。
3.5 在生产情况中使用HBase
如果是按照row_key检索更新的场景，通常会直接HBase API。
如果是统计分析的场景，更多的还是使用Spark和Hive查询HBase，简朴查询会用Phoenix，如果须要频繁扫描HBase表，发起将数据导出至HDFS，减轻HBase服务压力。
如果是在数仓中使用，还是Hive查询HBase较多。
4. Zookeeper
4.1 简介
Zookeeper一款分布式的应用步伐协调步伐，办理数据一致性问题，它的作用主要有2个：
[*]各节点之间的分布式协调，例如推举主备节点、管理各个节点之间的状态，可以简朴将它明白为集群的管理者，从各个节点中选出一个老大，然后其它节点听从老大指挥，大家互通消息、举措一致。
[*]存储重要数据，例如Kafka的副本信息、HBase的元数据信息都直接存储在Zookeeper中。
https://img-blog.csdnimg.cn/direct/18aa6317f90e4329b6b7cc68238c4bef.jpeg#pic_center
4.2 Zookeeper在Hadoop生态中的作用
Zookeeper在Hadoop中主要作为统一协调中央和统一配置中央存在，说它是整个集群的大管家也绝不为过。
4.3 Zookeeper在各个组件中的作用
[*]Hadoop利用Zookeeper实现高可用，但主节点挂掉之后，会切换到备节点。
[*]Hive利用Zookeeper实现高可用，当主节点挂掉之后，会切换到备节点。
[*]Kafka利用Zookeeper实现分布式协调，推举主从节点，每个Topic的副本信息等也会存储在Zookeepr中。
[*]HBase利用Zookeeper实现高可用，当HBase的一个Master挂掉之后，会立马切换到备用Master，HBase还会将一些比较重要的元数据信息存储到Zookeepr中。
[*]Elasticsearch利用Zookeepr实现分布式协调，它会将所有的节点信息都存储到Zookeepr中。
4.3 Zookeeper的缺点
Zookeeper采用推举机制推举Leader，其它节点作为Follower或Observer存在，当Leader挂掉之后，会重新推举Leader，但推举的过程须要时间，对于Hadoop这样的计算性集群而言可能不算什么，但对于电商系统这样高速运算的系统而言，集群停摆几秒就可能导致非常严重的后果，以是之前Dubbo这样的中央件使用Zookeepr作为注册中央就具有一定的风险，只要Leader停摆，集群就须要一直等，等待新的Leader上线。
5. Kafka
5.1 简介
Kafka是一款数据流平台，通过Kafka数据在各个组件之间流转，Kafka也可以作为消息中央件，用于各业务系统之间的解耦。
https://img-blog.csdnimg.cn/direct/a8e964eb9ddb411abf7205017a7f2853.png#pic_center
5.2 Kafka的作用
[*]实时数据流处理，负责集群中的实时数据流转，关于实时流数据处理的经典组合是业务系统将数据发往Kafka，然后Flink从Kafka拉取实时数据处理。
[*]流量削峰，有些业务流量不均，高峰时的流量是平常的数倍，这时就可以把数据发往Kafka，后续系统就可以在流量较低时慢慢处理Kafka中的数据。
[*]系统解耦，Kafka也可以直接作为消息队列，用于各个业务系统之间解耦，但Kafka模型简朴，如果业务复杂，须要更多功能，可以思量RabbitMQ等专业MQ。
6. Elasticsearch
6.1 简介
Elasticsearch是一款基于Lucene的分布式检索引擎，可以完成复杂的实时检索，稳定可靠、可扩展。
6.2 Elasticsearch的作用
Elasticsearch的作用就是做大数据实时检索，通过Elasticsearch提供Restful API可以完成各种复杂的数据检索，甚至可以跨索引检索。
须要留意的是Elasticsearch专注的领域是数据检索，如果有统计分析的场景，还是发起使用Spark或Hive，而且Elasticsearch也不属于Hadoop生态，须要将数据导入到Elasticsearch中。
7. Ooize
基于Hadoop的分布式调理系统，可以将我们写的MapReduce或Spark打包上传，由Ooize负责定时执行。
在我们实际生产过程中，还是有许多须要定时执行的Spark任务的，这时Ooize就排上用场了。
8. Sqoop && Flume
为什么最后先容这两个组件，是因为它们和Apache Pig一样，存在感确实很低。
Sqoop是一款将关系型数据库中的数据导入到Hadoop平台的ETL工具，但几乎没有哪家厂商乐意使用它，要么本身开辟ETL工具，要么使用Kettle、DataX等开源的ETL工具。
Flume是一个高可用的、高可靠的分布式的海量日志采集、聚合和传输的系统。
9. 结语
这是最好的时代，也是最坏的时代。Hadoop从诞生至今已不知不觉走过了20多年的时间，英雄迟暮，志在千里！但时代总要继续向前发展，渴望大家在拥抱Hadoop的同时，也积极去拥抱ClickHouse，拥抱Doris。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]