kafka和flink的入门到精通 2 系统架构,实时数仓架构,Kafka

参考007 - 大数据 - 系统架构 - 实时数仓架构_哔哩哔哩_bilibili

链接:https://pan.baidu.com/s/1QMOJVkRy4nKkjzoDryvQXw
提取码:fcoe

本文接着上一篇kafka和flink的入门到精通 1 大数据时代,分布式数据存储,数仓_水w的博客-CSDN博客

目录

一、系统架构

(1)数据来源:

(2)采集数据:

(3)数据存储:

(4)数据计算和展示:

 二、实时数仓架构

 ◼  架构模式:Lambda

讲解流程

三、Kafka

 ◼  Kafka安装以及使用

 ◼  消息队列

➢ 消息系统传输数据的方式:

JMS:Java Message,和平台无关的一个消息服务接口。

➢ 消息队列产品的特性:

➢ 主流的消息系统

 ◼  组件:Broker

 ◼  组件:Topic

 ◼  组件:Partition

 ◼  组件:Replica

 ◼  组件:Log

 ◼  组件:通信RPC


一、系统架构

(1)数据来源:

  • 业务数据比如说下单,注册用户等等;
  • 用户行为数据比如点个按钮,图片,链接等,发出请求。对特定的用户数据做出特定的操作,事先在前端准备埋点操作(在事件中添加标记)。

(2)采集数据:

  • 业务数据通过SpringBoot采集到数据库mysql中;
  • 用户行为通过SpringBoot数据采集到log日志文件;

(3)数据存储:

  • Hadoop大数据基础框架:离线数据操作,一般以小时和天为单位;
  • Kafka集群:实时数据分析,一般是消息队列;
    • 它里面其实也可以做暂时的存储,

(4)数据计算和展示:

  • 离线数据操作:
    • 可以将Hive理解为数仓,Hive将数据和计算进行统计分析进行分层放在不同的层次表当中;
    • 想要将数据展示处理,需要把数据放在mysql中, 使用echarts图表展示;
  • 实时数据操作:
    • flink对Kafka推送过来的数据进行计算;
    • 计算以后将结果存储到HBase(海里数据存储的库)当中, 使用echarts图表展示;

 二、实时数仓架构

为什么要讲实时数仓呢?因为我们现在的很多企业,离线数仓都已经搭建完毕了, 包括京东,百度,贝壳,快手。因为数据量太大了,传统的数据库已经装不下了。因此放到数据仓库中分层保存,建立不同的模型。

但是计算延时太长了,那么怎么能够快速得到结果?

大家更注重实时计算,所以现在的大厂都在尝试搭建实时数。


 ◼  架构模式:Lambda

(1)采集数据

又提到离散数据分析,是因为在早期的时候技术不成熟,实时数据分析不够准确,为了保证数据的准确性,所以有的时候需要用离散数据做一些计算,然后将我们的计算结果变成最新的数据。所以在这种情况下,两套环境是需要同时运行的。

  • 实时数据操作:用flink技术来实现数据层次的变换
    • ODS层:Kafka也可以做暂时的存储;
    • DWD层:Kafka,做一些简单的数据清洗,比如数据脱敏;
    • DWS层:Kafka;
  • 离线数据操作:
    • ODS层:Hive;
    • DWD层:Hive;
    • DWS层:Hive;

(2)数据统计和展示

  • 将Kafka的数据推送到mysql数据库中,推送给BI报表,变成图表展示;
  • 用户标签用来做查询使用,
  • Redis和HBase一般用来提供服务,用户服务接口;

 为了用这两套程序,我们就得找两批人,一批会使用flink实时数据分析,另一批会使用spark数据分析。你会发现做的东西差不多,但是两批人成本较高。

后来,flink可以哦用来代替spark,这样就很好了,因为不需要两批人了。

讲解流程:

三、Kafka

 ◼  Kafka安装以及使用

 ◼  消息队列

消息队列:一个系统向消息系统发送数据,另外一个系统向消息系统获取数据。

一个标准的消息系统中,分为三大组成部分:

  • 生产者
  • 消息队列系统
  • 消费者


1.消息系统,我们为什么需要?

在一个系统中,完成所有的功能不太现实。因为我们大量的请求会集中在同一台机器上,会导致当前的负载超过最大处能力,出现过载情况。

过载的出现就会导致部分的服务不可用。那么如果处置不当,就可能导致我们的服务出现雪崩。而且一个系统拆分成多个系统之后,就会导致其他的系统也出现问题。这种情况下我们并不会拿一个系统来实现所有的功能,会进行拆分。

比如, A系统的数据会给到B和C系统,是我们比较常见的。

缺陷:

  1. A系统的数据给到B和C时就会互相等待,而导致延时。可是B和C无关,那么为什么要等呢?不应该等待。------->消息传递应该是异步的,提升系统的总体性能
  2. A系统直接和C打交道不太好,耦合性太强(太紧密),扩展性很差。------>解耦合
  3. 如果A有大量数据传输,B和C不能及时消费,则会导致流量震荡,甚至导致全链路的服务雪崩。------->消封填谷,缓冲上下游瞬时突发流量,让其更加的平滑

改进:

2.消息系统怎么传输和接受数据?

➢ 消息系统传输数据的方式:

JMS:Java Message,和平台无关的一个消息服务接口。

要求:

  • 消息方式必须是异步的;
  • 消息保证传送只会一次;
  • 定义了消息处理模型;
    • 点对点:只能一次,不能重复消费消息
    • 发布、订阅:同一条消息可能被多个用户消费

➢ 消息队列产品的特性:

  • 必须是开源的,比较流行
  • 确保不丢消息
  • 支持集群,保证服务可用
  • 性能:足够好,应该能够满足绝大场所的性能要求

