鑽石舞台

朴朴數據平台基礎技術架構簡圖

朴朴雲上主體業務數據流轉簡圖

EMR 在朴朴雲上大數據平台擔任計算單元角色，數據計算完畢後經由服務通道輸出給業務平台 (平台架構圖最頂層部分)，核心計算場景有：離線、實時、查詢，三者比例約為 7:2:1。至於雲上主體業務數據流轉鏈路，我們使用 Apache Hudi 作為數據湖倉支撐基石，目前是以離線 + 實時雙線同步鏈路方式支持數據入湖。湖倉架構是一種靈活的架構設計模式，本文篇幅有限，後續有機會筆者單開一篇進行論述。

我司近七成為離線計算，所支撐的業務場景繁雜多樣：業務數據入湖倉 ETL、算法、數據報表、數據分析、倉儲配送等，這些離線任務我們內部按照對業務影響程度制定了相關故障等級標準，達到核心故障級別的有：

業務庫數據入湖倉主鏈路作為所有數據使用的保障基石，重要程度自然不言而喻

我司在算法域應用大體可分為：預測、推薦、規劃三大類，部分算法任務的輸出已嵌入業務流程中，典型如自動訂補貨、倉儲商品調度配送等

對公司經營業務產生影響的數據報表，如：收益類、營銷類、用戶類、商品庫存平衡等

目前我司實時計算平台，已上線實時計算任務有 200+，場景涵蓋：業務數據實時入湖倉 ETL、算法、數據報表、門店大屏等，與離線計算所不同的是實時計算要求響應時效性更高，基本等同於朴朴主體業務 (A/C 端) 響應速度，隨着業務場景不斷深化，會逐步按需提升實時計算任務。

查詢計算平台基於 presto 封裝實現，目前在我司應用場景涉及：BI 平台、即席式交互、跨源融合查詢，因雲上虛擬機自建 Clickhouse，其存儲瓶頸較明顯且成本又高，因此引入 Presto 實現跨源融合查詢以支持 BI 平台查詢湖倉 Hudi 明細表，如此一來湖倉中的數據可無需再同步至 Clickhouse，降低明細表數據傳輸及落地存儲至 Clickhouse 過程開銷。

除此之外，數據平台團隊已在規劃、開發實現統一查詢服務平台，該平台上線後會提供如下功能：

支持統一的 HiveSQL 語法 & 虛擬表查詢。

支持異步查詢和任務優先級調度。

支持 spark、presto、flink 等查詢引擎。

支持查詢路由及負載均衡。

多數據源融合查詢。

開篇伊始，先簡單了解下 EMR 集群單元架構。

AWS 官網介紹 EMR 部署模式有：EC2、EKS、Outposts、Serverless 這幾種，後兩者目前尚未在國內上線，而當前階段 EMR On EKS 模式有使用場景限制 (僅支持 Spark 應用)，待之後具體調研使用後再作評論，本文着重於 EMR On EC2 模式進行說明。EMR 集群由三個組類構成：MASTER、CORE、TASK，典型的 EMR 集群實例組架構如下圖所示：

在 EMR 集群中 master node 扮演着管理者角色，諸如：

等服務進程在此節點運行，因此一個集群中至少有一個 master node，若需要 HA 架構，可在部署時選擇 Multi master 模式 (3 實例)，然後靜待 EMR 集群初始化完畢即可。

以 HDFS 和 YARN 為例，Multi master 架構下 EMR5 集群中兩個 namenode 節點以 active/standby 狀態工作，resourcemanager 三節點分別以 active/standby/standby 狀態工作；而 EMR6 集群中有所不同的是全部 master node 會啟動 namenode 進程，並分別以 active/standby/standby 狀態工作，間接提高 HDFS 集群可用性。集群中可通過如下命令獲取服務進程狀態：

高可用架構下當出現某個 master node 崩潰時，ZK/HDFS/YARN 等組件服務因具備故障轉移機制，整體集群服務不受影響，EMR 後台會將故障 EC2 實例從集群中剔除並新增一個新 EC2 實例，待初始化完畢後 (含高可用配置操作) 重加入集群。

