Tera的系統設計

時間 2019-11-13

標籤 tera 系統設計简体版

原文原文鏈接

本文重點介紹百度的萬億量級數據庫Tera的誕生背景、業務場景及需求、設計目標和設計思路。若是您還不瞭解Tera，可參考Tera主頁。git

設計背景

百度的連接處理系統天天處理萬億級的超鏈數據，在過去，這是一系列Mapreduce的批量過程，對時效性收錄很不友好。在新一代搜索引擎架構設計中，咱們採用流式、增量處理替代了以前的批量、全量處理。連接從被發現到存入連接庫再到被調度程序選出，變成一個全實時的過程。在這個實時處理過程當中，不管連接的入庫仍是選取，都須要對連接庫進行修改，存儲系統須要支持千萬甚至上億QPS的隨機讀寫。舊的存儲系統不管在單機性能，仍是在擴展性方面，都沒法知足，因此咱們設計了Tera。github

連接存儲的需求

1. 數據按序存儲

支持主域、站點和前綴等多維度統計、讀取。數據庫

2. 自動負載均衡

分區能夠動態調整，在一個分區數據量變大或者訪問頻率太高時，能夠自動切分，小的分區也能夠自動合併。安全

3. 記錄包含時間戳和多個版本

對於連接歷史抓取狀態等記錄，須要保留多個版本，對於策略回灌等場景，須要根據時間戳判斷，避免舊的數據覆蓋新的。網絡

4. 強一致性

寫入成功，當即可被全部的用戶看到。架構

5. 支持列存儲

在用戶只訪問固定的少數幾列時，能使用更小的IO，提供更高的性能（相對於訪問全記錄），要求底層存儲將這部分列在物理上單獨存儲。負載均衡

設計目標

功能目標

1. 全局有序

key能夠是任意字符串(二進制串)，不限長度，比較邏輯可由用戶定義，按Key的範圍分區，分區內由單機維護有序，分區間由Master維護有序。分佈式

2. 多版本

每一個字段（單元格）均可以保留指定多個版本，系統自動回收過時版本，用戶能夠按時間戳存取。性能

3. 自動分片

用戶不須要關心分片信息，系統自動處理熱點區間的分裂，數據稀疏區間的合併。
單個分區的數據量超過閾值，自動切分爲多個，單個分區的讀寫頻率增高時，自動切分。優化

4. 自動負載均衡和擴容

單機上保存多個分區，分區的總大小和總訪問量達到閾值時，能夠觸發將部分分區遷移到空閒的機器。

5. 局部性羣組(LocalityGroup)

每一個局部性羣組內部包含多個列族，列族內列個數不限制，不一樣局部性羣組在物理上單獨存儲，以提升訪問效率。

6. 行級原子性

對一行的多列進行一次寫入，要麼所有成功，要麼所有失敗。

性能指標

Tera設計使用SSD+SATA磁盤混布機型。

1. 單機吞吐

        順序讀寫: 100MB/S
        隨機讀1KB: 30000QPS
        隨機寫1KB: 30000QPS

2. 延遲

延遲和吞吐須要折衷考慮，在延遲敏感性不高的場合，使用延遲換吞吐策略，延遲定位在10ms級，寫操做延遲<50ms，讀延遲<10ms。
對於對延遲要求高的場合，讀寫延遲定位在<1ms，但吞吐會有損失，初期不作優化重點。

3. 擴展性

水平擴展至萬臺級別機器，單機管理百級別數據分片。

	數據量	系統吞吐
站點信息服務	10TB	百億次/天
用戶行爲分析	1PB	百億次/天
超鏈存儲	10PB	萬億次/天
頁面存儲	100PB	萬億次/天

穩定性指標

能自動處理因爲網絡抖動帶來的各類問題，不會由於少許節點的網絡聯通性問題致使集羣不可用。能處理機器假死帶來的異常，保證及時清除問題機器，不影響整個集羣可用性與吞吐。

1. 數據節點單點故障恢復時間

數據節點故障，分區遷移到其餘數據節點自己代價不大，50ms能夠完成，但頻繁遷移會致使數據本地化喪失，因此設計數據節點30s不可用，才進行切換。

2. Master單點故障恢復時間

爲避免網絡抖動帶來的頻繁切換，設定master的lease過時時間爲10s，10s沒法服務纔會被備份節點取代。

3. 集羣均衡度

設計單機數據量超過集羣平均數據量1.2倍觸發負載均衡操做，單點訪問頻率超過集羣平均負載2倍，且負載超過設計負載，觸發負載均衡操做。

設計思路

數據存儲

1. 數據持久性

爲保證數據安全性，要使用三副本存儲，但維護副本的一致性與副本丟失恢復須要處理大量細節，基於一個分佈式的文件系統構建，能夠顯著下降開發代價，因此咱們選擇了使用DFS（如BFS）。
系統的全部數據（用戶數據和系統元數據）都存儲在DFS上，經過DFS+WriteAheadLog保證數據的持久性，每次寫入，保證在DFS上三副本落地後，才返回成功。