kafka_paper
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee
注意：以下英文来自kafka，本文主要是为学习使用，本文做出简单翻译，并进行个性化讲解，不触及任何商业使用
摘要
日志处理在以数据为驱动的互联网公司中处于一个关键的模块。kafka，是一种处理和发布大型数据、而低延时的分布式消息系统，同时也适用于传统办公、数据消费服务。kafka如何达到高效可伸缩性？kafka使用了非常规的方式来满足非常常用的场景。本文同时会使用两款同样热门的消息系统来与kafka进行对比，目前kafka每天在线上处理上百千亿兆字节的数据，这是很惊人的！
主要掌握
管理，性能，设计，实验
关键词
消息，分布式，日志处理，吞吐量，在线的
1. 介绍
这是一个充满互联网公司的信息时代，充斥着大量的日志数据。比如说简单的一些用户操作行为：点赞、登录、点击、分享、评论、查询；这些看起来简单的操作，实际上是非常有价值的数据，目前互联网公司越来越注重并将它们定位为某种产品特征，经过数据的分析，产出为更有价值的产品：例如广告、根据用户习惯推荐商品。
目前kafka就是一种非常适合支撑实时的大数据分析应用，提供了分布式和伸缩性，提供了高吞吐量，同时提供了与传统日志系统类似的API接口，实现平滑过渡。
2. 相关著作
对比传统的企业级消息系统，这些系统中处理异步的事件总线是其中最关键的角色，但他们因为具有很多冗余的功能特征，导致它们并不高效。例如：太注重于可达性保证，设计上不注重高吞吐量，不支持分布式，设计上忽视了哪些不被立即使用的数据，暴露了很多借口的细节；但是实际上，丢失一些数据是可以原谅的，为了做到数据必达而牺牲了效率实在不值得。
在linkedIn中，发现数据使用拉的方式比推的方式更加有效（更符合用户习惯）
3. kafka 架构和设计原则
每个消息流都会有迭代器接口，用于产生连续的消息流，而每一个消费者迭代消费流中的每一个消息，通过并行的方式处理达到负载均衡。这是一步接着另外一步的方式，而不像传统消息系统一样，一直轮询而永不终止。kafka中如果没有消息进行消费，那么迭代器会进行阻塞。
kafka同时提供了面对点的模式，多个消费者可以同时拷贝同一个主题下的消息在，在发布者与消费者模式下取回属于属于它的主题部分。
这里做简单的介绍：
- 主题：一串数据流的所定义的类型；由生产者来产生这些数据，并发布到主题。划分的主题概念上是对日志进行逻辑划分。
- 中介/代理：发布的消息将存储在服务代理上，由消费者从中介中订阅一个或者多个主题，并通过“拉”的方式从中介中获取数据。
因为是分布式，所以在kafka集群中，会存在多中介，负载均衡下，一个主题（逻辑）会分为多个物理划分区域，而每一个中介会存储一个或者多个这样子的物理划分区域（不知道这么强行解释对不对…)
3.1 单个分区的效率
3.1.1 简单存储
- 每一个主题的分区对应一个逻辑日志。
- 一个日志是通过同等大小的物理层次的分段文件。
- 中介会将生产者每一段消息简单的添加到最新的的分段文件上。
- 没有提供消息id，而是通过逻辑上的偏移量这可以避免维护产生的开销：映射到实际消息位置、查找随机访问缩影结构
消费者消费数据过程：
- 确认消息的偏移量，获取分区中偏移量对应的数据
- 消费者想中介/代理进行异步拉请求，为应用到数据缓冲区做好准备
- 每一个拉请求包括：偏移量、获取的字节数
- 中介提供了一个内存空间存放偏移量，提供了查询偏移量列表来定位分段的文件，并返回消费者
- 通过偏移量与字节数，消费者通过计算获取下一个拉请求
3.1.2 无状态代理
不采用传统的消息系统，kafka采用了一种消费者自己消费，自己维护消费数据。而kafka作为无状态的代理是不清楚消费者是不是消费了数据，消费了多少。kafka通过SLA，基于时间保留数据的协议规定，默认7天后就会自动删除数据。
这不仅让系统不会因为数据的增加而降低性能（因为每隔一段时间清理一次），而且有利于消费者通过旧的偏移量重新消费数据（重复消费）。
3.1.3 高效转换
kafka转换数据大小是一致的，且依赖于底层文件系统页面缓存，这有利于热缓存，避免消息代理重启后缓存消失，同时kafka不需要关心也不缓存消息在它的的进程中，也就减少了内存中垃圾回收的开销！这有利于基于VM语言的高效实现。
这里也解释了为什么拉会比推更合适，毕竟采用推的话，不可避免会出现消费者数据丢失的情况，而采用拉的模式，按照需要的来，消费者可以通过数据偏移量重复消费，就不再担心数据丢失的情况。
3.2 分布式协作
每个生产者可以通过区划键或者区划函数，使用任意分区或者一个语义上的分区来发布消息。消费者群体的概念：任意个数的消费者组成的消费群可以消费同一组订阅的主题，每个消息仅传递组内其中一个消费者，不同组内消费者不会相互影响，消费者组各自独立却完整的消费。但消费者组内的消费者可能使用不同的进程与不同的机器进行消费。
-
一个主题由尽可能小尽可能多的分区作为并行单元。只能由一个消费者来完成一个分区中的所有消费。使用尽可能多的分区（超过消费者的数量）能够达到一个更好的负载均衡的效果。
-
没有主节点，消费者之间使用分散式的协作方式。主节点的设计与添加只会添加系统的复杂度，一旦挂了就麻烦了。所以kafka为了促进节点之间的协作，采用了高可用一致性服务框架：zookeeper。zookeeper具有简单易用的API，能够创建路径、设置、读取、删除路径。并且还有几个特性：1）能够通过给路径设置观察者，获取路径的子节点发生的变化；2）路径只是短暂的被创建，这有利于当客户端挂了，zookeeper能够快速自动的删除节点，3）为了达到高可用与高可靠性，能够通过zookeeper复制数据到多个服务上。
kafka主要鉴于以下几点决定使用zookeeper：
- 能够检测代理与消费者的增加与删除
- 在检测到增加与删除时，每一个消费者会触发负载均衡
- 维护消费者之间的联系，保持每一个分区的消息偏移量的检测
当每一个代理或者消费者启动，zookeeper会储存这些注册信息，代理的注册信息包括有：域名与端口、每一组主题与分区的信息，消费者的注册信息包括有：当前消费者属于哪个消费组，哪一些主题是该消费者所订阅的。
zookeeper为代理注册、消费者注册和私有者注册所创建的路径都是短暂的。但是偏移量的注册是持久化的。对应的代理集与消费者组的改变，无论消费者还是代理失败，都会被zookeeper检测到，并自动删除对应所有分区，并通知到每一个消费者上。当消费者从分区中拉取数据，消费者会更新最新的消费者偏移量在zookeeper的偏移量注册中。
3.3 交付保证
kafka至少保证一次交付，但是也有一些情况会导致消息重复消费的情况：当消费者还没有正确关闭的时候就奔溃了，这些消息是最后一些偏移量成功提交给zookeeper的时候。所以如果应用在幂等性方面有需求，那么可以常用kafka提供的偏移量或者消费消息的唯一索引来实现去重逻辑。
kafka只能保证一个消息在同一个分区是有顺序的，但是不能保证一个消息在不同分区是有顺序的。
kafka在日志中每一个消息都存储CRC来达到避免日志损坏的效果。当IO出现错误，就会运行恢复进程来删除不一致的CRC消息，CRC还能用于网络错误的排查。
如果代理宕机、存储的消息尚未消费，存储系统永久损坏而未消费消息永久消失，kafka在未来版本会通过在多个代理实现冗余存储避免这个问题（已实现）
4. 在领英的使用场景
kafka集群的主数据分析用于联系其他数据中心，采用硬件的方式进行负载均衡，同时前端数据与日志都发布到该数据中心的代理上。另外一个数据中心用于做离线分析，其中搭配了hadoop集群与其他数据仓库设施从kafka的从节点中拉取数据，用于运行各种报告作业和数据分析。
通过实现一种特殊的Kafka输入格式，载入到hadoop集群中，以供mapReduce做数据的读处理，并进行分组与压缩。有赖于kafka的无状态代理与“拉”数据的模式，保证数据不会重复或丢失消失，在作业成功之后，数据与偏移量才会保存到文件服务器HDFS中。
在领英中，采用了Avro协议来实现序列化，在消费者与生产者之间起到了规范作用（只要满足规范就可以互相使用），对每一条消息的负载方面，都存储了schema id与序列化字节数组，通过注册中心将schema id映射到实际的schema上，消费端通过注册中心搜索id，找出后序列化数据，解码字节为对象。
5. 测试实验结果
对比kafka与activeMQ（完全服务JMS规范）、RabbitMQ，三款消息队列，
总之，kafka性能比对比的两款都要好很多。
生产端效率贼高，这里分析了两个原因：
- kafka通过异步的方式发送数据，生产者不需要等待数据是否已确认，这些优化等都促进了大吞吐量。
- kafka打破常规，没有遵守JMS（类似ActiveMQ），大大减少了冗余的消息头，也不需要维护大量的消息元数据和状态。
消费端效率贼高，这里分析了两个原因：
- 具有高效的数据存储格式，消费的数据传输过程不占过多字节。
- ActiveMQ and RabbitMQ需要维护每个消息的传递状态，而kafka基本不需要通过代理写入磁盘
当然，各有所长，activeMQ与rabbitMQ还有很多特性是优于kafka的。
6. 小结与未来
kafka是适合用于一种处理海量日志数据流的系统，采用了“拉”的消费模式，让消费者自己拉数据，并按照需要回滚数据。对其其他传统的消息队列系统，具有更高的吞吐量，同时支持分布式集成。目前LinkedIn应用kafka在离线与在线上。
同时，这里有两个展望：
- 在多个代理之间添加消息复制，提高持久性与数据可用性保证；为了权衡消息延迟与可用性，将提供异步与同步的方式的复制模型。
- 流处理功能，提供消费端集群的分布式流处理，提供有用的流工具包。
英语学习
- critical 关键的、决定性的、挑剔的
- distributed 分布式
- delivering 发布
- volumes 容量
- low latency 低延时
- latency 潜伏、延迟
- incorporates ideas 包含的思想
- aggregators 收集器
- unconventional 非常规的
- practical 实际的
- efficient and scalable 高效、可伸缩的
- superior 上级、优秀的
- gigabytes 千兆字节
- General Terms 术语
- corresponding 相对的，通信的
- operational metrics 运营指标
- utilization 使用
- call 调用
- engagement 参与度
- trends 趋势
- relevance 关联
- recommendations 推荐、受欢迎
- cooccurrence 共现
- spam 垃圾
- aggregate 集合
- orders of magnitude 数量级
- granular 颗粒的
- in addition to 除…之外
- combines 集合了，联合
- open sourced 开源
- infrastructure 基础架构
- delivery guarantees 交付保证
- specification 规范
- acknowledged 确认
- potentially 可能
- out of order 故障
- underlying 底层
- explicitly 明确的，显示的
- overkill 误伤，过度
- feasible 可行性
- partition 划分
- immediate 立即
- degrades 消耗
- significantly 显著的
- accumulate 积累
- periodic 定期的
- periodically 定期
- integrated 集成、整合、综合
- expose 暴露
- Additionally 此外
- retrieve 恢复、取、检索
- rewind 重绕
- durability 持久性
- elapsed 过去
- maintaining 维护
- auxiliary 辅助
- consecutive 连续的
- locates 定位
- optimize 优化
- corresponds 符合、通信
- retention 保留
- violates 违反
- crashes 坠毁，摔碎，奔溃
- Distributed 分布式
- Coordination 协作
- overhead 开销
- parallelism 平行、对应
- simultaneously 同时
- contrast 对比
- further 更促进一步
- facilitate 帮助
- replicates 复制
- triggering 触发
- detecting 察觉，检测
- semantically 语义
- decentralized 分散的
- consensus 一致性
- ephemeral 短暂的
- persistent 持久化的
- slightly 细微、稍微
- typically 通常的来说
- delivery 交付
- guarantee 保证
- corruption 损坏
- goes down 宕机
- frontend 前台
- geographically 地理上
- latency 延迟
- compatibility 兼容性
from: http://210.78.94.21:81/2Q2W8559BBAFFE1615F25BE98AB52F2D7C58B3456F55_unknown_6BFCB9EC5CD71312C07498F0D1DB16B4B4CB5655_4/notes.stephenholiday.com/Kafka.pdf
4586
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
