Google BigTable架构详解

什么是BigTable?

Bigtable是Google开发的一个高性能、可扩展的分布式存储系统，用于管理大规模的结构化数据。其架构设计充分考虑了数据的可扩展性、可靠性和高效性。以下是Bigtable架构的详细说明：

架构图

一、整体架构

Bigtable的整体架构由三个核心组件构成：客户端库（Client Library）、主服务器（Master Server）和多个子表服务器（Tablet Server）。此外，它还依赖于Google File System（GFS）作为底层存储系统，以及Chubby作为分布式锁和目录服务。

1. 客户端库：

   • 提供了用户与Bigtable系统进行交互的接口。
   • 负责将用户的请求转化为系统可以理解的操作，并将结果返回给用户。
   • 处理一些基本的错误检查和重试逻辑，以提高系统的健壮性。

2. 主服务器：

   • 整个Bigtable系统的核心，负责管理所有的子表服务器。
   • 维护数据的一致性，并处理客户端的请求。
   • 负责数据的负载均衡和故障恢复，确保整个系统的稳定性和可用性。

3. 子表服务器：

   • 实际存储数据的组件，每个子表服务器都负责管理一部分数据。
   • 这些数据被划分成多个子表（Tablet），每个子表都是一个连续的、不可变的、持久化的、有序的数据集合。
   • 负责处理针对其所管理数据的读写请求，并与主服务器协同工作，以确保数据的一致性和完整性。

二、数据存储与索引

Bigtable的数据模型是一个稀疏的、分布式的、持久化的多维有序映射表。这个映射表的索引由行键（Row Key）、列键（Column Key）和时间戳（Timestamp）三个维度构成。数据以单元格（Cell）的形式存储，每个单元格都可以通过这三个维度的组合来唯一确定。

存储模型

如图所示，所有客户端请求都是先经过前端服务器，然后再发送到 Bigtable 节点。（在原始语言中 这些节点称为“片服务器”）。通过 这些节点被整理成一个 Bigtable 集群，而 Bigtable 实例，即集群的容器。

Bigtable 表被分成多个连续的行块（称为片），旨在帮助平衡查询工作负载。（片类似于 HBase 区域。）片以 SSTable 格式存储在 Google 的文件系统 Colossus 上。SSTable 提供了一种持久、有序且不可变的键值对映射，其中键和值都可以是任意的字节字符串。每块平板电脑 与特定的 Bigtable 节点相关联。除了 SSTable 文件后，所有写入内容都会在写入后立即存储在 Colossus 的共享日志中 获得 Bigtable 确认，因而提高了耐用性。
重要的是，数据永远不会存储到 Bigtable 节点本身；每个节点都有指向 Colossus 中所存储的一组片的指针。因此：

• 由于 不会复制实际数据Bigtable 会更新 每个节点的指针
• 您可以快速从 Bigtable 节点故障中进行恢复，因为 只有元数据必须迁移到替换节点。
• 当 Bigtable 节点发生故障时，任何数据都不会丢失。

1. 行键：

   • 可以是任意的字节串，这为用户提供了极大的灵活性。
   • 数据按照行键进行排序存储，以支持高效的扫描操作。

2. 列键：

   • 用于区分同一行中的不同数据字段。
   • 列键被组织成列族（Column Family），每个列族可以包含多个列。

3. 时间戳：

   • 用于记录数据的版本信息，支持数据的多版本并发控制。
   • 时间戳可以由Bigtable自动赋值，也可以由客户端显式指定。

三、数据拆分与存储

为了实现集群的可扩展性，Bigtable以行键范围对数据拆分片存储，每个分片叫Tablet。每个Tablet是相同行键前缀的数据集合。Tablet服务器负责处理至少一个或多个Tablet分片，并将数据持久化到GFS中。

1. Tablet的分配与管理：

   • 主服务器负责给Tablet分配Tablet服务器，并管理Tablet服务器的状态等集群状态相关的工作。

