和風網標誌

生成數據智能

大數據

Amazon 如何使用 Amazon EMR 優化其大批量財務對帳流程以實現更高的可擴展性和效能 |亞馬遜網路服務

柏拉圖再版
柏拉圖再版

日期：

瀏覽次數： 70

會計核算是確保財務報表完整性、準確性的重要步驟。具體來說，公司必須協調 資產負債表 可能包含重大或重大錯報的帳目。會計師仔細檢查帳戶總帳中的每個帳戶，並驗證所列餘額是否完整且準確。當發現差異時，會計師會進行調查並採取適當的糾正措施。

作為亞馬遜金融科技組織的一部分，我們提供一個軟體平台，使亞馬遜的內部會計團隊能夠進行帳戶對帳。為了優化協調過程，這些用戶需要高效能轉換，能夠按需擴展，以及處理從幾 MB 到超過 100 GB 的可變檔案大小。並非總是能夠將資料安裝到一台機器上或在合理的時間範圍內使用一個程式對其進行處理。這種計算必須足夠快地完成，才能提供實用的服務，其中程式設計邏輯和底層細節（資料分佈、容錯和調度）可以分離。

透過使用分散式資料處理解決方案，我們可以在多個機器或具有相同功能的執行緒上跨資料集元素組實現這些同步計算。這鼓勵我們重新發明由 AWS 服務提供支援的通訊服務，包括 亞馬遜電子病歷 和 Apache Spark 分散式處理框架，它使用 火花。該服務使用戶能夠在 100 分鐘內處理超過 100 GB 的文件，其中包含多達 30 億筆交易。對帳服務已成為資料處理的動力來源，現在使用者可以無縫地執行各種操作，例如 樞, 註冊 （類似 Excel VLOOKUP 運算）， 算術 運營，以及 更多，為協調大量資料集提供通用且高效的解決方案。這項增強證明了透過採用分散式資料處理解決方案所實現的可擴展性和速度。

在這篇文章中，我們將解釋如何整合 Amazon EMR 來建立一個高度可用且可擴展的系統，使我們能夠運行大容量的財務對帳流程。

遷移前的架構

下圖展示了我們之前的架構。

我們的遺留服務是用以下建構的 亞馬遜彈性容器服務 （Amazon ECS） AWS 法門。我們使用 Python 按順序處理資料。然而，由於缺乏並行處理能力，我們經常必須垂直增加群集大小以支援更大的資料集。就上下文而言，處理 5 GB 資料和 50 次操作大約需要 3 小時。此服務配置為水平擴展至五個 ECS 實例，這些實例從下列位置輪詢訊息： Amazon Simple Queue服務 (Amazon SQS)，它提供轉換請求。每個實例配置有 4 個 vCPU 和 30 GB 內存，以允許水平擴展。然而，我們無法擴展其性能容量，因為該過程是連續發生的，從 亞馬遜簡單存儲服務 （Amazon S3）進行處理。例如，要連接兩個檔案的 VLOOKUP 操作需要在記憶體中逐塊讀取這兩個檔案以獲得輸出。這成為用戶的障礙，因為他們必須等待很長時間才能處理資料集。

作為我們重新架構和現代化的一部分，我們希望實現以下目標：

  • 高可用性 – 資料處理叢集應該是高可用的，提供三個9的可用性（99.9%）
  • 倉庫工作量統計 – 該服務每天應處理 1,500 次運行
  • 潛伏 – 它應該能夠在 100 分鐘內處理 30 GB 的數據
  • 異質性 – 叢集應該能夠支援各種工作負載，檔案範圍從幾 MB 到數百 GB
  • 查詢並行 – 實現要求能夠支援至少10度的並發
  • 作業的可靠性和資料的一致性 – 作業需要可靠且一致地運行，以避免違反服務等級協定 (SLA)
  • 經濟高效且可擴展 – 它必須根據工作負載進行擴展，使其具有成本效益
  • 安全與合規 – 鑑於資料的敏感性，它必須支援細粒度的存取控制和適當的安全實施
  • 監控 – 此解決方案必須提供叢集和作業的端到端監控

為什麼選擇亞馬遜 EMR

Amazon EMR 是業界領先的雲端大數據解決方案，使用開源框架（例如，PB 級資料處理、互動式分析和機器學習 (ML)） Apache Spark, 阿帕奇蜂巢和 急板。借助這些框架和相關開源項目，您可以處理資料以用於分析目的和 BI 工作負載。 Amazon EMR 可讓您將大量資料轉換並移入和移出其他 AWS 資料儲存和資料庫，例如 Amazon S3 和 亞馬遜DynamoDB.

