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接口进行处理：判断当前请求时哪种方式，进行不同的方法处理；