core node 為彈性且可選實例組類型，承載着 datanode、nodemanager、worker 等計算存儲角色，用戶可自定義 HDFS 副本參數，若不設置會依據 EMR 默認值進行設定：

task node 為計算節點，一般承載着 nodemanager、worker 等計算角色，適用於應對不同計算資源所需的彈性計算場景，對於彈性 scale 頻繁的計算場景，通過調整 task node 使用比例，起到消峰填谷作用的同時又能一定程度上控制和節省成本。

作為新手玩家，如何上手管理 EMR 集群呢？筆者大致總結後可從以下方面初窺門徑：

EMR 控制台提供兩種部署模式：快速、高級，快速選項模式用戶可根據提供的模板，簡單配置後即可構建集群，高級選項模式則提供給用戶更多自主選擇，支持從軟件、硬件、集群設置、安全性四大方面自定義配置構建集群。一般而言，作為剛接觸 EMR 的新手玩家，選擇前者會比較方便，有開源大數據集群運維經驗的用戶，建議使用後者，可以相對靈活方式管理和部署 EMR 集群。

自定義配置支持集群全局範圍和實例組範圍，參數項變更操作支持 json 或表格兩種格式編輯，這裡要注意的是 EMR 控制台頁面<集群配置>只允許在集群構建初始化階段定義，集群上線後即不可被修改，EMR 控制台在 5.21.0 及之後的版本支持實例組級別 (運行中) 服務配置項修改，具體配置項分發支持可檢索參考官網發行版<配置分類>說明。

EMR 原生提供部分指標並集成至 cloudwatch，用戶可在控制台查看或到 cloudwatch 檢索，常用指標基本已提供，若指標項不足以滿足需求，可基於 Prometheus+Grafana 套件自行實現指標採集與監控告警。

用戶在構建 EMR 集群前，建議事先定義創建好 VPC 網絡、安全組及 IAM 角色，部署過程中引用這些安全性定義，當集群構建完畢後，所有 EC2 實例的安全訪問即可實現受控，避免集群出現訪問安全方面隱患。

此外，依據筆者親身經歷的經驗教訓總結，構建 EMR 集群時可參考如下原則：

GRAY/TEST 屬性 EMR 集群單 Master 架構，PROD 屬性 EMR 集群務必使用 Multi Master 架構。

原因：防止單 Master 節點崩潰導致重要集群被銷毀。

Multi Master 集群初始化完畢後切記跟 AWS 團隊確認 master/core node 分布情況。

原因：若 master 角色所在 EC2 實例節點分布不均，集中在個別底層硬件上，當此硬件出問題時波及的就是整個集群，較新的 EMR 版本因引入 placement group 機制，會在部署時自動分散開，為防萬一，建議再核實一遍。

MASTER/CORE 實例組不建議使用 AMD CPU 機型。

原因：AMD CPU 機型雖然便宜一些，但在 AWS 北京 a、b 可用區域數量占比較少，容易集中在某些底層物理設施單元上 (機櫃、服務器等)，且經測試驗證系統穩定性相比 Intel CPU 機型也略差一些。

對於 EMR 已有初步認知和管理能力而言，下一步就是如何提高對其掌控力。

入門篇已簡單介紹如何在控制台創建 EMR 集群，官網有詳細的操作文檔給予用戶指引，在此介紹其他創建方式。

當集群出現故障或人為手動終止且該集群上存在許多用戶自定義配置項時，在 EMR 控制台頁面有個克隆功能，可通過此功能鏡像式創建新集群，新集群構建時會自動同步舊集群用戶自定義配置項，避免配置項丟失或遺漏。

除 EMR 控制台外，用戶還可基於 AWS CLI、AWS SDK、AWS WEB API 三種更高級定義的方式創建集群，先以 JSON 格式定義好集群模板，一鍵 POST 提交後靜待十分鐘，一個新鮮出爐的集群即已創建完畢。

一個 EMR 集群要上線，並不止於構建完畢，還需對集群環境做初始化工作，通常初始化操作分兩步：操作系統及平台組件環境。