2. 数据的持久化：

   • Tablet服务器使用GFS作为底层存储系统，将数据以LSM（Log-Structured Merge-tree）方式存储。
   • 每个Tablet服务器使用一个WAL（Write-Ahead Logging）日志文件，用来记录接收的所管理分片的数据写入；然后将数据插入到内存中；当内存中数据达到上限，就会写入到对应的Tablet分片的新sst文件中。

四、元数据管理

Bigtable的元数据也是按Tablet方式分片、分级存储的。在Chubby中只记录顶级元数据的Tablet位置或文件名，然后通过级联二级元数据的Tablet，最终可以定位到用户数据的Tablet。每个Tablet服务器维护一个或多个Tablet分片，并处理后台sst的合并等操作。

五、读写流程

1. 写流程：

   • 客户端通过客户端库发送写请求到主服务器。
   • 主服务器将写请求转发到相应的Tablet服务器。
   • Tablet服务器将数据写入到内存中的MemTable，并同时写入到WAL日志文件中以保证数据的持久性。
   • 当MemTable达到一定大小时，会被冻结并生成一个新的SSTable文件，然后写入到GFS中。

2. 读流程：

   • 客户端通过客户端库发送读请求到主服务器。
   • 主服务器将读请求转发到相应的Tablet服务器。
   • Tablet服务器首先在内存中查找数据，如果找不到则去SSTable文件中查找。
   • 如果SSTable文件中也没有找到数据，则返回查找失败的结果给客户端。

综上所述，Bigtable的架构设计充分考虑了数据的可扩展性、可靠性和高效性。通过分布式架构、面向列的数据模型、稀疏性设计以及元数据管理等机制，Bigtable能够高效地处理大规模数据集，满足各种复杂的应用需求。

其他内容概览

负载平衡

每个 Bigtable 区域都是由一个主实例进程管理，该进程可使集群内的工作负载和数据量达到平衡。此过程会拆分成较繁忙或更大的区域 将不常用的平板电脑/较小的平板电脑合并在一起， 根据需要在节点之间重新分配它们。如果某个片遇到流量高峰，Bigtable 会先将该片拆分成两部分，然后再将其中一个新片移至另一个节点。Bigtable 可自动管理拆分、合并和再平衡操作，从而节省了手动管理片的工作量。了解性能部分详细介绍了此过程。

为了使 Bigtable 达到最佳写入性能，请尽可能均匀地在各节点间分配写入操作，这一点非常重要。实现这一目标的方法之一 目标是使用不遵循可预测顺序的行键。例如，用户名在整个字母表中的分布往往是大致均匀的，因此将用户名包含在行键的开头位置通常会使写入操作得到均匀分布。

同时，对相关行进行分组以使它们彼此相邻也很有用，这可让您更高效地同时读取多个行。例如，如果您要存储一段时间内不同类型的天气数据，您可以在行键中依次添加收集了这些数据的位置和时间戳（例如 WashingtonDC#201803061617）。这种类型的行键会将来自一个位置的所有数据组织成连续范围的行。对于其他位置，所属的行将以不同的标识符开头；如果有多个位置都在以相同速率收集数据，那么写入操作仍然会均匀分布到各片之中。

其他存储和数据库选项

Bigtable 不是关系型数据库，不支持 SQL 查询、联接或多行事务。

• 需要对联机事务处理 (OLTP) 的全面 SQL 支持 系统请考虑使用 Spanner 或 Cloud SQL。
• 如果您需要在一个在线分析处理 (OLAP) 系统中进行互动式查询，请考虑使用 BigQuery。
• 如果您必须在文档数据库中存储高度结构化的对象， 支持 ACID 事务和类似 SQL 的查询，请考虑 Firestore。
• 如需低延迟的内存中数据存储，请考虑使用 Memorystore。
• 要实时同步用户之间的数据，可考虑使用 Firebase Realtime 数据库。