Google发表了一篇新的论文，该论文描述了他们内部所使用的一个被称为Mesa的新型数据仓库系统。Mesa是一个规模横跨多个数据中心，并可以处理PB级数据的系统。该系统可以对查询作出亚秒级（sub-second）的响应，同时维持了ACID属性。 Mesa主要 是围绕Google的广告业务使用场景而设计的。据Google描述，随着他们的广告平台的不断发展，客户对各自的广告活动的可视化提出了更高的要求。对 于更具体和更细粒度的信息需求，直接导致了数据规模的急速增长。Google构建了Mesa从而能处理持续增长的数据量，同时它还提供了一致性和近实时查 询数据的能力。我们可以从Google的白皮书中了解到Mesa的需求：
根据Google的描述，所有Google现有的大数据技术都无一能满足所有以上的需求。BigTable无法提供原子性和强一致性。而Megastore、Spanner和F1虽然为跨地域复制的数据提供了强一致性的访问，但是他们无法支持Mesa客户端所有需要的峰值更新吞吐率。 不管怎样，Mesa在其不同的基础设施中充分利用了现有的Google技术组件。它使用了BigTable来存储所有持久化的元数据，使用了Colossus (Google的分布式文件系统)来存储数据文件。此外，Mesa还利用了MapReduce来处理连续的数据。 Mesa概念上的数据模型与传统的关系型数据库极为相似。所有的数据都存储在表中。一个表同样也可以是另一个表的物化视图。每个表拥有一个指定了其结构的模式。因为“到底有多少”是广告业务中如此普遍的一个问题，所以一个例如像“SUM”这样的聚合函数可以作为表定义的一部分来指定。在模式中同样也可以指定一个或多个该表的索引。 在Mesa 中，最有意思的一个方面是处理更新的方式。Mesa中存储的数据是多版本的，这使得当新的更新正在处理时，Mesa可以向用户提供前置状态的一致性数据。 通常，每隔几分钟，上游系统就会执行一次数据更新的批处理。独立的各个无状态的数据提交者实例，负责对跨（Mesa运行所在的）全部数据中心的更新操作进 行协调。提交者为每个更新批处理分配一个新的版本号，并基于Paxos一致算法向版本数据库发布全部与该更新关联的元数据。当一个更新满足提交的条件时，意味着一个给定的更新已经被全球范围内的大量Mesa实例进行了合并，提交者会将该次更新的版本号声明为新的提交版本号，并将该值存储在版本数据库里。查询通常都是根据提交版本号来分发的。 因为查询通常都是根据提交版本号来分发的，所以Mesa不需要在更新和查询之间进行任何的锁操作。更新都是由Mesa实例在批处理中进行异步实施的。这些属性使得Mesa获得了非常高的查询和更新吞吐率，同时也对数据一致性提供了保障。 Google 提供了数个关于Mesa的更新和查询性能的基准测试数据。一个简单的数据源，平均每秒可以读取30到60MB的压缩数据、更新3到6百万个不同的行和新增 30万个新行。在单独的一天里，Mesa执行了大约5亿次查询，返回了1.7到3.2万亿行，并且平均延迟是10毫秒，而且99%的延迟低于100毫秒。 据Google描述，Mesa中所存储的数据总量在过去的两年内扩增到了原来的五倍。这暗示了Mesa在Google内部的生产环境中已经使用了至少两年之久。 如果你是一个技术极客，并且想对Mesa进行更多的了解，那么你可以参考Google的Mesa白皮书。 查看英文原文：Google unveils Mesa - Geo-Replicated Near-Realtime Scalable Data Warehouse |
