為什麼 LinkedIn 改變了他們的資料分析技術堆疊 - Quastor

ETL代表提取、傳輸、載入。它是將資料從各種來源（不同的資料生產者）複製到單個目標系統（通常是資料倉儲）中的過程，在該系統中可以更輕鬆地使用它。 
這個堆疊為 LinkedIn 服務了 6 年，但它有一些缺點：

• 缺乏發展的自由——由於這個系統的封閉性，他們在創新的選擇上受到限制。此外，與內部和開源系統的整合也是一個挑戰。
• 擴充套件困難- 由於 Informatica/Appworx 許可證的限制，資料管道開發僅限於一個小型中央團隊。這日益成為LinkedIn快速增長的瓶頸。

您可以在此處瞭解 LinkedIn 如何將 Hadoop 分散式檔案系統擴充套件到 1 EB 的資料。
但是，他們沒有明確的過渡過程，這導致他們同時維護新系統和舊系統。
資料在技術堆疊之間複製，導致維護成本和複雜性增加了一倍。
 

從Teradata遷移出資料
為了解決這個問題，工程師決定使用 Hadoop 將所有資料集遷移到新的分析堆疊。
為了做到這一點，第一步是匯出 LinkedIn 的資料沿襲。

資料沿襲是跟蹤資料從資料來源流向消費的過程，包括資料在此過程中經歷的所有轉換。
瞭解這一點將使工程師能夠計劃資料集遷移的順序，識別零使用資料集（並刪除它們以減少工作量）並跟蹤新舊系統的使用情況。

您可以在全文中準確閱讀 LinkedIn 如何處理資料沿襲過程。
在資料沿襲之後，工程師使用這些資訊來計劃主要的資料模型修訂。
他們計劃將 1424 個資料集合併到 450 個，有效地從遷移工作量中減少約 70% 的資料集。
他們還將 OLTP 工作負載生成的資料集轉換為更適合業務分析工作負載的不同模型。
遷移是使用各種資料管道完成的，並說明了 LinkedIn 系統中的瓶頸。
瓶頸之一是Avro 檔案格式的讀取效能差。工程師遷移到ORC後，讀取速度提高了約 10-1000 倍，壓縮率提高了 25-50%。
資料傳輸後，如果手動完成舊系統上 1400 多個資料集的折舊，將是乏味且容易出錯的，因此工程師還構建了一個自動化系統來處理此過程。
他們構建了一項服務來協調棄用，該服務將識別要刪除的候選資料集（沒有依賴關係且使用率低的資料集），然後向這些資料集的使用者傳送電子郵件，其中包含有關即將棄用的訊息。
該服務還將通知 SRE 在寬限期後從遺留系統中鎖定、存檔和刪除資料集。

Hadoop新系統
新生態系統的設計深受舊生態系統的影響，並解決了遺留技術堆疊的主要痛點。

• 資料民主化- Hadoop 生態系統支援 LinkedIn 的其他團隊開發和採用資料。以前，由於專有平臺的許可限制，只有中央團隊可以在舊系統上構建資料管道。
• 透過開源專案實現技術開發的民主化——新技術堆疊的所有方面都可以透過開源或定製專案自由增強。
• 技術堆疊的統一——同時執行 2 個技術堆疊顯示了維護冗餘系統的複雜性和成本。統一技術可以大大提高效率。

• Unified Metrics Pipeline - 開發人員提供 ETL 指令碼來建立資料管道的統一平臺。
• Azkaban - 一個分散式工作流排程程式，用於管理 Hadoop 上的作業。
• 資料集讀取器 - 資料集儲存在 Hadoop 分散式檔案系統上，可以透過多種方式讀取。
  
  • 它們可以被DALI讀取，這是一種 API，開發用於允許 LinkedIn 工程師讀取資料而無需擔心它的儲存介質、路徑或格式。
  • 它們可以被各種儀表板和業務分析的臨時查詢讀取。