简介：https://blog.csdn.net/w1573007/article/details/52966742

https://blog.csdn.net/qq_38122518/article/details/78201472

2003年，Google发布Google File System论文，这是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。它运行于廉价的普通硬件上，提供容错功能。从根本上说：文件被分割成很多块，使用冗余的方式储存于商用机器集群上。

主要设计理念：

0、愿景:

　　给用户一个无限容量、放心使用的硬盘，快速的存取文件。

1、架构为 client + master + chunkserver

        master为单点大脑，负担小，持久化一些重要的不常变的元数据，易变元数据启动后从chunkserver拉取，存在内存里。

　　chunkserver为集群，

　　chunk为文件存储单位，最大大小可配置但配后固定，尽可能配大些，这样chunk个数少，master上需要维护的元数据少。

　　chunk存在多份副本，位于不同的chunkserver上，分首要副本和普通副本。

　　数据流和控制流解耦，客户端先发数据到所有副本上(有些传输发生在副本间)，所有副本把数据准备好，并没有实施变异。然后发执行命令到首要副本，然后根据严格的次序，在各个副本上实施变异。

　　client先通过master获取元数据，并缓存。然后对文件的操作都是直接与chunkserver交互。

2、设计原则：

　　chunk副本的布置策略主要遵循两个目标：最大化数据可靠性和可用性，最大化网络带宽利用。

　　高可用性：我们保持整体系统高度可用，只用两个简单但是高效的策略：快速恢复和复制。master和chunkserver都可以在几秒内重启并恢复它们的状态。

　　数据完整性：每个chunkserver使用checksum来侦测腐化的存储数据。但是每个chunkserver自己校验，不是chunkserver之间校验。校验出问题后，从其他副本拷贝

3、当一个文件被应用删除时，master立刻打印删除操作的日志，然而不会立刻回收资源，仅仅将文件重命名为一个隐藏的名字，包含删除时间戳。在master对文件系统命名空间执行常规扫描时，它会删除任何超过3天的隐藏文件（周期可配）。

MapReduce（2004）：面向大型集群的简化数据处理

 https://blog.csdn.net/qq_38122518/article/details/78205655

紧随其后的就是2004年公布的 MapReduce论文，论文描述了大数据的分布式计算方式，主要思想是将任务分解然后在多台处理能力较弱的计算节点中同时处理，然后将结果合并从而完成大数据处理。

Mapreduce是针对分布式并行计算的一套编程模型。

 与之前理解的差异：

1、Map不是分块函数，而是分块处理函数。分块函数没名字

2、原始的MapReduce是通过文件传输数据的，包括中间数据也是由Map写到文件里，再由Reduce来获取的。

3、在每个工作节点上，可以先进行一次结果处理，也就是Recuce处理，以减少最终Reduce的压力，以及网络传输压力。

BigTable（2006）

 Bigtable发布于2006年，启发了无数的NoSQL数据库，比如：Cassandra、HBase等等。Cassandra架构中有一半是模仿Bigtable，包括了数据模型、SSTables以及提前写日志（另一半是模仿Amazon的Dynamo数据库，使用点对点集群模式）。

 Bigtable 是一个分布式的结构化数据存储系统，它被设计用来处理海量数据：通常是分布在数千台普通服务器上的 PB 级的数据。

BigTable 是建立在 GFS 和 MapReduce 之上的。每个Table都是一个多维的稀疏图

Bigtable 是一个稀疏的、分布式的、持久化存储的多维度排序 Map5。 Map 的索引是行关键字、列关键字以及时间戳； Map 中的每个 value 都是一个未经解析的 byte 数组。

Bigtable 通过行关键字的字典顺序来组织数据。表中的每个行都可以动态分区。每个分区叫做一个”Tablet”，Tablet 是数据分布和负载均衡调整的最小单位。这样做的结果是，当操作只读取行中很少几列的数据时效率很高，通常只需要很少几次机器间的通信即可完成。用户可以通过选择合适的行关键字，在数据访问时有效利用数据的位置相关性，从而更好的利用这个特性。

