1. 概述
成千上萬的客戶在Amazon EMR上使用Apache Spark，Apache Hive，Apache HBase，Apache Flink，Apache Hudi和Presto執行大規模資料分析應用程式。Amazon EMR自動管理這些框架的配置和擴縮容，並通過優化的執行時提供更高效能，並支援各種Amazon Elastic Compute Cloud（Amazon EC2）例項型別和Amazon Elastic Kubernetes Service（Amazon EKS）叢集。Amazon EMR方便資料工程師和資料科學家通過Amazon EMR Studio（預覽版）和Amazon EMR Notebook輕鬆開發、視覺化和除錯資料科學應用程式。
可以參考來自客戶在2020 AWS re:Invent大會上的一些talk
- How Nielsen built a multi-petabyte data platform using Amazon EMR
- Contextual targeting and ad tech migration best practices
- The right tool for the job: Enabling analytics at scale at Intuit
以下部落格提供了更多資訊
- How the Allen Institute uses Amazon EMR and AWS Step Functions to process extremely wide transcriptomic datasets
- How the ZS COVID-19 Intelligence Engine helps Pharma & Med device manufacturers understand local healthcare needs & gaps at scale
- Dream11’s journey to building their Data Highway on AWS
- Enhancing customer safety by leveraging the scalable, secure, and cost-optimized Toyota Connected Data Lake
回顧2020年，EMR團隊致力於以較低的價格提供更好的Amazon EMR效能，並使Amazon EMR在LakeHouse架構中更易於管理和更易於分析，本篇文章總結了過去一年的主要改進。
2. 差異化的引擎效能
Amazon EMR簡化了大資料環境和應用程式的構建和運維，可以在幾分鐘內啟動EMR群集，並且無需擔心基礎架構設定、叢集設定、配置或調優。Amazon EMR負責這些任務，可以使得團隊集中精力專注業務開發。除了避免構建和管理自己的基礎架構來執行大資料應用程式的運維外，Amazon EMR還提供了比開源發行版更好的效能，並提供了100％的API相容性。這意味著可以以更快速度執行工作負載而無需修改任何程式碼。
適用於Apache Spark的Amazon EMR執行時是針對Spark進行效能優化的執行時。我們首先在2019年11月在Amazon EMR 5.28.0版中引入了適用於Apache Spark的EMR執行時，並使用TPC-DS基準的查詢來衡量相較於開源Spark 2.4的效能提升。測試結果表明相比開源版本查詢執行時間的平均快了2.4倍，總查詢執行時間快了3.2倍，最新結果表明Amazon EMR 5.30的執行速度是沒有執行時的3倍，這意味著執行PB級資料可以以不到傳統本地解決方案一半的成本進行規模分析。
我們還改善了Hive和PrestoDB的效能。2020年4月我們宣佈從Amazon EMR 6.0開始支援Hive低延遲分析處理（LLAP）服務。測試表明在Amazon EMR 6.0上使用Hive LLAP比Apache Hive快兩倍。2020年5月我們在Amazon EMR 5.30中引入了PrestoDB的Amazon EMR執行時，使用TPC-DS基準查詢比較了使用執行時的Amazon EMR 5.31與未使用執行時的Amazon EMR 5.29，測試結果表明使用Amazon EMR 5.31和PrestoDB的執行時，查詢執行時間的平均值快2.6倍。
3. 更簡單的增量資料處理
Apache Hudi （Hadoop Upserts, Deletes and Incrementals）是一個開源資料管理框架，用於簡化增量資料處理和資料管道開發，基於Apache Hudi，可以在Amazon Simple Storage Service（Amazon S3）資料湖中執行記錄級的插入，更新和刪除，從而簡化構建變更資料捕獲（CDC）管道，藉助此功能你可以遵守資料隱私法規並簡化資料提取管道，以處理來自流式管道輸入和事務系統CDC等來源的遲到或更新的記錄。Apache Hudi與開源大資料分析框架（例如Apache Spark，Apache Hive和Presto）整合，並以Apache Parquet和Apache Avro等開放格式維護Amazon S3或HDFS中的資料。
我們從2019年11月的Amazon EMR 5.28版本開始支援Apache Hudi。2020年6月Apache Hudi從孵化器畢業，併發布了0.6.0版本，我們在Amazon EMR 5.31.0、6.2.0及更高版本支援了該版本。Amazon EMR團隊與Apache Hudi社群合作開發了一個新的引導功能特性，該功能用於將Parquet資料集轉化為Hudi資料集，而無需重寫資料集。此引導功能可加快從現有資料集遷移至Apache Hudi資料集過程，經過測試，使用Amazon S3上的1 TB Parquet資料集，引導執行的速度比批量插入快五倍。
在2020年6月，從Amazon EMR版本5.30.0開始支援了HoodieDeltaStreamer實用程式，該實用程式提供了一種從許多來源（包括AWS資料遷移服務（AWS DMS））提取資料的簡便方法，通過此整合，可以以無縫，高效和連續的方式將資料從上游關聯式資料庫提取到S3資料湖中。有關更多資訊，請參閱使用Amazon EMR和AWS資料庫遷移服務上的Apache Hudi將記錄級別變更從關聯式資料庫應用於Amazon S3資料湖
Amazon Athena和Amazon Redshift Spectrum增加了對基於S3的資料湖中的Apache Hudi資料集查詢的支援。Athena於2020年7月宣佈支援查詢Hudi表，而Redshift Spectrum 9月宣佈支援查詢Hudi表。你可以繼續使用Amazon EMR中的Apache Hudi對資料集進行更改，然後從Athena和Redshift Spectrum查詢Apache Hudi寫入時複製（CoW）資料集的最新快照。
4. 差異化的例項效能
除了通過Amazon EMR執行時提供更好的軟體效能外，EMR團隊還提供了更多的例項選項，可以選擇為工作負載提供最佳效能和成本的例項，可以根據應用程式的要求選擇在群集中配置哪些型別的EC2例項（標準，高記憶體，高CPU，高I / O），並完全自定義群集來滿足需求。
2020年12月，我們宣佈Amazon EMR現在支援6.1.0、5.31.0及更高版本的M6g，C6g和R6g例項，可以使得能夠使用由AWS Graviton2處理器例項，AWS使用64位Arm Neoverse核心定製設計了Graviton2處理器，為Amazon EC2中執行的雲工作負載提供最佳的價格效能。儘管效能優勢會因工作負載的不同特性而有所不同，基於TPC-DS 3 TB基準測試表明，Apache Spark的EMR執行時與Graviton2相比，效能提高了15％，成本降低了30％。
5. 更容易的叢集優化
我們還使優化EMR群集變得更加容易。2020年7月我們推出了Amazon EMR Managed Scaling，這項新功能可自動調整EMR叢集大小，從而以最低的成本實現最佳效能。EMR託管擴充套件無需預先預測工作負載模式，也無需先深入瞭解應用程式框架（例如Apache Spark或Apache Hive）的規則，相反只需要指定叢集最小和最大計算資源限制，Amazon EMR會根據工作負載監視關鍵指標並優化叢集大小以實現最佳資源利用率，Amazon EMR可以在高峰期擴大叢集規模，並在閒置期間優雅地縮減叢集規模，從而將成本降低20–60％。
Amazon EMR 5.30.1及更高版本上的基於Apache Spark，Apache Hive和YARN的工作負載均支援EMR託管擴充套件，EMR託管擴充套件支援EMR例項佇列，可以無縫擴充套件競價型例項、按需例項以及保留的一部分例項，它們都在同一叢集中，可以利用Managed Scaling獲取最低成本配置的叢集。
2020年10月，我們宣佈Amazon EMR支援配置EC2競價型例項的容量優化分配策略，容量優化分配策略會自動利用可用的備用容量，同時仍然可以利用競價型例項提供的大幅折扣，這為Amazon EMR提供了更多選擇。
6. 工作負載合併
以前需要在Amazon EC2上使用完全託管的Amazon EMR或在Amazon EKS上管理Apache Spark之間選擇。在Amazon EC2上使用Amazon EMR時，可以從多種EC2例項型別中進行選擇以滿足價格和效能要求，但是不能在叢集上執行多個版本的Apache Spark或其他應用程式，並且不能為非Amazon EMR應用程式使用未使用的容量。在Amazon EKS上對Apache Spark進行自我管理時必須進行繁重的安裝、管理和優化，Apache Spark才能在Kubernetes上執行，並且無法從Amazon EMR優化執行時受益。
2020年12月，我們宣佈Amazon EKS上的Amazon EMR合併，這是Amazon EMR新的部署選項，可以在Amazon EKS上執行完全託管的開源大資料框架。如果已經使用Amazon EMR，則可以在同一Amazon EKS叢集上將基於Amazon EMR的應用程式與其他基於Kubernetes的應用程式合併以提高資源利用率並使用常見的Amazon EKS工具簡化基礎架構管理。如果當前正在Amazon EKS上自我管理大資料框架，則現在可以使用Amazon EMR來自動進行設定和管理，並利用優化的Amazon EMR執行時來提供更好的效能。
7. 更高的開發生產力
使用Amazon EMR的目標不僅是要為大資料分析工作負載實現最佳的價格效能，而且還要提供業務新見解。
2020年11月我們釋出了Amazon MWAA，這是一項完全託管的服務，可輕鬆在AWS上執行Apache Airflow的開源版本以及構建工作流以執行提取，轉換和載入（ETL）作業和資料管道。Airflow流程使用Athena查詢從Amazon S3等來源檢索輸入，在EMR叢集上執行轉換，並可以使用所得資料在Amazon SageMaker上訓練機器學習（ML）模型。使用Python程式語言，將Airflow中的工作流編寫為有向非迴圈圖（DAG）。
在AWS re:Invent 2020上我們介紹了EMR Studio的預覽，EMR Studio使資料科學家可以輕鬆地開發、視覺化和除錯用R，Python，Scala和PySpark編寫的應用程式。它提供了完全託管的Jupyter筆記本以及Spark UI和YARN Timeline Service之類的工具來簡化除錯，使用者可以將應用程式所需的自定義Python庫或Jupyter核心直接安裝到EMR叢集，並可以連線到程式碼儲存庫（例如AWS CodeCommit，GitHub和Bitbucket）進行協作。
EMR Studio核心和應用程式在EMR群集上執行，因此使用針對Apache Spark進行了效能優化的EMR執行時可以獲得分散式資料處理的優勢。也可以在AWS Service Catalog中建立叢集模板以簡化資料科學家和資料工程師的工作負擔，並可以利用在Amazon EC2/Amazon EKS上執行的EMR叢集。
8. 統一治理
在AWS我們建議使用現代化的Lakehouse架構來構建雲上資料和分析基礎架構。這不僅涉及將資料湖與資料倉儲整合在一起，而且還涉及將資料湖、資料倉儲和專用分析服務整合在一起，並實現統一的治理和資料移動。
如下圖所示，Amazon EMR與Amazon S3，Amazon Redshift等一起構成AWS上Lakelouse體系結構。
現代分析體系結構中最重要的部分之一就是可以授權、管理和稽核對資料的訪問。AWS提供了細粒度的訪問控制和治理，可以從一個控制點管理跨整個資料湖的資料訪問以及專用資料儲存和分析服務。
在2021年1月Amazon EMR整合了Apache Ranger，Apache Ranger是一個開源專案，為Hadoop和相關的大資料應用程式（如Apache Hive，Apache HBase和Apache Kafka）提供授權和稽核功能。從Amazon EMR 5.32開始，Apache Ranger 2.0外掛可啟用對Apache SparkSQL，Amazon S3和Apache Hive授權和稽核功能。可以設定多租戶EMR叢集，使用Kerberos進行使用者身份驗證，使用Apache Ranger 2.0進行授權，以及為資料庫、表、列和S3物件配置細粒度的資料訪問策略。