大数据必知必会系列_开源组件总结（2）：数据存储层

采集数据之后，一般先存储再计算。对于离线系统通常先存于消息队列中，再存入文件系统，而对于实时系统，一般存放在消息中间件（如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等兼容。如果是湖仓一体则考虑多种组件联合使用。