EMR 底層 EC2 實例所引用的系統映像已由後台針對大數據場景做針對性系統參數優化，因此，一般情況下用戶無需再做定製化修改，只要初始化系統時區、Prometheus node_exporter 服務、dnsmasq、docker(若有網段定義衝突) 等基礎服務設施即可。

泛指 HDFS/YARN/SPARK 之類組件配置項，EMR 初始化生成的組件配置項大多為默認值或者通用化模板配置，部分場景會存在不適用問題，因此建議用戶務必按照集群運行環境所需進行修改。

例：spark-env.sh 在初始化過程若不去掉 Standalone 配置，提交 SPARK Application 後會因運行架構衝突導致訪問時無法正確解析 SPARK MASTER WEB 服務地址。

若用戶需在 EMR 集群範圍集成較多複雜組件，卻又不想花費太多精力在部署運維上，可嘗試使用自定義 AMI 映像方案。以我司為例，早期出於提交計算任務便利性和提高資源利用率考量，將調度平台 Airflow 與 EMR 混部，又因我司在 Airflow 使用場景較為複雜，部署運維不便，經調研後引入自定義 AMI 映像解決掉部署運維上帶來的麻煩。

禍福相依的是此模式在持續穩定運行約一年後的某天突然爆雷：EMR 集群底層 EC2 實例所引用的自定義 AMI 映像被誤刪，這直接導致當天所有 EMR 集群無法擴容啟動新 EC2 實例，基本處於半癱狀態。事發當天重新構建 AMI 映像，優先恢復 PROD 屬性 EMR 集群，之後其餘 EMR 集群分批剷除重新構建，過程持續近一個月才恢復到此前狀態。

因此，備份的重要性，不言而喻。建議有在 EMR 集群內使用自定義 AMI 映像的用戶，切記一定要保管好它，避免對線上生產環境造成損失。

具體是指對 EC2 實例和 EMR 平台服務打標籤，便於之後告警項治理。打標籤應成為一種習慣，從管理角度其價值不言而喻。

在我司，EC2 實例上線前會以類 userData 方式自動安裝 node_exporter 服務，之後由 Prometheus server 拉取這些系統層指標，指標落地後使用 Grafana 展示，最後結合 Alertmanager 及自研監控平台實現指標項告警。

EMR 所提供的組件指標不能完全滿足我司實際指標監控訴求，作為管理員可自行開發 exporter 服務將組件指標採集後匯聚到監控中心，依託於監控中心實現平台組件服務監控覆蓋和告警能力，也可以將這些指標推送至 AWS cloudWatch 服務進行告警實現。

在沒有 scale 機制的自建 Hadoop 集群，不可避免地會碰到計算資源問題 (不足或未用滿)，一種典型的做法是將計算引擎運行在 K8S 上，與業務平台錯峰使用，以提高整體資源利用率。在 EMR 上用戶可基於 cluster 或 InstanceGroup 兩個層面定義 scaling 規則，規則觸發後即進行集群節點擴縮容操作。

scale 一般是應用在需動態伸縮的 Core/Task 節點，Core 相對而言伸縮偏穩定保守一些，建議按比例固定。因此 scale 着重應用於 Task 節點並分別按 OnDemand&Spot 機型靈活配比，scale 配置時支持多種指標定義，用戶可擇其一或多指標組合形成多層次彈性伸縮規則。定義彈性伸縮策略時可參考如下規則：

按 CPU 內存最小化計算集群平均占用資源值，將其換算成 OnDemand 機型個數，這部分為常駐節點

在上一條基礎上，彈性部分引用 Spot 機型，因 Spot 屬於競爭資源，存在被外界引用導致資源申請不到現象，生產環境使用應混搭不同機型，或按需申請此部分比例

以 YARN 為例，建議按 cpu、內存、container 三個層級定義複合型彈性規則，規避單條規則定義局限性

集群中創建多個 InstanceGroup，避免某個 InstanceGroup 資源伸縮受阻影響到集群計算效率

客觀地說，EMR Scaling 確實是個很棒的功能，激進一點調配使用，集群資源利用基本可達如下效果

一個 EMR 集群從觸發創建請求到上線會大致經歷這幾個階段：

