Bigtable 具体是怎样一个东西？和 MapReduce, GFS 之间的关系是什么？
Bigtable 是 Google 开源的一款分布式、高并发、NoSQL 的列族数据库。它被设计用来处理海量结构化数据，并提供极高的读写吞吐量和低延迟访问。在 Google 内部，Bigtable 被广泛应用于许多核心业务，例如网页索引、用户数据存储、时序数据分析等。
为了更详细地理解 Bigtable，我们可以从以下几个方面入手：
Bigtable 的核心概念
Bigtable 的数据模型与传统的关系型数据库截然不同，它基于一个稀疏的、分布式、持久化的多维映射表 (sparse, distributed, persistent multidimensional sorted map)。这个模型可以理解为一个巨大的表格，其中：
行键 (Row key)：
每一行都有一个唯一的行键，行键是字符串，且按字典序排序。
行键是 Bigtable 中访问数据的关键，查询通常通过行键来完成。
行键的设计对性能至关重要，一个好的行键设计能够将相关数据存储在同一个分片（tablet）中，减少跨分片查询。
例如，一个用户数据表，行键可以是用户的 ID 或一个组合字段（如 `user_id:timestamp`）。
列族 (Column Family)：
列被组织到列族中。在一个 Bigtable 表中，可以有任意数量的列族。
列族在创建表时定义，并且是物理存储上的分组。属于同一个列族的数据通常存储在一起，以提高读取效率。
列族中的列是动态的，可以随时添加，不需要预先定义。
例如，在一个用户表里，可以有一个 `personal_info` 列族（包含姓名、年龄等）和一个 `activity` 列族（包含最近活动记录）。
列限定符 (Column Qualifier)：
列限定符是列族内的具体列名。
列限定符也是字符串，但它们不必在同一个列族内预先定义。这意味着每个行可以在同一个列族下拥有不同的列。
列限定符的组合形成了一个具体的列，例如 `personal_info:name`。
时间戳 (Timestamp)：
对于同一个单元格（cell，即行键、列族、列限定符和时间戳的组合），可以存储多个版本的值。
每个版本的值都关联一个时间戳，Bigtable 会保留指定数量的最新版本，或者在指定的时间范围内保留版本。
这使得 Bigtable 非常适合存储历史数据或需要版本控制的场景。
时间戳是 Bigtable 内部自动生成的，也可以手动指定。
单元格 (Cell)：
Bigtable 的基本数据存储单元是单元格，它由行键、列族、列限定符、时间戳和一个值（Value）组成。
值本身可以是任意字节数组。
数据的组织结构可以想象成一个巨大的稀疏表格：
```
Row Key | Column Family:Column Qualifier:Timestamp | Column Family:Column Qualifier:Timestamp | ...
row1_key | cf1:col1:ts1 > value1 | cf1:col2:ts2 > value2 | ...
row2_key | cf1:col1:ts3 > value3 | cf2:colA:ts4 > value4 | ...
row3_key | cf1:col2:ts5 > value5 | | ...
```
其中，`cf1:col1` 这种组合就是列 (Column)。请注意，不同行之间可能拥有不同的列，这体现了 Bigtable 的稀疏性。
Bigtable 的内部架构
Bigtable 的设计巧妙地结合了多个 Google 的核心技术，以实现其分布式和高吞吐量的特性。其核心组件包括：
1. Master Server：
负责集群的管理，包括分配 tablet 到 chunkserver，监控 chunkserver 的状态，处理服务器故障等。
Master Server 是集群的控制中心，但它不直接参与数据的读写操作。
2. Chunkserver：
负责存储数据的实际单元，称为 tablet。
一个 tablet 是一段连续的行键范围。
Chunkserver 负责存储这些 tablet 的数据，并处理来自客户端的读写请求。
Chunkserver 的数据是以 SSTable (Sorted String Table) 的形式存储在 GFS 文件系统中的。
3. ZooKeeper：
用于协调 Master Server 和 Chunkserver。
Master Server 需要知道 Chunkserver 的状态，以及哪些 tablet 应该分配给哪个 Chunkserver。
ZooKeeper 提供了一个高可用的协调服务。
4. GFS (Google File System)：
Bigtable 的数据是持久化存储在 GFS 中的。
GFS 负责提供大文件（即 tablet 的 SSTable 文件）的存储和访问。
GFS 的容错性、高可用性和高吞吐量是 Bigtable 能够稳定运行的基础。
数据读写流程简述：
读请求：客户端首先查询 Master Server 以确定哪个 Chunkserver 存储了目标行键所在的 tablet。然后，客户端直接向对应的 Chunkserver 发送读请求。Chunkserver 读取 GFS 中的 SSTable 文件，并返回结果。
写请求：写请求首先被发送到 Master Server，Master Server 会将其重定向到负责该 tablet 的 Chunkserver。Chunkserver 在内存中维护一个写缓冲区（memtable），并将写操作记录在 GFS 的日志中（用于恢复）。当 memtable 达到一定大小时，它会被刷写到 GFS 中，生成一个新的 SSTable 文件。
Bigtable 的优势
高可扩展性：通过增加 Chunkserver，可以轻松扩展集群的处理能力和存储容量。
高吞吐量：设计支持大规模并行读写操作。
低延迟：对于单行键的访问，延迟非常低。
数据模型灵活性：列族的动态性允许存储半结构化或非结构化数据。
版本控制：自动或手动管理多版本数据，适用于时间序列数据或历史记录。
与 Google 生态系统的集成：例如与 MapReduce、GFS 的紧密集成。
Bigtable 与 MapReduce、GFS 的关系
Bigtable 的设计和出现与 MapReduce 和 GFS 是紧密相关的，它们共同构成了 Google 大数据处理的基础设施。
1. GFS (Google File System) 数据存储的基础：
作用：GFS 是一个分布式文件系统，用于存储海量数据，并提供高可用性、容错性和高吞吐量的文件访问。
与 Bigtable 的关系：Bigtable 的所有数据都存储在 GFS 上。每个 tablet 实际上是 GFS 上的一个文件（或一组文件），以 SSTable 的格式组织。GFS 提供了 Bigtable 底层数据持久化和可靠性的保证。如果没有 GFS，Bigtable 就无法存储如此大规模的数据。
2. MapReduce 数据处理的引擎：
作用：MapReduce 是一个分布式计算框架，用于并行处理海量数据。它定义了 Map 和 Reduce 两个核心操作，能够将复杂的计算任务分解成可并行执行的子任务。
与 Bigtable 的关系：
数据源和结果输出：MapReduce 作业可以从 Bigtable 中读取数据作为输入，也可以将计算结果写回到 Bigtable。Bigtable 的数据模型非常适合 MapReduce 的输入/输出格式。
数据分析和转换：Bigtable 可以作为 MapReduce 作业的后端存储，用于存储原始数据、中间结果或者最终分析结果。例如，你可以使用 MapReduce 对 Bigtable 中的数据进行 ETL（Extract, Transform, Load），或者进行复杂的统计分析。
Bigtable 的维护和管理：某些 Bigtable 的管理任务，例如数据的压缩、GC（垃圾回收）等，也可能通过 MapReduce 作业来完成。
“Google File System, Bigtable, and MapReduce” 是 Google 大数据处理三驾马车。它们协同工作，为处理 PB 级别的数据提供了强大的能力。GFS 提供底层存储，Bigtable 提供结构化数据的高并发访问，MapReduce 提供灵活的批量数据处理。
总结关系：
GFS 是 Bigtable 的存储基础设施。
Bigtable 是一个分布式数据库，它利用 GFS 进行数据存储，并提供对结构化数据的快速、高并发访问。
MapReduce 是一个计算框架，它可以从 Bigtable 读取数据进行处理，并将结果写回 Bigtable。
想象一下：
GFS 就像一个巨大的、分布式的仓库，里面存放着很多大箱子。
Bigtable 就是这个仓库中的一个特定的、经过精心组织的货架系统，每个货架上的物品（数据）都有明确的标签（行键、列族、列限定符、时间戳），并且可以被快速地找到。Bigtable 负责管理哪些货架上的哪些物品被分配给哪个仓库管理员（Chunkserver）。
MapReduce 就像是一个批量的装卸工人团队。他们会根据任务清单（MapReduce 作业），从 Bigtable 的货架上取出大量的物品（数据），进行加工（Map），然后将加工好的物品重新放回 Bigtable 的货架上（Reduce 结果）。
重要的补充说明：
Bigtable vs. HBase：HBase 是 Google Bigtable 的一个开源实现，它在 Hadoop 生态系统中扮演着类似的角色。HBase 借鉴了 Bigtable 的设计思想，并运行在 HDFS（Hadoop Distributed File System）上，与 MapReduce 框架紧密集成。许多人将 HBase 视为 Bigtable 在开源世界中的“翻版”。
Bigtable 的演进：Google 后续推出了 Cloud Bigtable 服务，这是其云平台上的托管数据库服务，在底层技术和功能上可能有所演进和增强，但核心的设计理念仍然与原始的 Bigtable 一致。
NoSQL 的定位：Bigtable 是一个典型的 NoSQL 数据库，它不遵循传统关系型数据库的 ACId（原子性、一致性、隔离性、持久性）事务模型，而是更侧重于数据可用性和分区容错性（CAP定理中的AP模型）。
通过理解 Bigtable 的数据模型、内部架构以及它与 MapReduce 和 GFS 的协同关系，我们可以更深入地认识到它在大规模数据处理领域的重要地位。
为了更详细地理解 Bigtable，我们可以从以下几个方面入手：
Bigtable 的核心概念
Bigtable 的数据模型与传统的关系型数据库截然不同，它基于一个稀疏的、分布式、持久化的多维映射表 (sparse, distributed, persistent multidimensional sorted map)。这个模型可以理解为一个巨大的表格，其中：
行键 (Row key)：
每一行都有一个唯一的行键，行键是字符串，且按字典序排序。
行键是 Bigtable 中访问数据的关键，查询通常通过行键来完成。
行键的设计对性能至关重要，一个好的行键设计能够将相关数据存储在同一个分片（tablet）中，减少跨分片查询。
例如，一个用户数据表，行键可以是用户的 ID 或一个组合字段（如 `user_id:timestamp`）。
列族 (Column Family)：
列被组织到列族中。在一个 Bigtable 表中，可以有任意数量的列族。
列族在创建表时定义，并且是物理存储上的分组。属于同一个列族的数据通常存储在一起，以提高读取效率。
列族中的列是动态的，可以随时添加，不需要预先定义。
例如，在一个用户表里，可以有一个 `personal_info` 列族（包含姓名、年龄等）和一个 `activity` 列族（包含最近活动记录）。
列限定符 (Column Qualifier)：
列限定符是列族内的具体列名。
列限定符也是字符串，但它们不必在同一个列族内预先定义。这意味着每个行可以在同一个列族下拥有不同的列。
列限定符的组合形成了一个具体的列，例如 `personal_info:name`。
时间戳 (Timestamp)：
对于同一个单元格（cell，即行键、列族、列限定符和时间戳的组合），可以存储多个版本的值。
每个版本的值都关联一个时间戳，Bigtable 会保留指定数量的最新版本，或者在指定的时间范围内保留版本。
这使得 Bigtable 非常适合存储历史数据或需要版本控制的场景。
时间戳是 Bigtable 内部自动生成的，也可以手动指定。
单元格 (Cell)：
Bigtable 的基本数据存储单元是单元格，它由行键、列族、列限定符、时间戳和一个值（Value）组成。
值本身可以是任意字节数组。
数据的组织结构可以想象成一个巨大的稀疏表格：
```
Row Key | Column Family:Column Qualifier:Timestamp | Column Family:Column Qualifier:Timestamp | ...
row1_key | cf1:col1:ts1 > value1 | cf1:col2:ts2 > value2 | ...
row2_key | cf1:col1:ts3 > value3 | cf2:colA:ts4 > value4 | ...
row3_key | cf1:col2:ts5 > value5 | | ...
```
其中，`cf1:col1` 这种组合就是列 (Column)。请注意，不同行之间可能拥有不同的列，这体现了 Bigtable 的稀疏性。
Bigtable 的内部架构
Bigtable 的设计巧妙地结合了多个 Google 的核心技术，以实现其分布式和高吞吐量的特性。其核心组件包括：
1. Master Server：
负责集群的管理，包括分配 tablet 到 chunkserver，监控 chunkserver 的状态，处理服务器故障等。
Master Server 是集群的控制中心，但它不直接参与数据的读写操作。
2. Chunkserver：
负责存储数据的实际单元，称为 tablet。
一个 tablet 是一段连续的行键范围。
Chunkserver 负责存储这些 tablet 的数据，并处理来自客户端的读写请求。
Chunkserver 的数据是以 SSTable (Sorted String Table) 的形式存储在 GFS 文件系统中的。
3. ZooKeeper：
用于协调 Master Server 和 Chunkserver。
Master Server 需要知道 Chunkserver 的状态，以及哪些 tablet 应该分配给哪个 Chunkserver。
ZooKeeper 提供了一个高可用的协调服务。
4. GFS (Google File System)：
Bigtable 的数据是持久化存储在 GFS 中的。
GFS 负责提供大文件（即 tablet 的 SSTable 文件）的存储和访问。
GFS 的容错性、高可用性和高吞吐量是 Bigtable 能够稳定运行的基础。
数据读写流程简述：
读请求：客户端首先查询 Master Server 以确定哪个 Chunkserver 存储了目标行键所在的 tablet。然后，客户端直接向对应的 Chunkserver 发送读请求。Chunkserver 读取 GFS 中的 SSTable 文件，并返回结果。
写请求：写请求首先被发送到 Master Server，Master Server 会将其重定向到负责该 tablet 的 Chunkserver。Chunkserver 在内存中维护一个写缓冲区（memtable），并将写操作记录在 GFS 的日志中（用于恢复）。当 memtable 达到一定大小时，它会被刷写到 GFS 中，生成一个新的 SSTable 文件。
Bigtable 的优势
高可扩展性：通过增加 Chunkserver，可以轻松扩展集群的处理能力和存储容量。
高吞吐量：设计支持大规模并行读写操作。
低延迟：对于单行键的访问，延迟非常低。
数据模型灵活性：列族的动态性允许存储半结构化或非结构化数据。
版本控制：自动或手动管理多版本数据，适用于时间序列数据或历史记录。
与 Google 生态系统的集成：例如与 MapReduce、GFS 的紧密集成。
Bigtable 与 MapReduce、GFS 的关系
Bigtable 的设计和出现与 MapReduce 和 GFS 是紧密相关的，它们共同构成了 Google 大数据处理的基础设施。
1. GFS (Google File System) 数据存储的基础：
作用：GFS 是一个分布式文件系统，用于存储海量数据，并提供高可用性、容错性和高吞吐量的文件访问。
与 Bigtable 的关系：Bigtable 的所有数据都存储在 GFS 上。每个 tablet 实际上是 GFS 上的一个文件（或一组文件），以 SSTable 的格式组织。GFS 提供了 Bigtable 底层数据持久化和可靠性的保证。如果没有 GFS，Bigtable 就无法存储如此大规模的数据。
2. MapReduce 数据处理的引擎：
作用：MapReduce 是一个分布式计算框架，用于并行处理海量数据。它定义了 Map 和 Reduce 两个核心操作，能够将复杂的计算任务分解成可并行执行的子任务。
与 Bigtable 的关系：
数据源和结果输出：MapReduce 作业可以从 Bigtable 中读取数据作为输入，也可以将计算结果写回到 Bigtable。Bigtable 的数据模型非常适合 MapReduce 的输入/输出格式。
数据分析和转换：Bigtable 可以作为 MapReduce 作业的后端存储，用于存储原始数据、中间结果或者最终分析结果。例如，你可以使用 MapReduce 对 Bigtable 中的数据进行 ETL（Extract, Transform, Load），或者进行复杂的统计分析。
Bigtable 的维护和管理：某些 Bigtable 的管理任务，例如数据的压缩、GC（垃圾回收）等，也可能通过 MapReduce 作业来完成。
“Google File System, Bigtable, and MapReduce” 是 Google 大数据处理三驾马车。它们协同工作，为处理 PB 级别的数据提供了强大的能力。GFS 提供底层存储，Bigtable 提供结构化数据的高并发访问，MapReduce 提供灵活的批量数据处理。
总结关系：
GFS 是 Bigtable 的存储基础设施。
Bigtable 是一个分布式数据库，它利用 GFS 进行数据存储，并提供对结构化数据的快速、高并发访问。
MapReduce 是一个计算框架，它可以从 Bigtable 读取数据进行处理，并将结果写回 Bigtable。
想象一下：
GFS 就像一个巨大的、分布式的仓库，里面存放着很多大箱子。
Bigtable 就是这个仓库中的一个特定的、经过精心组织的货架系统，每个货架上的物品（数据）都有明确的标签（行键、列族、列限定符、时间戳），并且可以被快速地找到。Bigtable 负责管理哪些货架上的哪些物品被分配给哪个仓库管理员（Chunkserver）。
MapReduce 就像是一个批量的装卸工人团队。他们会根据任务清单（MapReduce 作业），从 Bigtable 的货架上取出大量的物品（数据），进行加工（Map），然后将加工好的物品重新放回 Bigtable 的货架上（Reduce 结果）。
重要的补充说明：
Bigtable vs. HBase：HBase 是 Google Bigtable 的一个开源实现，它在 Hadoop 生态系统中扮演着类似的角色。HBase 借鉴了 Bigtable 的设计思想，并运行在 HDFS（Hadoop Distributed File System）上，与 MapReduce 框架紧密集成。许多人将 HBase 视为 Bigtable 在开源世界中的“翻版”。
Bigtable 的演进：Google 后续推出了 Cloud Bigtable 服务，这是其云平台上的托管数据库服务，在底层技术和功能上可能有所演进和增强，但核心的设计理念仍然与原始的 Bigtable 一致。
NoSQL 的定位：Bigtable 是一个典型的 NoSQL 数据库，它不遵循传统关系型数据库的 ACId（原子性、一致性、隔离性、持久性）事务模型，而是更侧重于数据可用性和分区容错性（CAP定理中的AP模型）。
通过理解 Bigtable 的数据模型、内部架构以及它与 MapReduce 和 GFS 的协同关系，我们可以更深入地认识到它在大规模数据处理领域的重要地位。
网友意见
Hadoop是很多组件的集合，主要包括但不限于MapReduce，HDFS，HBase，ZooKeeper。MapReduce模仿了Google MapReduce，HDFS模仿了Google File System，HBase模仿了Google BigTable，ZooKeeper或多或少模仿了Google Chubby（没有前3个出名），所以下文就只提MapReduce、HDFS、HBase、ZooKeeper吧。
简单来讲，
- HDFS和HBase是依靠外存（即硬盘）的分布式文件存储实现和分布式表存储实现。HDFS是一个分布式的“云存储”文件系统，它会把一个文件分块并分别保存，取用时分别再取出、合并。重要的是，这些分块通常会在3个节点（即集群内的服务器）上各有1个备份，因此即使出现少数节点的失效（如硬盘损坏、掉电等），文件也不会失效。如果说HDFS是文件级别的存储，那HBase则是表级别的存储。HBase是表模型，但比SQL数据库的表要简单的多，没有连接、聚集等功能。HBase的表是物理存储到HDFS的，比如把一个表分成4个HDFS文件并存储。由于HDFS级会做备份，所以HBase级不再备份。
- MapReduce则是一个计算模型，而不是存储模型；MapReduce通常与HDFS紧密配合。举个例子：假设你的手机通话信息保存在一个HDFS的文件callList.txt中，你想找到你与同事A的所有通话记录并排序。因为HDFS会把callLst.txt分成几块分别存，比如说5块，那么对应的Map过程就是找到这5块所在的5个节点，让它们分别找自己存的那块中关于同事A的通话记录，对应的Reduce过程就是把5个节点过滤后的通话记录合并在一块并按时间排序。MapReduce的计算模型通常把HDFS作为数据来源，很少会用到其它数据来源比如HBase。
- ZooKeeper本身是一个非常牢靠的记事本，用于记录一些概要信息。Hadoop依靠这个记事本来记录当前哪些节点正在用，哪些已掉线，哪些是备用等，以此来管理机群。
相比较而言，
- Storm本身主要是一个分布式环境下的实时数据计算模型，没有外存存储部分。Storm的应用场景是，数据来的特别快、并且要求随来随处理。比如Twitter服务器自身每秒收到来自全世界的推能达几千条，并且要求收到后还需立即索引，以供查询。这用传统的方法乃至Hadoop都是比较难的，因为外存的使用会带来较大的延迟，这时可以用Storm。Storm节点对内存中的数据进行操作，然后流出数据到下一个节点，以此来维系节点间的协作、达到高速协同处理。
- Storm有一个总的控制节点Nimbus来与ZooKeeper交流、进行集群管理。
- Storm还没有做到数据备份，这是它的不足（2013年Update: 较新的Storm已引入了类事务的概念，会有重做的操作来保证数据的处理）。
所以，Hadoop和Storm都是分布式环境下的计算平台，不过前者依赖外存，适应批处理情形，后者依赖内存，适应实时处理、超低延迟、无需大量存储数据情形。前类出现的时间较早（03年GFS的论文），后类出现的时间较晚（10年Yahoo! S4的论文）。我不大赞同“Storm改进了Hadoop的缺点”的说法——这种说法有点像“轮船改进了汽车的哪些缺点”——因为它们本身即不太同类。Storm和Hadoop有很多相似也有很多区别，适用的场景是不一样的，主要取决于使用者自己的需求。
*上面很多叙述方法是为了读者的更好理解，不尽完全准确，比如HBase是有内存缓冲机制的，并非只依赖外存，再比如Nimbus实质上是某个节点上的守护进程，而非节点本身。
最终，关于这几者各自具体是什么，我的建议是读下列论文：
- 2003 The Google file system
- 2005 MapReduce: Simplified data processing on large clusters
- 2008 TheBigtable: A distributed storage system for structured data Google file system
- 2010 S4: distributed stream computing platform
- 2011 Fast Crash Recovery in RAMCloud
和Storm的主页：
nathanmarz/storm · GitHub中wiki的Rational页。
类似的话题
-
Bigtable 是 Google 开源的一款分布式、高并发、NoSQL 的列族数据库。它被设计用来处理海量结构化数据，并提供极高的读写吞吐量和低延迟访问。在 Google 内部，Bigtable 被广泛应用于许多核心业务，例如网页索引、用户数据存储、时序数据分析等。为了更详细地理解 Bigtabl.............
本站所有内容均为互联网搜索引擎提供的公开搜索信息，本站不存储任何数据与内容，任何内容与数据均与本站无关，如有需要请联系相关搜索引擎包括但不限于百度，google,bing,sogou 等
© 2025 tinynews.org All Rights Reserved. 百科问答小站 版权所有