“ 来一起认识下大数据的技术框架有哪些,它们分别用于解决哪些问题?它们的内在逻辑和适用场景有哪些?OK,一起去探索下。”
生态架构
首先,看一下大数据技术体系的整体架构图。根据数据流转的方向,从下而上进行介绍。
在前面,我们了解到,大数据的数据存储是分布式的,而且能够接受任务调度,与传统的数据存储存在差异。所以离线方式处理的数据,需要通过ETL模块,导入到大数据的数据存储系统进行存储;其中Sqoop是常见的抽取结构化数据工具;而Flume和Logstach是用于抽取非结构化、半结构化数据工具。
大数据的数据存储系统,最常见的就是分布式文件系统HDFS;如果需要使用NoSQL数据库功能,HBase是基于HDFS实现的一个分布式NoSQL数据库。
存储起来的数据,使用大数据的通用计算引擎MapReduce或Spark进行计算,这些计算任务会由资源管理框架——Yarn进行调度。将任务分发到数据的存储位置——HDFS中。
但使用通用计算引擎MapReduce或Spark编写处理任务,需要使用特定的语法;这样一来,原有的特定领域的传统业务,进行迁移时就会带来很多问题。比如原有的数据仓库,使用SQL进行数据处理任务,但迁移到大数据平台之后,原来的SQL业务需要全部转换为MapReduce、Spark语法,迁移成本太大。其次,图计算、机器学习等其他领域,在MapReduce、Spark语法基础上,实现起来非常困难,且易用性很差。
于是在通用计算引擎之上,针对不同的领域,诞生了很多提升易用性的产品;以使得对存储在大数据平台上的数据进行数据分析,变得更加容易。
比如在Hadoop生态圈的Hive,它的作用就是将SQL转化成MapReduce任务,减少了数据仓库迁移成本,虽然它的SQL支持率只有60%左右,而且有特定的语法HQL(Hive SQL),但已经极大的简化了结构化数据的处理过程。当然它现在也支持底层计算引擎转换为Spark,以便提升处理性能。
Hadoop生态圈的Pig的功能和Hive类似,但它是将MapReduce封装为自己的API,使用起来比原生的MapReduce更易用一些;在早期,使用的公司较多,现在基本已很少被使用。
Hadoop生态圈的Malhot是机器学习的一个框架,可以完成机器学习的任务,底层将任务转换为MapReduce,从而实现分布式运算。
除了Hadoop生态圈,Spark引擎也有自己的生态圈,其中Spark SQL和Hive功能类似,将SQL转换为Spark任务,提升结构化数据处理的易用性。MLlib提供机器学习的功能,GraphX完成图计算功能,Spark Streaming完成流计算任务。
在架构图中的数据分析层中,有一个产品比较特殊——ElasticSearch,它是用于大数据下的搜索与检索场景的产品。但它是独立运行的,将数据存储于本地磁盘,不依赖于HDFS;有自己的计算引擎,不依赖于MapReduce、Spark。所以,除了在大数据领域,其它很多场景中也能见到它的身影。
大数据实时流处理
在大数据实时运算这里,半结构化、非结构化数据先通过实时ETL工具,如Flume、Logstash进行数据的实时采集;结构化数据,一般会采用监控数据库预写日志的方式,通过CDC或者OGG等工具进行实时抽取。
实时抽取的数据,首先会进入到消息队列中,完成削弱峰值和解耦合的功能,之后便交于流处理引擎进行处理。常见的流处理引擎有Spark Streaming、Flink。
其中Spark Streaming是将实时处理任务转换为Spark这种离线批处理任务进行处理,它的原理就是将一定时间间隔内的数据,转换为离线批处理任务,只要时间间隔足够短,它就可以近似于实时处理。所以Spark Streaming的处理方式也被称为微批处理模式。
而Flink,它有自己的运算引擎,所以是真正意义上的实时计算,而不需要转换为批处理任务。
数据经过处理之后,最终的结果会被存储到数据库集群中,企业常用的选型是HBase,因为它有一个较好的特性:高并发读,可以满足前端系统结果的实时查询。当然,Druid、Clickhouse也是常用的选型产品。
分布式协调
大数据的产品,都是分布式架构,以集群的形式部署和运算。于是,分布式集群的管理便成了一个问题,比如节点间的发现、主从的切换等。而Zookeeper,就是为了解决这些问题而存在的,它提供分布式协调服务。
Zookeeper本质上是一个特殊的文件系统,加上消息通知机制,来完成分布式协调。
比如节点间的发现,当某个集群在第一次启动时,假设为Kafka,它会在Zookeeper上的文件系统中创建自己的目录——Kafka。
其中Kafka每个节点启动成功后,假设为Node01,会在Zookeeper上的Kafka目录中注册,即创建自己的节点文件——Node01,Zookeeper检测到Kafka目录创建了Node01,便会通知Kafka中的所有节点,Node01加入到集群中了。
而Node01超过一定时间没有向Zookeeper进行通信,Kafka目录下的Node01文件便会被删除,于是Zookeeper便又会通知所有Kafka节点,Node01节点被移除了。
在很多大数据产品中,都会依赖Zookeeper集群,用于实现分布式协调服务。
分布式任务调度
大数据分析任务,一般都会有多个产品协同完成,并且存在严格的先后顺序。比如,要完成对当天数据的处理,首先需要通过ETL组件,将数据抽取到HDFS中进行存储,之后再由Hive或Spark SQL将数据接入进行处理,处理完成之后,为了保证前端的查询效率,可能再通过ETL组件将结果表存储到其它数据库中。
其次,大数据任务的执行,如离线数据仓库,一般会选择定时执行;如凌晨零点,对昨天的数据统一进行抽取,并处理计算。
大数据的分布式任务调度组件Azkaban、Oozie就是来完成这些任务的,它们可以完成控制任务的执行顺序、定时执行等功能。
而Azkaban相对Oozie来说,它的功能相对丰富,Web界面也较为美观,在企业选型中比较常见。
看到这里,关于大数据技术体系,你懂了吗?记得关注,下期见! 编辑于 2021-9-17 15:54
|