於 EMR 初階用戶而言，上述階段能感知到只有首尾階段，其餘部分基本像盲盒，對於中間過程執行情況一概不知。事實上這裡列舉的各個階段皆有脈絡可循：

申請 EC2 實例。從 EMR 管理控制台 InstanceGroup 入口可跳轉到 EC2 實例控制台，那裡可以觀測到 EC2 實例運行情況。

初始化系統。包含兩部分：選擇 AMI 系統映像啟動 EC2 實例及系統環境初始化，這部分可查看操作系統日誌獲知執行情況。

執行 userData。在 EMR 集群中較少定義，通常是在單獨啟動 EC2 實例場景應用，在操作系統初始化完畢之後執行用於自動化修改系統運行環境。

執行 bootstrap。EMR 集群中對 EC2 實例啟動後的初始化操作，與 userData 功效類似，執行結果可在 /emr 掛載點 bootstrap-actions 目錄中獲悉，以 controller、stderr、stdout 三個文本文件記錄執行過程信息。

安裝集群組件及集群組件配置。在 bootstrap 執行成功後，EMR 內部以 puppet 任務方式執行集群組件安裝及配置初始化，甚至於 HDFS HA 構建，詳細執行過程信息可在如下路徑獲取，S3 上傳會有一定滯後。

當上述階段步驟執行全無問題後，即確認為集群節點服務部署正常，最後狀態變更上線。

EMR 集群上線時會設定一些資源調度策略，該策略會最終影響計算任務調度分布。為提高單集群可承載計算任務並行數量，我們對該策略設定做了一些調整：在原有的 Core NodeLabel 設置基礎之上，修改為 exclusive=true ， 即分區獨占模式。結合 YARN DominantResourceCalculator 調度策略，調整後 Core 隊列有多少核 CPU，即可最高支撐多少個計算任務並行運行，在存算分離較徹底的 EMR 集群中使用 m5.8x、m5.12x 等實例機型作為 Core 節點，顯著減低集群 Core 使用成本的同時還能提高集群計算並行度。

注意：EMR5 集群初始化時默認會將 CORE 節點設定為一個單獨的 Node Label，YARN application 啟動時 application master 進程只在 CORE 節點上運行，而 EMR6 集群已將此 CORE Node Label 機制默認關閉。

我司基於 Hive 構建企業級大數據平台元數據服務，存在多集群復用統一元數據庫現象，從元數據庫高可用及運維投入產出比方面考慮，選擇 RDS 作為 Hive 等組件元數據庫無疑是個明智之舉，對於 Hive 元數據庫這類讀寫 IO 要求不高的應用場景，甚至可開啟多 A-Z 模式以提高其健壯性。

優點:

開箱即用，基本免運維，原生支持高可用。

EMR 後台已對 JDBC 相關兼容性做適配。

缺點:

版本升級需重啟 RDS 服務，諸如安全補丁之類升級會較頻繁。

需單獨監測底層是否發生 A-Z 切換，若有集群需重啟相關組件服務，確保連接有效。

高版本 RDS 與 EMR 兼容性適配不佳，建議 RDS 不要超過 5.7 版本。

既已使用了 EMR，那麼選擇 AWS S3 作為主數據存儲就是自然而然的選擇，一者存算分離是使用趨勢，二者 EBS 與 S3 相比存儲成本不在一個量級。在 EMR 體系中，Core 節點作為主數據存儲節點，承載着分布式文件系統角色，典型應用有：

我們僅將 EMR 用於計算而不涉及主數據存儲，基於 S3 存儲強一致性前提 (2021 年 12 月上線)，已具備 checkpoint 或 hbase 場景遷移至 S3 可行性，我們將 checkpoint 從 HDFS 遷移至 AWS S3 後，集群 Core 節點只需存儲 application log 及 hdfs 部分應用文件，顯著降低存儲成本。目前實時計算集群已支持近 200 個 Flink job 運行暫未發現明顯問題，今後隨着 Flink job 大規模使用，需關注 AWS S3 Bucket 吞吐性能，防止 put、get 達到一定上限，如存在此問題，建議與 AWS 團隊溝通，或通過分區倒排序、加鹽等方式進行處理，以支撐不斷高並發、高吞吐場景。

