导引
- 大数据开发之路-概述
- flume-高度定制化的日志采集传输系统
- sqoop-rdbms和hadoop之间的数据同步工具
- datax-多种异构数据源间的高效数据同步工具
- canal-基于MySQL binlog的增量同步工具
- hdfs-大数据生态系统的存储基石
- hbase-基于hdfs的支持实时随机读写的列式数据库
- kudu-介于hdfs和hbase之间的“锋卫摇摆人”
- kafka-出色的分布式高性能发布/订阅消息队列系统
- hive-基于Hadoop的数据仓库工具
- spark streaming-分布式流式计算引擎
- 离线任务优化-数据开发的看家本领
- 实时任务优化-数据开发的看家本领
- presto-基于MPP架构的分布式SQL交互式查询引擎
- clickhouse-OLAP分析数据库的异域猛禽
- doris-OLAP分析数据库的国产之光
- kylin-MOLAP引擎的“扛把子”
- mongodb-最接近“mysql”的nosql数据库
- yarn-大数据生态体系的资源管理系统
- ranger-大数据生态体系的统一权限控制系统
- cap原则-分布式系统设计的指导思想
- 行存和列存-大数据存取的选择
- 存算分离-让大数据获得真正的弹性
- 离线数仓-大数据系统的重量级应用
- 实时数仓-实时性需求催生的数仓架构
- 流批一体-实时数仓架构的百家争鸣
- olap-基于数仓的多维实时分析系统
- 数据湖-数据宇宙的未来架构（科普篇）
kafka-出色的分布式高性能发布/订阅消息队列系统
kafka的slogan虽然是A distributed streaming platform，即定位为一个分布式流式处理平台，但是为人所熟知的角色是作为消息队列。kafka的主要应用场景是：日志收集系统和消息系统。
优秀特性
- 系统解耦。生产端的服务和消息端的服务在遵守同样的接口约束条件下，可以独立扩展和修改，而互不影响
- 流量削峰。面对突发大流量，也即生产端生产速度比消费端的消费速度快的时候，消费端服务不会因为超负荷的请求而完全崩溃
- 可扩展性。因为生产者与消费者已经隔离解耦，所以一旦想增加生产端或消费端的处理逻辑，或者服务实例等都变得十分容易
- 高吞吐量。以时间复杂度为 O(1) 的方式提供消息持久化能力，即使对 TB 级以上数据也能保证常数时间复杂度的访问性能。即使在非常廉价的商用机器上也能做到单机支持每秒 100K 条以上消息的传输
- 数据冗余存储。Kafka支持多副本冗余存储机制，保障不正常宕机之后数据不丢失
- 消息顺序性。Kafka分布式的单位是partition，Kafka保证同一个partition中的消息的有序性。一个topic多个partition时，则不能保证Topic级别的消息有序性
- 回溯消费。指的是Kafka重新设置消息位移offset。kafka支持两种方式回溯。一种是基于消息偏移量回溯，一种是基于时间点的消息回溯
架构
- Broker：服务代理节点。可以简单理解为一个服务实例。多个Broker组成的就是一个Kafka集群
- Producer：生产者。就是生产、发送消息的一方
- Consumer：消费者。就是消费、接收在Kafka上的消息，进而做相应业务处理的一方。多个Consumer可组成一个Consumer Group，叫消费组
- ConsumerGroup：每个consumer属于一个特定的consumer group，可为每个consumer指定group name，若不指定，则属于默认的group，一条消息可以发送到不同的consumer group，但一个consumer group中只能有一个consumer能消费这条消息。
- Topic：每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。
- Partition：topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。
- Leader：每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。
- Follower：Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。
- Offset：消费者消费的位置信息，监控数据消费到什么位置，当消费者挂掉再重新恢复的时候，可以从消费位置继续消费。
- Offset 的维护：由于 Consumer 在消费过程中可能会出现断电宕机等故障，Consumer 恢复后，需要从故障前的位置继续消费。所以 Consumer 需要实时记录自己消费到了哪个 Offset，以便故障恢复后继续消费。Kafka 0.9 版本之前，Consumer 默认将 Offset 保存在 Zookeeper 中，从 0.9 版本开始，Consumer 默认将 Offset 保存在 Kafka 一个内置的 Topic 中，该 Topic 为 __consumer_offsets。
- Zookeeper：是Kafka用来负责集群元数据的管理、动态集群扩展、控制器的选举等操作引入的服务。（注：不过Kafka正在弱化zookeeper的作用）
可靠性保证
- ACK 应答机制
- 0：Producer 不等待 Broker 的 ACK，这提供了最低延迟，Broker 一收到数据还没有写入磁盘就已经返回，当 Broker 故障时有可能丢失数据。
- 1：Producer 等待 Broker 的 ACK，Partition 的 Leader 落盘成功后返回 ACK，如果在 Follower 同步成功之前 Leader 故障，那么将会丢失数据。
- -1（all）：Producer 等待 Broker 的 ACK，Partition 的 Leader 和 Follower 全部落盘成功后才返回 ACK。但是在 Broker 发送 ACK 时，Leader 发生故障，则会造成数据重复。
- 故障恢复
- LEO：每个副本最大的 Offset。
- HW：消费者能见到的最大的 Offset，ISR 队列中最小的 LEO。
- Follower 故障：Follower 发生故障后会被临时踢出 ISR 集合，待该 Follower 恢复后，Follower 会 读取本地磁盘记录的上次的 HW，并将 log 文件高于 HW 的部分截取掉，从 HW 开始向 Leader 进行同步数据操作。等该 Follower 的 LEO 大于等于该 Partition 的 HW，即 Follower 追上 Leader 后，就可以重新加入 ISR 了。
- Leader 故障：Leader 发生故障后，会从 ISR 中选出一个新的 Leader，之后，为保证多个副本之间的数据一致性，其余的 Follower 会先将各自的 log 文件高于 HW 的部分截掉，然后从新的 Leader 同步数据。
- Exactly Once
- At Most Once：将服务器 ACK 级别设置为 0，可以保证生产者每条消息只会被发送一次
- At Least Once：将服务器的 ACK 级别设置为 -1，可以保证 Producer 到 Server 之间不会丢失数据
- Exactly Once：At Least Once + 幂等性。要启用幂等性，只需要将 Producer 的参数中 enable.idompotence 设置为 true 即可。开启幂等性的 Producer 在初始化时会被分配一个 PID，发往同一 Partition 的消息会附带 Sequence Number。而 Borker 端会对 <PID,Partition,SeqNumber> 做缓存，当具有相同主键的消息提交时，Broker 只会持久化一条。但是 PID 重启后就会变化，同时不同的 Partition 也具有不同主键，所以幂等性无法保证跨分区会话的 Exactly Once。
分区分配策略
Kafka 有两种分配策略，一个是 RoundRobin，一个是 Range，默认为Range，当消费者组内消费者发生变化时，会触发分区分配策略（方法重新分配）。
- RoundRobin 轮询方式将分区所有作为一个整体进行 Hash 排序，消费者组内分配分区个数最大差别为 1，是按照组来分的，可以解决多个消费者消费数据不均衡的问题。
- Range 方式是按照主题来分的，不会产生轮询方式的消费混乱问题。当消费者组内订阅的主题越多，分区分配可能越不均衡。
缺点
实际使用中，kafka也有一些不方便的地方，如:
- 无法自动均衡数据
由于数据量的增加或集群扩容等原因，集群很容易出现数据不均衡的问题，需要手工指定将哪个分区的数据搬迁到哪个broker，比较繁琐。如果数据量大的话，搬迁过程会非常慢而且严重影响机器性能。针对这个问题pulsar进行了比较好的解决，将分区抽象成一个逻辑概念，而不再是物理上对应具体的目录，分区对应的文件存储在分布式文件系统中，能够自动均衡，分区的迁移变成一个很简单迅速的操作。 - 同步落后的follower，被踢出isr后，并不会自动恢复
- 当集群中有节点挂掉，重新选举leader的过程是明显有感知的，甚至导致应用失败
