AtlasDB是Palantir公司为NoSQL存储开发的事务处理层。在介绍AtlasDB之前，有必要提及一下Palantir公司，它在大数据公司生态谱里有着重要位置，因为它的客户里有着军方和情报机构，曾经帮助CIA干掉本登，棱镜系统就运行于Palantir的分析平台之上。Palantir的起源是Pay Pal在支付领域反欺诈的积累，公司有两个产品线：一个是Palantir Gotham, 主要是应用于国防与安全领域。另一个是Palantir Metropolis，主要应用于金融领域。Palantir目前估值已有200亿美元，在独角兽公司排行中名列前茅，做为一家面向企业的大数据公司，是我们在相关方向上创业创新的重要学习对象之一。下图是Palantir的技术栈，涵盖数据抓取，数据预处理，数据存储，搜索，以及数据分析，这些每个技术领域都是大数据行业必不可少的组件之一。
在这个技术栈里，AtlasDB就是服务数据存储中的"Revisioning Database"，Palantir对它的需求是，既能像NoSQL那样容易扩展，也能像Oracle那样具备高性能和事务操作。截至本文写作之时，AtlasDB是Palantir开源的众多项目中唯一一个关于后端基础架构方面的，并且在整个开源界，又是为数不多敢于直面困难(事务实现)的项目，又因为在Palantir基础架构中的核心地位，我们没有理由不去研究这样一个核心基础架构组件。
首先先来看下Palantir公开的技术资料，尽管并不很多。
在Palantir官方Blog写到，开发AtlasDB是源自Google的Percolator，这是一个在BigTable的基础上，通过两阶段提交实现了跨行跨表事务(快照隔离语义)以及notification的框架。在Google内部，Percolator用于增量索引的实时更新，在没有采用Percolator的时候，索引只能做到周期性的批量更新，因此Percolator的事务性对于Googe搜索引擎的实时更新非常重要。这种需求对于Palantir来说是类似的，因为数据分析产品都是构建在事务性数据库基础之上的。但是，采用Percolator后，性能只能达到原来BigTabe的23%，Palantir认为这是不可接受的，因此Palantir并没有完全照搬Percolator的设计思路。
在刚开始的时候，Revision Database采用传统的RDBMS，随着数据量的增长，当时有2条道路，一个是Scale Up，采用更强大的主机，另一个是采用数据切分，既现在很流行的数据库分库分表解决方案。但Palantir都没有采用，前者很容易理解，而对于后者来说，Palantir主要是考虑到自身的Schema定义不太适合切分，容易引起应用的复杂化，因此palantir选择了第三条道路—自研。首先，Palantir开发了一个叫做Phoenix的批处理系统，可以在PB级数据存储上运行MapReduce任务，Phoenix首先把需要处理的数据分类和过滤，然后通过搜索来把结果直接导出到数据分析平台，这样只需要在Revision Database中存储元信息，包括数据的变化历史，以及分析结果，避免了对大型数据库的依赖。然而随着元信息的增长，这种绕过问题的方法也变得不合时宜起来，于是此时Palantir考虑引入NoSQL系统，但他们马上发现传统的NoSQL基本都是最终一致，这对于Palantir来说是不能接受的，因为Revision Database中存储的不是数据本身，而是一系列相关的记录引用，为了避免数据不一致带来的业务逻辑代码复杂化，需要确保这些数据的强一致性访问，于是才有了AtlasDB——给NoSQL存储增加事务层。目前，AtlasDB支持用LevelDB，PostgreSQL，以及Cassandra作为底层存储，理论上可以容易的扩展到各类NoSQL方案，由于AtlasDB本身并不考虑伸缩性的问题，因此选择什么样的存储引擎做后端，这是需要架构师根据需求自行做出的选择，在Palantir内部，Cassandra被用来做为AtlasDB的后端选择，写入性能损耗只有15%，远低于Percolator，整个AtlasDB的结构图如下所示：
在架构上，AtlasDB由Lock Server，TimeStamp Server，Transaction Server，以及NoSQL Key-Value Store组成。为避免Percolator的性能问题，AtlasDB进行了相关的调整，例如，Lock Server只进行内存操作，Atlasdb把Lock Server单独存放，避免在存储引擎上操作锁，减少了写放大。此外，Transaction Server的事务处理存储跟Key Value Store解耦，独立存放，由于事务存储比数据存储体积小得多，这种解耦改进了写入性能。
下边来看一下AtlasDB的事务处理设计。写入：AtlasDB在内存中缓存数据，直到需要提交。提交时，获得所有写入行的行锁，同时为事务表获得相应的时间戳startTS。在获得行锁时需要进行冲突检测，如果有其他事务在startTS之后，以及该事务提交之前提交，那么就存在冲突。写入数据到Key-Value Store中，并设置时间戳为startTS，然后在事务表中用本事务的提交时间戳进行一个原子操作"put Unless Exists"，最后再释放锁资源。可以参见网站上刚刚放出的slide加深理解：
初始时，Timestamp Server的下一个有效时间戳为55。
记录下startTS后，写入数据首先插入到缓存中。
获得写锁。
进行冲突检测，发现冲突。
将带有startTS的记录写入到Key Value Store中。
获得提交时间戳commit TS。
提交，写入数据(startTS和commitTS)到事务表中。
AtlasDB的事务读取协议需确保能够读取时间戳小于startTS的最新数据，因此如果当前时间戳 由此，从startTS和commitTS可以看出，AtlasDB是典型的MVCC快照隔离事务隔离级别(SI)。同时，AtlasDB也实现了更强的SSI，既顺序快照隔离级别。在实现上很容易做到，只需要在SI的写入冲突检测基础之上再添加读写冲突检测即可，这在论文"A Critique of Snapshot Isolation"已有相关证明。 有朋友可能会问，Cassandra从2.0起已经支持事务了，还需要AtlasDB这种第三方事务层有必要么？实际上，Cassandra目前只支持轻量级单行事务，在未来则有可能支持RAMP事务，这是Bailis在SIGMOD 2014上提出的新的事务隔离级别，简单说就是在分布式数据库中一个对多行同时写入的事务，需要保证其他客户端在读取事务发生时要么可以见到其修改的所有行，要么都见不到。RAMP事务只保证了单个写入事务在其他读取事务面前的原子性，但是多个事务同时写的话不保证隔离性。因此经典的“银行转账”类跨行事务的需求因为可能涉及到并发写，RAMP事务隔离性是搞不定的。 另外，基于BigTable的开源版HBase的Percolator实现，也已经有一些存在了，例如Haeinsa[1]，Yahoo Omid[2]，小米Themis[3] ，本文在这里也顺道提及下。Haeinsa本身没有Percolator原版的全局时间戳，因此它需要借助外部的时间机制。Haeinsa通过客户端乐观锁和两阶段提交实现事务隔离级别，因为客户端需要缓存数据，涉及到两次读取操作，对性能损失较大，另外错误恢复也比较简单，例如超过5秒就认为是错误超时事务。小米Themis基本是按照Percolator实现的，不过单行事务借助于HBase CoProcessor，同时也进行了其他一些相关优化（例如prewrite阶段，锁写入Memstore等），使得Themis的写入性能可以达到HBase的60%多，比Percolator提高不少。Omid则采用了无锁的事务处理设计，系统中引入单点的TSO来裁决事务冲突，一次事务处理的流程如下图所示： Omid另一个值得关注的地方在于引入了BookKeeper作为全局日志，我们知道Twitter已经拿BookKeeper取代Kafka来做为全局日志的存储，因此Omid本身值得用更多的篇幅来叙述，这里就不再深入展开了。总体来说，这些方案都是专门为HBase定制的方案，无法移植到其他存储引擎。 最后再来回顾一下整个Google的Infrastructure栈，随着AtlasDB的出现，在解决分布式事务的道路上，在正在演进的CockroachDB，刚刚启动的TiDB之外，开源界对应的残缺拼图又多了一个填充。 [1] https://github.com/VCNC/haeinsa [2] https://github.com/yahoo/omid [3] https://github.com/XiaoMi/themis