以客觀角度而言，AWS EMR 這一產品確實是提供了諸如節省成本、AWS 服務集成、部署、可靈活地擴展、安全性、監控、界面化管理這些功能特性。相較於其他雲廠商亦或開源社區集群管理解決方案相比，雖各有千秋，但也存在有一定的改進空間。

節省成本：小規模場景使用綜合成本節省比較明顯，當規模達到 PB 級時，EC2、EMR、S3、網絡流量四者成本累計則未必，所以需要進一步進行架構優化，以獲取最佳性價比。

監控方面：集群缺乏組件服務狀態如健康程度、HA 狀態等類指標查看，可根據需要利用 exporter 採集。

集群部署 & 管理：基於快速構建集群設計思想，導致部署操作集成度較高，若過程出現異常，只能重新執行構建操作，無法斷點連續操作，個別場景下集群驗證有明顯等待時間成本；EMR 組件只提供 initctl/systemd 系統進程管理方式，不支持按組件 / 進程級別進行啟 / 停。

擴展伸縮：EMR scale 機制不支持以 CPU vCore 指標作為彈性伸縮規則，在混合計算業務場景 scale 伸縮某些時刻會不符合預期。

安全性：依託於 VPC 子網、安全組、IAM Role 等多重機制提供安全性保障，若結合 S3 層面數據安全訪問管控，詳見 AWS EMR 雲上數據安全管控實踐 一文。

該階段標誌着用戶對 EMR 這套產品體系架構的理解程度已達入木三分之境地，日常 EMR 相關使用問題隨手可解。因此，筆者認為這一階段的特點應當不拘泥於官方對 EMR 使用定義，而是要結合各自企業應用場景，靈活調配組裝以適應和滿足業務需求，形成獨有的解決方案架構。

早期，數據平台承載業務量不太，離線、實時計算任務集中在單一集群運行倒也問題不大，隨着任務量暴漲、任務重要等級制定、任務屬性劃分的事項推進，我們按如下原則對集群進行拆分：

數據平台環境：PROD、GRAY、TEST

計算屬性：離線、實時

拆分後集群單元從 3 個裂變為 4 個 (成本考量，GRAY、TEST 環境集群任務依然為混合模式運行)。

要知道雲計算設計之初衷，便是假設一切皆不可靠。實際使用中 EMR 集群發生局部範圍崩潰是個常態化現象，更有甚者，集群級別停服也偶有發生，因此早在 2020 下半年我們已開始規劃當集群出現大面積崩潰或停服時如何快速恢復的方案，恢復方案歷經多個迭代，迄今為止，我們已實現計算集群恢復時長從 2 小時 + 縮短至分鐘級，實現思路請看下文。

a. 分離集群單元

不同計算屬性集群切換方案因其集群計算依賴差異性，切換方案自然有所不同，因此在切換操作前務必先按離線、實時計算屬性做好分離工作。

b. 離線計算集群切換

離線集群切換實現前提有四：

計算、存儲分離。EMR 只負責相對單純的計算承載體，數據存儲方面則由 AWS S3 服務提供，確保集群切換時底層數據存儲統一。

元數據。元數據不應存儲於 EMR 集群內，應外掛於集群之外，我司將其外掛至 RDS，以確保 EMR 集群故障時元數據不丟。

收攏離線集群任務提交入口。以我司為例，在最初計算集群服務上線前即已規劃限制離線任務提交入口為 Airflow、Livy(Spark Rest 服務化提供載體，之後將以 Kyuubi 替代)，其餘任務提交通道拒不提供。

另行開發實現 Livy 負載均衡服務並以域名形式對外提供，調度 Airflow 集群則以 Gateway 方式加入計算集群。

當需要進行集群切換操作時，只需修改調度 Airflow 集群中環境信息、Livy 或 Kyuubi 服務域名解析指向到新 EMR 集群即可實現切換。

c. 實時計算集群切換