Amazon EMR 的一個顯著優勢在於它有效地利用了 PySpark 的平行處理，這標誌著對傳統順序 Python 程式碼的顯著改進。這種創新方法簡化了 Apache Spark 叢集的部署和擴展，從而實現大型資料集的高效並行化。分散式運算基礎設施不僅增強了效能，而且能夠以前所未有的速度處理大量資料。 PySpark 配備了庫，可促進類似 Excel 的操作 數據框，並且 DataFrame 的更高層次抽象簡化了複雜的資料操作，降低了程式碼複雜性。結合自動叢集預置、動態資源分配以及與其他 AWS 服務的集成，Amazon EMR 被證明是一種多功能解決方案，適用於從批次到 ML 等各種工作負載。即使在節點發生故障的情況下，PySpark 和 Amazon EMR 固有的容錯能力也能提高穩健性，使其成為 AWS 上並行資料處理的可擴展、經濟高效且高效能的選擇。

Amazon EMR 將其功能擴展到基礎功能之外，提供各種部署選項來滿足不同的需求。無論是 EC2 上的 Amazon EMR, EKS 上的亞馬遜 EMR, 亞馬遜 EMR 無服務器， 或者 AWS Outposts 上的 Amazon EMR，您可以根據具體要求自訂您的方法。對於那些為 Spark 作業尋求無伺服器環境的人來說，集成 AWS膠水 也是一個可行的選擇。除了支援 Spark 等各種開源框架外，Amazon EMR 還提供了選擇部署模式的靈活性， 亞馬遜彈性計算雲 (Amazon EC2) 執行個體類型、擴展機制和眾多節省成本的最佳化技術。

Amazon EMR 是雲端中的一股動態力量，為尋求強大大數據解決方案的組織提供無與倫比的功能。其無縫整合、強大的功能和適應性使其成為解決 AWS 上的資料分析和機器學習複雜性不可或缺的工具。

重新設計的架構

下圖展示了我們重新設計的架構。

該解決方案根據 API 合約運行，客戶可以在其中提交轉換配置，定義操作集以及 S3 資料集位置以進行處理。此請求透過 Amazon SQS 排隊，然後透過 Lambda 函數定向到 Amazon EMR。此流程啟動建立 Amazon EMR 步驟，以便在專用 EMR 叢集上實作 Spark 框架。儘管 Amazon EMR 在長期運行的叢集的生命週期內可容納無限數量的步驟，但只能同時運行或掛起 256 個步驟。為了實現最佳並行化，步驟並發度設定為 10，允許 10 個步驟同時運行。如果請求失敗，Amazon SQS 死信隊列 (DLQ) 保留事件。 Spark 處理請求，將類似 Excel 的操作轉換為 PySpark 程式碼，以實現高效率的查詢計劃。 Resilient DataFrame 將輸入、輸出和中間資料儲存在記憶體中，最佳化處理速度，降低磁碟 I/O 成本，增強工作負載效能，並將最終輸出傳送到指定的 Amazon S3 位置。

我們從兩個維度定義 SLA：延遲和吞吐量。延遲定義為針對確定性資料集大小執行一項作業所需的時間以及對資料集執行的操作數量。吞吐量定義為服務在不違反一項作業的延遲 SLA 的情況下可以執行的並發作業的最大數量。服務的整體可擴展性SLA取決於彈性運算資源的水平擴展和單一伺服器的垂直擴展的平衡。

由於我們每天必須以最小延遲和高效能運行 1,500 個進程，因此我們選擇在 EC2 部署模式上整合 Amazon EMR，並啟用託管擴充功能以支援處理可變檔案大小。

EMR 叢集配置提供了許多不同的選擇：

  • EMR 節點類型 – 主要、核心或任務節點
  • 實例購買選項 – 隨選實例、預留實例或 Spot 實例
  • 配置選項 – EMR 實例佇列或統一實例組
  • 縮放選項 - 自動縮放 或 Amazon EMR 託管擴展

根據我們的可變工作負載，我們配置了 EMR 實例佇列（有關最佳實踐，請參閱 可靠性）。我們還決定使用 Amazon EMR 託管擴充功能來擴展核心節點和任務節點（有關擴展場景，請參閱 節點分配場景）。最後我們選擇了記憶體優化 AWS 引力子 實例，最多提供 Spark 工作負載的成本降低了 30%，效能提高了 15%.

以下程式碼提供了我們的叢集配置的快照：

Concurrent steps:10

EMR Managed Scaling:
minimumCapacityUnits: 64
maximumCapacityUnits: 512
maximumOnDemandCapacityUnits: 512
maximumCoreCapacityUnits: 512

