对于大部分互联网公司来说，数据量最大的几类数据是： 点击流数据、监控数据和日志数据。 这里面「点击流」指的是在 App、小程序和 Web 页面上的埋点数据，这些埋点数据记录用户的行为，比如你打开了哪个页面，点击了哪个按钮，在哪个商品上停留了多久等等这些。

当然你不用太担心自己的隐私问题， 记录的这些行为数据不是为了监控用户，主要目的是为了从统计上分析群体用户的行为，从而改进产品和运营 。比如，某件商品看的人很多，停留时间很长，最后下单购买的人却很少，那采销人员就要考虑是不是这件商品的定价太高了。

除了点击流数据以外，还有监控和日志数据都是大家常用的。

这类数据都是真正海量的数据，相比于订单、商品这类业务的数据，数据量要多出 2～3 个数量级。每天产生的数据量就可能会超过 TB（1 TB = 1024 GB）级别，经过一段时间累积下来，有些数据会达到 PB（1 PB = 1024 TB）级别。

这种量级的数据，在大数据技术出现之前，是没法保存和处理的，只能是通过抽样的方法来凑合着做分析。Hadoop 等大数据技术出现，才使得存储和计算海量数据成为可能。那么如果要保存像「点击流」这样的海量数据，应该选择什么样的存储系统？

使用 Kafka 存储海量原始数据

早期对于这类海量原始数据，都倾向于先计算再存储。也就是，在接收原始数据的服务中，先进行一些数据过滤、聚合等初步的计算，将数据先收敛一下，再落存储。这样可以降低存储系统的写入压力，也能节省磁盘空间。

这几年，随着存储设备越来越便宜，并且，数据的价值被不断地重新挖掘，更多的大厂都倾向于先存储再计算，直接保存海量的原始数据，再对数据进行实时或者批量计算。这种方案，除了贵以外都是优点：

但是，这种方式对保存原始数据的存储系统要求就很高了：既要有足够大的容量，能水平扩容，还要读写都足够快，跟得上数据生产的写入速度，还要给下游计算提供低延迟的读服务。什么样的存储能满足这样的要求呢？这里给出几种常用的解决方案。

第一种方案是，使用 Kafka 来存储。Kafka 不是一个消息队列么，怎么成了存储系统了？实际上，现代的消息队列，本质上就是分布式的流数据存储系统。

那么Kafka的数据是如何存储、分片、复制的？它是如何保证高可用，如何保证数据一致性的？那你会发现它和分布式存储系统，并没有什么太大的区别。唯一的区别就是，它的查询语言（生产和消费消息）和存储引擎的数据结构（Commit Log）比一般的存储系统要简单很多。但也正是因为这个原因，使得 Kafka 的读写性能远远好于其他的存储系统。 Kafka 官方给自己的定位也是「分布式流数据平台」

Kafka 提供「无限」的消息堆积能力，具有超高的吞吐量，可以满足我们保存原始数据的大部分要求 。写入点击流数据的时候，每个原始数据采集服务作为一个生产者，把数据发给 Kafka 就可以了。下游的计算任务，可以作为消费者订阅消息，也可以按照时间或者位点来读取数据。并且，Kafka 作为事实标准，和大部分大数据生态圈的开源软件都有非常好的兼容性和集成度，像 Flink、Spark 等大多计算平台都提供了直接接入 Kafka 的组件。

Kafka 也支持把数据分片，这个在 Kafka 中叫 Partition，每个分片可以分布到不同的存储节点上。写入数据的时候，可以均匀地写到这些分片上，理论上只要分片足够多，存储容量就可以是「无限」的。但是，单个分片总要落到某一个节点上，而单节点的存储容量毕竟是有限的，随着时间推移，单个分片总有写满的时候。

即使它支持扩容分片数量，也没办法像其他分布式存储系统那样，重新分配数据，把已有分片上的数据迁移一部分到新的分片上。所以扩容分片也解决不了已有分片写满的问题。而 Kafka 又不支持按照时间维度去分片，所以，受制于单节点的存储容量，Kafka 实际能存储的数据容量并不是无限的。

#Kafka 之外还有哪些解决方案？

如果需要长时间（几个月 - 几年）保存的海量数据，就不适合用 Kafka 存储。这种情况下，只能退而求其次，使用第二种方案了。

第二种方案是，使用 HDFS 来存储。使用 HDFS 存储数据也很简单，就是把原始数据写成一个一个文本文件，保存到 HDFS 中。我们需要按照时间和业务属性来组织目录结构和文件名，以便于下游计算程序来读取，比如说： ，代表 2020 年 8 月 8 日，从北京地区用户收集到的点击流数据，这个是当天的第一个文件。

对于保存海量的原始数据这个特定的场景来说，HDFS 的吞吐量是远不如 Kafka 的。按照平均到每个节点上计算，Kafka 的吞吐能力很容易达到每秒钟大几百兆，而 HDFS 只能达到百兆左右。这就意味着，要达到相同的吞吐能力，使用 HDFS 就要比使用 Kafka，多用几倍的服务器数量。

但 HDFS 也有它的优势，第一个优势就是， 它能提供真正无限的存储容量 ，如果存储空间不够了，水平扩容就可以解决。另外一个优势是， HDFS 能提供比 Kafka 更强的数据查询能力 。Kafka 只能按照时间或者位点来提取数据，而 HDFS 配合 Hive 直接就可以支持用 SQL 对数据进行查询，虽然说查询的性能比较差，但查询能力要比 Kafka 强大太多了。

以上这两种方案因为都有各自的优势和不足，在实际生产中，都有不少的应用，你可以根据业务的情况来选择。 那有没有兼顾这二者优势的方案呢？ 最好能做到，既有超高的吞吐能力，又能无限扩容，同时还能提供更好的查询能力，有这样的好事儿么？

目前已经有一些的开源项目，都致力于解决这方面的问题。

一类是分布式流数据存储，比较活跃的项目有 Pravega 和 Pulsar 的存储引擎 Apache BookKeeper。这些分布式流数据存储系统，走的是类似 Kafka 这种流存储的路线，在高吞吐量的基础上，提供真正无限的扩容能力，更好的查询能力。

还有一类是时序数据库（Time Series>