大家好，我是不才陳某~
YouTube 是僅次於Google的第二大熱門網站。在 2019 年 5 月，每分鐘會有超過 500 小時的影片內容上傳到該平台。
這個影片分享平台有超過 20 億的用戶，每天有超過10億小時的影片被播放，產生數十億的瀏覽量。這些都是令人難以置信的數字。
本文將對 YouTube 使用的資料庫和後端資料基礎設施進行深入講解，它們使得該影片平台能夠儲存如此巨量的數據，並能擴展至數十億的用戶。
那我們就開始吧。
YouTube 的旅程開始於 2005 年。隨著這家由風險資本資助的技術新創公司不斷取得成功，它於 2006 年 11 月被谷歌以 16.5 億美元收購。
在被Google收購之前，它們的團隊由以下人員組成：
YouTube的後端微服務是由Python、資料庫、硬體、Java（使用了Guice框架）和Go 編寫的。使用者介面是使用JavaScript編寫的。
主要的資料庫是由 Vitess 支撐的 MySQL，Vitess是一個資料庫叢集系統，用於 MySQL 的水平擴展。另外，使用 Memcache 實作快取並使用 Zookeeper 進行節點的協調。
流行的影片透過 CDN 來提供，而一般的、較少播放的影片則從資料庫中取得。
每個視頻在上傳的時候，都會賦予一個唯一的標識符並且會由一個批處理job 進行處理，該job 會運行多個自動化的過程，比如生成縮圖、元數據、視頻腳本、編碼、設定貨幣化狀態等。
VP9 & H.264/MPEG-4 AVC 高級視訊編碼（Advanced Video Coding codecs）會用於視訊壓縮，它能夠使用其他編碼器一半的頻寬來編碼 HD 和 4K 品質的視訊。
視訊串流則是使用基於HTTP協定的動態自適應串流（Dynamic Adaptive Streaming），這是一種自適應位元速率的串流技術，能夠從傳統的HTTP Web 伺服器上實現高品質的視訊串流。透過這種技術，內容可以按照不同的比特率提供給觀眾。 YouTube 用戶端會根據觀看者的網路連線速度自動適應影片渲染，從而盡可能減少緩衝時間。
我曾經在一篇專門的文章中討論過 YouTube 的影片轉碼過程，請參閱「YouTube是如何以低延遲提供高品質的影片」。
所以，這裡對平台的後端技術有一個快速的介紹。 YouTube 主要使用的資料庫是 MySQL。現在，我們來了解一下 YouTube 的工程團隊為什麼覺得有必要寫 Vitess？他們在最初的 MySQL 環境中面臨的問題是什麼，使他們在此基礎上實現了一個額外的框架？
網站最初只有一個資料庫實例。隨著網站的發展，為了滿足日益增長的 QPS（每秒查詢次數）需求，開發人員不得不對資料庫進行水平擴展。
副本會加入到主資料庫實例。讀取請求會被路由到主資料庫和副本上，以減少主資料庫的負載。新增副本有助於緩解瓶頸，增加讀取的吞吐量，並增加系統的持久性。
主節點處理寫入的流量，主節點和副本節點同時處理讀取流量。
但是，在這種場景中，有可能會從副本中讀取到陳舊的資料。如果在主節點將資訊更新到副本之前，一個請求讀取了副本的數據，那麼觀看者就會得到陳舊的數據。
此時，主節點和副本節點的資料是不一致的。在這種情況下，不一致的資料是主節點和副本節點上特定影片的觀看次數。
其實，這完全沒有問題。觀眾不會介意觀看次數上略微有點不一致，對吧？更重要的是，影片能夠在他們的瀏覽器中渲染出來。
主節點和副本節點之間的資料最終會是一致的。
因此，工程師們覺得非常開心，觀眾們也非常開心。隨著副本的引入，事情進展順利。
網站繼續受到歡迎，QPS 繼續上升。主-從副本策略現在很難跟上網站流量的增長了。
那現在該怎麼辦？
下一個策略就是對資料庫進行分片（shard）。分片是除了主-從副本、主-主副本、聯盟和反範式化（de-normalization） 之外，擴展關係型資料庫的方式之一。
資料庫分片並不是一個簡單的過程。它大大增加了系統的複雜性，並使得管理更加困難。
但是，資料庫必須要進行分片，以滿足 QPS 的成長。在開發人員將資料庫分片後，資料會被分散到多台機器上。這增加了系統寫入的吞吐量。現在，不再是只有一個主實例處理寫入，寫入操作可以在多台分片的機器上進行。
同時，每台機器都創建了單獨的副本，以實現冗餘和吞吐。
該平台的受歡迎程度持續上升，大量的數據被內容創作者不斷添加到資料庫中。
為了防止機器故障或外部未知事件造成的資料遺失或服務不可用，此時需要在系統中新增災難管理的功能了。
災難管理指的是面臨停電和自然災害（如地震、火災）時的緊急措施。它需要進行冗餘，並將用戶資料備份到世界不同地理區域的資料中心。遺失使用者資料或服務不可用是不允許的。
在世界範圍內擁有多個資料中心也有助於 YouTube 減少系統延遲，因為使用者請求會被路由到最近的資料中心，而不是路由到位於不同大陸的原始伺服器。
現在，你可以想像基礎架構會變得多複雜。
經常會有未經最佳化的全表掃描導致整個資料庫癱瘓。資料庫必須進行保護，防止受到不良查詢的影響。所有的伺服器都需要被追蹤以確保服務的高效性。
開發人員需要有一個系統來抽象系統的複雜性，能夠讓他們解決可擴展性的挑戰，並以最小的成本管理該系統。這一切促使 YouTube 開發了 Vitess。
Vitess是一個運行於 MySQL 之上的資料庫叢集系統，能夠使 MySQL 進行水平擴展。它有內建的分片特性，能夠讓開發人員擴展資料庫，而不必在應用中添加任何的分片邏輯。這類似於 NoSQL 的做法。
Vitess 也會自動處理故障轉移和備份。它能夠管理伺服器，透過智慧重寫資源密集的查詢和實現快取來提高資料庫效能。除了 YouTube，該框架也被其他業界的知名廠商使用，如 GitHub、Slack、Square、New Relic 等。
當你需要 ACID 事務和強一致性的支持，同時又希望像 NoSQL 資料庫一樣快速擴展關係型資料庫時，Vitess 就會大顯身手。
在 YouTube，每個 MySQL 連線都有 2MB 的開銷。每一個連線都有可計算出來的成本，而且隨著連線數量的增加，還必須增加額外的 RAM。
透過基於 Go 程式語言並發支援建置的連接池，Vitess 能夠以很低的成本管理這些連接。它使用 Zookeeper 來管理叢集，並使其保持最新狀態。
Vitess 是雲端原生的，很適合雲端中部署，因為就像雲端的模式一樣，容量是逐步新增到資料庫的。它可以作為一個 Kubernetes 感知（Kubernetes-aware）的雲端原生分散式資料庫運作。
在 YouTube，Vitess 在容器化環境中運行，並使用 Kubernetes 作為容器編排工具。
在現今的運算時代，每個大規模的服務都在分散式環境的雲端中運作。在雲端運行服務有許多好處。
Google Cloud Platform是一套雲端運算服務，它的基礎設施與Google內部的終端用戶產品（如Google搜尋和 YouTube）所使用的基礎設施是相同的。
每個大規模的線上服務都有一個多樣化（polyglot）的持久性架構，因為某一種資料模型，無論是關係型或 NoSQL，都無法處理服務的所有使用情境。
在為本文展開的研究中，我無法找到YouTube 所使用的具體谷歌雲端資料庫的清單，但我非常肯定它會使用GCP 的特有產品，如穀歌 Cloud Spanner、Cloud SQL、Cloud Datastore 、Memorystore 等來運作服務的不同特性。
這篇文章詳細介紹了其他Google服務所使用的資料庫，如Google Adwords、Google Finance、Google Trends等。
YouTube 使用Google的全球網路進行低延遲、低成本的內容傳輸。借助全球分佈的 POP 邊緣點，它能夠使客戶能夠更快地獲取數據，而不必從原始伺服器獲取。
所以，到此為止，我已經談到了 YouTube 使用的資料庫、框架和技術。現在，該談一談儲存問題了。
YouTube 是如何儲存如此龐大的資料量的呢（每分鐘上傳 500 小時的影片內容）？
影片會儲存在Google資料中心的硬碟中。這些資料由 Google File System 和 BigTable 管理。
GFS Google File System是Google開發的分散式檔案系統，用於管理分散式環境中的大規模資料。
BigTable是一個建立在 Google File System 上的低延遲分散式資料儲存系統，用於處理分佈在成千上萬台機器上的 PB 層級的資料。 60 多個谷歌產品都使用了它。
因此，影片被儲存在硬碟中。關係、元資料、使用者偏好、個人資料資訊、帳戶設定、從儲存中取得影片所需的相關資料等都儲存在 MySQL 中。
Google資料中心擁有同質化的硬件，軟體則是內部構建的，管理成千上萬的獨立伺服器叢集。
Google部署的伺服器，能夠增強資料中心的儲存能力，它們都是商用伺服器（commodity server），也被稱為商用現成的伺服器（commercial off-the-shelf server）。這些伺服器價格低廉，可廣泛使用和大量購買，並能以最小的成本和代價替換或配置資料中心的相同硬體。
隨著對額外儲存需求的增加，新的商用伺服器會被插入到系統中。
出現問題後，商用伺服器通常會直接被替換，而不是進行修理。它們不是客製化的，與運行客製化的伺服器相比，使用它們能夠使企業在很大程度上減少基礎設施成本。
YouTube 每天需要超過一個 PB 的新儲存空間。旋轉硬碟驅動器是主要的儲存介質，因為其成本低，可靠性高。
SSD 固態硬碟比旋轉磁碟具有更高的效能，因為它們是基於半導體的，但大規模使用固態硬碟並不划算。
它們相當昂貴，也容易隨著時間的推移逐漸失去資料。這使得它們不適合用於歸檔資料的儲存。
另外，Google正在開發一個適用於大規模資料中心的新磁碟系列。
有五個關鍵指標可用來判斷為資料儲存而建構的硬體的品質：
以上是YouTube 是如何保存巨量影片檔案的？的詳細內容。更多資訊請關注PHP中文網其他相關文章！