➢ 主流的消息系统

(1)RabbitMQ:

  • 缺点:
    • 对积压消息处理的不够好;
    • 如果有大量的消息积压,那么性能会下降;
  • 优点:轻量级,使用方便

(2)RocketMQ:

  • 缺点:
    • 国产的消息队列,在国际上不流行,导致与很多软件和生态系统不兼容。继承和兼容不够好;

(3)Kafka:

  • 优点:
    • 与周边其他开源软件都会优先兼容它, 兼容性是最好的;
    • 大量使用批量和异步进行消息处理,具有超高的性能;

(4)Pulsar:新兴的,开源,兼容Kafka

3.为什么选择Kafka?

首先因为与周边其他开源软件都会优先兼容它, 兼容性是最好的。其次

  • 处理消息快:每秒钟处理几十万甚至上百万条消息。
  • 高并发:同等配置的机器下,可以拥有更多生产者和消费者,那么生产数据和消费数据的能力就会更强。
  • 磁盘锁:锁住磁盘IO的场景非常少,因此等待时间短。

 ◼  组件:Broker

Kafka中提供消息读写服务的节点,称之为Broker

分布式环境,多台机器形成集群,同时提供服务。

  • Broker应该是分布式部署,而且相互独立;
  • 每一个Broker节点应该在集群中具有唯一性标识,不能重复;

4.分布式集群的经典架构---主从,那么多个Broker应该如何管理?

Kafka使用的是zookeeper,严重依赖zookeeper。因此要先启动zookeeper,再启动Kafka。

xcall jps  查看当前虚拟机里的进程

 可以看到“[0,1,2]”,说明每一个Broker节点在集群中具有唯一性标识,不重复。

 ◼  组件:Topic

Topic:承载消息逻辑的容器。在实际的使用中,用来区分不同的具体业务数据。是Kafka消息队列的标识,也可以认为消息队列的ID。

意味着会存储很多消息。 Topic可以是多个,

可以看到,当前只有一个名为test的Topic。

 ◼  组件:Partition

服务过载:大量请求集中到一个节点时,就会导致服务过载,雪崩。

为了负载均衡,把一个队列拆成多个队列,把拆分后的队列放在不同的服务节点中--->拷贝。等同于把一份完整的数据拆成多份。

Partition:把一个队列拆成多个队列(称之为:分区),让数据可以均匀分配,达到负载均衡。

而且因为数据是放在不同节点的,所以可以适应任意大小的数据。当发现不够的时候,可以添加Topic,因此Topic可以是任意大小,扩容起来是非常方便的。

可以看到,这里的“[0]”表示只有一个分区,分区号是0。

 ◼  组件:Replica

5.所有分区的数据合在一起是完整的数据,如果某一个节点宕掉了,那么该服务肯定不可用了(黑色)。怎么办?

 如果某一个节点宕掉了,就会导致该节点的数据不可用。所以为了保证数据的高可靠,不丢失数据,它提供了副本机制

Replica:为了保证数据的高可靠性,为每个分区提供了多个副本机制多个副本直接形成了主从。

其中一个称之为leader(主)副本,其他副本统称为fllower(从)副本

  • LP:leader(主)副本
  • FP:fllower(从)副本

图中有两个副本,leader(主)副本和fllower(从)副本。但是这样画是不合理的,我们应该把它们分开在不同的节点中。 多个副本应该放置在不同的节点上。

 6.那么到底在三台机器上,有多少副本是合适的呢?最多有多少?

副本的数量应该不超过节点的数量,因为没有意义。

leader(主)副本主要用于读写请求;

fllower(从)副本:主要用于备份,不参与读写;数据都来自于leader。

7.那么我们选择哪一个当作leader?选择哪一个当作fllower?

leader和fllower,主要是争抢资源,抢到了就是leader。

 可以看到,leader是2号,说明2号抢到了资源。

 ◼  组件:Log

每个分区可以认为是一个无限长度的数组队列,新的数据可以追加到这个数组中,数据在分区中的位置(称之为:偏移量)。

那么一个分区的数据都放在一起,内存无法放置太多,所以肯定要写入磁盘。磁盘IO会极大影响写入速度,为了性能考虑,磁盘文件不能随机访问。所以需要顺序写入数据

如果所有的数据都写入一个文件,也不行。如果想要能够快速消费消息,我们需要将文件拆分(称之为:Seqment),默认情况下是1GB。

为了能够快速访问文件中的数据,kafka还会生成索引文件

8.文件存哪里了?

 查看文件的存放路径,

 

 后缀为.index就是索引文件,后缀为.log的就是日志文件。日志文件的命名是针对于整个分区来讲数据的偏移量是多少。

查看log日志文件里的内容,

  其中,“payload”就是数据本身。

 查看索引文件里的内容,

 其中,“offest”是数据的偏移量,“position”是数据的物理偏移量。

 ◼  组件:通信RPC

首先,我们要搞清楚,Java的进程是什么?JVM?执行java的一个应用程序(Java Test),会启动一个java虚拟机,也即是说会启动一个进程,名字叫Test。

其次,scala语言是基于java语言的,很多语法类似。所有Test一定存在main方法(是可以直接执行的)。

main方法里有“buildServer(serverProps)”构建了一个服务器,其中包括依赖zookeeper以及Broker。

  1. 服务器构建好之后,就会启动服务器;
  2. SocketServer服务器启动好之后,就可以开始提供服务了,接受到的请求放到requestChannel.sendRequest(req),放到了一个队列当中;
  3. 然后从requestChannel.sendRequest()中取出请求;
  4. 通过KafkaApis.Handle(req) API接口进行处理:判断当前请求时哪种方式,进行不同的方法处理;

  • 2
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 3
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

水w

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值