Master Instance Fleet:
r6g.xlarge
- 4 vCore, 30.5 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:250 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 1 units

Core Instance Fleet:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

Task Instances:
r6g.2xlarge
- 8 vCore, 61 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 8 units
r6g.4xlarge
- 16 vCore, 122 GiB memory, EBS only storage
- EBS Storage:100 GiB
- Maximum Spot price: 100 % of On-demand price
- Each instance counts as 16 units

性能

透過遷移到 Amazon EMR，我們能夠實現能夠處理各種資料集的系統效能，範圍從低至 273 B 到高達 88.5 GB p99 491 秒（約 8 分鐘）。

下圖說明了處理的各種檔案大小。

下圖顯示了我們的延遲。

為了與順序處理進行比較，我們取得了兩個包含 53 萬筆記錄的資料集，並相互執行 VLOOKUP 操作以及其他 49 個類似 Excel 的操作。新服務中的處理時間為 26 分鐘，而舊服務中的處理時間為 5 天。這項改進在效能方面比之前的架構提高了近 300 倍。

注意事項

考慮此解決方案時請記住以下幾點：

  • 調整叢集大小 – 儘管 Amazon EMR 可調整大小，但調整叢集大小也很重要。如果叢集規模過小，則適當調整規模可以緩解叢集緩慢的情況；如果叢集規模過大，則可以減輕較高的成本。為了預測這些問題，您可以計算工作負載所需的節點數量和類型。
  • 平行步驟 – 並行運作步驟可讓您執行更進階的工作負載、提高叢集資源使用率並減少完成工作負載所需的時間。一次允許運行的步驟數是可配置的，並且可以在叢集啟動時以及叢集啟動後的任何時間進行設定。當多個作業在單一共享叢集中執行時，您需要考慮並最佳化每個作業的 CPU/記憶體使用量。
  • 基於作業的臨時 EMR 集群 – 如果適用，建議使用基於作業的瞬態 EMR 集群，該集群可提供卓越的隔離性，驗證每個任務是否在其專用環境中運行。這種方法優化了資源利用率，有助於防止作業之間的干擾，並提高整體效能和可靠性。瞬態特性可實現高效擴展，為不同的資料處理需求提供強大且隔離的解決方案。
  • EMR 無服務器 – 如果您不想處理叢集的管理和操作，EMR Serverless 是理想的選擇。它允許您使用 EMR Serverless 中提供的開源框架輕鬆運行應用程序，從而提供簡單、無憂的體驗。
  • Amazon EKS 上的電子病歷 – EKS 上的 Amazon EMR 提供了獨特的優勢，例如更快的啟動時間和改進的可擴展性，解決了運算容量挑戰，這對 Graviton 和 Spot 實例使用者特別有利。包含更廣泛的計算類型可以提高成本效率，從而實現量身定制的資源分配。此外，多可用區支援提供了更高的可用性。這些引人注目的功能為管理大數據工作負載提供了強大的解決方案，並在各種運算情境中提高了效能、成本最佳化和可靠性。

結論

在這篇文章中，我們解釋了 Amazon 如何使用 Amazon EMR 來優化其大批量財務對帳流程，以實現更高的可擴展性和效能。如果您有一個依賴垂直擴展來處理其他請求或資料集的單體應用程序，那麼將其遷移到Apache Spark 等分散式處理框架並選擇Amazon EMR 等託管服務進行運算可能有助於縮短運行時間，從而降低交付率SLA 也可能有助於降低總擁有成本 (TCO)。

當我們針對此特定用例採用 Amazon EMR 時，我們鼓勵您在資料創新之旅中探索更多可能性。請考慮評估 AWS Glue 以及其他動態 Amazon EMR 部署選項（例如 EMR Serverless 或 EKS 上的 Amazon EMR），以發現適合您獨特使用案例的最佳 AWS 服務。數據創新之旅的未來蘊藏著令人興奮的可能性與進步，有待進一步探索。

關於作者

吉尚·赫特拉帕爾 是亞馬遜的高級軟體開發工程師，他開發基於雲端運算無伺服器架構的金融科技產品，負責公司的 IT 一般控制、財務報告以及治理、風險和合規性控制。

薩克蒂·米甚拉 是 AWS 的首席解決方案架構師，他協助客戶實現資料架構現代化並定義端到端資料策略，包括資料安全性、可存取性、治理等。 他也是這本書的作者 使用 Amazon EMR 簡化大數據分析. 工作之餘，Sakti 喜歡學習新技術、看電影和與家人一起參觀地方。

現貨圖片

最新情報

現貨圖片

版權所有@ 2024 Plato Technologies Inc.