⑴ 什麼是分布式存儲系統
分布式存儲系統
定義
分布式存儲系統是大量普通PC伺服器通過Internet互聯，對外作為一個整體提供存儲服務
特性
可擴展
低成本
高性能
易用
挑戰
分布式存儲系統的挑戰主要在於數據、狀態信息的持久化，要求在自動遷移、自動容錯、並發讀寫的過程中保證數據的一致性。分布式存儲涉及的技術主要來自兩個領域：分布式系統以及資料庫。
數據分布
一致性
容錯
負載均衡
事務與並發控制
易用性
壓縮/解壓縮
分類
非結構化數據，一般的文檔
結構化數據， 存儲在關系資料庫中
半結構化數據，HTML文檔
不同的分布式存儲系統適合處理不同類型的數據：
分布式文件系統
非結構化數據，這類數據以對象的形式組織，不同對象之間沒有關聯，這樣的數據一般稱為Blob（二進制大對象）數據
典型的有Facebook Haystack 以及 Taobao File System
另外，分布式文件系統也常作為分布式表格系統以及分布式資料庫的底層存儲，如谷歌的GFS可以作為分布式表格系統Google Bigtable 的底層存儲，Amazon的EBS（彈性存儲塊）系統可以作為分布式資料庫（Amazon RDS）的底層存儲
總體上看，分布式文件系統存儲三種類型的數據：Blob對象、定長塊以及大文件
分布式鍵值系統
較簡單的半結構化數據，只提供主鍵的CRUD（創建、讀取、更新、刪除）
典型的有Amazon Dynamo 以及 Taobao Tair
分布式表格系統
較復雜的半結構化數據，不僅支持CRUD，而且支持掃描某個主鍵范圍
以表格為單位組織數據，每個表格包括很多行，通過主鍵標識一行，支持根據主鍵的CRUD功能以及范圍查找功能
典型的有Google Bigtable 以及 Megastore，Microsoft Azure Table Storage，Amazon DynamoDB等
分布式資料庫
存儲結構化數據，一般是由單機關系資料庫擴展而來
典型的包括MySQL資料庫分片集群、Amazon RDS以及Microsoft SQL Azure
⑵ 在大數量級的數據存儲上，比較靠譜的分布式文件存儲有哪些
一、 Ceph
Ceph最早起源於Sage就讀博士期間的工作、成果於2004年發表，並隨後貢獻給開源社區。經過多年的發展之後，已得到眾多雲計算和存儲廠商的支持，成為應用最廣泛的開源分布式存儲平台。
二、 GFS
GFS是google的分布式文件存儲系統，是專為存儲海量搜索數據而設計的，2003年提出，是閉源的分布式文件系統。適用於大量的順序讀取和順序追加，如大文件的讀寫。注重大文件的持續穩定帶寬，而不是單次讀寫的延遲。
三、 HDFS
HDFS(Hadoop Distributed File System)，是一個適合運行在通用硬體(commodity hardware)上的分布式文件系統，是Hadoop的核心子項目，是基於流數據模式訪問和處理超大文件的需求而開發的。該系統仿效了谷歌文件系統(GFS)，是GFS的一個簡化和開源版本。
⑶ GFS 小結
title: GFS 小結
tags:
categories:
comments: true
date: 2017-06-12 17:00:00
提到分布式系統，有一個無法繞開的話題—— Google 三駕馬車。本文就 GFS 概括介紹。
與傳統的分布式系統相比，在大方向上，GFS 同樣追求高性能、高可靠性、高可用性，同時 Google 基於自身的生產環境、技術環境，有一些特殊的設計思路。
GFS 架構比較簡單，一個 GFS 集群一般由一個 master 、多個 chunkserver 和多個 clients 組成，在 GFS 中，所有文件被切分成若干個 chunk，並且每個 chunk 擁有唯一不變的標識（在 chunk 創建時，由 master 負責分配），所有 chunk 都實際存儲在 chunkserver 的磁碟上。為了容災，每個 chunk 都會被復制到多個 chunkserver。
系統架構如下：
在整個集群中，為了簡化設計，master 是單節點，它管理著所有文件系統的所有 metadata：命名空間、訪問控制信息、文件和 chunk 的映射關系、chunk 的存儲位置。同時 master 還管理系統范圍內的各種活動：chunk 創建、復制、遷移、回收，chunk lease 等等，是系統中最核心的部分，後面會繼續進一步描述 master 是如何工作的。
Chunkserver 真正存儲著所有 chunk，chunkserver 依託於 linux 文件系統，所以它本身不需要緩存文件數據，直接利用 linux 系統的數據緩存，簡化了設計。
Master 是整個 GFS 的核心，這里重點介紹下 master 的存儲以及工作。
所有的元數據都存儲在 Master 的內存中，以保證 Master 的性能。大部分元數據同時會以變更記錄的形式保存到操作日誌中，操作日誌會在本地磁碟中持久化同時被復制到其他的 Master 上（雖然是 single master，但是會有備份節點備份 Master 的相關數據，比如操作日誌、checkpoint 文件，以保證可靠性）。
Master 會在後台周期性的掃描所保存的狀態信息，因為全部在內存中，所以效率非常高。通過這種周期性的掃描，master 實現 chunk 回收、chunkserver 宕機時 chunk 的復制、以及遷移 chunk ，實現 chunkserver 的負載均衡。
但是， chunk 的位置信息不會被持久化，而是在每次 master 啟動時（以及啟動後定期執行），或有 chunkserver 加入時，master 會輪訓所有 chunkserver 獲取所有的 chunk 信息然後保存在內存中。這種方式簡化了 master 和 chunkserver 的數據同步，當然數據定期輪訓的缺點就是實時性稍差。
操作日式是元數據唯一的持久化記錄，它還定義了並發操作的執行順序的邏輯時間線，所以操作日誌的完整性得到保證，才能保證 GFS 的可靠性，否則會丟失文件或者 client 的操作。因此操作日誌會被復制到多台備份節點，而且，只有 master 把操作日誌持久化到本地並且復制到遠程之後，才會響應客戶端的請求，保證數據不丟失。
隨著時間的增長，操作日誌會越來越大，當日止增長到一定量時，master 會將所有的系統狀態做一次 checkpoint（可以理解為持久化某一個時間點的全部狀態數據），後續的操作變更會寫入到新的日誌文件，這樣在重啟或災難恢復時，master 只需要載入最新的 checkpoint 文件到內存，然後重新執行最新的一部分操作日誌即可。（這也是比較通用的一種災備方法，定期做 checkpoint，然後重新記錄操作日誌，恢復時基於 checkpoint + operation log）
Checkpoint 文件以壓縮 B- 樹的結構存儲，能直接映射到內存，無需額外解析，大幅提升了速度。同時創建 checkpoint 時，master 會啟動獨立的線程，不會阻塞正在進行的操作。
Master 節點執行所有的命名空間管理、chunk管理以及負責垃圾回收。
Master 在操作命名空間是基於鎖實現的，在操作對應的文件或目錄時，會給對應的文件/目錄加讀鎖以及讀寫鎖，eg：對於一個 /home/usr/zhaif 的操作，會依次給父目錄 /home，/home/usr 加讀鎖，讀鎖可以防止正在讀取得文件、父目錄被刪除、改名，同時給 /home/usr/zhaif 加讀鎖或寫鎖（根據操作類型），當對操作目標的操作是修改類操作時，會加寫鎖，保證並發場景下互斥寫。
上文提到，master 會負責 chunk 副本的存儲位置，即存儲在哪些 chunkserver 上，master 會最大化的保證數據可靠性，同時最大化利用網路帶寬。
在創建一個 chunk 時，master 選擇存儲空副本的初始位置時，會考慮一下幾點：
除了管理 chunk 副本的存儲位置，master 會在 chunk 有效副本數小於指定數量時重新復制 chunk 副本，以保證數據可靠性。
最後，Master 會定期對所有副本負載均衡，檢查當前副本分布情況，然後移動副本位置以更搞笑的利用硬碟空間和負載。
GFS 的文件刪除不會立刻回收物理空間，而是惰性的（現如今，惰性回收在存儲系統中是一種比較常見的策略，比如 redis 回收過期數據，分配的內存空間）。這種回收機制使系統更簡單、更可靠、更高效。
當一個文件被刪除時，master 只是將文件改名，標記為已刪除。Master 會對命名空間做定期掃描，會刪除一定時間前標記刪除的文件，同時刪除其在命名空間中的記錄以及相關元數據，此時一個文件才被真正的刪除。
Master 在常規定期掃描的過程中會發現一些孤兒 chunk，即不被任何文件包含的 chunk，然後刪除他們的元數據。Chunkserver 在和 master 定期交互時，匯報了其所有的 chunk 信息，master 會告知其不存在的 chunk，chunkserver 得知後會刪除這些 chunk 副本。
這種惰性刪除的主要問題是空間利用率，尤其的在存儲空間緊缺時。所以 GFS 也提供了通過顯示的再刪除一次已經刪除的文件來加速空間回收，另外也允許用戶根據需要對不同的目錄設置不同的回收策略，eg：指定用些目錄的刪除策略為即時刪除，而不是惰性刪除。
Master 的寫操作是基於 lease 機制（後文介紹），當 master 每次分配 lease 時都會增加對應的 chunk 的版本號，然後所用最新的副本，通過版本號區分當前的和過期的副本。
GFS 在設計是採用 client 和 API 協同設計的思路，所以在讀寫過程中 client 也不單純是發讀請求或寫請求，還包括其他一些操作。
Client 不通過 master 節點讀寫文件，而是從 master 那獲取讀寫操作的需要聯系的 chunkserver，為了避免頻率的和 master 聯系，client 會緩存 從 master 獲取的 metadata，後續操作直接和 chunkserver 溝通實現讀寫。一次簡單的讀流程如下：
相較於讀操作，寫實現更為復雜一些。所有的寫入操作會在所有 chunk 的副本上執行，GFS 採用 lease 機制來保證多個 chunk 副本之間變更順序一致。
Master 會選擇一個副本分配 lease，擁有這個 lease 的 chunk 被稱為 primary，其他副本則是 secondary。Primary 會將對 chunk 的操作序列化，然後其他 secondary 按也這個序列執行修改，從而保證所有副本變更一致。
Lease 有效期初始為 60s，primary chunk 在完成修改操作後可以申請延長 lease 有效期，同樣的 master 在一些情況下可以提起取消 lease。Master 和 chunkserver 之間會有定期的心跳監測，傳遞心跳信息是可以帶上這些 lease 的驗證請求或者批准信息。Lease 機制極大的簡化的 master 的負擔，將寫操作保證數據一致性的工作分擔給 chunkserver，使得 master 變得很輕量。
下圖是一次寫操作的流程：
GFS 將寫操作拆分為數據流（對應3）和控制流（對應4），數據流以 Pipline 的方式推送到所有副本。
GFS 同時提供了一個種原子的寫入操作——記錄追加。相比普通的寫入操作，追加只需指定要寫入的數據，不需要提供偏移量（即要寫入的位置）。GFS 會保證追加操作至少一次原子性寫入。記錄追加的控制流程同上文描述基本相同，卻別在於 primary 會檢測此次追加後 chunk 是否超過最大值，如果達到最大值，primary 會先將當前 chunk 填充滿，然後同步給 secondary 同樣操作，然後回復 client 要求其對下一個 chunk 重新執行追加操作。
原子記錄追加操作在避免了使用一個分布式鎖帶來的開銷，對於多 procer，單 consumer的場景以及合並多個來源文件的場景很契合。
GFS 是一個分布式系統，為了更好的 AP，一定程度上降低了對 C 的要求，其一致性模型是比較寬松。下圖是變更後文件狀態，其中：
從上文的寫入數據流程可以發現，串列的寫數據secondary 和 primary 操作順序是一直的，如果成功，則一定是 defined，如果失敗，則不一致，比如 primary 寫成功了，而有一個 secondary 寫失敗。同樣的道理，在並行場景下，寫失敗會不一致，但是成功的話只能保證一致，因為並發操作可能會導致一個文件 region 內包含來自多個 client 的寫操作，所以是 undefined.
記錄追加操作是原子的，GFS對於此操作能保證的是 至少一次成功 語義，所以有可能會在某個副本上發生多次追加，但是 GFS 返回給 client 的 offset 都是 defined region 的起點，如果這期間在某個副本的操作被重復追加了，此時它的 offset 會比其他大，後續的操作對所有副本都會從這個最大的 offset 開始追加，或者被追加到其他 chunk 上，因此對於記錄追加操作而言，如果執行成功，文件 region 狀態是定義的但會有部分不一致。
GFS 通過 Checksum 叫校驗數據是否損壞，比如因為宕機丟失了一些修改操作而導致失效，此時 master 會標記失效，不在返回給 client 失效的副本位置信息，並盡快回收。 對於已經被 client 緩存的失效副本信息，當 client 訪問這個失效副本時，一個失效副本會返回提前結束的 chunk，從而 client 能得知重新聯系 master 獲取最新的位置信息。
另外，正如上文所述， master 也會和 chunkserver 通過心跳來檢測宕機，並校驗數據有效性，在發現問題後會盡快恢復。
GFS 通過快速恢復和復制保證整個集群的高可用性，無論 master 還是 chunkserver 都可以在數秒內重啟並恢復狀態。
Chunk 會被復制到不同的機架上的不同 chunkserver，當某台 chunkserver 失效或者其上的 chunk 已損壞時，master 會繼續復制已有的副本，保證每個 chunk 的可用性。
Master 伺服器的狀態會被復制，它所有的操作日誌、checkpoint 文件都會被復制到多台機器，對 master 伺服器的狀態的任何操作都要等操作日誌被復制到備份節點後本機磁碟後才會被提交生效。所以 Master 宕機後，重啟後不會有任何數據丟失，如果無法重啟或磁碟故障，則可以選擇擁有全部操作日誌的備份節點啟動一個新的 master 進程。由此可以保證 master 的可靠性。
同時，還存在一些 shadow master ，在 master 宕機時能可以提供 read-only 服務，但要比 master 慢一些（通常不到 1s），它們通過讀取操作日誌副本的並順序執行方式保證其和 master 以相同的方式變更。同樣的，shadow master 也會和 chunkserver 定期交互檢測 chunkserver狀態、拉取數據。
⑷ 分布式儲存_gluster
9)查看卷
gluster volume info
gluster volume stop 卷名 停止
gluster volume delete 卷名 刪除註： 刪除 磁碟 以後，必須刪除 磁碟( 數據目錄 ) 中的 （ .glusterfs/ .trashcan/ ）目錄。 否則創建新 volume 相同的 磁碟 會出現文件 不分布，或者 類型 錯亂 的問題。
gluster peer detach 節點名 刪除節點
。
添加GlusterFS節點：
gluster peer probe swarm-node-3
gluster volume add-brick models swarm-node-3:/opt/gluster/data
註：如果是復制卷或者條帶卷，則每次添加的Brick數必須是replica或者stripe的整數倍
配置卷
gluster volume set
縮容volume:
先將數據遷移到其它可用的Brick，遷移結束後才將該Brick移除：
gluster volume remove-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data start
在執行了start之後，可以使用status命令查看移除進度：
gluster volume remove-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data status
不進行數據遷移，直接刪除該Brick：
gluster volume remove-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data commit
注意，如果是復制卷或者條帶卷，則每次移除的Brick數必須是replica或者stripe的整數倍。
擴容：
gluster volume add-brick models swarm-node-2:/opt/gluster/data
修復命令:
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data commit -force
遷移volume:
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data start
pause 為暫停遷移
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data pause
abort 為終止遷移
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data abort
status 查看遷移狀態
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data status
遷移結束後使用commit 來生效
gluster volume replace-brick models swarm-node-2:/opt/gluster/data swarm-node-3:/opt/gluster/data commit
均衡volume:
gluster volume models lay-outstart
gluster volume models start
gluster volume models startforce
gluster volume models status
gluster volume models stop
gluster 性能調優：
開啟 指定 volume 的配額： (models 為 volume 名稱)
gluster volume quota models enable
限制 models 中 / (既總目錄) 最大使用 80GB 空間
gluster volume quota models limit-usage / 80GB
gluster volume set models performance.cache-size 4GB
gluster volume set models performance.flush-behind on
gluster volume set models performance.io-thread-count 32
gluster volume set models performance.write-behind on
部署GlusterFS客戶端並mount GlusterFS文件系統 (客戶端必須加入 glusterfs hosts 否則報錯。)
yum install -y glusterfs glusterfs-fuse
mkdir -p /opt/gfsmnt
mount -t glusterfs swarm-manager:models /opt/gfsmnt/
確認掛載結果：
mount -t fuse.glusterfs
查看卷
gluster volume list / 列出集群中的所有卷 /
gluster volume info [all] / 查看集群中的卷信息 /
gluster volume status [all] / 查看集群中的卷狀態 /
更改卷類型
1.需要先卸載掛載的目錄
umount ／mnt
2.停止卷
3.更改卷的類型
語法：gluster volume set test-volume config.transport tcp,rdma OR tcp OR rdma
例子：
重新均衡卷
語法：gluster volume rebalance <VOLNAME> fix-layout start
例子：gluster volume rebalance test-volume fix-layout start
⑸ Bigtable---分布式的結構化數據存儲系統
sina
Bigtable 是一個分布式的結構化數據存儲系統，它被設計用來處理海量數據：通常是分布在數千台普通伺服器上的PB 級的數據。Google 的很多項目使用Bigtable 存儲數據，包括Web 索引、GoogleEarth、Google Finance。這些應用對Bigtable 提出的要求差異非常大，無論是在數據量上（從URL到網頁到衛星圖像）還是在響應速度上（從後端的批量處理到實時數據服務）。
Bigtable 已經實現了下面的幾個目標：適用性廣泛、可擴展、高性能和高可用性,Bigtable 是一個稀疏的、分布式的、持久化存儲的多維度排序Map。
圖一：一個存儲Web 網頁的例子的表的片斷。行名是一個反向URL。contents 列族存放的是網頁的內容，anchor 列族存放引用該網頁的錨鏈接文本（alex 註：如果不知道HTML 的Anchor，請Google一把）。CNN 的主頁被Sports Illustrater和MY-look 的主頁引用，因此該行包含了名為「anchor:cnnsi.com」和「anchhor:my.look.ca」的列。每個錨鏈接只有一個版本（alex 註：注意時間戳標識了列的版本，t9 和t8 分別標識了兩個錨鏈接的版本）；而contents 列則有三個版本，分別由時間戳t3，t5，和t6 標識。
行
Bigtable 通過行關鍵字的字典順序來組織數據。表中的每個行都可以動態分區。每個分區叫做一個」Tablet」，Tablet 是數據分布和負載均衡調整的最小單位。
列族
Webtable 有個列族language，language 列族用來存放撰寫網頁的語言。
我們在language 列族中只使用一個列關鍵字，用來存放每個網頁的語言標識ID。Webtable 中另一個有用的列族是anchor；這個列族的每一個列關鍵字代表一個錨鏈接，如圖一所示。Anchor 列族的限定詞是引用該網頁的站點名；Anchor 列族每列的數據項存放的是鏈接文本。訪問控制、磁碟和內存的使用統計都是在列族層面進行的。
時間戳
不同版本的數據通過時間戳來索引。Bigtable 時間戳的類型是64 位整型。
Bigtable 可以給時間戳賦值，用來表示精確到毫秒的「實時」時間；用戶程序也可以給時間戳賦值。如果應用程序需要避免數據版本沖突，那麼它必須自己生成具有唯一性的時間戳。數據項中，不同版本的數據按照時間戳倒序排序，即最新的數據排在最前面。為了減輕多個版本數據的管理負擔，我們對每一個列族配有兩個設置參數， Bigtable 通過這兩個參數可以對廢棄版本的數據自動進行垃圾收集。用戶可以指定只保存最後n 個版本的數據，或者只保存「足夠新」的版本的數據（比如，只保存最近7 天的內容寫入的數據）。
Bigtable支持的其他特性
1、Bigtable 支持單行上的事務處理，利用這個功能，用戶可以對存儲在一個行關鍵字下的數據進行原子性的讀-更新-寫操作。
2、Bigtable 允許把數據項用做整數計數器。
3、Bigtable 允許用戶在伺服器的地址空間內執行腳本程序
4、Bigtable 可以和MapRece一起使用，MapRece 是Google 開發的大規模並行計算框架。我們已經開發了一些Wrapper 類，通過使用這些Wrapper 類，Bigtable 可以作為MapRece 框架的輸入和輸出。
Bigtable依賴於google的幾項技術。用GFS來存儲日誌和數據文件；按SSTable文件格式存儲數據；用Chubby管理元數據：
Bigtable是建立在其它的幾個Google基礎構件上的。BigTable 使用Google 的分布式文件系統(GFS)存儲日誌文件和數據文件。BigTable 集群通常運行在一個共享的機器池中，池中的機器還會運行其它的各種各樣的分布式應用程序，BigTable 的進程經常要和其它應用的進程共享機器。BigTable 依賴集群管理系統來調度任務、管理共享的機器上的資源、處理機器的故障、以及監視機器的狀態。
BigTable 內部存儲數據的文件是Google SSTable 格式的。SSTable 是一個持久化的、排序的、不可更改的Map 結構，而Map 是一個key-value 映射的數據結構，key 和value 的值都是任意的Byte串，從內部看，SSTable 是一系列的數據塊（通常每個塊的大小是64KB，這個大小是可以配置的）。。SSTable 使用塊索引（通常存儲在SSTable 的最後）來定位數據塊；在打開SSTable的時候，索引被載入到內存。每次查找都可以通過一次磁碟搜索完成：首先使用二分查找法在內存中的索引里找到數據塊的位置，然後再從硬碟讀取相應的數據塊。也可以選擇把整個SSTable 都放在內存中，這樣就不必訪問硬碟了。
BigTable 還依賴一個高可用的、序列化的分布式鎖服務組件，叫做Chubby。Chubby有五個活躍副本，同時只有一個主副本提供服務，副本之間用Paxos演算法維持一致性，Chubby提供了一個命名空間（包括一些目錄和文件），每個目錄和文件就是一個鎖，Chubby的客戶端必須和Chubby保持會話，客戶端的會話若過期則會丟失所有的鎖。
Bigtable 包括了三個主要的組件：鏈接到客戶程序中的庫、一個Master主伺服器和多個Tablet片 伺服器。
Bigtable會將表（table）進行分片，片（tablet）的大小維持在100-200MB范圍，一旦超出范圍就將分裂成更小的片，或者合並成更大的片。每個片伺服器負責一定量的片，處理對其片的讀寫請求，以及片的分裂或合並。片伺服器可以根據負載隨時添加和刪除。這里片伺服器並不真實存儲數據，而相當於一個連接Bigtable和GFS的代理，客戶端的一些數據操作都通過片伺服器代理間接訪問GFS。主伺服器負責將片分配給片伺服器，監控片伺服器的添加和刪除，平衡片伺服器的負載，處理表和列族的創建等。注意，主伺服器不存儲任何片，不提供任何數據服務，也不提供片的定位信息。
客戶端需要讀寫數據時，直接與片伺服器聯系。因為客戶端並不需要從主伺服器獲取片的位置信息，所以大多數客戶端從來不需要訪問主伺服器，主伺服器的負載一般很輕。
Master 伺服器主要負責以下工作：為Tablet 伺服器分配Tablets、檢測新加入的或者過期失效的Table 伺服器、對Tablet 伺服器進行負載均衡、以及對保存在GFS 上的文件進行垃圾收集。除此之外，它還處理對模式的相關修改操作，例如建立表和列族。
我們使用一個三層的、類似B+樹的結構存儲Tablet 的位置信息。
第一層是一個存儲在Chubby 中的文件，它包含了Root Tablet 的位置信息。這個Chubby文件屬於Chubby服務的一部分，一旦Chubby不可用，就意味著丟失了root tablet的位置，整個Bigtable也就不可用了。
第二層是root tablet。root tablet其實是元數據表（METADATA table）的第一個分片，它保存著元數據表其它片的位置。root tablet很特別，為了保證樹的深度不變，root tablet從不分裂。
第三層是其它的元數據片，它們和root tablet一起組成完整的元數據表。每個元數據片都包含了許多用戶片的位置信息。
片的數據最終還是寫到GFS里的，片在GFS里的物理形態就是若干個SSTable文件。下圖展示了讀寫操作基本情況。
BigTable和GFS的關系
集群包括主伺服器和片伺服器，主伺服器負責將片分配給片伺服器，而具體的數據服務則全權由片伺服器負責。但是不要誤以為片伺服器真的存儲了數據（除了內存中memtable的數據），數據的真實位置只有GFS才知道，主伺服器將片分配給片伺服器的意思應該是，片伺服器獲取了片的所有SSTable文件名，片伺服器通過一些索引機制可以知道所需要的數據在哪個SSTable文件，然後從GFS中讀取SSTable文件的數據，這個SSTable文件可能分布在好幾台chunkserver上。
一個簡化的Bigtable結構圖：
結構圖以Webtable表為例，表中存儲了網易、網路和豆瓣的幾個網頁。當我們想查找網路貼吧昨天的網頁內容，可以向Bigtable發出查詢Webtable表的(com..tieba, contents:, yesterday)。
假設客戶端沒有該緩存，那麼Bigtable訪問root tablet的片伺服器，希望得到該網頁所屬的片的位置信息在哪個元數據片中。使用 METADATA.Webtable.com..tieba 為行鍵在root tablet中查找，定位到最後一個比它大的是 METADATA.Webtable.com..www ，於是確定需要的就是元數據表的片A。訪問片A的片伺服器，繼續查找 Webtable.com..tieba ，定位到 Webtable.com..www 是比它大的，確定需要的是Webtable表的片B。訪問片B的片伺服器，獲得數據。
這里需要注意的是，每個片實際都由若干SSTable文件和memtable組成，而且這些SSTable和memtable都是已排序的。這就導致查找片B時，可能需要將所有SSTable和memtable都查找一遍；另外客戶端應該不會直接從元數據表獲得SSTable的文件名，而只是獲得片屬於片伺服器的信息，通過片伺服器為代理訪問SSTable。
⑹ 如何自己在linux上搭建類似雲盤的分布式雲存儲
如何自己在linux上搭建類似雲盤的分布式雲存儲
對分布式的要求（彈性可伸縮、高可用）的需求，只是為了整合多個電腦的存儲資源，並且還想要一個漂亮的操作界面的話，最簡單的方法其實是用iscsi將其他電腦的存儲資源掛載到伺服器，然後使用seafile提供服務。
如果真正的有對分布式存儲的需求並且對界面沒什麼需求或者打算自己開發一個界面的話，swift，ceph，glusterFS都是可以考慮的可靠的技術。（需求簡單的話swift還是有很多界面的，也是可以考慮
⑺ GFS採用了哪些容錯措施來確保整個系統的可靠性
GFS的精彩在於它採用了多種方法，從多個角度，使用不同的容錯措施來確保整個系統的可靠性。
客戶端在訪問GFS時，首先訪問Master節點，獲取將要與之進行交互的Chunk Server信息，然後直接訪問這些Chunk Server完成數據存取。GFS的這種設計方法實現了控制流和數據流的分離。Client與Master之間只有控制流，而無數據流，這樣就極大地降低了Master的負載，使之不成為系統性能的一個瓶頸。Client與Chunk Server之間直接傳輸數據流，同時由於文件被分成多個Chunk進行分布式存儲，Client可以同時訪問多個Chunk Server，從而使得整個系統的I/O高度並行，系統整體性能得到提高。
⑻ 如何實現高性能分布式文件存儲
其實分布式文件存儲，最復雜的就是元數據的保存和處理，而我使用的XGFS文件存儲軟體只需要三個全快閃記憶體元數據高可用節點，就可以高效保存和處理 100 億文件規模的數據，可以靈活擴展，滿足公司不斷增長的業務對性能和容量的需求，XSKY星辰天合這款產品還是很有性價比的。
⑼ GFS論文筆記
GFS的誕生來源於google日益增長的數據量的處理需求，它是一個可擴展的分布式文件系統，用於大型分布式數據密集型應用，在廉價的通用硬體上運行時提供容錯機制，並且可以為大量客戶端提供較高的聚合性能。
它的設計由當前和預期的應用負載(當時的)和技術環境驅動，與以前的文件系統的假設有著明顯不同，因此gfs在設計上有幾個不同的points：
當前已部署多個集群用於不同目的，最大的擁有1000多個存儲節點，超過300TB的存儲服務，並且有數百個客戶端連續不斷地高負載請求。
前面提到一些對應用負載和技術環境的觀察，現在更詳細地進行闡述：
雖然GFS不能提供像POSIX標準的API，但它提供一個相似的文件系統介面。文件在目錄中按層次結構組織，並以路徑名作為標識。支持create、delete、open、close、read and write files。
gfs支持快照和record append操作。快照以低代價創建文件副本或者目錄樹，record append支持多個客戶端並發地寫文件，保證每個獨立客戶端append的原子性。
一個gfs集群包含一個master和多個chunkservers，chunkserver被多個客戶端訪問，如圖1所示。每一個都是普通linux機器上運行的用戶態服務進程。資源允許的情況下，客戶端可以和chunkserver部署在同一台機器上。
文件被劃分為固定大小的塊。每個chunk由一個獨一無二的64位大小的chunk handle所標識，chunk handle在chunk被創建時由master分配。每個chunk的副本分布在多個機器上，系統默認為三副本模式，用戶也可以為不同namespace的文件指定不同級別的副本。
master包含文件系統的所有元信息。包含namespace、訪問控制許可權信息、文件到chunks的映射、當前chunks的位置信息。也控制著全局的活動，像chunk租約管理、gc、chunk遷移等。master通過心跳的方式與每個chunkserver交流來發送它的指令和收集狀態。
客戶端與master的交互涉及元信息操作，所有數據操作直接與chunkserver交互。gfs不提供POSIX標准API，因此不需要掛接到linux的vnode層。
客戶端和chunkserver都不緩存文件數據。大多數應用傳輸大文件，客戶端緩存收益很低。chunks作為本地的文件存儲，linux系統有自己的buffer cache，chunkserver不需要再增加緩存。
單master簡化了系統的設計，但是會有單點的瓶頸問題，這是必須要解決的。客戶端不會從master讀寫數據文件，客戶端請求master它需要的交互的chunkserver信息，並且將其緩存一段時間，後續的操作直接與chunkservers交互。
客戶端會發送請求給離它最近的一個副本。實際上，客戶端通常會向master請求多個chunk的信息，以減少未來與maser交互的代價。
chunk size定為64MB，相比普通的文件系統的block size更大。每個chunk副本以linux文件的形式存在chunkserver上，僅根據需要來擴展。使用lazy space allocation的方式避免空間浪費。
large chunk size有以下幾個優點：
但是large chunk size with lazy space allocation也有其缺點：單個文件可能包含很少數量的chunks，或許只有一個，當許多客戶端訪問相同文件時這些chunks成為熱點。但由於目標應用大多是順序的讀多個large chunk文件，熱點並不是主要的問題。
然而GFS第一次用於批處理隊列系統時確實出現了熱點問題，數百個客戶端同時訪問一個單chunk文件，存儲這個文件的幾個chunkserver超負荷運轉，當時通過錯開應用的啟動時間避免了這個問題，一個潛在、長期的解決方法是允許客戶端從其它客戶端讀取數據。
master保存三種類型的元數據：
所有元數據都保存在內存中 。對於元數據的內存操作是很快的，後台任務周期巡檢整個狀態也是比較簡單高效的。周期巡檢用於實現chunk gc、在chunkserver故障時重新構造副本、chunk遷移以平衡多個chunkserver的負載和disk usage。
雖然系統的容量受master內存大小的限制，但這並不是一個嚴重的問題，64MB的chunk只需要不到64byte大小的元信息，如果一定需要更大的文件系統，那麼增加內存的代價相比為可靠性、性能和靈活性等付出的代價是較小的。
前兩種類型的元數據通過寫日誌來保證持久化，並且會復制日誌到遠程機器上。master不需要將chunks的位置信息持久化，而是在master啟動和新的chunkserver加入集群時向每個chunkserver詢問它的位置信息，之後通過心跳信息監控chunk位置變更信息。chunkserver作為最後一關是確切知道自己本地有沒有哪些chunk的，因此維護一個一致性的視圖是沒有必要的。
operation log 包含元數據的變更記錄， 它是GFS的核心 ，它不僅僅是唯一的元數據持久化記錄，也表明了並發操作的邏輯時間線。文件、chunks和它們的版本都是由邏輯時間線唯一標識。元數據變更記錄在持久化之前對客戶端是不可見的，而且日誌被復制到多個遠程的機器，只有相應的記錄在本地和遠程都持久化到硬碟了才可以回復客戶端。master使用批處理log的方式提高系統的吞吐。
master通過回放日誌來恢復文件系統的狀態，為提高恢復速度需要保持log量足夠小。當log增長超過特定大小時，master會checkpoint它的狀態，以加速恢復提高可用性。構建checkpoint可能需要花費一段時間，因此master以一種不delay後續變化的方式來組織內部狀態，先switch到一個新的日誌文件，使用獨立的線程創建checkpoint，新的checkpoint包含了所有switch之前的變化。幾百萬個文件的集群在一分鍾內可以完成，完成後將同時被寫入本地和遠程。恢復只需要最新的checkpoint和之後的日誌文件，舊的checkpoints和日誌文件可以完全刪除。
GFS使用一個寬松的一致性模型，這種模型可以很好地支持分布式應用程序，而且實現起來簡單有效。
file namesapce變化(例如文件創建)是原子的，使用namespace鎖。
master的operation log定義了這些操作的全局順序。
數據變化後文件region的狀態取決於變化的類型，是否成功、失敗或者是並發的。Table1做了總結。如果所有客戶端都能看到相同的數據，無論它們讀的是哪個副本，則這個file region是一致的。
數據變化有兩種：writes或者record appends。write是指從應用指定offset處開始寫數據，record append指即使存在並發沖突，數據也要被原子地append到文件至少一次，但offset是由GFS選定。
GFS保證在一系列成功的mutations後，file region是defined，通過下面兩點來保證：
過期的副本將不會再涉及到任何mutation，master也不會將其位置信息回應給客戶端，不久後將會被gc。但客戶端緩存的信息可能包含過期的副本，緩存失效存在一個時間窗口，文件再次打開也會清除該文件的所有chunk信息。由於大多數文件是append-only，過期的副本通常返回的是過早的結尾???而不是過期的數據。
介紹客戶端、master和chunkserver之間如何交互來實現數據變化、原子追加寫和快照的。
使用租約的方式維護多個副本間一致的mutation order。master授權租約給副本中的一個，稱之為primary。primary為chunk的mutaions選擇一個順序，所有副本都按照這個順序apply。
租約機制最小化了master的管理overhead。租約初始的超時時間是60s，如果chunk一直在變化過程中，primary可以申請續租。這些授權和續租請求由master和chunkserver之間的心跳信息攜帶。master也可以嘗試撤銷租約，即使它與primary失去了聯系，也可以等租約過期後安全地授權給另外一個副本。
在Figure2中，跟隨著寫入控制流展示了處理過程：
如果一個寫請求比較大或者超出了chunk邊界，GFS客戶端將它拆為多個寫操作，但是多個操作可能與其它客戶端並發交叉寫入，因此共享的fie region最終可能包含多個不同客戶端的碎片，這會造成 一致性模型 中所描述的file region處於consistent but undefined狀態。
數據以pipline的機制在chunkserver鏈上線性傳輸，而控制流是從客戶端到primary再到所有的其它副本。分離數據流和控制流可以更高效地使用網路。可以帶來以下好處：
GFS提供原子的append operaton叫作 record append 。傳統的write中，客戶端指定offset，並發寫相同region時不是serializable，最終region可能包含多個客戶端的碎片數據。而對於record append，客戶端僅指定數據，GFS保證至少一次成功的原子append，offset由GFS選定，與Unix的O_APPEND模式相似。
多個客戶端並發操作相同文件是比較重的。如果處理傳統的write，客戶端需要額外復雜和昂貴的同步邏輯，像分布式鎖。而record append僅需要primary增加一點額外的邏輯：primary檢查是否並發append數據的chunk會超出max size，如果會超出則將chunk填充到max size，並且告訴所有二級副本同樣操作，然後回應客戶端指出這個操作應該選擇另一個chunk重試；大多數情況下記錄是在max size內的，primary將數據append到自己的副本，並告訴所有二級副本按照確切的offset寫數據，最後回應給客戶端。
如果中間出現錯誤，客戶端重試，相同chunk的副本可能包含不同的數據，可能包含相同的記錄或者一部分相同，GFS不保證bytewise identical，僅僅保證數據至少有一次被成功地原子寫入。從report success邏輯可以容易得出，數據必須是在某個chunk的所有副本上以相同的offset寫入。在此之後，所有副本都與記錄end一樣長，即使後面不同的副本成為primary，任何將來的記錄也將分配到更高的offset或者不同的chunk。根據上述的一致性保證，成功的record append的region是defined和一致的，而中間的region是不一致的(undefined)。GFS的應用可以處理這種不一致的region(2.7.2)。
snapshot 操作拷貝一份文件或者目錄樹，幾乎是實時的，同時最大程度減少對正在進行中的mutation的干擾。
像AFS一樣，使用標準的COW技術實現snapshot。當master接收到一個snapshot請求，首先將所有涉及到chunks的租約撤銷，這保證了這些chunks後續的write將會先請求master查找租約持有者，master會創建一個新的副本來回應。
租約被撤銷或者過期後，master將這個操作記錄日誌到disk。新創建的snapshot引用元數據相同的chunks。
當snapshot操作完成後，客戶端第一次要寫chunk C，發送請求給master查詢持有租約者，master察覺到chunk C的引用大於1，則讓每個含有當前chunk副本的chunkserver創建一個新的chunk叫作C'，所有創建都使用本地的副本，相比100Mb的網路本地速度大約是三倍速度。master授權租約給新的chunk C'中的一個並且回復給客戶端，之後正常地寫chunk。整個過程對客戶端是透明的。
master執行所有的namespace操作。另外，它管理整個系統的chunk副本：
接下來，詳細探討這些細節。
許多master操作可能花費較長一段時間，比如snapshot操作需要撤銷相關的所有chunks的租約。因此為了不delay其它master操作，在namesapce的regions上使用locks來確保串列化。
GFS沒有按目錄列出該目錄中所有文件的結構，也不支持文件和目錄的別名(unix中的硬鏈和軟鏈)。GFS將完整的路徑名到元數據的映射表作為它的邏輯namespace。使用前綴壓縮，這個表可以有效保存在內存中。namespace tree中的每個節點都有一個關聯的讀寫鎖。
每個master操作在運行前都會獲取一組鎖。如果涉及到/d1/d2/../dn/leaf，它將獲取目錄名稱/d1、/d1/d2、...、/d1/d2/.../dn上的讀鎖，完整路徑/d1/d2/../dn/leaf的讀鎖或者寫鎖。leaf可以是文件或者目錄。
創建文件不需要對父級目錄加鎖，因為沒有"目錄"的概念不會修改它，而加讀鎖是防止它被刪除、重命名或者snapshot。這種鎖機制的好處是允許相同目錄下並發的mutations。
一個GFS集群通常具有分布在多個機架上的數百個chunkserver，這些chunkserver也會被相同或者不同機架的數百個客戶端訪問。不同機架上的兩台計算機之間的通信可能會跨越一個或者多個網路交換機。另外進出機架的帶寬可能小於機架內所有計算機的總帶寬。多級分布式對如何分發數據以實現可伸縮性、可靠性和可用性提出了獨特的挑戰。
副本放置策略有兩個目的：最大化數據可靠性和可用性，最大化網路帶寬利用率。不僅要在多台機器上放置，還要在多個racks上，即使整個racks損壞也可以確保部分副本保持可用。也可以利用多個racks的總帶寬。
chunk副本創建有三個原因：
當master創建新的chunk時，根據幾個因素考慮如何放置新的副本：
當chunk可用副本的數量低於用戶指定時，master會重新復制。可能發生在幾種情況：
需要重新復制的chunk根據以下幾個因素確定優先順序：
master限制集群和每一個chunkserver內的活躍的clone數量，另外chunkserver通過限制其對源chunkserver的讀請求來限制在每個clone操作上花費的帶寬。
master會定期重新平衡副本：檢查當前副本的分布，遷移副本以獲得更好的磁碟空間利用率和負載平衡。同樣通過此過程，master逐漸填充一個新的chunkserver。另外，master通常更傾向於移除具有低磁碟利用率chunkservers上的副本，以平衡空間使用。
當文件被刪除時，master記錄日誌，但不會立即回收資源，而是將文件重命名為包含刪除時間戳標記的隱藏名稱。如果這些文件存在時間超過三天(時間可配置)，master巡檢時會將其刪除。在此之前，仍然可以用特殊名稱來讀取文件，並且可以重命名為正常名稱來取消刪除。當從namesapce中刪除隱藏文件時，其內存元數據將被刪除，這有效切斷了所有chunk的連接，在對chunk namespace的掃描中，master識別出孤立的chunk並清除元數據。在心跳信息中，每個chunkserver報告其擁有的chunks子集，而master將回應不在存在於master元數據中的所有的chunk的標識。chunkserver可以自由刪除此類chunk的副本。
這種gc機制相比立即刪除有以下幾個優點：
這種機制主要的缺點是當存儲空間緊張時，延遲有時會影響用戶的使用，重復創建和刪除臨時文件的應用可能無法立即重用存儲。如果刪除的文件再次被明確刪除，GFS將通過加快存儲回收來解決這些問題。還允許用戶將不同的復制和回收策略應用於不同的namespace的不同部分中。
如果一個chunkserver故障或者chunk丟失了mutations，這個chunk副本可能是過期的。對於每個chunk，master都維護了一個chunk版本號。
當master授權租約給一個chunk時，這個chunk的版本號增加1，如果一個副本當前不可用了，則其版本號將不會領先。當chunkserver重新啟動並報告其chunks集合和相關聯的版本號時，master將檢測到該chunkserver上具有過期的副本。如果master看到的版本號大於它記錄的版本號，則認為在授權租約時失敗了，因此將較高的版本號更新。
master在常規gc中刪除舊的副本。另一個保護措施，在master回應客戶端哪個chunk持有租約或者clone操作中chunkserver從另一個chunkserver讀取chunk時會包含chunk的最新版本號。客戶端或者chunkserver在執行操作時會驗證版本號。
這個系統最大的挑戰之一是處理經常故障的組件。組件的質量和數量造成的問題會超出預期，組件故障可能造成系統不可能，甚至數據錯誤。接下來討論GFS如何應對這些挑戰，還有系統如何診斷不可避免問題。
使用兩個簡單有效的方式保證系統的高可用：快速恢復和復制。
master和chunkserver的恢復都是秒級別的。
master維護每個chunk的副本數量，當chunkserver下線或者checksum檢測出錯誤副本時，master會通過已有副本來復制。盡管復制提供了很好的解決方式，但仍在探索其它形式的跨伺服器冗餘方案，例如奇偶校驗或者糾刪碼，以適應不斷增長的只讀存儲需求。在非常松耦合的系統中實現這些更復雜的冗餘方案更具有挑戰性。
master的操作日誌和checkpoint會被復制到多台機器上，狀態的變化只有在本地和所有副本上都持久化以後才可以commit。master進程負責所有的mutations以及後台任務，當它宕機時可以很快重啟，如果機器或者磁碟故障，GFS的外部監控將使用日誌在其它節點重啟新的master進程。在master宕機時，master的備節點只提供只讀服務，它們不與master保持強一致，可能會落後於master，通常在1/4秒內。它們保證了那些不介意讀到過期數據的應用的高可用讀。類似於chunk的primary機制，master的備按照相同的序列應用日誌。與master一樣，在啟動時從每個chunkserver拉取chunks的位置信息，與它們頻繁交換握手消息來監控其狀態。
每個chunkserver使用checksum來檢測存儲數據的損壞。數據損壞的chunk可以通過其它的副本來恢復，但是通過副本間比較來檢驗數據是不切實際的。正常的副本也不是完全一樣的，如前文所講，原子的append並不能保證完全一樣的副本。因此每個chunkserver會維護自己的checksum。
每個chunk分為多個64kb的blocks，每個block包含一個32位的checksum，與其它元數據一樣，checksum保存在內存中，依靠log持久化，與用戶數據分離。
對於讀，chunkserver在返回數據給請求者前先檢測checksum，確保不會將出錯的數據傳輸給其它chunkservers或者客戶端。如果數據是壞的，chunkserver將錯誤返回給請求者並報告給master，請求者將會去讀其它副本， master將會根據其它副本重新克隆一份。當新的副本創建以後，master指示chunkserver將錯誤的副本刪除。checksum的計算不涉及I/O，對讀的影響比較小，客戶端通常嘗試使用對齊block邊界讀來減少overhead。
為append寫是做了checksum計算上的優化的，因為append寫是主要的負載(相比於overwrite)。GFS只增量地更新最後部分block的checksum，為新的block的計算新的checksum。這樣即使block已經損壞，新的checksum將與存儲的數據不會匹配，下次讀時將會與正常一樣被檢測出來。
如果一個寫請求要寫一個chunk中已存在的region，必要要先檢驗region的第一個和最後一個block的checksum，然後再重寫，最後計算新的checksums。因為第一個和最後一個block可能含有不被重寫的內容，如果這部分數據是損壞的，則新的checksum將包含錯誤的數據。
在idle時，checkserver可以掃描並檢查不活躍的chunks，可以檢測到冷chunks的錯誤，一旦錯誤被檢測到，master可以創建一個新的副本。
GFS在設計上與傳統文件系統有很多不同，這些點是基於對當時應用負載和技術環境的觀察所重新設計，將組件故障看作平常的事件而非異常，為大文件的讀取和追加寫做優化，擴展和放寬了標準的文件系統介面以改善整個系統。通過監控、復制以及快速恢復能力提供容錯能力，使用checksum機制來校驗數據的正確性。通過將控制流和數據流分離，數據直接在chunkservers、客戶端之間傳輸，為許多並發的各種任務的讀取和寫入提供了高吞吐量。大chunk size和租約機制使得master的操作足夠輕量化，使得這樣一個簡單中心化的master不會成為瓶頸。
GFS成功地滿足了google的存儲需求，作為研究、開發和數據處理的存儲平台廣泛地應用於google內部。
⑽ 介紹一下雲計算的核心技術
雲計算系統運用了許多技術，其中以編程模型、數據管理技術、數據存儲技術、虛擬化技術、雲計算平台管理技術最為關鍵。
(1)編程模型
MapRece是Google開發的java、Python、C++編程模型，它是一種簡化的分布式編程模型和高效的任務調度模型，用於大規模數據集（大於1TB）的並行運算。嚴格的編程模型使雲計算環境下的編程十分簡單。MapRece模式的思想是將要執行的問題分解成Map(映射)和Rece(化簡)的方式，先通過Map程序將數據切割成不相關的區塊，分配（調度）給大量計算機處理，達到分布式運算的效果，再通過Rece程序將結果匯整輸出。
(2) 海量數據分布存儲技術
雲計算系統由大量伺服器組成，同時為大量用戶服務，因此雲計算系統採用分布式存儲的方式存儲數據，用冗餘存儲的方式保證數據的可靠性。雲計算系統中廣泛使用的數據存儲系統是Google的GFS和Hadoop團隊開發的GFS的開源實現HDFS。
GFS即Google文件系統（Google File System），是一個可擴展的分布式文件系統，用於大型的、分布式的、對大量數據進行訪問的應用。GFS的設計思想不同於傳統的文件系統，是針對大規模數據處理和Google應用特性而設計的。它運行於廉價的普通硬體上，但可以提供容錯功能。它可以給大量的用戶提供總體性能較高的服務。
一個GFS集群由一個主伺服器（master）和大量的塊伺服器(chunkserver)構成，並被許多客戶（Client）訪問。主伺服器存儲文件系統所以的元數據，包括名字空間、訪問控制信息、從文件到塊的映射以及塊的當前位置。它也控制系統范圍的活動，如塊租約（lease）管理，孤兒塊的垃圾收集，塊伺服器間的塊遷移。主伺服器定期通過HeartBeat消息與每一個塊伺服器通信，給塊伺服器傳遞指令並收集它的狀態。GFS中的文件被切分為64MB的塊並以冗餘存儲，每份數據在系統中保存3個以上備份。
客戶與主伺服器的交換只限於對元數據的操作，所有數據方面的通信都直接和塊伺服器聯系，這大大提高了系統的效率，防止主伺服器負載過重。
(3) 海量數據管理技術
雲計算需要對分布的、海量的數據進行處理、分析，因此，數據管理技術必需能夠高效的管理大量的數據。雲計算系統中的數據管理技術主要是Google的BT(BigTable)數據管理技術和Hadoop團隊開發的開源數據管理模塊HBase。
BT是建立在GFS, Scheler, Lock Service和MapRece之上的一個大型的分布式資料庫，與傳統的關系資料庫不同，它把所有數據都作為對象來處理，形成一個巨大的表格，用來分布存儲大規模結構化數據。
Google的很多項目使用BT來存儲數據，包括網頁查詢，Google earth和Google金融。這些應用程序對BT的要求各不相同：數據大小（從URL到網頁到衛星圖象）不同，反應速度不同（從後端的大批處理到實時數據服務）。對於不同的要求，BT都成功的提供了靈活高效的服務。
（4）虛擬化技術
通過虛擬化技術可實現軟體應用與底層硬體相隔離，它包括將單個資源劃分成多個虛擬資源的裂分模式，也包括將多個資源整合成一個虛擬資源的聚合模式。虛擬化技術根據對象可分成存儲虛擬化、計算虛擬化、網路虛擬化等，計算虛擬化又分為系統級虛擬化、應用級虛擬化和桌面虛擬化。
（5）雲計算平台管理技術
雲計算資源規模龐大，伺服器數量眾多並分布在不同的地點，同時運行著數百種應用，如何有效的管理這些伺服器，保證整個系統提供不間斷的服務是巨大的挑戰。
雲計算系統的平台管理技術能夠使大量的伺服器協同工作，方便的進行業務部署和開通，快速發現和恢復系統故障，通過自動化、智能化的手段實現大規模系統的可靠運營。
我是從IT號外知道的。