Amazon Elastic MapReduce（以下簡稱EMR）是集齊數據接入、存儲、計算、交互式查詢、機器學習等一系列開源社區組件封裝的雲上託管大數據平台，用戶可以基於EMR迅速建立一套大數據集群，用於大規模數據處理、分析，使用時可根據實際業務所需靈活調配計算資源，一定程度上降低底層基礎設施運維成本。Amazon是最早將大數據管理平台上雲的雲廠商，查詢其官網發行版本記錄，能檢索到的最古老版本EMR-4.2.0發布日期為2015年11月18日，當時大數據領域最火的三家Hadoop發行廠商：Cloudera、Hortonwoks、MapR，三分天下，互為掎角，世事難料的是幾年後的今天惟Cloudera一家尚存。
入門
- EMR集群單元構成
Amazon官網介紹EMR部署模式有：EC2、EKS、Outposts、Serverless這幾種，後兩者目前尚未在國內上線，而當前階段EMR On EKS模式有使用場景限制（僅支持SPARK應用）。
EMR集群由三個組類構成：MASTER、CORE、TASK，典型的EMR集群實例組架構如下圖所示：
- 上手管理EMR集群
▌部署
EMR控制台提供兩種部署模式：快速、高級，快速選項模式用戶可根據提供的模板，簡單配置後即可構建集群，高級選項模式則提供給用戶更多自主選擇，支持從軟體、硬體、集群設置、安全性四大方面自定義配置構建集群。
▌集群配置
自定義配置支持集群全局範圍和實例組範圍，參數項變更操作支持JSON或表格兩種格式編輯，這裡要注意的是EMR控制台頁面<集群配置>只允許在集群構建初始化階段定義，集群上線後即不可被修改，EMR控制台在5.21.0及之後的版本支持實例組級別（運行中）服務配置項修改，具體配置項分發支持可檢索參考官網發行版<配置分類>說明。
▌監控
EMR原生提供部分指標並集成至Amazon CloudWatch，用戶可在控制台查看或到CloudWatch檢索，常用指標基本已提供，若指標項不足以滿足需求，可基於Prometheus+Grafana套件自行實現指標採集與監控告警。
▌安全性
用戶在構建EMR集群前，建議事先定義創建好VPC網絡、安全組及IAM角色，部署過程中引用這些安全性定義，當集群構建完畢後，所有EC2實例的安全訪問即可實現受控，避免集群出現訪問安全方面隱患。
進階
1、更優雅便捷地構建集群
▌集群克隆
當集群出現故障或人為手動終止且該集群上存在許多用戶自定義配置項時，在EMR控制台頁面有個克隆功能，可通過此功能鏡像方式創建新集群，新集群構建時會自動同步舊集群用戶自定義配置項，避免配置項丟失或遺漏。
▌高級API
除EMR控制台外，用戶還可基於Amazon CLI、Amazon SDK、Amazon WEB API三種更高級定義的方式創建集群，先以JSON格式定義好集群模板，一鍵POST提交後靜待十分鐘，一個新鮮出爐的集群即已創建完畢。
2、集群環境初始化
一個EMR集群要上線，並不止於構建完畢，還需對集群環境做初始化工作，通常初始化操作分兩步：作業系統及平台組件環境。
▌作業系統
EMR底層EC2實例所引用的系統映像已由後台針對大數據場景做針對性系統參數優化，因此，一般情況下用戶無需再做定製化修改，只要初始化系統時區、Prometheus node_exporter服務、dnsmasq、Docker（若有網段定義衝突）等基礎服務設施即可。
▌平台組件
泛指HDFS/YARN/SPARK之類組件配置項，EMR初始化生成的組件配置項大多為默認值或者通用化模板配置，部分場景會存在不適用問題，因此建議用戶務必按照集群運行環境所需進行修改。
3、自定義AMI
若用戶需在EMR集群範圍集成較多複雜組件，卻又不想花費太多精力在部署運維上，可嘗試使用自定義AMI映像方案。
4、監控告警完善
▌標籤定義
具體是指對EC2實例和EMR平台服務打標籤，便於之後告警項治理。打標籤應成為一種習慣，從管理角度其價值不言而喻。
▌集群EC2實例指標採集
▌集群平台組件指標採集
EMR所提供的組件指標不能完全滿足我司實際指標監控需求，作為管理員可自行開發exporter服務將組件指標採集後匯聚到監控中心，依託於監控中心實現平台組件服務監控覆蓋和告警能力，也可以將這些指標推送至Amazon CloudWatch服務進行告警實現。
5、scale規則使用
在沒有scale機制的自建Hadoop集群，不可避免地會碰到計算資源問題（不足或未用滿），一種典型的做法是將計算引擎運行在K8S上，與業務平台錯峰使用，以提高整體資源利用率。在EMR上用戶可基於cluster或InstanceGroup兩個層面定義scaling規則，規則觸發後即進行集群節點擴縮容操作。
scale一般是應用在需動態伸縮的Core/Task節點，Core相對而言伸縮偏穩定保守一些，建議按比例固定。因此scale著重應用於Task節點並分別按OnDemand&Spot機型靈活配比，scale配置時支持多種指標定義，用戶可擇其一或多指標組合形成多層次彈性伸縮規則。
6、bootStrap
一個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上傳會有一定滯後。
當上述階段步驟執行全無問題後，即確認為集群節點服務部署正常，最後狀態變更上線。
7、CORE NodeLabel
EMR集群上線時會設定一些資源調度策略，該策略會最終影響計算任務調度分布。
8、集群使用 RDS
▌優點：
- 開箱即用，基本免運維，原生支持高可用；
- EMR後台已對JDBC相關兼容性做適配。
▌缺點：
- 版本升級需重啟RDS服務，諸如安全補丁之類升級會較頻繁；
- 需單獨監測底層是否發生A-Z切換，若有集群需重啟相關組件服務，確保連接有效；
- 高版本RDS與EMR兼容性適配不佳，建議RDS不要超過7版本。
9、集群存儲使用
既已使用了EMR，那麼選擇Amazon S3作為主數據存儲就是自然而然的選擇，一者存算分離是使用趨勢，二者EBS與S3相比存儲成本不在一個量級。在EMR體系中，CORE節點作為主數據存儲節點，承載著分布式文件系統角色。
▌節省成本：小規模場景使用綜合成本節省比較明顯，當規模達到PB級時，EC2、EMR、S3、網絡流量四者成本累計則未必，所以需要進一步進行架構優化，以獲取最佳性價比。
▌監控方面：集群缺乏組件服務狀態如健康程度、HA狀態等類指標查看，可根據需要利用exporter採集。
▌集群部署&管理：基於快速構建集群設計思想，導致部署操作集成度較高，若過程出現異常，只能重新執行構建操作，無法斷點連續操作，個別場景下集群驗證有明顯等待時間成本；EMR組件只提供initctl/systemd系統進程管理方式，不支持按組件/進程級別進行啟/停。
▌擴展伸縮：EMR scale機制不支持以CPU vCore指標作為彈性伸縮規則，在混合計算業務場景scale伸縮某些時刻會不符合預期。
▌安全性：依託於VPC子網、安全組、IAM Role等多重機制提供安全性保障。