受限於此前實時計算集群災備切換尚未實現，未將計算任務按 (CPU/MEM) 屬性分流到不同集群，個別任務會因底層計算 container 資源爭搶受影響，導致計算延遲。相比於離線計算，實時計算集群切換實現要更加複雜，在計算存儲分離、元數據統一的前提下，我們從以下方面實現了實時集群平滑切換：

任務提交入口實現。

我司當前 Flink 任務主要分為 FlinkSQL、JAR 兩種類型，前者占比約九成，為方便用戶使用 Flink 實時計算能力，數據平台研發人員基於 Flink+YARN API 另行開發實現一套流計算作業管理平台，既用於流計算作業編碼提交，也用於集群作業管理，收攏實時計算任務提交入口。早期流計算作業管理平台與 EMR 集群捆綁式部署，使得僅支持單一集群提交指向，經迭代幾個版本之後，目前已具備多集群指向提交能力。

checkpoint 機制。

checkpoint 機製作為卡死實現實時計算集群切換最重要的一道關卡，這點是毋庸置疑的。我司一開始使用 Spark StructedStreaming 處理實時計算任務，基於開發易用性、流計算處理機制、實時計算趨勢等方面考慮於 2021 年上半年全面切換為 Flink。在使用 StructedStreaming 及 Flink 期間每逢有集群切換操作時，checkpoint 遷移與恢復都是令人無比頭疼的事，中間分別做了兩次 checkpoint on S3 方案調研工作，都受限於 S3 最終一致性問題效果不佳，所幸的是 AWS S3 在 2021 年底實現強一致性支持，簡單驗證了下基本滿足 checkpoint 使用需求，最後基於 checkpoint on s3 可行性前提，我們規劃及開發了任務在多集群內切換功能實現。

結合 PROD 環境離線、實時集群拆分操作，至此集群單位裂變為 7+(中間為保障實時計算高等級任務運行，再獨立出一個集群單元)。

我們在 EMR 集群底層 EC2 實例使用選擇上基本圍繞着 C、M、R 三種機型，幾種機型主要區別在於 vCPU/memory 的比例，C 型適用於 CPU 計算密集型任務 (除非極度需要 CPU 算力，不然成本相近條件下，不妨優先考慮 M 型)，R 型適用於內存需求比較高的計算場景 (需緩存大量數據在內存中計算)。基於實際計算任務運行所需，在較大規模生產集群中我們選擇以 m5/m5a.8xlarge 機型為主，m5/m5a.4xlarge 機型為輔，次之規模集群則按業務計算屬性靈活搭配。

至於 G 型屬於 ARM 芯片架構，因 EMR 是個多組件嵌套大型集群平台，且我司有對部分組件做二開，從集群組件底層兼容性適配驗證考量，暫未納入使用，我司目前將 G 型用於 Cassandra 數據庫集群，計算效率有比較明顯的提升。

EMR 集群構建時可選擇實例組管理方式: 統一實例組、實例隊列。

我們主要使用統一實例組方式構建集群，結合自定義 scale 規則管理集群計算資源，原因如下：

a. EMR-Managed scaling 方式按照節點負載進行彈性伸縮，規則局限性很明顯。

b. 至於不使用實例隊列 (InstanceFleet) 的原因也是因為規則存在明顯局限性，如一旦在集群創建時定義好實例組類型，之後無法進行實例組配置修改，對於需長期運行的生產集群，管理靈活度欠佳。

C. 使用自定義 scale 規則，管理員可以定義多個指標 (如集群存儲使用占比、Container Pending 值、內存使用值等) 作為彈性規則供 AWS 後台判斷是否需對集群進行擴縮容。

因 Spot 類型資源較容易出現緊俏現象，為提高集群計算穩定性，避免節點頻繁上下線帶來的波動影響，我們基本將其從生產集群使用中剔除，主力使用 OnDemand 類型，結合主動 + 被動伸縮策略管理 OnDemand 機型數量。被動策略跟之前一樣，由 EMR 監控集群狀態指標被動進行伸縮調整，主動伸縮策略初期規劃是根據歷史資源占用指標值，將資源所需換算成具體 EC2 實例所需數量，提前主動發起資源申請，在業務計算節點來臨之前準備好計算資源，最大程度保證計算效率及利用集群計算資源，主動伸縮效果如下圖所示：

