对谷歌大数据"老三篇"论文的理解-Onceme Blog

有master节点，且master节点只存储元数据，极大降低了master节点的负担，使得只需要普通配置的机器，就可以在一个庞大分布式系统中使用统一的master节点
数据块大小为64M
每个数据块都会在另外的节点中有指定数量的副本
节点会与分布式文件锁系统挂钩，占用特定的文件锁，来表示节点的存活
节点失效后，master节点会从其他备份节点恢复出一个新的节点
节点维持着一个seq写入序号，当序号与master节点存储的不一致时，认为节点跟不上进度，将被认为是失效节点，被清理 (这样跟不上就丢弃的处理刚觉是不是过于粗暴)
数据的不同副本的存储策略问题，尽量分散在物理距离远的地方？（不同交换机，机柜，机房）
客户端缓存路径与存储节点的元数据信息

Google Bigdata

结构化分布式数据存储系统(TODO 确认是结构化还是半结构化)
依托于GFS
目的：适用性广泛、可扩展、高性能和高可用性
类似于一种在nosql基础上实现的简单的行列逻辑的表（TiDB的实现也可以看到这篇论文的影子， TiDB的存储层也是TiKV这样的Nosql，）
行表示与列标识都保存在kv数据结构的key上
根据一些条件判断数据是存在内存还是硬盘
每个列可以保存不同限定条件下的不同版本形成列簇（如时间戳）
通过行关键字来排序
Bigtable 是一个稀疏的、分布式的、持久化存储的多维度排序 Map5。Map 的索引是行关键字、列关键字以及时间戳；Map 中的每个 value 都是一个未经解析的 byte 数组。 >(row:string, column:string,time:int64)->stri
master负责对tablet节点的调度管理，对保存在GFS上的文件进行垃圾收集，以及对存储数据的模式进行维护(类似于表结构)
tablet节点管理一定数量的tablet
和GFS类似，bigdata的数据读取不经过master节点，而是由客户端直接与tablet节点通信
SSTable是一系列数据块(每块默认64k),然后使用块索引来定位到具体的数据块，而块索引存储在SSTable末尾
Bigdata 包含一个master服务器和多个Tablet服务器
Bigdata 使用一个 METADATA 表存储所有tablet的位置信息
METADATA 表的第一个tablet是root table，其存储了METADATA表各个tablet的位置信息
METADATA表的其他tablet都存储了一个用户tablet的集合的位置信息
root tablet信息不分割，保证了tablet位置信息存储始终是三层
对同一个行关键字的读或者写操作都是原子的（不管读或者写这一行里多少个不同列），这个设计决策能够使用户很容易的理解程序在对同一个行进行并发更新操作时的行为。
表中的每个行都可以动态分区。每个分区叫做一个”Tablet”，Tablet 是数据分布和负载均衡调整的最小单位
(一行就可以有多个分区？)即按什么规则拆分tablet
- 一个表的初始状态是一个tablet,
- 同一行是否会被分割为两个tablet?
tablet服务器恢复时，会从元信息表中读取元信息。
元信息，是由多个SSTables组成。SSTable由一个tablet和一系列的重做点（redo points）组成。
BigTable 内部存储数据的文件是 Google SSTable 格式的。SSTable 是一个持久化的、排序的、不可更改的 Map 结构，
BigTable 还依赖一个高可用的、序列化的分布式锁服务组件，叫做 Chubby

Map Reduce

一种简化分布式程序编写的编程模型与计算框架、
同样有一个master节点负责调度
一定数量的map节点与一定数量的reduce节点
原始数据打散分发到各个map节点
map节点将原始数据进行初步的加工，得到一组key以及对应的val
master节点按就近原则，将中间结果发送给reduce节点
reduce节点分别计算，最后将结果汇总
map节点与reduce节点都是无状态的，任意节点执行失败，都可以将该节点的任务调度到其他节点，而且只需要执行失败的部分
在大部分任务完成时，总的运行时间可能会被个别节点所拖延，所以对于执行时间过长的任务，master节点会在其他节点重新执行一次相同任务
这两个流程不论哪个先完成，整个任务都算完成了

对谷歌大数据"老三篇"论文的理解

TOC

Google File System

Google Bigdata

Map Reduce

FEATURED TAGS

FRIENDS