既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!
由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新
02-[了解]-第5天:课程内容提纲
主要讲解:存储引擎
Kudu
,类似HBase数据库,由Cloudera公司开发,目的取代HDFS和HBase框架,
- HDFS文件系统:批量加载分析,尤其parquet列式存储
- HBase数据库:对海量数据随机读写,速度比较快
1、数据实时ETL流程
选择结构化流StructuredStreaming实时消费Kafka数据,对数据进行ETL转换,存储外部系统
2、Kudu 入门使用
1)、Kudu 为什么诞生,能够解决什么问题
2)、SQL on Hadoop 框架发展史
Kudu和Impala一对CP,Kudu存储数据,Impala 分析数据
3)、Kudu 是什么应用场景
4)、Kudu 架构设计和原理
5)、Kudu 安装部署
已经使用CM安装部署,启动及监控
03-[掌握]-数据实时ETL 处理流程图
对于物流项目来说,如何对业务数据进行实时ETL存储。
- 1)、将业务系统数据实时存储到分布式消息队列Kafka中
- 2)、编写流式应用程序:StructuredStreaming结构化流,实时消费Kafka数据,进行ETL转换处理,最终存储到外部存储引擎(Es索引、Kudu数据库和ClickHouse数据库)。
- 数据源Source:业务数据实时增量采集到Kafka Topic中,1个业务系统,对应1个Topic,不同业务系统Topic的分区数目不一样。
数据转换ETL
:消费Kafka中消息都是JSON格式字符串,需要进行解析转换处理- 数据终端Sink:将转换后数据存储到Kudu、ES及CK中,此时如何保存DataFrame到外部存储系统,像ES和Kudu框架自身提供与Spark集成库,直接使用接口;但是Clickhouse数据库没有提供,需要自己实现如何保存数据,与Spark集成。
面试题:为什么使用StructuredStreaming实时ETL,而不是SparkStreaming或者Flink呢?
- 第一、StructuredStreaming 优势
- Spark 2.0开始诞生新的针对结构化流式数据处理模块,取代SparkStreaming,底层重用SparkSQL中Catalyst分析引擎,进行更多优化,性能提升。
- 此外,数据结构:
DataFrame
,更好知道内部结构,方便处理数据。Spark2.2发布Release版本,可以用于生产环境,Spark 2.3版本提供持续流处理。- 在设计之初保证端到端精确一次性语义功能。
Source数据源:偏移量offset、数据处理:WAL和Checkpoint、数据终端:支持幂等性
- 第二、SparkStreaming 缺陷
- 底层基于RDD数据结构进行数据处理,需要开发人员更好理解RDD,调用合适API方法,处理分析数据。某些流式数据处理功能不能实现,比如窗口分析是基于处理时间ProcessingTime;实时计算无状态,如果进行状态计算,需要自己管理状态,调用API(updateStateByKey或mapWithState)等。
- SparkStreaming从2.0开始进入维护状态,一直没有新的功能,官方建议时用StructuredStreaming。
- 第三、对比Flink计算引擎
- 物流项目来说,对实时性要求不是很高,使用StructuredStreaming完全可以满足
- Flink中流式计算使用DataStream API,比较底层,没有StructuredStreaming编程简单方便
- Spark框架目前相当成熟稳定,很多外部存储系统都与Spark进行集成,比如Es和Kudu提供集成库,直接调用API就可以读写数据,进行分析处理保存。
04-[理解]-为什么使用Kudu(两大应用场景)
Kudu存储引擎诞生以后,在国内使用较早
小米和网易
公司,使用Kudu主要2大应用场景:
- 1)、【数据库数据】上的
快速
分析
将原有业务数据(MySQL、Oracle数据库)实时同步到Kudu存储引擎,Kudu对外提供实时查询分析和数据变更操作。
- 2)、【用户行为日志】的快速分析
在没有使用Kudu之前,为了满足业务需求,用户行为日志数据处理处理如下所示:
引入 Kudu 以后,大家看,数据的导入和查询都是在线实时的:
Kudu存储数据以后,可以快速查询分析(即席查询,与Impala集成)和报表分析(SparkSQL)。
Kudu诞生之初(设计目标)就是为取代HDFS文件系统和HBase数据库,既能够实现随机读写,又能够批量加载分析,所以Kudu属于HBase和HDFS折中产品。
05-[理解]-SQL on Hadoop 技术发展
大数据技术框架中(领域中),SQL框架目前越来越多,从最开始Hive框架,到现在Flink SQL,至少10种以上框架出现,但是使用较多:Hive、
Impala、Presto
、SparkSQL、FlinkSQL(正在迅速发展)。
- 1)、Hive 数仓框架,建立在HDFS和HBase之上,提供SQL分析数据
- 2)、Impala 内存分析引擎,取代Hive底层MapReduce,使用内存分析数据
Cloudera公司依据Google论文:Dremel 论文,开发基于内存分析引擎Impala。
- 3)、Impala集成Kudu,在快速数据之上建立快速分析
Cloudera公司,如果公司既要求对数据进行随机读写查询,又要对数据进行批量加载快速分析,需要将数据存储到HDFS(PARQUET)和HBase,能不能一个框架存储引擎实现2个功能:
Kudu
。
Kudu和Impala都是使用C++语言编写,使用内存进行数据存储和分析,速度比较快的,很多金融公司、证券公司或游戏公司,都会使用此种大数据技术,进行存储数据和分析数据。
Kudu 在一个系统中融合了 OLTP 型随机读写能力与 OLAP 型分析能力,填补了 Hadoop存储层的缺憾,是 Hadoop 生态的一大生力军。
06-[理解]-Kudu 是什么及应用场景
Apache Kudu是由Cloudera开源的
存储引擎
,可以同时提供低延迟的随机读写
和高效的数据分析
能力。
1、Kudu是一种非洲的大羚羊,中文名叫“捻角羚”;
2、Impala是另一种非洲的羚羊,叫做“黑斑羚”,也叫“高角羚”;
不知道Cloudera公司为什么这么喜欢羚羊,也许是因为羚羊的速度快。
在Kudu之前,大数据主要以两种方式存储:
如果对业务数据既需要随机读写,有需要批量加载快速分析,实现如下架构:
上述架构:数据冗余性比较大、技术框架复杂性比较高、数据实时性降低。
为了解决上述架构的这些问题,Kudu应运而生。Kudu的定位是
Fast Analytics on Fast Data
,是一个既支持随机读写、又支持 OLAP 分析的大数据存储引擎。
从上图可以看出,KUDU 是一个折中的产品,在 HDFS 和 HBase 这两个偏科生中平衡了随机读写和批量分析的性能。
Kudu相比与以往的系统,CPU使用降低了,I/O的使用提高了,RAM的利用更充分了。
Kudu 应用场景:
07-[掌握]-Kudu 数据存储模型
KUDU 的数据模型与传统的关系型数据库类似:一个 KUDU 集群由多个表组成,每个表由多个字段组成,一个表必须指定一个由若干个(>=1)字段组成的主键。
KUDU 表中的
每个字段是强类型的
,而不是 HBase 那样所有字段都认为是 bytes。好处是可以对不同类型数据进行不同的编码
,节省空间。同时,因为 KUDU 的使用场景是 OLAP 分析,有一个数据类型对下游的分析工具
也更加友好。
- 1)、Table表:Schema信息(字段名称和字段类型)、主键约束(PrimaryKey)
- 2)、Tablet:表的一个数据片段,类似HBase中Region
- 在Kudu中将表划分为多个Tablet,每个Tablet存储自己数据
- Tablet 副本机制,1个副本为leader,其他副本为Follower,类似Kafka Topic中分区Partition。
- 副本之间,
基于Raft协议,实现高可用HA,
当leader挂掉以后,从Follower中选取leader。 - 副本数必须为奇数,例如为3个副本等
08-[掌握]-Kudu 分区策略及列式存储
在Kudu存储引擎中,如何将一个表Table数据划分为多个Tablet???有哪些分区策略:
在Kudu中,每个表的分区Tablet需要
在创建表的时候指定
,表创建以后不能被修改。
- 1)、范围分区:
Range Partitioning
,类似HBase表划分
- 按照字段值范围进行分区,HBase 就采用了这种方式。
- 2)、
Hash Partitioning
,按照字段的Hash 值
进行分区,Cassandra
采用了这个方式。
- 3)、多级分区,可以指定范围,再指定哈希或者指定多个哈希分析
KUDU 支持用户对一个表指定一个范围分区规则和多个 Hash 分区规则,如下图:
多级散列分区组合,如下图所示:
KUDU 是一个
列式存储
的存储引擎,其数据存储方式如下:
列式存储的数据库很适合于
OLAP
场景,其特点如下:
09-[掌握]-Kudu 框架整体架构设计
KUDU 中存在两个角色:基于Raft协议实现一致性,所以不依赖Zookeeper
- 1、
Master Server
:负责集群管理、元数据管理等功能,类似HBase Master- 2、
Tablet Server
:负责数据存储,并提供数据读写服务,类似HBase RegionServer在 KUDU 中都可以设置特定数量(3 或 5)的副本。各副本间通过 Raft 协议来保证数据一致性。Raft 协议与 ZAB 类似,都是 Paxos 协议的工程简化版本。
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
[外链图片转存中…(img-0YhoC6l5-1715058187786)]
[外链图片转存中…(img-gCqh0dff-1715058187786)]
网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!