因離線計算集群存在資源爭搶問題，有一定幾率促使高優先等級任務運行時申請不到資源，為保證該類型任務申請時有足夠資源，集群資源管控策略需做調整優化。EMR YARN 默認以 capacity-scheduler 策略管理及調度集群計算資源，資源調配上不如 fair-scheduler 策略靈活。

筆者曾嘗試 EMR 集群集成 fair-scheduler 可行性調研，結論是 YARN 集群所有 nodemanager 節點上需存在 fair-scheduler.xml，方可執行 fair-scheduler 調度策略，而 emr 控制台不支持 fair-scheduler 配置分發，雖可勉強通過 bootstrap 方式支持，但遠沒有 capacity-scheduler 兼容性好。退而求其次，轉為研究 capacity-scheduler 隊列資源隔離劃分，目前已驗證可行並即將上線至生產集群。

受歷史包袱影響，當前我司數據平台基礎組件部分版本有些錯綜不一，出於提高平台整體服務執行效率和統一數據平台基礎組件版本信息考量，長遠規劃，有必要對數據平台基礎設施進行整改升級，主要升級列表如下：

數據平台基礎設施大範圍升級牽扯範圍極大且操作複雜，以上述列表中所涉及平台組件為例，稍有差池即為平台級別故障，因篇幅有限，加上我們目前尚在實施過程中，待完成後有機會的話筆者單寫一篇介紹。

伴隨我司業務快速發展，數據平台底層基礎設施也在不斷調整以適應這種變化，而繁多的集群環境和龐大組件矩陣也給數據平台使用者、管理者帶來極大的不便。例如：數據平台使用者應專注於業務開發本身而無需過多關注平台底層基礎設施運轉邏輯、環境信息，避免增加學習使用成本。

為此，我們針對性規劃一個平台，開發實現多集群統一管理、數據平台計算資源治理、離線 / 實時任務管理、數據生命周期等功能，輔助平台使用者更便捷地使用數據平台資產的同時為下一步推動降本增效的開展提供治理依據。

自 2020 年開始使用 EMR 至今，我們從多種渠道了解、探索 EMR 相關實踐，自身也在不斷地深入壓榨 EMR 以滿足業務計算所需，即便如此，仍有力所不逮之處：

離線計算場景。部分高優先等級離線計算任務運行頻次不僅細化到分鐘粒度，而且業務方還無法容忍重跑帶來的整體計算延時，嚴格意義上此場景已脫離離線計算場景範疇，達到近實時計算效果，這對離線計算平台的整體響應時效性要求到近乎苛刻程度。面對如此棘手的困境，我們一方面從着手升級基礎平台計算設施以提升計算服務效率，另一方面結合業務團隊深入優化計算平台服務使用技巧，雙線並行，盡最大程度滿足業務部門需求。

實時計算場景。個別任務會因底層計算 container 資源爭搶受影響，導致計算延遲的問題，因 YARN 底層運行機制所限暫無解決辦法，雖說引入 CGroup 機制可緩解 CPU 資源爭搶問題，但相應的也會在集群管理使用帶來其他問題，總體而言得不償失。未來我們應該會在 Flink ON K8S、部分任務遷移 Kinesis Data Analytics 兩個方向以尋求突破。

文末，感謝在此過程中 AWS EMR 相關團隊對我們的支持。

作者介紹：

吳建陽，朴朴科技大數據運維負責人，主要負責支撐朴朴大數據平台離線 / 實時計算、數據湖、OLAP 等基礎設施，具有多年的大數據實戰經驗。

翁建清，AWS 資深解決方案架構師，具有多年 IT 從業經驗，涉及移動互聯網、企業、金融、政府等行業，曾任職諮詢總監、CIO、企業架構師等崗位，具有多年豐富的各類項目經驗，尤其在數據倉庫、大數據、數據應用場景等方面具有豐富的實戰經驗，目前專注於企業整體上雲的架構規劃、設計和實施。