流数据分析技术笔记4 流数据流程管理

Posted 2021-06-28 Lora青蛙

文章目录

• • 1 分布式流数据流程管理
  • 2 Kafka的高吞吐量消息机制

1 分布式流数据流程管理

分布式数据流程的管理出现已久，它涉及数据的处理和采集两种任务，其发展历程为：
-内部开发或外包开发的定制应用
-建立公共基础架构
-跳出最初针对的应用独立使用
这类系统中，最早的大概是队列系统，例如21世纪初面世的ActiveMQ。后来就出现了由Facebook这样的大型互联网公司开源出来的系统，2008年发布的Scribe工具就是这一代系统中最著名的一个。目前，由Cloudera开发的Flume以及Linkedin开发的Kafka，是当今一代的分布式数据采集系统。

在任何类型的数据采集框架中，数据交付和处理都有三个选择：
（1）最多交付一次：不需要传送全部数据，但需要有最高的性能，例如系统监控。（降频采样以获得较高性能）
（2）恰好交付一次：提供较好的安全性，例如日志计费的金融或广告系统。（Avtive MQ、Rabbit MQ等）（通过队列系统实现恰好交付一次）
（3）至少交付一次：两种极端机制间的平衡点，例如两个账户间的金融交易（自行处理去重）
一般认为，除了确保至少交付一次，消息应该怎样处理只取决于应用逻辑。

“n+1”问题

反模式——在“传统”日志处理系统中，架构基本上都是“漏斗”形态。
边缘系统数据被采集到少数几个数据（节点）中心
第一次“漏斗”处理完之后，要加入第二个数据消费者，因而还要再创建一个“漏斗”。接着，可能还要引入其他前端服务，这些服务都有自己的数据采集机制。
最终，每当加入了新的服务或处理机制，就必须与其他所有系统集成起来。

解决方法：面向服务架构（Service-Oriented Architecture，SOA）
企业服务总线（Enterprise Service Bus，ESB）是构建基于SOA解决方案时所使用基础架构的关键部分，是由中间件技术实现并支SOA的一组基础架构功能。该思想的主要内容是，对于不使用公共协议各自独立实现的服务，由总线处理它们之间的交互，并将它们之间的通信标准化。在实际情况中，总线常负责在企业内部的不同“孤岛”之间移动数据。
总线与服务之间的通讯都是标准化的，消息系统只负责物理流程

2 Kafka的高吞吐量消息机制

Kafka快在哪里：顺序写（选择磁盘顺序读写，比内存读写快且不占用内存资源，安全性更强）、直接以文件输出（不存在用户态和核心态间的转换）

Kafka拥有4个核心API：
生产者（producer）：负责选择将哪个记录分配给主题中的哪个分区，允许应用程序将记录流发布到一个或多个Kafka主题。
消费者（customer）：向Kafka broker读取消息的客户端，允许应用程序订阅一个或多个主题，并处理为其生成的记录流。
流生成器（stream processor）:允许应用程序充当流处理器，从一个或多个主题使用输入流，并将输出流生成为一个或多个输出主题，从而有效地将输入流转换为输出流。
连接器（connector）:允许构建和运行将Kafka主题连接到现有应用程序或数据系统的可重用生产者或消费者。

设计与实现——主题、分区和代理
主题（topic）是Kafka的组成要素，是一个数据物理分区，包含在主题中的所有数据都具有一定的联系。
主题可以进一步细分为许多分区（partition），分区的数量实际上限制了I/O受限的消费者从Kafka中提取数据的速度。
分区自身是分散存在于代理（broker）之中，代理是组成Kafka集群的物理进程，集群中的每个代理通常对应一个独立的物理服务器，并管理向该服务器磁盘的所有写操作。
如果要从主题中消费数据，消费者应用或者消费者组（如果应用是分布式的）会为每个分区指定一个线程或进程。随后，与Map-Reduce应用的Map阶段非常相似，这些独立的线程按自己的节奏处理所负责的分区。Kafka消费者的高层实现跟踪各线程消费情况，如果某个进程或线程发生中断，就将处理重启。

设计与实现——结构化的日志存储
Kafka基于只追加（append-only）的日志机制，这个机制类似于数据库应用的预写日志（write ahead-log）协议，它为系统中每个主题的每个分区维护单独的日志，在将消息的变更提交给日志后，才向消费者提供这条消息，这样，没有哪个消费者会消费可能在代理故障事件中丢失的消息。

设计与实现——存储空间管理
Kafka基于时间的日志保存机制，除非特别说明，这些打包成1GB文件的日志都会在保留规定的几小时之后被删除，这意味着Kafka能够使用它的整个磁盘，能够持续地接受消息，不管是否能够成功地将消息保留在非易失性存储中。存储空间管理通常是核心系统监控的内置组件，一旦发生问题，通过为每个代理（物理机）加入更多磁盘或加入更多代理和分区。

设计与实现——非队列系统
Kafka的分区无法维护消息的处理顺序与消息的接收顺序一致，即对于特定主题的分区的读写没有固定顺序，因此不保证客户端从分区中的读取顺序与写入顺序一致。另外，生产者实现中的异步性也并不少见，这就导致可能发生这样的情况：一条消息首先发送到一个分区，而由于延迟差异或者其他非确定性事件，直到后发生的另一条消息发送到其他分区，这条消息才被写入。在许多队列系统中，消息被消费之后，就会从系统中删除。Kafka则没有这种删除消息的机制，而是依靠消费者来跟踪所消费的最后一条消息的偏移量。尽管Kafka自带的高层消费者通过使用ZooKeeper管理偏移量，从而对此有所简化，但代理自身不负责消费者或其状态

设计与实现——复制
Kafka是在主题层进行复制的。主题的每个分区都有一个首席分区（leader partition），这个分区被零个或多个追随分区（follower partition）所复制，这些追随分区散布在不同物理代理中，目的是使每个追随分区都位于不同的代理中。向Kafka加入复制功能也向Kafka的生产者API引入了一些变化，具有三个不同等级的确认功能：
无确认：不会向生产者返回任何响应信息。这种情况允许数据丢失，是最不持久的，但性能最高，每秒能轻松处理数万条消息。
首席确认：首席分区收到消息之后且从ISR收到确认消息之前发送确认。这降低了性能，并且仍然可能有数据丢失，但为多数应用提供了合理水平的持久性。
全部确认：只有在首席分区提交消息之后才发送确认。这种情况下，只要ISR中至少还有一个分区，数据是不会丢失的，但性能损失最大