采集数据之后，一般先存储再计算。对于离线系统通常先存于消息队列中，再存入文件系统，而对于实时系统，一般存放在消息中间件（如kafka)直接计算（减小时延）
1、消息中间件
消息中间件是用于在分布式系统中传递消息的中间件，它们在不同的应用程序或服务之间提供可靠的消息传递机制。
为什么要引入消息中间件？
- 数据缓冲：接收来自数据采集组件的数据，并将其暂存，以便后续的处理组件可以按需消费这些数据。
- 解耦和扩展：数据采集组件和后续的处理组件（如数据存储、数据分析、实时处理等）之间需要解耦，以提高系统的灵活性和扩展性。消息队列提供了一个解耦层，数据采集组件只需将数据发送到消息队列，而处理组件则从消息队列中消费数据。这种解耦机制使得系统更具弹性，能够更好地应对负载波动和组件故障。
- 数据流控制：数据采集组件可能会以不同的速率生成数据，而后续的处理组件可能无法以同样的速率处理数据。为了避免数据丢失或处理延迟，需要一种机制来控制数据流。消息队列可以通过其内置的流控机制来管理数据流。它可以暂存数据，直到处理组件准备好消费这些数据。此外，消息队列还支持多种消费模式（如点对点、发布-订阅），可以灵活地适应不同的处理需求。
- 数据持久化和可靠性：消息队列通常提供数据持久化和高可靠性的特性。它可以将数据持久化到磁盘，以确保在系统故障时数据不会丢失。此外，消息队列还支持多副本存储和故障恢复机制，进一步提高了数据传输的可靠性。
- 流批一体：消息队列同时支持流处理和批处理。实时处理组件可以从消息队列中消费数据流，而批处理组件可以定期从消息队列中批量消费数据。
- 数据路由和过滤：消息队列可以通过其内置的路由和过滤机制，将数据分发到不同的处理组件。例如，Kafka 的主题和分区机制可以将不同类型的数据路由到不同的消费者，从而实现数据的高效处理。
总之，消息队列提供高效、可靠的数据暂存功能。通过解耦、流控、持久化和灵活的消费模式，使数据采集和处理之间的协作更加高效和可靠。
大数据系统中用到的消息中间件：
开源组件优点缺点应用场景Kafka- 高吞吐量，单机写入 TPS 约在百万条 / 秒。
支持多个生产者和消费者。
可扩展性强，支持热扩展。
具有副本集机制，实现数据冗余，保证数据可靠性。
通过 topic 将数据进行分类，方便管理。
支持多种模式的消息。
对 CPU 和内存的消耗相对较小。
支持跨数据中心的数据复制。- 数据并非真正的实时，存在一定延迟（由于批量发送）。
对于 MQTT 协议不支持。
不支持物联网传感数据直接接入。
监控不完善，需要安装插件。
需要配合 Zookeeper 进行元数据管理。
可能会出现消息重复消费、乱序的情况（只能保证单个分区内消息有序）。- 大数据实时处理，如日志收集、监控信息收集。
流式处理，与 Spark Streaming 和 Flink 等流计算框架配合使用。
作为消息系统，解耦生产者和消费者、缓存消息等。Pulsar- 具有多租户功能，方便资源管理和访问控制。
单个实例原生支持多个集群，可跨机房在集群间无缝地完成消息复制。
具有极低的发布延迟和端到端延迟。
可无缝扩展到超过一百万个 topic。
简单的客户端 API，支持多种编程语言。
数据存储具有强一致性和高可靠性。- 处于成长期，流行度和成熟度相对没有那么高。
安全性方面相对较弱- 对消息实时性要求较高且需要多租户管理的场景，如大型企业的多部门消息通信。
金融场景中对数据可靠性和低延迟有要求的业务（如果对 Kafka 的某些特性不满意，Pulsar 可作为替代选择）。
适用于大规模的分布式消息通信场景，如跨地域的分布式系统之间的消息传递。RocketMQ- 单机吞吐量高，可达十万级。
可用性高，分布式架构。
消息可靠性强，经过参数优化配置可做到 0 丢失。
功能较为完善，支持分布式、扩展性好。
支持 10 亿级别的消息堆积，不会因堆积导致性能下降。
源码是 Java，方便进行定制和掌控。- 支持的客户端语言相对较少，目前主要是 Java 及 C++，且 C++ 不成熟。
社区活跃度一般，与周边生态系统的集成和兼容程度略逊一筹。
没有在 MQ 核心中去实现 JMS 等接口，系统迁移时可能需要修改大量代码。- 适用于电商等交易系统中的订单处理、交易、充值等场景。
大规模的消息推送、日志流式处理、binlog 分发等场景。
对消息可靠性要求高、吞吐量需求较大的业务场景，如金融领域的业务系统。RabbitMQ- 相对轻量，容易部署和使用。
支持多种消息队列协议。
具有灵活的路由配置，支持多种路由规则。
支持的编程语言众多，客户端开发语言选择广泛。
提供丰富的管理界面。
文档齐全，社区比较活跃。- 对消息堆积的处理能力较差，大量消息积压时性能急剧下降。
性能上存在瓶颈，每秒处理消息数量在几万到十几万条。
使用 Erlang 开发，学习成本高，后期二次开发难度大。- 适用于对性能要求不是特别高，但需要灵活的路由功能和丰富管理界面的场景，如企业内部的一些业务系统间的通信。
小型公司或业务量相对较小的场景下，可作为消息队列的选择。
总结Kafka: 高吞吐量、低延迟、适用于大规模数据流处理，应用最广泛，一般场景都能用。
Pulsar: 新兴的消息中间件，支持多租户、分层存储，具有高吞吐量和低延迟。
RocketMQ: 高可靠性、高可用性，适用于金融和电商等高要求场景。如双11，处理极端高并发订单。
RabbitMQ: 易于管理和配置，适用于中小规模数据量的场景。
2、文件存储组件
开源组件核心特点相对其他组件的优势缺点应用场景Hadoop Distributed File System (HDFS)分布式、大规模数据存储与处理，高容错，与 Hadoop 生态集成与 Hadoop 生态紧密结合，对大数据处理框架支持好，专为海量数据处理优化小文件存储效率低，硬件资源需求高，不适合低延迟实时访问大数据处理，如数据挖掘、机器学习中的数据存储Amazon S3 (Simple Storage Service)完全托管对象存储，高可用持久，大规模存储，与 AWS 生态集成AWS 生态强大，全球覆盖范围广，稳定性高，适合各种规模企业的云存储需求非 AWS 用户传输成本高，供应商锁定风险企业数据备份、归档，大数据分析，云原生应用存储Google Cloud Storage完全托管对象存储，高可用持久，多存储类，与 Google Cloud 集成与 Google Cloud 服务无缝对接，存储类多样可优化成本，数据处理能力强依赖 Google 云，供应商锁定，数据迁移困难数据科学项目，机器学习模型存储，企业数据存储与共享Microsoft Azure Blob Storage完全托管对象存储，多存储层，高可用持久，与 Azure 生态集成与 Azure 平台集成度高，多种存储层灵活应对不同需求依赖 Azure，供应商锁定，跨云迁移难Azure 平台应用的数据存储，企业混合云存储解决方案Ceph开源，支持多种存储类型，高可扩展高可用开源可定制，功能全面支持多种存储类型，适合自建存储系统部署管理复杂，性能受配置影响大云计算环境，大规模数据存储，对存储类型有多样化需求的场景GlusterFS开源分布式文件系统，大规模存储，高可扩展高可用开源免费，易部署管理，适合大规模数据存储的简单方案功能丰富度不如商业存储，大规模性能优化难中小规模企业数据存储，简单的大规模数据存储需求MinIO高性能对象存储，兼容 S3 API，适用于私有云和混合云兼容 S3 API 便于集成，适合私有云混合云，高性能功能单一，社区小，大规模存储需优化私有云、混合云环境下的对象存储，与 S3 兼容的应用存储IBM Cloud Object Storage完全托管对象存储，多存储类，与 IBM Cloud 集成与 IBM Cloud 生态深度融合，存储类适应不同需求依赖 IBM 云，非 IBM 用户有成本和兼容问题IBM 云平台相关的数据存储，企业级数据备份与归档Alibaba Cloud Object Storage Service (OSS)完全托管对象存储，大规模存储，与阿里云生态集成与阿里云生态集成好，适合阿里云用户的数据存储需求依赖阿里云，非阿里云用户存在问题，国际市场份额有限阿里云用户的数据存储、备份、大数据分析等
其中HDFS在过往的大数据建设中是文件存储组件最主流的选择，但在数据湖或湖仓一体场景下选择文件存储组件则需要重新考虑：
存储组件在湖仓一体 / 数据湖场景下的适用性
HDFS
- 作为数据湖底层存储，适合大规模数据批处理。
- 与 Hadoop 生态框架集成方便，利于数据处理。
S3
云原生集成，与 AWS 服务配合构建数据湖
适合多租户场景，安全功能丰富
方便数据共享协作
用于存储和管理大量非结构化数据
OSS
- 与阿里云生态集成构建湖仓一体架构。
- 支持大规模数据存储。
- 多种计费方式优化成本效益。
总之，如果只是建设数仓，选择HDFS。HDFS与 YARN、MapReduce、Hive、Spark 等无缝集成，非常适合大数据分析和处理。如果建设数据湖，则选择S3。S3具有无限可扩展、低延时访问、多层权限控制、提供不同的存储类（如标准存储、近线存储、冷线存储和归档存储），适应不同的数据访问需求和成本要求，也能和Spark、Presto、Hive等兼容。如果是湖仓一体则考虑多种组件联合使用。
版权归原作者 数据出奇迹 所有， 如有侵权，请联系我们删除。