数据API 案例 开发者 关于
掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道

Kafka 是否可以用做长期数据存储?

问题

“把 Kafka 作为长期存储有问题吗?” 这是一个非常常见的问题,我们知道,Kafka 是这样存储日志记录的

答案是“可以”,只要把数据保留时间设置为“永久”,或者开启日志压缩,数据就会被一直保存

把数据长期存储在 Kafka,这个做法并不疯狂,很多人已经在这么用,并且 Kafka 的设计中也涵盖了这种用法,下面是一些实际应用的场景

应用场景

(1)你有一个应用,使用了事件模式,并需要对变更日志进行存储,理论上可以使用很多系统来存储日志,但是 Kafka 直接解决了很多此类场景的问题,例如日志的不可变,纽约时报就使用 Kafka 来存储他们所有文章的数据

(2)在应用中有一个内存缓存,数据源于 Kafka,这时可以把 Kafka topic 中的日志压缩,应用重新启动时,从偏移量为0的位置重新读取数据到缓存

(3)需要对来自 Kafka 的流数据进行流计算,当流计算逻辑发生变化时,我们希望重新计算一遍,这时就可以把偏移量置为0,重头计算

(4)Kafka 常被用于捕获数据库的变更,关心数据变化的应用就可以从中获取变更记录,做相应的业务操作,这时出现了一个新的应用,需要全部的数据快照,如果对一个大型产品数据执行全量 dump 操作是不现实的,非常耗时,但我们可以对 Kafka 中的记录在0偏移量重新加载一遍

为什么可以?

这些长期存储的场景都是真实可行的,因为 Kafka 就是这么设计的

数据在 Kafka 中是持久化到硬盘的,有数据检查,有多副本来容错,并且持续累加的数据不会使性能变慢

实际应用案例中,已经有存储 PB 量级数据的 Kafka cluster 在运行

人们之所以对 kafka 长期存储数据的用法存在疑虑,是因为我们通常认为 kafka 是一个消息队列

使用“消息队列”时有一个原则:不要在消息队列中存储消息

因为,读消息时就要移除这个消息、消息系统的扩张能力不足、消息系统也缺少强壮的复制特性

传统消息系统不重视消息的存储,而 kafka 认为这点是非常关键的,认为消息系统的基础功能就是存储,即使一个消息很快被消费,那也是需要短暂的存储,必须要保证消费者能够接收到消息,必须提供容错存储机制

所以,kafka 的设计中有以下特点:

  1. kafka 存储可被重新读取的持久数据

  2. kafka 是一个分布式系统,以 cluster 形式运行,可以弹性的扩展和缩减,有容错复制系统,具有高可用性

  3. kafka 允许实时的数据流处理,而不是一次处理一条消息

kafka 已经不是一个传统的消息队列,而应该归类到“流处理平台”

Kafka 会成为数据库吗?

既然 kafka 这么牛,很适合长期储存,那么 kafka 会不会发展为一个数据库呢?

答案是不会,主要原因有2个:

  1. 数据库主要是关于查询的,kafka 是顺序读写机制,如果加入随机访问机制,对 kafka 没有什么好处

  2. kafka 的发展目标不在于成为第1001个数据库,而是要成为主流的流数据处理平台,成为现代数字业务中的核心系统

小结

kafka 已经不是一个简单的消息系统,kafka 在不断壮大,有 connector 可以方便的连接其他系统,有 stream api 进行流计算,最近又推出 KSQL,流处理的代码都不用我们写了,用 sql 就可以方便的进行流处理

原文来自:性能与架构

掌握聚合最新动态了解行业最新趋势
API接口,开发服务,免费咨询服务
新闻动态 > 媒体报道
Kafka 是否可以用做长期数据存储?
发布:2017-09-19

问题

“把 Kafka 作为长期存储有问题吗?” 这是一个非常常见的问题,我们知道,Kafka 是这样存储日志记录的

答案是“可以”,只要把数据保留时间设置为“永久”,或者开启日志压缩,数据就会被一直保存

把数据长期存储在 Kafka,这个做法并不疯狂,很多人已经在这么用,并且 Kafka 的设计中也涵盖了这种用法,下面是一些实际应用的场景

应用场景

(1)你有一个应用,使用了事件模式,并需要对变更日志进行存储,理论上可以使用很多系统来存储日志,但是 Kafka 直接解决了很多此类场景的问题,例如日志的不可变,纽约时报就使用 Kafka 来存储他们所有文章的数据

(2)在应用中有一个内存缓存,数据源于 Kafka,这时可以把 Kafka topic 中的日志压缩,应用重新启动时,从偏移量为0的位置重新读取数据到缓存

(3)需要对来自 Kafka 的流数据进行流计算,当流计算逻辑发生变化时,我们希望重新计算一遍,这时就可以把偏移量置为0,重头计算

(4)Kafka 常被用于捕获数据库的变更,关心数据变化的应用就可以从中获取变更记录,做相应的业务操作,这时出现了一个新的应用,需要全部的数据快照,如果对一个大型产品数据执行全量 dump 操作是不现实的,非常耗时,但我们可以对 Kafka 中的记录在0偏移量重新加载一遍

为什么可以?

这些长期存储的场景都是真实可行的,因为 Kafka 就是这么设计的

数据在 Kafka 中是持久化到硬盘的,有数据检查,有多副本来容错,并且持续累加的数据不会使性能变慢

实际应用案例中,已经有存储 PB 量级数据的 Kafka cluster 在运行

人们之所以对 kafka 长期存储数据的用法存在疑虑,是因为我们通常认为 kafka 是一个消息队列

使用“消息队列”时有一个原则:不要在消息队列中存储消息

因为,读消息时就要移除这个消息、消息系统的扩张能力不足、消息系统也缺少强壮的复制特性

传统消息系统不重视消息的存储,而 kafka 认为这点是非常关键的,认为消息系统的基础功能就是存储,即使一个消息很快被消费,那也是需要短暂的存储,必须要保证消费者能够接收到消息,必须提供容错存储机制

所以,kafka 的设计中有以下特点:

  1. kafka 存储可被重新读取的持久数据

  2. kafka 是一个分布式系统,以 cluster 形式运行,可以弹性的扩展和缩减,有容错复制系统,具有高可用性

  3. kafka 允许实时的数据流处理,而不是一次处理一条消息

kafka 已经不是一个传统的消息队列,而应该归类到“流处理平台”

Kafka 会成为数据库吗?

既然 kafka 这么牛,很适合长期储存,那么 kafka 会不会发展为一个数据库呢?

答案是不会,主要原因有2个:

  1. 数据库主要是关于查询的,kafka 是顺序读写机制,如果加入随机访问机制,对 kafka 没有什么好处

  2. kafka 的发展目标不在于成为第1001个数据库,而是要成为主流的流数据处理平台,成为现代数字业务中的核心系统

小结

kafka 已经不是一个简单的消息系统,kafka 在不断壮大,有 connector 可以方便的连接其他系统,有 stream api 进行流计算,最近又推出 KSQL,流处理的代码都不用我们写了,用 sql 就可以方便的进行流处理

原文来自:性能与架构

电话 0512-88869195
数 据 驱 动 未 来
Data Drives The Future