pb blob儲存到image 鵝廠儲存往事

2021-10-12 20:16:27 字數 3781 閱讀 9921

2023年,是中國第二次網際網路浪潮的發始之年。剛剛從破碎泡沫中走出的網際網路產業,逐漸迎來了「web 2.0」時代。

這個時代的特徵,就是去中心化、開放和共享。

越來越多的網際網路使用者,開始以興趣為聚合點,組成社群,分享生活,發表觀點。他們積極參與話題討論,渴望獲得關注和認同。

qq空間,作為「展示自我和與他人互動的平台」,推出之後獲得了極好的反饋,使用者數量快速增長,平台活躍度不斷攀公升。

根據當時的資料統計,qq空間上線的3個季度,註冊使用者數就突破了5000萬,月活躍使用者數約2300萬,日訪問人數超過1300萬。

這種方式,對於qq空間這種爆款產品來說,顯然是無法滿足要求。它帶來的直接後果就是,空間開啟速度越來越慢,使用者體驗越來越差,投訴也越來越多。

當時,業務團隊購買儲存伺服器的速度,根本趕不上使用者增長的速度。

最典型的例子,就是那時候qq空間只允許所有使用者每天上傳800萬張,只有黃鑽使用者才可以無限上傳。

與此同時,競爭對手窺覷qq空間的業務增長,很快推出了相應的競品,意圖趁機搶奪使用者。

內憂外患之下,一支新成立的年輕團隊站了出來,勇挑重擔。

團隊成立之後的首要任務,就是解決qq空間發展所帶來的儲存瓶頸問題。

當時,面對海量資料儲存的難題,不僅是國內,就連海外也沒有什麼可供參考的成熟經驗。唯一可供儲存技術團隊借鑑的,就是此前谷歌公司發表的那幾篇關於bigtable、gfs和mapreduce的**。

如果稍微了解一點大資料知識,就會知道,這幾篇**是海量資料儲存技術的經典之作。谷歌作為一家搜尋引擎公司,當時的主要目的,是從昂貴的企業級儲存轉向大規模廉價分布式儲存,以更低的成本,滿足搜尋引擎業務的需求。

借鑑經驗之後,也是團隊成立的第二年,他們就上線了自主研發的tfs儲存系統,全面接管了qq空間的相簿業務。

tfs系統上線之後,雖然緩解了業務部門的儲存壓力,但並沒有徹底解決問題。當時,系統仍然會出現比較高的延遲,影響使用者的體驗。

高延時的原因,主要是因為相簿業務和搜尋引擎業務之間存在區別。相簿業務中,的資料體量更小,索引密集度更高,所以難度更大,完全照搬搜尋引擎模式並不可行。

於是,儲存技術團隊在tfs系統基礎上進行持續改進,推出了適合不同儲存場景的系統。其中包括支援實時**的ctfs系統、基於hdd的鍵值對tdb儲存平台等。

終於,在持續的改進下,儲存技術團隊徹底解決了qq空間的儲存瓶頸問題。

這個成績的背後,儲存技術團隊功不可沒。

儲存技術團隊一方面瘋狂擴容裝置,另一方面基於資料規模不太大但是訪問量極高的業務特點,快速研發了全記憶體的分布式儲存系統。在保障資料安全可靠的前提下,系統的併發訪問效能得到極大提公升。

快速上線、快速驗證、完全自研,儲存技術團隊「hold」住了局面,再立大功。

第一階段使命的完成,使得儲存技術團隊積累了豐富的經驗。團隊成員的架構設計能力和開發能力也得到了充分的鍛鍊。

很快,他們又迎來了一項新的挑戰。這次遇到的,是頻寬問題

這是乙個標誌性的事件。

儲存平台當時啟動了相簿一通點等專案,海量業務資料開始從深圳向西安、杭州、廣州、上海等地資料遷移,訪問頻寬也同時排程到天津、南京、東莞等成本更低的一通機房。

更讓人意料之外的是,儲存團隊搬遷這些資料的方法,並不是通過專線(因為怕影響公司正常業務),而是通過後半夜閒時的公網出口。他們採用螞蟻搬家式的資料遷移方法,一點一點把資料拷貝到異地資料中心。

這些冷資料占用了大量的儲存空間,為了容災,還進行多重備份,更加消耗資源。

於是,儲存技術團隊就開始做分級儲存。他們優化了系統的分布式儲存架構,研發btfs平台,把資料從三副本降到1.33份的糾刪儲存。他們將qq相簿、微雲,郵件附件等產品中的歷史資料放到btfs裡面去,以此來降低儲存成本。

