big table的架构是一个和GFS mapreduce非常类似的结构，它有一个中心的master server，管理底下一堆的tablet server，然后client会需要从master server得到一系列的元数据，然后具体的数据传输和操作会由tablet server和client单独的来完成。结构的好处，比如它的性能会比较高，因为可能client不需要通过一个bottleneck来进行操作的，这样一个执行，同时它可以利用到底层的分布式文件系统和底层的mapreduce进行数据处理，它性能上也会有一定的保证。但它的缺点是会有单点的失败，master server是一个，整个系统一个单点的失败，那么系统的取舍，实际上是工业界在经过一定的探索之后它们决定使用这样的一个结构。当然更好的结构，比如说我们对master进行一定的备份，进行一定的分布式，这都是今天工业界在探讨的课题。那么下面我们来介绍的就是说，我们有了这样一个架构，整个big table是如何工作起来的，以及我们对big table它的一些看法和建议是什么样子？
1.big table它首先启动master server，那么和GFS mapreduce是一致的，master server通过chubby(chubby维护了整个big table它的名字空间以及一些元数据信息)获得了master的权限，然后master server会去在chubby里面去找，目前big table能够使用的tablet的server。然后他会和tablet server进行通讯，然后知道这些tablet server的情况，比如说是否真的在工作，这些tablet server上面，有哪些数据，master server会从，刚刚我们说的3层结构里面，得到当前系统的tablet 的一些信息，包含tablet的树形结构以及各个tablet 对应的tablet server。这是master server启动之后，对元数据的读取，load的一个情况。
2.master server还会做些什么事呢？ 它会去做tablet server的分配，也就是说它会决定哪些tablet被哪些tablet server去服务。master server会去scan(扫描)整个元数据信息里面哪一些表格没有指定tablet server，那表格我们把它叫做unassigned table，那么当一个表格没有被指定给tablet server服务的时候，master就需要去安排它的服务。那么master服务过程，实际上就是说它会去找着这样的一些tablet server，这些tablet server并不是特别的繁忙，当前的运行状态是正常的，会从里面挑选tablet server，来服务tablet。
Master Startup • Grab unique master lock in Chubby • Scan servers directory in Chubby to find live Master Servers • Communicate with every live tablet to discover which tablets are assigned • Scan METADATA table to learn set of tablets – Track unassigned tablet3.tablet的server的服务会保证tablet在系统中是持久化的，持久化到了分布式文件系统里面。同时它也具有了失败的可控，比如说他有3个物理的备份，在3个不同的server上。对于tablet server，另一方面，就是说当我们要对数据进行一个修改，不只是读的时候，会将过程序列化(log化)，也就是说我们会把这些记录记下来。比如说对某一个tablet，需要做什么样的修改，需要做什么样的调整，那么记录会被cache到一个叫做memtable的结构里面，那么memtable里面就会记录一系列commits，一系列用户对修改的提交，形成一个日志。日志会被big table在后续的时间里面调动起来，让修改真正的发生，当发生的时候可能会涉及到，table的真实的修改，或者说tablet的一个拆分，那这是系统周期性，去完成的这样一个事情。
Tablet Assignment • Master has list of unassigned tablets • When a tablet is unassigned, and a tablet server has room for it, master sends tablet load request to tablet server Tablet Serving • Persistent state of tablet is stored in GFS • Updates committed to log that stores redo records – Memtable: sorted buffer in memory of recent commits – Older updates stored in SSTable4.那么这张图，和刚刚的系统架构是能够对应的，那边有big table的这些使用的进程或者是client，那这边是master server。来看它这些模块，分别负责的一些任务是什么？来看big table，master，实际上它主要是对元数据进行读取保存，以及对元数据进行真实的操作，那同时他还要去做一些策略管理，比如说怎么样维护各个tablet server的load balance。而tablet server它最本质的任务就是去执行具体的查询，可能会做一些代码的部署，然后它会去服务数据。当然它是通过GFS模块，那直接部署中，它们其实上是一套统一的集群，那client是一个比较聪明的client，它需要和master去协调，对元数据进行一个查询和调整，那么它需要对被big table进行数据的读和数据的写，那么它还需要和chubby进行交互，然后拿到整个系统中一些关键的名字空间的一些数据，那么依然是一个smart client。我们认为有了这样一个工作流程后，master server启动起来，然后找着tablet server启动起来，然后client会去和各个模块进行沟通，达到数据的读和写。
那我们来看在big table里面，他们给的这些例程是什么样的情况？
1.这是对表格进行打开，然后进行一个删除操作的一个例子，那我们来看它的逻辑是什么样的？首先我们把一个表格打开，那么表格的名字空间，这时候会和master，会和chubby，进行一定的沟通，然后我们通过row，把一个row给提取出来，那么row可以指定到某一个具体的column上面，然后指定到column上面之后，我们实际上就对数据进行了一个定位，在row column的这样一个层面上，进行的一个定位，然后我们可以执行一个操作，叫做得delete，那么操作可以实施到整个系统里面去，那么有了这样一个操作之后，实际上big table已经帮我们把这样的一个操作，记录到了memtable里面。
// Open the table Table *T = OpenOrDie("/bigtable/web/webtable"); // Write a new anchor and delete an old anchor RowMutation r1(T, "com.cnn.www"); r1.Set("anchor:www.c-span.org", "CNN"); r1.Delete("anchor:www.abc.com"); Operation op; Apply(&op, &r1);2.那么在随后系统的运行过程中，会帮我们把操作实施到big table里面。我们也可以看到，在big table里面，进行一个数据的查询的操作，它的整个过程也很类似。我们可以指定要fetch的column，它的一个family是什么，那么我们可以让它返回所有的version，也就是说所有time stamp对应的数据。
Scanner scanner(T); ScanStream *stream; stream = scanner.FetchColumnFamily("anchor"); stream->SetReturnAllVersions(); scanner.Lookup("com.cnn.www"); for (; !stream->Done(); stream->Next()) { printf("%s %s %lld %s\n", scanner.RowName(), stream->ColumnName(), stream->MicroTimestamp(), stream->Value()); }3.我们使用了一个for循环来对我们需要的一些关键词进行检索，检索之后把它打印出来，那我们来看检索的过程，我们能够对哪些数据进行提取？
我们可以提取到，row的名字，column的名字，以及它的timestamp里面具体的数据，也就是row column timestamp对应的数据。所以可以发现big table，实际上提供了非常高层，也非常类似sql的这样一些操作。当然它没有特别复杂的查询，但是基于big table的思想，今天的nosql系统，已经可以提供非常复杂的，以及非常类似于关系数据库的数据查询。
那么基于这样一些原始的接口，那么我们来看Google的发展，从GFS mapreduce到big table宏观的角度，会有一些什么样的启发？
首先Google的三驾马车，big table是最后产生出来的，那么最开始是分布式文件系统可以用来存数据，可以不用再担心数据变得有多少，那么只要我有服务器，我就可以扩展整个系统的容量；到后面我们可以去运行一些分布式文件处理的程序mapreduce，我们可以去执行一系列操作，然后利用到很多的服务器；那么我们又想把执行进一步简单化，从操作层面简单化，而从效果的层面，我们需要它尽可能执行比较复杂的语句，产生了big table。那么把这3个东西给连到了一块，那big table实际上，整合了GFS和mapreduce的能力，他通过GFS存储数据，通过mapreduce去执行操作，把他们俩做了一个协同，就用到一种数据库的执行模式。那么他共通的一些特性？首先他们都是分布式的系统，能够在大量的服务器上对数据进行存储存取和操作，那么它们都基于简单的结构，有中心服务器和若干的执行的服务器，数据承载的服务器，那么他们都依赖比较聪明的一个客户端，客户端需要做很多的事情，需要去维护很多的状态，那么对业务的要求是比较高的。就是说这几套系统，实际上他们的设计都是和业务关联起来，最终他们要求业务在用这些系统时，也能够变得比较聪明，能够执行这些具体流程的控制。这是我们对3个系统，他们的关联、关系，进行一个分析，他们的关系，GFS、mapreduce支撑了big table，他们共享了相同的架构；他们的不太一样的地方，GFS承载数据，mapreduce执行操作，big table给上层提供使用数据的简单接口。
Google: The Big Picture • Custom solutions for unique problems! • GFS: Stores data reliably – But just raw files • BigTable: gives us key/value map – Database like, but doesn’t provide everything we need – Chubby: locking mechanism – SSTable file format • MapReduce: lets us process data from BigTable (and other sources)1.
Common Principles • One master, multiple helpers – MapReduce: master coordinates work amongst map / reduce workers – Bigtable: master knows about location of tablet servers – GFS: master coordinates data across chunkservers2. Chubby是一种高可用的分布式锁服务，Chubby有五个活跃副本，同时只有一个主副本提供服务，副本之间用Paxos算法维持一致性，Chubby提供了一个命名空间（包括一些目录和文件），每个目录和文件就是一个锁，Chubby的客户端必须和Chubby保持会话，客户端的会话若过期则会丢失所有的锁。