列关键字组成的集合叫做“列族“，列族是访问控制的基本单位。存放在同一列族下的所有数据通常都属于同一个类型（我们可以把同一个列族下的数据压缩在一起）。

Bigtable 支持单行上的事务处理，利用这个功能，用户可以对存储在一个行关键字下的数据进行原子性的读-更新-写操作。

 为了管理巨大的Table，把Table根据行分割，这些分割后的数据统称为：Tablets。每个Tablets大概有 100-200 MB，每个机器存储100个左右的 Tablets。底层的架构是：GFS。

 由于GFS是一种分布式的文件系统，采用Tablets的机制后，可以获得很好的负载均衡。比如：可以把经常响应的表移动到其他空闲机器上，然后快速重建。

Bigtable 是建立在其它的几个 Google 基础构件上的。 BigTable 使用 Google 的分布式文件系统(GFS) 【17】存储日志文件和数据文件。 BigTable 集群通常运行在一个共享的机器池中，池中的机器还会运行其它的各种各样的分布式应用程序，BigTable 的进程经常要和其它应用的进程共享机器。 BigTable 依赖集群管理系统来调度任务、管理共享的机器上的资源、处理机器的故障、以及监视机器的状态。

  BigTable 内部存储数据的文件是 Google SSTable 格式的。 SSTable 是一个持久化的、排序的、不可更改的 Map 结构，而 Map 是一个 key-value 映射的数据结构， key 和 value 的值都是任意的 Byte 串。可以对 SSTable 进行如下的操作：查询与一个 key 值相关的 value，或者遍历某个 key 值范围内的所有的 key-value 对。从内部看， SSTable 是一系列的数据块（通常每个块的大小是 64KB，这个大小是可以配置的）。 SSTable 使用块索引（通常存储在 SSTable 的最后）来定位数据块；在打开 SSTable 的时候，索引被加载到内存。每次查找都可以通过一次磁盘搜索完成：首先使用二分查找法在内存中的索引里找到数据块的位置，然后再从硬盘读取相应的数据块。也可以选择把整个 SSTable 都放在内存中，这样就不必访问硬盘了。

  BigTable 还依赖一个高可用的、序列化的分布式锁服务组件，叫做 Chubby【8】。一个 Chubby 服务包括了 5 个活动的副本，其中的一个副本被选为 Master，并且处理请求。只有在大多数副本都是正常运行的，并且彼此之间能够互相通信的情况下， Chubby 服务才是可用的。当有副本失效的时候， Chubby 使用 Paxos 算法【9,23】来保证副本的一致性。 Chubby 提供了一个名字空间，里面包括了目录和小文件。每个目录或者文件可以当成一个锁，读写文件的操作都是原子的。 Chubby 客户程序库提供对 Chubby 文件的一致性缓存。每个Chubby 客户程序都维护一个与 Chubby 服务的会话。如果客户程序不能在租约到期的时间内重新签订会话的租约，这个会话就过期失效了9。当一个会话失效时，它拥有的锁和打开的文件句柄都失效了。 Chubby 客户程序可以在文件和目录上注册回调函数，当文件或目录改变、或者会话过期时，回调函数会通知客户程序。

Bigtable 包括了三个主要的组件：链接到客户程序中的库、一个 Master 服务器和多个 Tablet 服务器。针对系统工作负载的变化情况， BigTable 可以动态的向集群中添加（或者删除） Tablet 服务器。

  Master 服务器主要负责以下工作：为 Tablet 服务器分配 Tablets、检测新加入的或者过期失效的 Table 服务器、对 Tablet 服务器进行负载均衡、以及对保存在 GFS 上的文件进行垃圾收集。除此之外，它还处理对模式的相关修改操作，例如建立表和列族。