数据存储层
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) 应用的批量分析，包括训练机器学习模型。
无限的写入和读取扩缩能力
Bigtable 将计算资源与数据存储空间分离，因而可以透明地调整处理资源。每个增加的节点都能够以同样的质量处理读取和写入操作，从而轻松实现横向扩缩。Bigtable 通过自动扩缩资源来适应服务器流量、处理分片、复制和查询处理，从而优化性能。
灵活的数据模型
Bigtable 让您的数据模型自然发展。可存储标量、JSON、协议缓冲区、Avro、Arrow、嵌入、图片等各种对象，并根据需要动态地添加或移除新列。在单个数据库中基于原始的非结构化数据提供低延迟传送或高性能的批量分析。
从单个可用区快速扩容至 8 个区域
无论您的用户在哪里，由 Bigtable 支持的应用都可通过全球分布的多主配置实现低延迟读写。可用区级实例有助于节省费用，并且可以通过自动复制功能无缝扩容为多区域部署。运行多区域实例时，您的数据库可以防范单区域故障，并提供业界领先的 99.999% 可用性。
从 NoSQL 数据库轻松迁移
实时迁移可减少工作量并确保准确迁移数据，帮助您更快、更轻松地完成迁移。HBase Bigtable 复制库支持使用导入和验证工具轻松地将 HBase 快照导入到 Bigtable，而 Dataflow 模板可简化从 Cassandra 到 Bigtable 的迁移。
与工作负载隔离的高性能数据处理
借助 Bigtable Data Boost，用户可以更快地运行分析查询、批处理 ETL 流程、训练机器学习模型或导出数据，而不会影响事务型工作负载。Data Boost 不需要进行容量规划或管理。它支持直接查询存储在 Google 分布式存储系统 Colossus 中的数据（使用按需容量），使用户能够轻松处理混合工作负载并放心共享数据。
丰富的应用和工具支持
使用 Apache HBase API 可轻松连接到开源生态系统。通过与 Apache Spark、Hadoop、GKE、Dataflow、Dataproc、Vertex AI Vector Search 和 BigQuery 无缝集成，可更快地构建数据驱动型应用。利用 Java、Go、Python、C#、Node.js、PHP、Ruby、C++、HBase 的 SQL 和客户端库以及与 LangChain 的集成，满足开发团队的需求。
自动维护
为任何规模的数据库降低运营成本并提高可靠性。内置自动复制和维护功能，无需停机。
实时变更数据捕获和事件
使用 Bigtable 变更数据流从 Bigtable 数据库中捕获变更数据并将其与其他系统集成，以用于分析、事件触发和合规性目的。
企业级安全和控制
支持 Cloud External Key Manager 的客户管理的加密密钥 (CMEK)、用于访问和控制的 IAM 集成、VPC-SC 支持、Access Transparency、Access Approval 以及全面的审核日志记录可帮助确保您的数据得到保护并遵守相关法规。精细的访问权限控制让您可以在表级、列级或行级授予访问权限。
可观测性
使用服务器端指标监控 Bigtable 数据库的性能。借助 Key Visualizer 交互式监控工具分析使用模式。使用查询统计信息、表统计信息和热片工具排查查询性能问题，并利用客户端监控快速诊断延迟问题。
灾难恢复
经济高效地对数据库进行即时的增量备份，并根据需要进行恢复。将备份存储在不同区域以提高弹性；针对测试和生产场景，可在实例或项目之间轻松恢复备份。
Vertex AI Vector Search 集成
使用 Bigtable to Vertex AI Vector Search 模板和 Vertex AI 将 Bigtable 数据库中的数据编入索引，以便使用 Vertex AI Vector Search 对向量嵌入执行相似度搜索。
LangChain 集成
利用内置的 kNN 最近邻向量搜索（预览版）及 LangChain 集成，轻松构建更准确、更透明且更可靠的生成式 AI 应用。
Spanner
Spanner 是 Google 开发的分布式 SQL 数据库管理和存储服务。 它提供全局事务、强一致性读取以及自动多站点复制和故障转移等功能。使用汇集了关系型、图表、键值对和搜索的单个数据库构建智能应用。Spanner 用于 Google F1、其广告业务 Google Ads 的数据库以及 Gmail 和 Google Photos。
Spanner核心特性
无限的写入和读取扩缩能力
Spanner 将计算资源与数据存储空间分离，因而可以透明地对处理资源进行横向缩容和横向扩容。每一个增加的计算容量都可以处理读取和写入操作，轻松实现横向扩缩。Spanner 通过自动处理分片、复制和事务处理来优化性能。
自动维护
为任何规模的数据库降低运营成本并提高可靠性。内置自动同步复制和维护功能。在处理流量的同时，实现 100% 的在线架构更改和维护，零停机时间。
Spanner Graph
揭示隐藏的关系和连接。Spanner Graph 支持图数据库的新国际标准 ISO 图查询语言 (GQL)，提供了一种直观而简洁的方式来匹配数据中的模式并遍历数据中的关系。它结合了 SQL 和 GQL 的优势，让您只需通过一次操作即可查询结构化和关联的数据。Spanner Graph（预览版）可与全文和向量搜索功能互操作，为您提供一类依托 AI 技术的新型应用。
向量搜索
在 Spanner 中利用精确最近邻 (KNN) 和近似最近邻 (ANN) 向量搜索（预览版同时提供这两种搜索）以几乎无限的规模搜索向量嵌入，实现高度可分区的工作负载。Spanner 内置的向量搜索支持消除了对单独的、专门的向量数据库解决方案的需求，提供了运营数据的事务保证，并在横向扩容的无服务器架构上提供最新且一致的向量搜索结果，且无需任何管理。
PostgreSQL 页面
将 Spanner 的可伸缩性和可靠性与 PostgreSQL 页面的熟悉度和可移植性相结合。利用您的团队熟悉的技能和工具，保证您的投资不会过时，您可以安心无忧。
自动数据库分片
您再也不用担心手动对数据库进行重新分片的问题。内置分片功能会自动分布数据以优化性能和可用性。纵向扩容和纵向缩容不会导致中断。
地理分区
保留单个全球数据库的可管理性，同时减少分布在全球各地的用户的延迟时间。借助 Spanner 中的地理分区功能，您可以在全球范围内对表数据进行行级分区，从而在更靠近用户的位置传送数据。尽管数据被拆分到不同的数据分区，Spanner 仍会将所有分布式数据维护为一个整合表，供查询和更改之用。
单区域、双区域和多区域配置
无论您的用户位于哪里，由 Spanner 提供支持的应用都可以在全球范围内读取和写入最新的强一致性数据，此外，在运行双区域或多区域实例时，您的数据库能够承受区域性故障，并提供业界领先的 99.999% 可用性。
事务强一致性
依靠出色的外部一致性，不牺牲可伸缩性或可用性。
工作负载隔离的高性能查询处理
Spanner Data Boost 使用户能够更快地运行分析查询、批处理作业或数据导出操作，而不会影响现有的事务型工作负载。Data Boost 完全由 Google Cloud 托管，不需要进行容量规划或管理。它始终处于热状态，可直接对存储在 Spanner 的分布式存储系统 Colossus 中的数据处理用户查询。这种独立的按需计算资源可让用户轻松处理混合工作负载并放心地共享数据。
全文搜索
利用根据 Google 搜索学习成果提供支持的高性能文本搜索功能，摆脱独立的搜索工具以及相关的提取、转换和加载 (ETL) 流水线。全文搜索提供事务上一致的搜索结果以及强大的功能，如拼音搜索和基于 NGRAMs 的拼写变体匹配。
LangChain 集成
利用 LangChain 集成，轻松构建更准确、更透明、更可靠的生成式 AI 应用。Spanner 有三个 LangChain 集成：文档加载器（用于加载和存储文档中的信息）、向量存储区（用于实现语义搜索），以及 Chat Messages Memory（用于实现可记起先前对话的链）。
Vertex AI 集成
使用 Spanner 的 ML.PREDICT SQL 函数，基于 Vertex AI 中提供的嵌入、生成式 AI 或自定义模型执行在线推理。使用 Spanner 到 Vertex AI 向量搜索工作流，通过 Vertex AI 向量搜索对 Spanner 数据执行相似度搜索。
备份和恢复、时间点恢复 (PITR)
备份数据库以存储一致的数据副本并按需恢复。PITR 提供持续数据保护，能以微秒精度恢复过去的数据。
企业级安全和控制
客户管理的加密密钥 (CMEK)、数据层加密、IAM 集成（用于访问权限和控制），以及全面的审核日志记录。支持 VPC-SC、Access Transparency 和 Access Approval。精细的访问权限控制可让您在表和列级别授予对 Spanner 数据的访问权限。
Megastore
Megastore 是一种存储系统，旨在满足当今交互式在线服务的需求。Megastore 以一种新颖的方式将 NoSQL 数据存储的可扩展性与传统 RDBMS 的便利性融为一体，同时提供强一致性保证和高可用性。我们在细粒度数据分区中提供完全可序列化的 ACID 语义。这种分区使我们能够在合理的延迟下同步复制广域网上的每次写入，并支持数据中心之间的无缝故障转移,为交互式服务提供可扩展、高可用的存储。其主要目标如下：
(1)可扩展至数百万用户;
(2)尽管互联网延迟，但对不耐烦的用户仍能做出响应;
(3)开发人员可以轻松使用;
(4)从驱动器故障到数据中心丢失以及介于两者之间的所有情况，都具有故障恢复能力;
(5)低延迟同步复制到远程站点。
资源管理与服务协调层
Brog
Borg 是 Google 自 2008 年或更早以来使用的集群管理器。它导致了类似方法的广泛使用，例如 Docker 和 Kubernetes。
Borg 是 Google 第一个专有的统一容器集群管理器。它包括一组主节点、一组从属节点、一个 CLI 和一个基于 Web 的 UI。所有服务器组件均使用 C 编写。主节点提供 API，让 CLI、UI 和其他外部系统与集群管理器进行通信。在每个从属节点中，安装了一个名为 borglet 的代理组件，用于管理容器、网络和路由。调度程序根据从属节点的资源可用性做出容器调度决策，并通过 borglet 执行这些决策。系统状态存储在 Paxos 中，Paxos 是一个分布式、高可用性的持久存储。
Borg 将数据中心中的容器作为单元集合进行管理。单元是一组以单元为单位进行管理的机器集合，平均单元大小约为 10,000 台机器 。每个单元都属于一个集群。Borg 已实现以下集群管理功能：
(1)命名和服务发现（使用 Borg 名称服务）
(2)应用程序感知负载平衡
(3)水平和垂直自动扩展
(4)用于部署软件/配置更新的推出工具
(5)用于运行具有阶段间相互依赖关系的多作业分析管道的工作流工具
(6)用于收集有关容器、聚合、显示在仪表板上和触发警报的信息的监控工具
Omega
在单片集群调度程序架构很难满足规模的扩大和对不断变化的需求的快速响应的时代。这限制了新功能的部署速度，降低了效率和利用率，并最终会限制集群的增长。当时Google提出了一种新颖的方法来满足这些需求，即使用并行性、共享状态和无锁乐观并发控制。
Google将这种方法与现有的集群调度程序设计进行了比较，评估了调度程序之间发生的干扰程度以及它在实践中的重要性，提出了一些缓解干扰的技术。这种技术采用了共享状态的架构，这样使得应用程序调度器拥有了整个集群的权限，可以自由的获取当前操作所需要的所有资源，在这个前提下其采用了基于多版本的并发控制方式（MVCC）来解决在高并发场景下所可能产生的资源冲突问题。
Chubby
Google Chubby 是一种高可用性和持久性的分布式锁服务和配置管理器，适用于大规模分布式系统。它于 2006 年首次推出，用于管理资源锁并存储整个 Google 集群环境中各种分布式服务的配置信息。从那时起，它就成为许多 Google 服务的重要组成部分，包括 Google 文件系统、Bigtable、MapReduce 和 Pregel。
Chubby 提供了一个简单可靠的接口，用于获取和释放锁、存储少量数据以及在数据或锁发生变化时注册通知。它被实现为一个复制服务，运行在不同数据中心的一组服务器上，提供容错和高可用性。Chubby 的主要设计目标是高可用性和高可靠性。
Chubby 选择一个主服务器作为主服务器。该主服务器负责处理对 Chubby 的所有请求。如果主服务器发生故障，则从可用的副本中选出一个新的主服务器，确保即使遇到服务器故障或网络分区，服务仍然可用。
默认情况下，该服务在五台计算机上作为五个活动副本运行。这种分组称为 Chubby 单元。这些副本中的一个被选为主节点，以处理客户端请求。只有主节点才能处理客户端请求；单元中的其他机器用于在主节点死机时提供容错功能。它们唯一会回答客户端的请求就是告诉他们主节点是谁。
单元中的大多数副本必须处于运行状态，服务才能正常运行。Paxos 用作领导者选举算法，用于保持副本的一致性（即确保所有更新在所有副本上都以相同的顺序进行）。通常，每个数据中心会有一个 Chubby 单元。
除了提供锁之外，Chubby 还用于管理相对少量的数据：例如系统配置和各种服务的状态信息。Chubby 为客户端提供了文件和目录的命名空间。每个文件或目录都可以被视为锁文件，当然，每个文件都可用于存储数据。锁的名称是其文件的名称：其分层路径名。 Chubby 的接口不是原生文件系统的接口。没有内核模块，客户端软件通过 API 与 Chubby 通信，该 API 向 Chubby 主服务器发送远程过程调用。
文件操作与传统文件系统提供的操作略有不同。文件只能以整体形式读取和写入：没有寻道或字节范围的读写操作。当客户端打开文件时，会下载该文件并建立该文件的租约。通过这种方式，Chubby 会跟踪哪些客户端缓存了文件的副本。客户端的所有写入都必须发送到 Chubby 主服务器（我们有一个直写缓存）。然后，Chubby 会向所有缓存了副本的客户端发送失效通知。
锁是建议性的，可以是独占的（一个写入器），也可以不是（多个读取器）。客户端可以发送请求以获取文件的锁，释放它，还可以分配和检查锁的序列号。客户端还可以订阅接收打开文件的事件。这些事件包括文件修改通知、在打开的目录下创建目录或文件以及获取锁。
Chubby 主要用于管理粗粒度锁。细粒度锁通常用于小对象，例如数据库表中的一行。它们通常被持有很短的时间，几秒或更短。粗粒度锁通常控制更大的结构，例如整个表或整个数据库。它们可能会被持有数小时或数天。与细粒度锁相比，它们很少被获取。因此，为粗粒度锁设计的服务器可以处理更多的客户端。
尽管 Chubby 使用了"粗粒度"一词，但它并不完全适合"纯"粗粒度/细粒度锁模型，但该模型在实际系统中并不一定能很好地工作。理论上，粗粒度锁的概念是授予进程对特定类的大量对象池的锁，然后让该进程成为这些对象的锁管理器。这基本上就是 Chubby 所做的，但 Chubby 不会跟踪所有对象。相反，最顶层（粗略）是一组服务，例如 Bigtable 表、GFS 文件系统或 Pregel 框架。Chubby 允许它们确保只有一个主服务器，并锁定可能在这些应用程序之间共享的任何关键资源。然后，这些应用程序处理为数据块、表单元格或同步通信屏障提供锁定的细粒度方面。
由于 Chubby 不保存大量数据，但可能为数千个客户端提供服务，因此所有 Chubby 数据都缓存在内存中。为了实现容错，所有数据都直接写入磁盘 .
计算引擎层
MapReduce
MapReduce 是一种编程模型和相关实现，用于在集群上使用并行分布式算法处理和生成大数据集。
MapReduce 程序由 map 过程和 Reduce 方法组成，map 过程执行过滤和排序（例如按名字将学生分入队列，每个名字一个队列），Reduce 方法执行汇总操作（例如计算每个队列中的学生人数，得出姓名频率）。"MapReduce 系统"（也称为"基础设施"或"框架"）通过编组分布式服务器、并行运行各种任务、管理系统各个部分之间的所有通信和数据传输以及提供冗余和容错来协调处理。
该模型是数据分析的拆分-应用-合并策略的专门化。它受到函数式编程中常用的 map 和 Reduce 函数的启发，尽管它们在 MapReduce 框架中的用途与原始形式不同。MapReduce 框架的主要贡献不是实际的 map 和 Reduce 函数（例如，它们类似于 1995 年消息传递接口标准的 Reduce 和 scatter 操作），而是由于并行化而为各种应用程序实现的可扩展性和容错性。因此，MapReduce 的单线程实现通常不会比传统（非 MapReduce）实现更快；任何收益通常只有在多处理器硬件上的多线程实现中才能看到。只有当 MapReduce 框架的优化分布式 shuffle 操作（可降低网络通信成本）和容错功能发挥作用时，使用此模型才有益。优化通信成本对于良好的 MapReduce 算法至关重要。
MapReduce 库已用多种编程语言编写，具有不同的优化级别。支持分布式 shuffle 的流行开源实现是 Apache Hadoop 的一部分。 MapReduce 这个名字最初指的是 Google 的专有技术，但后来被通用化了。到 2014 年，Google 不再使用 MapReduce 作为其主要的大数据处理模型，Apache Mahout 上的开发已转向功能更强大、更少面向磁盘的机制，这些机制结合了完整的映射和缩减功能。
Dremel
Dremel 是 Google 开发的分布式系统，用于交互式查询大型数据集。
Dremel 是 Google BigQuery 服务中使用的查询引擎。
Dremel 是 Apache Drill、Apache Impala 和 Dremio 的灵感来源，Dremio 是一个包含分布式 SQL 执行引擎的 Apache 许可平台。
Google 的 Dremel 是一个可扩展的交互式即席查询系统，用于分析只读嵌套数据。它能够在几秒钟内对数万亿行表运行聚合查询。
该系统可扩展到数千个 CPU 和数 PB 的数据，在 Google 拥有数千名用户。
大规模分析数据处理已在网络公司和各个行业中广泛使用。大规模执行交互式数据分析需要高度的并行性。
网络和科学计算中使用的数据通常是非关系型的。因此，灵活的数据模型在这些领域至关重要。
嵌套数据模型是 Google 和其他主要网络公司大多数结构化数据处理的基础。
Dremel 能够对原位嵌套数据进行操作。原位是指能够"就地"访问数据。例如，数据可以位于 GFS 或 BigTable 中。请参阅我关于 GFS 和 Bigtable 论文的帖子以了解有关这些的更多信息。
Dremel 可以对这些数据执行许多查询，这些查询通常需要一系列 MapReduce 作业，但执行时间却只是其中的一小部分。
Dremel 并非旨在取代 MapReduce，而是与之结合使用。
Dremel 自 2006 年以来一直投入生产。Google 内部部署了许多 Dremel 实例。每个实例的范围从十到数千个节点。下面列出了一些示例系统：
(1)分析抓取的 Web 文档。
(2)跟踪 Android Market 上应用程序的安装数据。
(3)Google 产品的崩溃报告。
(4)Google Books 的 OCR 结果。
(5)垃圾邮件分析。
(6)Google Maps 上的地图图块调试。
(7)托管 Bigtable 实例中的平板电脑迁移。
(8)在 Google 的分布式构建系统上运行的测试结果。
(9)数十万个磁盘的磁盘 I/O 统计信息。
(10)在 Google 数据中心运行的作业的资源监控。
(11)Google 代码库中的符号和依赖项。
Dremel 建立在网络搜索和并行 DBMS 的理念之上。 Dremel 的架构借鉴了分布式搜索引擎中使用的服务树的概念。Dremel 提供了一种高级的、类似 SQL 的语言来表达即席查询。Dremel 使用列条带存储表示，这使得它能够从二级存储中读取更少的数据，并且由于更便宜的压缩而降低了 CPU 成本。
列存储已被用于分析关系数据，但没有人将这个想法扩展到嵌套数据模型。
2020 年，Dremel 在 VLDB 2020 大会上获得了"时间考验"奖，以表彰其开创的创新。
Pregel
Pregel 最初是在 Google 于 2010 年发表的一篇论文中提出的。它是一个用于大规模图形处理的系统（数十亿个节点），并成为 Apache Giraph 的灵感来源，Facebook 内部使用它来分析他们的社交网络，Apache Spark 的 GraphX 库也提供了 Pregel 计算的 API。
Pregel 计算由一系列迭代组成，每个迭代称为一个超级步骤。
"在超级步骤期间，框架为每个顶点调用一个用户定义的函数，概念上是并行的。该函数指定单个顶点 V 和单个超级步骤 S 的行为。它可以读取超级步骤 S - 1 中发送给 V 的消息，向将在超级步骤 S + 1 中接收的其他顶点发送消息，并修改 V 及其传出边的状态。消息通常沿着传出边发送，但消息可以发送到任何已知标识符的顶点。"
顶点可以选择在给定步骤停止，将其状态从激活切换到停用。 Pregel 框架不会从下一个超级步骤开始在此顶点调用该函数，除非该顶点被消息重新激活。
由于各个顶点通过消息传递而不是共享内存进行通信，因此该函数可以在每个顶点上并行调用。
"在每个超级步骤中，顶点并行计算，每个顶点执行相同的用户定义函数，该函数表达给定算法的逻辑。顶点可以修改其状态或其传出边的状态，接收在上一个超级步骤中发送给它的消息，向其他顶点发送消息（将在下一个超级步骤中接收），甚至改变图的拓扑。边不是此模型中的一等公民，没有相关的计算。"
还支持使用消息传递而不是共享内存通信的决定，指出研究人员没有发现任何图算法中消息传递不是顶点之间通信的充分手段。
Precolator
Percolator 建立在 Bigtable 之上，支持 Google 搜索索引的增量更新。以前，他们使用 MapReduce 以批处理方式重建索引。Percolator 允许工程师以事务的形式编写计算，该事务在写入受监视的列时运行。
将计算封装为事务是一种有趣的方法，可以简化数据库更新，从而消除并行数据库进行并发更新带来的复杂性。
这些事务具有宽松的延迟要求。这允许作者进行诸如延迟锁清理之类的优化。
核心特性
ACID 事务
跨行和跨表
快照隔离
读取来自一个一致的快照，写入则在另一个快照上执行，事实上虽然快照隔离并不完美（写入偏差），但它可以实现出色的性能
MillWheel
MillWheel 是一个用于构建低延迟数据处理应用程序的框架，在 Google 中得到广泛使用。用户为各个节点指定有向计算图和应用程序代码，系统管理持久状态和连续的记录流，所有这些都在框架的容错保证范围内。本文介绍了 MillWheel 的编程模型及其实现。Google 使用的连续异常检测器案例研究有助于了解 MillWheel 的许多功能。MillWheel 的编程模型提供了逻辑时间的概念，使编写基于时间的聚合变得简单。MillWheel 从一开始就考虑到了容错和可扩展性。在实践中，我们发现 MillWheel 独特的可扩展性、容错性和多功能编程模型的组合有助于解决 Google 的各种问题。
MillWheel 是 Google 原创的通用流处理架构。
它提供低延迟、强一致性的无界无序数据处理。
MillWheel 用于解决 Google 的各种问题，因为它提供了可扩展性、容错性和多功能编程模型的独特组合。
用户为各个节点指定有向计算图和应用程序代码。 MillWheel 管理持久状态和连续的记录流。
MillWheel 的编程模型提供了逻辑时间概念，使编写基于时间的聚合变得简单。
数据分析层
FlumeJava
MapReduce 和类似系统大大简化了编写数据并行代码的任务。但是，许多现实世界的计算都需要 MapReduce 管道，而编程和管理此类管道可能很困难。
FlumeJava是一个 Java 库，可以轻松开发、测试和运行高效的数据并行管道。FlumeJava 库的核心是几个表示不可变并行集合的类，每个类都支持少量操作以并行处理它们。并行集合及其操作对不同的数据表示和执行策略提出了一种简单、高级、统一的抽象。为了使并行操作能够高效运行，FlumeJava 推迟了它们的评估，而是在内部构建执行计划数据流图。当最终需要并行操作的最终结果时，FlumeJava 首先优化执行计划，然后在适当的底层原语（例如 MapReduce）上执行优化的操作。并行数据和计算的高级抽象、延迟评估和优化以及高效的并行原语相结合，产生了一个易于使用的系统，其效率接近手动优化的管道。FlumeJava 被 Google 内部数百名管道开发人员积极使用。
FlumeJava 是一个用于构建数据管道的 Java 库。虽然编写单个 MapReduce 作业并不困难，但编写多个作业之间的粘合代码却很麻烦，而且容易出错。此外，代码不是很模块化，因为每个阶段都倾向于嵌入粘合代码（例如，读取前几个阶段的输出）。FlumeJava 允许计算模块化并与管道分离。
虽然 FlumeJava 转换为 MapReduce 步骤，而在实际应用场景中，更倾向于将 FlumeJava 转换为 MillWheel 计算。在例如 Twitter 的流式计算团队工作场景下，实际上很多 Storm 用户非常喜欢 Trident 提供的抽象。即使他们不需要精确一次处理。
Tenzing
Tenzing 是一个基于 MapReduce 构建的查询引擎，用于对 Google 数据进行临时分析。Tenzing 支持几乎完整的 SQL 实现（带有多个扩展），并结合了异构性、高性能、可扩展性、可靠性、元数据感知、低延迟、支持列式存储和结构化数据以及易于扩展等几个关键特性。Tenzing 在 Google 内部由超过 1000 多名员工使用，每天处理超1.5 PB 压缩数据的 10000 多个查询。在本文中，我们描述了 Tenzing 的架构和实现，并介绍了典型分析查询的基准。