艾位元組俱樂部:LinkedIn 在擴展 Hadoop 分散式檔案系統上的旅程

  1. 橫跨所有 Hadoop 叢集, LinkedIn 現在儲存了1 艾位元組 (exabyte,1 EB 等於 1 百萬 TB) 的總資料量。
  2. 我們最大有 10,000 個節點的叢集儲存了 500 拍位元組(petabyte,1 PB 等於1,000 TB)的資料,那座叢集在單一台提供遠程程序呼叫(RPCs) 的 NameNode 下以平均延遲低於 10 毫秒的水準維護著十億個物件(目錄、檔案、和區塊),讓它成為了業界裡面最大的 Hadoop 之一。

歷史性擴展

圖一、LinkedIn 最大 Hadoop 叢集( 2015 至 2020 )在資料、元資料(meatadata)、以及運算上的指數成長圖。在 2020 年,我們使用了 500 PB (1PB=1,000TB)的儲存容量、16 億件命名空間物件、以及每小時 5,000萬 GB 的運算量。
  1. 叢集上使用到的總資料儲存量——從 2015 年我們有 20 PB 的資料一直成長到 500 PB 的用量。
  2. 命名空件物件的數目(目錄、檔案、區塊)在 2015 年是 1.45 億個物件。 2020 年底,這座叢集有三個命名空間管理單位(namespace volume),當中總共有 16 億個物件,而最大的管理單位超過 10 億個物件。
  3. GbHr 量測了一天裡面這座叢集被所有應用程式使用到的隨機存取記憶體(RAM)的總使用量。運算成長在過去兩年內因著在 LinkedIn 裡機器學習的擴展運用有很大幅度地加速成長。

高可用性和滾動式更新

Java 調教

Java 堆記憶體世代

非公平性上鎖

  1. 公平模式:鎖的取用以先進先出順序去執行(Java 預設)
  2. 非公平模式:鎖的取用能夠不透過順序去索要
圖二、非公平性上鎖讓 NameNode 伺服器的遠程程序呼叫延遲改善了 10 倍。

衛星叢集

小檔案問題

日誌目錄

啟動衛星叢集

相當大的區塊報告

待命中節點的一致性讀取

動機與需求

  1. 強型一致性。客戶端應該要總是能取得 HDFS 的一致性檢視不論他們正連著哪一座 NameNode 伺服器。
  2. 元資料操作的高吞吐量。
  3. 現有應用程式的透明度。客戶端 APIs 應該要將 NameNode 伺服器看成單一服務。

一致性模型

  • 如果客戶端 C 在時間點 t1 看見或是修改了一個在狀態 s1 的物件,那麼在未來任何時間點 t2 > t1 的情況下,客戶端 C 都會是看見物件的狀態 s2 ≥ s1。
  1. 讀取自身寫入(RYOW,read your own writes)
    如果 HDFS 客戶端在運轉節點上修改了命名空間,接著讓觀察者給讀取了,觀察者應該要能看見同樣或是較晚之後的命名空間的狀態,而不是較早先時候的狀態。
  2. 第三方通訊(3PC,third-party communication)
    如果一個客戶端修改了命名空間並且給另一個客戶端傳遞了這份資訊,後者應該要能從觀察者節點讀取命名空間同樣的狀態或是較為之後的狀態但不會是早先時候的狀態。

日誌尾隨:快速路徑

  1. 這份提議引進了最近日誌交易的內存快取。日誌節點服務從記憶體中而不是磁碟中給待命中的節點快取過的交易。
  2. 一個待命中的節點可以索取一系列從 startTxId 開始的交易。日誌節點接著就會從起始 ID 到所設定的最大批次大小回傳所有已知的交易。這允許了細度控制的日誌尾隨,因為通常這類的請求只會回傳一些最近未被應用的交易。
  3. 最後一次交易的請求就是 RPC 呼叫,這比透過 HTTP 傳送分段檔案還快。RPC 呼叫是透過日誌節點的投票性讀取去實作,保證了待命中節點只會看見被確認的交易。
  • 一個觀察者節點在 RYOW 情境中的平均客戶端觀察到的延遲(客戶端從運轉中節點上採用後在觀察者上能看到交易的時間)低於 6 毫秒。
  • 平均的交易處理時間,從一份交易從運轉節點上被遞交到它被觀察者採用,是 25–30 毫秒。

讀取你自己的寫入

第三方通訊:msync()

  1. 啟動時無成本的自動客戶端狀態同步化。當一個 HDFS 客戶端啟動了,它就會發現現有 NameNode 伺服器的 HA 狀態。命名空間狀態 ID 會在這些呼叫中被背著。
  2. 週期性同步化強制客戶端在一段可設定的時間之後自動呼叫 msync()
  3. 總是 msync 模式是前者當時間週期等於零的一個特殊情境,這迫使客戶端在每次讀取請求前會自動呼叫 msync()
  4. 總是運轉模式。客戶端被設定為讀取時不使用觀察者節點。
圖三、觀察者節點一致性讀取的HDFS 叢集架構

效能結果

超越 Hadoop 生態系統的擴展

基於通訊埠的可選擇性資訊加密(port-based selective wire encryption)

  1. 這個方法泛化 NameNode RPC 伺服器在諸多通訊埠的監聽。每一個通訊埠都有自己的安全性設定,定義了是否要執行加密。
  2. 客戶端可以和不同的 NameNode 通訊埠溝通,這讓一個客戶端連線到加密過的通訊埠時會啟用 RPC 呼叫加密。
  3. NameNode 在區塊存取標記(token)中設定了一個欄位指出它要執行的安全性政策。這份標記會被返回給客戶端。
  4. 客戶端如此一來會將區塊存取標記呈現給資料節點。資料節點會檢查標記然後進一步執行和 NameNode 一樣的安全性政策。這擔保了資料傳送加密和 RPC 政策相聯繫。
  1. 防火牆規則阻擋了未加密要跨連線存取的 NameNode 通訊埠。
  2. 客戶端根據它們在資料中心外面或裡面被設置了連線到不同的 NameNode 通訊埠。

靜態加密

  • 作業系統層級上的整體磁碟加密似乎是最直觀的方式。不過雖然它能從未授權的存取到硬體設備上提供足夠的保護,透過 HDFS 被存取時,資料人就是透明的。
  • 應用層級加密的缺點包括缺乏合一性(non-uniformity):每個團隊需要在他們系統中實作相同的密碼學技術。它也傳播了資料產生者和資料消費者到應用程式間鑰匙共享的問題。
  • 欄位層級加密在所儲存的資料集中鎖定了包含機敏資訊的特定欄位。這種細度顆粒的加密很有效也方便,被鎖定要加密的欄位通常會在資料集綱要裡透過註釋被標註。然而,這種作法被證實很容易出錯。隨著欄位綱要進化,人為疏失會造成不恰當的註釋進而導致機密資料非有心的洩漏。

蟲洞(Wormhole)

圖四、蟲洞簡化了從 HDFS 到線上服務的資料傳送流程

感謝

Photo by Umer Sayyam on Unsplash

--

--

--

10 x AWS-certified, Data Architect in the 104 Corporation. An AWS Community Builder

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Scott Hsieh (史考特)

Scott Hsieh (史考特)

10 x AWS-certified, Data Architect in the 104 Corporation. An AWS Community Builder

More from Medium

Hadoop PIG

Databricks — An Introduction and Tutorial

How to Interact Delta Lake Using EMR

Spark Starter Guide 4.9: How to Rank or Row Number Data