重塑 Sprout Social 的大數據方法

已發表: 2022-11-15

Sprout Social 的核心是一家數據驅動型公司。 Sprout 每天處理來自多個社交網絡的數十億條消息。 正因為如此,Sprout 工程師面臨著一個獨特的挑戰——如何存儲和更新大量進入我們平台的同一消息的多個版本(即轉發、評論等)。

由於我們存儲了消息的多個版本,因此 Sprout 工程師每天要多次“重建世界”——這是一個必不可少的過程,需要遍歷整個數據集,將社交消息的每個部分整合為一個“真實來源”。

例如,跟踪單個 Twitter 帖子的點贊、評論和轉推。 過去,我們依靠自我管理的 Hadoop 集群來維護和處理如此大量的數據。 每個 Hadoop 集群將負責 Sprout 平台的不同部分——Sprout 工程團隊依賴這種做法來大規模管理大數據項目。

Sprout 大數據方法的關鍵

我們的 Hadoop 生態系統依賴於 Apache Hbase,這是一個可擴展的分佈式 NoSQL 數據庫。 讓 Hbase 對我們處理大數據的方法至關重要的是它不僅能夠對整個數據集進行快速範圍掃描,而且還能夠進行快速、隨機、單條記錄查找。

Hbase 還允許我們批量加載數據和更新隨機數據,這樣我們就可以更輕鬆地處理亂序到達或部分更新的消息,以及社交媒體數據帶來的其他挑戰。 然而,自我管理的 Hadoop 集群給我們的基礎設施工程師帶來了高昂的運營成本,包括手動管理災難恢復、集群擴展和節點管理。

為了幫助減少管理這些具有數百 TB 數據的系統所花費的時間,Sprout 的基礎設施和開發團隊齊心協力尋找比運行自我管理的 Hadoop 集群更好的解決方案。 我們的目標是:

  • 讓 Sprout 工程師更好地構建、管理和運營大型數據集
  • 最大限度地減少工程師手動擁有和維護系統的時間投入
  • 減少由於集群擴展而導致的過度配置的不必要成本
  • 提供更好的容災方式和可靠性

當我們評估當前大數據系統的替代方案時,我們努力尋找一種可以輕鬆與我們當前的處理和模式集成的解決方案,並且可以減輕手動管理集群帶來的操作麻煩。

評估新的數據模式備選方案

我們的團隊考慮的解決方案之一是數據倉庫。 數據倉庫充當數據分析和聚合的集中存儲,但與 Hbase 相比,它更類似於傳統的關係數據庫。 他們的數據是結構化的、經過過濾的並且具有嚴格的數據模型(即單個對象的單個行)。

對於我們存儲和處理具有多個並排存在的消息版本的社交消息的用例,數據倉庫有一個低效的模型來滿足我們的需求。 我們無法將現有模型有效地適應數據倉庫,而且性能比我們預期的要慢得多。 重新格式化我們的數據以適應數據倉庫模型將需要大量開銷來按照我們的時間表進行返工。

我們研究的另一個解決方案是數據湖屋。 數據湖屋擴展了數據倉庫的概念,以允許結構化程度較低的數據、更便宜的存儲和圍繞敏感數據的額外安全層。 雖然數據湖屋提供的功能比數據倉庫多,但它們的效率不如我們當前的 Hbase 解決方案。 通過測試我們的合併記錄和我們的插入和刪除處理模式,我們無法為我們的批處理作業生成可接受的寫入延遲。

使用 AWS EMR 減少開銷和維護

鑑於我們對數據倉庫和 lakehouse 解決方案的了解,我們開始研究運行託管 Hbase 的替代工具。 雖然我們認為目前對 Hbase 的使用對我們在 Sprout 所做的工作有效,但我們問自己:“我們如何才能更好地運行 Hbase 以降低我們的運營負擔,同時仍然保持我們的主要使用模式?”

這是我們開始評估 Amazon 的 Hbase Elastic Map Reduce (EMR) 託管服務的時候。 評估 EMR 需要以與我們測試數據倉庫和湖屋相同的方式評估其性能,例如測試數據攝取以查看它是否能夠滿足我們的性能要求。 我們還必須測試數據存儲、高可用性和災難恢復,以確保 EMR 從基礎設施/管理的角度滿足我們的需求。

EMR 的功能改進了我們當前的自我管理解決方案,使我們能夠像使用 Hbase 一樣重用當前模式來讀取、寫入和運行作業。 EMR 的最大優勢之一是使用 EMR 文件系統 (EMRFS),它將數據存儲在 S3 中而不是節點本身。

我們發現的一個挑戰是 EMR 的高可用性選項有限,這限制了我們只能在單個可用區中運行多個主節點,或者在多個可用區中運行一個主節點。 這種風險通過利用 EMRFS 得到緩解,因為它為災難恢復提供了額外的容錯能力,並將數據存儲與計算功能分離。 通過使用 EMR 作為我們的 Hbase 解決方案,我們能夠提高我們的可擴展性和故障恢復能力,並最大限度地減少維護集群所需的手動干預。 最終,我們認為 EMR 最適合我們的需求。

遷移過程很容易預先測試並執行,以將數十億條記錄遷移到新的 EMR 集群,而無需任何客戶停機。 新集群的性能得到提升,成本降低了近 40%。 要詳細了解遷移到 EMR 如何幫助降低基礎設施成本並提高我們的性能,請查看 Sprout Social 使用 AWS 的案例研究。

我們學到了什麼

該項目的規模和範圍為我們基礎設施數據庫可靠性工程團隊提供了與多個工程團隊跨職能合作的機會。 雖然它具有挑戰性,但它被證明是我們作為協作工程組織在 Sprout 可以處理的大型項目的一個令人難以置信的例子。 通過這個項目,我們的基礎架構團隊對 Sprout 數據的使用、存儲和處理方式有了更深入的了解,我們也更有能力幫助解決未來的問題。 我們已經創建了一個跨多個團隊的公共知識庫,可以幫助我們構建下一代客戶功能。

如果您對我們正在構建的產品感興趣,請立即加入我們的團隊併申請我們的一個開放式工程職位。