除此之外,他們還在資料訪問量不大的儲存伺服器上做虛擬化,利用空閒的cpu資源跑計算負載,例如的編譯碼等,充分提公升資源的利用率。

顯然,這是大家印象中程式設計師的」正常操作」,但最終這個名字被確定為yottastore。

對於做儲存的同學來說,經常會跟gb、tb、pb、eb這些概念打交道。現在全球網際網路巨頭公司的資料量基本都是在eb這個量級。eb上面是zb,全球網際網路巨頭資料加起來也就幾個zb。zb再往上,就是yb,也就是yottabyte。目前全世界所有的資料加起來,也不超過乙個yottabyte。

作為乙個雲儲存系統,yottastore的能力可以說是非常強悍:

yottastore是乙個雲原生的資料儲存系統,這個系統的理論極限是乙個集群可以管理超上千萬臺伺服器。而要管理這上千萬臺的機器,元資料管理只需要用600g左右的空間,僅用一台機器就能存下索引結構,這在業界絕無僅有。

當集群規模非常大的時候,1%的剩餘空間量都非常大。所以,yottastore將硬碟利用率提公升到很高的水平,配合實時**機制,有效資料佔比達90%以上。這在業界非常少見。

另外,由於大集群的全集群均衡能力,伺服器資源使用均衡,所以資源使用率也可以做得很高。伺服器硬體可以最低位配置,所有尖峰流量在這個超大的池子裡,波瀾不驚。

所以,無論是成本,還是服務能力,都很大程度受益於超大規模集群帶來的紅利。

yottastore單集群可以零研發成本同時支援各種不同的冗餘模式,像兩副本、三副本、四副本、五副本,任意的ec編碼,任意的m、加任意的n、任意的演算法;單az、雙az、多az,也都可以靈活支援。

另外,整個集群可以自適應各種各樣不同的機型,包括jbod;各種硬碟介質,如磁帶、hdd、ssd等,儲存的拓撲結構、混合部署也都可以任意指定。

這樣的靈活性在業界首屈一指。

以儲存節點迭代公升級為例,十萬百萬規模的乙個集群,上線公升級速度都是一樣的。如果是同構的資料格式,分鐘級就可以完成整個公升級過程。如果是異構的資料格式,集群可以在短時間內自動將資料格式透明收斂到最新版。

可用性達到「數個9」很容易,但是達到100%非常難。例如機房網路抖動,如果容錯做的不夠好,就很容易出現失敗。

yottastore開始上線大規模支撐業務的前三個月,一直維持100%的可用性。到現在一年半了,系統一直單人值周零故障執行,在業界是極少見的。

基於前文所述的在超大規模集群和超高資源利用率上的技術突破,隨著資源利用率的增高,yottastore的單位儲存成本不斷降低。

磁碟容量擴大,單機磁碟數變多,密度增高,成本也隨之降低。此外,cpu、網絡卡等新硬體的變化都會導致成本降低。

針對海量小檔案的使用者場景,yottastore採用多種冗餘和資料組織策略持續優化成本。

他們不會想到,自己所在的公司會推出比qq空間更爆款的產品,自己會面對更嚴峻的考驗。

他們不會想到,自己的使命,從服務內部,到服務外部,從服務c端,到服務b端,不斷轉變。

他們不會想到,自己開發的儲存系統,資料體量規模竟然會從pb到eb,覆蓋全球範圍內30多個region,擁有上萬台伺服器。

他們不會想到,自己所在的團隊,會成為整個公司的「黃埔」軍校,走出了無數的技術專家和管理幹部。

時代就是這樣,前進的步伐太快,永遠超出常人的想象。

能夠擁有這樣的成績並非偶然。成績的背後,既離不開他們對使用者需求的精準把握,也離不開對產品效能的極致挖潛,更離不開對技術夢想的執著追求。

儲存的戰爭還沒有結束,只是進入了乙個新的階段。

未來,有新的挑戰在等待著他們。也有新的機遇,在召喚著他們。再過15年,又會發生什麼樣的故事?不如讓時間來告訴我們答案吧。

把資料儲存到本地

student.h import inte ce student nsobject property nonatomic,copy nsstring name property nonatomic,copy nsstring property nonatomic,assign nsinteger a...

Scrapy item資料儲存到mysql

以下操作是在window環境下進行的 pip install mysqlclient2.新建pipelineitem 類class mysqlpipelineitem object def init self pass def process item self,item,spider pass d...

spark儲存到本地檔案

spark dataframe儲存到本地csv或者txt,會基於hahoop儲存為乙個資料夾如a.csv資料夾。為了儲存為單一檔案的方式如下 1.df.coalesce 1 write.csv result.csv coalesce num returns a newdataframethat ha...