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系统，是我们比较常见的。
缺陷：
- A系统的数据给到B和C时就会互相等待，而导致延时。可是B和C无关，那么为什么要等呢？不应该等待。------->消息传递应该是异步的，提升系统的总体性能
- A系统直接和C打交道不太好，耦合性太强（太紧密），扩展性很差。------>解耦合
-
如果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。
- 服务器构建好之后，就会启动服务器；
- SocketServer服务器启动好之后，就可以开始提供服务了，接受到的请求放到requestChannel.sendRequest(req)，放到了一个队列当中；
- 然后从requestChannel.sendRequest()中取出请求；
- 通过KafkaApis.Handle(req) API接口进行处理：判断当前请求时哪种方式，进行不同的方法处理；
