Google大数据架构技术栈

剑海风云

已于 2024-09-13 20:59:28 修改

阅读量1.5k

点赞数 24

分类专栏： Big Data 文章标签：大数据架构 Google BigData

于 2024-09-13 20:55:08 首次发布

本文链接：https://blog.csdn.net/nanxiaotao/article/details/142155453

版权

在这里插入图片描述

数据存储层

Colossus

Colossus作为Google下一代GFS（Google File System）。

GFS本身存在一些不足

单主瓶颈

GFS 依赖单个主节点进行元数据管理，随着数据量和访问请求的增长，出现了可扩展性瓶颈。想象一下，只有一位图书管理员管理着一个庞大的图书馆——最终，事情变得难以承受。

元数据可扩展性有限

主节点上的集中元数据存储无法有效扩展，影响了性能并妨碍了 PB 和 EB 级数据的管理。

实时应用程序的高延迟

GFS 针对批处理进行了优化，导致搜索和 Gmail 等实时应用程序的延迟更高。想象一下，在一个只有一名图书管理员的大型图书馆中搜索一本特定的书——这可能需要一些时间。

静态数据分布

GFS 具有预定义的数据块大小（64 MB）和复制策略，缺乏针对各种工作负载和闪存等存储选项的灵活性。想象一下，只使用一种类型的盒子来存放您的所有物品——有些东西可能不太合适。

Colossus核心组件

客户端库

客户端库为应用程序与 Colossus 交互提供了接口。可以将其视为应用程序访问和管理 Colossus 中数据的入口点。

Colossus 控制平面

Colossus 控制平面由两个组件组成，即管理员和保管人。
管理员管理元数据，并将其存储在 BigTable 中。他们就像图书管理员一样，跟踪所有文件的位置及其相关信息。客户端直接与管理员对话以进行控制操作（例如文件创建），并且可以水平扩展。
另一方面，保管人管理磁盘空间并执行垃圾收集。他们就像看门人一样，确保有效利用存储空间并删除任何不必要的数据。他们在维护数据的持久性和可用性以及整体效率方面发挥着关键作用。

元数据

BigTable 数据库存储有关文件、目录和块的元数据。想象一下，这是一个巨大的目录卡系统，用于 Colossus 中的所有文件，可以有效地跟踪它们的位置和详细信息。

构建 Colossus 的最初动机是尝试容纳与搜索相关的元数据时解决 Google 文件系统 (GFS) 的扩展限制。将文件元数据存储在 BigTable 中使 Colossus 能够比最大的 GFS 集群扩展 100 倍以上。

“D”文件服务器

这些文件服务器存储实际的文件数据。可以将它们视为存放文件实际内容的书架。

Colossus主要特性

资源分解

Colossus 可以灵活地满足实时工作负载（例如低延迟的 YouTube 视频流）的峰值需求，同时通过填补空闲时间的空白，以低成本运行批量分析工作负载。

硬件复杂性抽象

Colossus 消除了大量原本难以配置的物理硬件复杂性。为了确保每个应用程序都有所需的存储空间，Colossus 根据三个要求提供了一系列服务层：

I/O 要求

可用性要求
耐用性要求
为了处理硬件故障，Colossus 执行快速后台恢复，以提供高度耐用和可用的存储。

最大限度地提高存储效率

为了找到应用程序拥有足够存储空间而不会过度配置的最佳点，Colossus 利用了热数据（频繁访问）的概念。将热数据放在闪存上以实现较低的延迟。最终，它会均匀分布在集群的所有驱动器上。

BigTable

Bigtable 是一项完全托管的宽列和键值 NoSQL 数据库服务，适用于大型分析和运营工作负载。

BigTable核心特性

低延迟和高吞吐量

Bigtable 是一种键值对形式的宽列存储区，非常适合快速访问结构化、半结构化或非结构化数据。因此，对延迟敏感的工作负载（如个性化）非常适合 Bigtable。但是，其分布式计数器、很高的单位成本读写吞吐量效率使得它也非常适合点击流和 IoT 用例，甚至也非常适合用于高性能计算 (HPC) 应用的批量分析，包括训练机器学习模型。