導讀：本次演講的主題是無服務技術賦能大數據分析。亞馬遜云科技從2006年開始投入云計算，在Serverless也是有很長的演進歷程，本次跟大家分享亞馬遜云科技上的主要的數據分析Serverless組件，重點介紹在2022年6月發布的Amazon EMR Serverless。本次演講主要分為以下五個部分：

智能湖倉——現代化數據架構概覽

無服務技術演進

Amazon EMR Serverless的核心概念

Amazon EMR Serverless的常見使用場景

文檔資料

01客戶希望從自己的數據中獲得更多價值

在介紹Serverless產品之前，先簡單回顧一下客戶在數據分析領域遇到的一些挑戰。

從關系數據庫開始，數據已經呈現出爆炸性增長，特別隨著互聯網的快速增長，包括企業的數字化轉型，我們的數據也在不斷增長。有一個研究表明，每小時產生的數據比過去20年每年產生的數據還要多。從數據的來源來講，過去更多是關系型數據庫，數倉這類的結構化數據，支撐企業內BI、報表等業務，而互聯網的普及催生了更多的數據來源，像點擊流、IOT、圖片、音視頻等各種半結構化、非結構化的數據都在源源不斷地產生。從用戶場景來講，分析場景更加多樣化，除了常見的報表比如看DAU（Daily Active User，日活躍用戶數量）、PV（Page View，頁面瀏覽量）、UV（Unique Visitor，獨立IP訪客數）這樣一些信息，現在還會跟機器學習的服務，像智能推薦、自動營銷的場景。

02智能湖倉——現代化數據架構

正是在這樣的基礎上，亞馬遜云科技在2021年提出了一個智能湖倉——現代化的數據架構。

從智能湖倉的架構講，它以中心化的數據湖支撐，在亞馬遜云科技上就是S3對象存儲，周邊去構建具有極致性能的數據分析服務，包括本次重點講的基于開源的Hadoop Spark打造的商業托管平臺——Amazon EMR、云上的數倉服務——Redshift、NoSQL的服務——DynamoDB、日志分析和文本搜索服務——OpenSearch、關系型數據庫的服務——Aurora、機器學習服務——SageMaker。

在數據湖和數據倉庫之間，以及和周邊專門構建的數據服務之間，數據都可以做到無縫流轉，統一管控。同時，數據分析組件也可以將其能力進行拓展，比如在亞馬遜云科技數倉服務Redshift有Redshift ML，一旦一個報表在數倉里便可以借助ML的能力達到如銷售報表的預測等功能。

最后，這些組件具有很好的開放性，如亞馬遜云科技核心組件像EMR、OpenSearch、像托管的Kafka等，其API都是跟開源組件API百分百兼容的，所以用戶不管是自建還是從IDC環境遷移到亞馬遜云科技的托管服務上，其遷移成本都很低。

03無服務技術演進

簡單回顧一下亞馬遜云科技在Serverless的發展歷程。

從2006年亞馬遜云科技誕生開始，其第一個服務Amazon S3就是一個Serverless服務，是一個Serverless對象存儲。Amazon S3發展到今天已經有豐富的功能，包括11個9的持久性、各種數據分層，作為一個有巨量用戶和核心的服務，Amazon S3在支撐各種各樣云計算的場景。

在2013年亞馬遜云科技發布了消息流處理的Serverless服務——Kinesis，可以作為一個可擴展、伸縮的消息流服務去支撐流計算的場景。

在2014年亞馬遜云科技發布了大家熟知的重磅的、基于函數的Serverless服務——Lambda，提出了一種事件驅動的場景，對于以前需要運行虛擬機來運行的代碼，現在可以放到Lambda里面運行。

在2016年亞馬遜云科技發布了Athena BI——QuickSight，去支持BI的場景。

在2017年亞馬遜云科技發布了Glue，其是一個Serverless的ETL服務，可以在運行ETL任務的同時，不需要管理底層的基礎設施。

在2019年亞馬遜云科技發布了LakeFormation，該組件可幫助用戶快速構建數據湖，同時對數據湖和數倉的數據進行權限管理。

在2021年12月relnvent發布了4個Serverless，將組件的數量推到了極致，包括EMR Serverless、Redshift Serverless、MSK Serverless、Kinesis on-demand，這4個服務將整個數據Serverless能力拓展到了全棧。

這里會看到一個趨勢：

越來越多的數據分析服務，客戶要求其易用性，要求不去管理底層的基礎設施，越來越走向無服務化。

從單一數據分析能力走向全棧的數據分析能力。如之前數據分析服務只具備某些數據分析環節的能力，比如即時分析、ETL。到現在Serverless涵蓋從數據的攝取、存儲、大數據分析、數倉等，可以看到，Serverless已經演進到具備一個全棧數據分析的能力。

從應用人員來講，我們之前面對的數據分析的用戶更多是Bulider的角色（即要在數據分析之上構建自身的上層應用），到現在有越來越多的Buyer角色（更多的是業務團隊），Serverless提供了良好的開箱即用的能力，像數據分析師、數據科學家等用戶直接基于Serverless的數據分析產品，可以快速開展工作，如交互式查詢、數據探索等。

從PPT右上這張圖可以看出，在亞馬遜云科技上具有廣泛的serverless數據分析服務， 涵蓋流處理、NoSQL、大數據處理、數倉、BI等Serverless能力。

04Amazon EMR Serverless

本次重點講一下Amazon EMR Serverless。

Amazon EMR是在亞馬遜云科技上一個在云上的基于Hadoop生態的托管的數據分析平臺。在Amazon EC2上，幾分鐘就可以拉起一個集群，支撐用戶在上面部署需要的應用，包括主流的Hive、Spark、Presto、Flink、HBase等，支撐超過20種的開源組件。

在性能上，針對很多組件，如Spark、Hive等，做了很多的調優。

在成本收益上，Amazon EMR可以通過去預留實例，像Spot 實例的方式去節省用戶成本。

在功能上，可以與Amazon EMR Studio、NoteBook等產品做集成，做自動化的工作調度或IDE相應的工具開發的功能。

而剛剛發布的Amazon EMR Serverless則是將之前基于EC2的部署方式轉化為不需要管理任何集群的Serverless部署方式，對用戶來講更加簡單易用。

下面就幾個Amazon EMR Serverless的主要的幾個收益展開來講一下。

1. 簡單易用

第一個：簡單易用。

在以前運行EMR集群模式方式下需要勾選不同組件、選擇集群的規模、實例的類型等，開啟這個集群。那么在Serverless下就比較簡單只需更輕松地運行開源框架，比如要運行Spark，只需要選擇對應EMR版本，不需要再去選擇集群的規模和類型，在做決策上來講會更加簡單，也不需要去配置、優化、運維、對集群做一些安全的工作，更不需要像OS一樣做一些系統補丁相關的工作，非常簡單易用。

2. 無需猜測集群規模

第二個：無需猜測集群的規模。

亞馬遜云科技 Serverless 產品在后臺可以支持自動的細粒度的擴展，以一個worker為單位來進行擴展，自動為處于不同Stage、不同工作階段的負載輕松添加和刪除工作節點。

數據發生變化后也不需要再根據數據量重新配置添加或減少相應的計算節點。

只需要為自己實際使用的資源付費，和以前IDC或托管的方式下如果有常跑的集群在空閑情況下還是要付費的模式相比，Serverless只需要在使用、計算的worker的時候才需要付費，也可以指定最小的worker和最大的worker所需的資源，讓后臺資源在最小和最大的資源區間來進行彈性擴縮，有效地控制成本。

3. 無需管理集群即可獲得Amazon EMR的所有收益

第三個：無需管理集群即可獲得Amazon EMR的所有收益。

Amazon EMR有一個很大的優勢就是相較于開源框架來講，性能的優化，一般較開源組件會有2-3倍性能提升。另外， Amazon EMR會和開源組件新版本的發布周期保持一致，一般在開源新版本發布的30天和60天內就會把新的版本合入到Amazon EMR組件中。同時Amazon EMR組件的API與開源社區的API是100%兼容的，所以不管是使用習慣還是現有的在開源組件上、在IDC、在自建上有用相應的負載，遷移到Amazon EMR組件上也沒有任何的遷移成本的。

下面來看一下性能提升具體的效果：

Amazon EMR Spark Runtime v/s OSS Spark

這個性能效果，亞馬遜云科技有詳細的基于業界知名的TPC-DS的權威的測試數據。不管在Spark3還是Spark2上，Amazon EMR都提供性能優化的Spark運行時。

以Spark3為例，Spark 3.1.2與開源社區對比，基于TPC-DS 6個節點C5.9XL集群 3TB的數據做了詳細的測試，幾何平均性能提升了3.1倍，總耗時性能提升4.2倍。

適用于Apache Hive的Amazon EMR運行時

在Hive上類似，幾何平均值性能提升1.25倍，單個查詢性能提升2倍。同時，API與開源社區API 100%兼容。另外，值得一提的是，最新 Hive版本，對S3讀寫做了優化，消除了之前開銷較大的S3 re-name操作，更進一步提升了Hive處理的性能。

4. 通過細粒度擴縮節約成本

第四個：通過細粒度擴縮節約成本。

舉例：在Spark或Hive里分為不同的階段Stage，不同階段對負載的需求是不一樣的。雖然在Amazon EC2時可以支持不同負載需求的擴容，但它是EC2級別的，從響應時間講，其依賴的一些指標、擴容的時效性相對較低。

Amazon EMR Serverless在擴容的顆粒度可以精確到worker級別，時效性比集群方式的好很多。例如：在運行Spark作業時，前期可能涉及在S3的目錄讀取，不需要消耗太多負載，前10分鐘可能只需要10個工作節點；后面由于要涉及很多計算的工作，需要更多計算資源，這樣在隨后40分鐘分配了40個工作節點；在之后涉及數據計算完成進行數據移動，也不需要更多的計算資源，在后面5分鐘降到5個工作節點。以上可以看到在一個Spark作業中，可以針對不同的Stage所需的資源需求，去靈活地擴縮其工作節點，擴縮顆粒度相較于集群模式更加細粒度。

5. 可用區容錯設計

第五個：可用區容錯設計。

Amazon EMR Serverless是一個天然的Regional Service區域級服務，相較于集群模式，有更好的容錯性設計。EMR serverless會管理作業可用區的分配，選擇一個最佳可用區來運行作業，當某個可用區出現故障后，通過重試提交作業，可以把作業放到其他正常的可用區運行。因此，客戶就不必擔心單個可用區的故障造成業務中斷。

6. 以安全的方式共享應用程序

第六個：以安全的方式共享應用程序。

Amazon EMR Serverless可以為每個作業綁定獨立的IAM execution Role來做到權限和資源的隔離，簡化了多租戶環境的管理和實現。

7.? 實現交互式應用程序

第七個：實現交互式應用程序。

EMR serverless可以初始化工作節點池，來支撐對延遲敏感的業務，比如交互式查詢。

8. 易于切換的部署模式

第八個：易于切換的部署模式。

Amazon EMR代碼構建一次，在不同的EMR形態下都可以部署，包括EMR serverless, EMR on EC2, EMR on EKS等都可以去部署。

05Amazon EMR Serverless的核心概念

下面看一些關于Amazon EMR Serverless的核心概念。

1.? 應用程序（Application）

應用程序（Application）就是亞馬遜云科技的開源框架，如Hive、Spark，后續也會支持Presto。在Amazon EMR Serverless上選擇應用程序（Application）非常簡單，基于應用程序版本選擇相應的EMR版本，不同的應用程序可以對應不同的開源版本。這樣做的好處是：第一，可以維護一些獨立的邏輯環境，不同的應用程序之間不會出現資源的爭搶，在進行版本升級或執行A/B測試時也很方便。第二，在客戶側做成本核算時，可通過應用程序方式區分不同的團隊用的資源，在成本核算上可以獨立成本控制和用量追蹤。

2. 作業（Jobs）、工作節點（Workers）、初始化的工作節點（Pre-Initialized Workers）

作業（Jobs），與大家熟知的Spark作業、Hive作業沒有本質區別，只是在一個Serverless環境下運行，可以綁定相應的execution role來實現權限管控。

工作節點（Workers），是Amazon EMR Serverless的計算單位，所有的Spark、Hive組件都是基于工作節點來分配計算和存儲資源的。

初始化的工作節點（Pre-Initialized Workers），對于對延遲要求比較高的交互式任務，可以在啟動一個應用程序（Application）時，初始化一些工作節點，當作業提交過來時，任務可以立即執行，省去申請資源和預置資源的時間。相當于Amazon EMR Serverless幫助去維護一個warm pool，讓資源在stand by來快速響應任務。

06Amazon EMR Serverless的常見使用場景

快速看一下在Amazon EMR Serverless下幾個常用的場景。

1. ?場景1：數據管道

第一個場景是構建用戶數據管道。

來看一下 EMR on EC2 與 EMR Serverless 構建數據管道的方式。

在EMR on EC2上需要經過比較多的步驟：首先需要選取相應的組件，如Spark、Hive等。然后需要確定實例和集群的規模，確定集群規模的節點數及節點類型。然后創建集群，集群創建可能需要幾分鐘時間，取決于選擇的開源框架的類型、是否有自定義的啟動腳本等。集群準備好后，提交作業。作業完成后，終止集群。最后是停止。這就是EMR on EC2上的數據管道。

EMR Serverless數據管道創建：首先創建應用程序，啟動應用程序，提交作業，作業完成后自動停止。

通過對比EMR Serverless數據管道相較于EMR on EC2會簡化很多。

關于管道的擴縮容具體是怎么操作的？

例如：一個作業涉及不同的步驟，初始化工作節點是0，此時沒有任何費用產生。當步驟A需要3個工作節點時，先啟動3個工作節點。

步驟A完成后，到處理步驟B和步驟C。

根據步驟B和步驟C的工作節點需要，再分配所需的18個工作節點。而在步驟A階段的資源得以釋放，不需要再產生費用。

在步驟D時，只需要10個工作節點，之前的工作節點就會被釋放縮容。

當整個工作任務停止時，工作節點全部釋放變為0。

可以看到工作節點是根據業務負載能夠靈活地、彈性地擴縮容。擴縮的顆粒度比在集群方式下更加細化。

2. 場景2：共享集群

第二個場景是共享集群。

在IDC場景下，是通過隊列的方式來共享，但還是會出現資源沖突或資源爭搶的情況，比如在做一些成本核算時，很難說是哪些資源給到哪些團隊。在這些問題上都存在一些挑戰。

在EMR on EC2上可能會有多種任務提交方式，比如Airflow、Functions、數據工程師來提交作業等，在共享集群上，我們可以看到，是權限很難做有效的區分，另外是資源上也很難做到有效隔離。比如在運行一些交互式的任務時，突然有個很大的批量處理任務過來，可能會影響當前使用的資源。我們會建議用戶對于不同的工作負載跑在不同的集群上，但因為集群模式基于虛機部署的方式，不可避免地會出現資源浪費的問題。

在EMR Serverless上，共享集群問題就會變得很簡單。可以通過IAM execution Role方式進行資源的隔離，基于不同的作業分配相應的Workers資源。

在EMR Serverless一個作業會賦予一個Execution Role，不同的作業可以分配不同的權限，比如圖中作業A訪問S3桶A和Redshift集群A，作業B訪問S3桶B和DynamoDB表B。

從作業的調試上來講也會變得很簡單。EMR serverless提供了Spark UI、Tez UI來簡化調試工作。客戶不需要像自建集群單獨去host一個Spark History或Spark UI的服務或service。在EMR Serverless上，可以隨時借助Spark UI，查看當前或之前的作業信息，快速開始debug和troubleshooting。

3. 場景3：交互式應用程序

第三種場景就是交互式場景。

EMR serverless提供一個可選的初始化計算池。對于一些延遲要求高的任務，如交互式查詢，可以借助初始化計算池提前預置好計算資源，來提供作業響應的時效性。

如示例中，在啟動EMR 應用程序A時，設置InitialCapacity=10，先會有10個節點處于就緒狀態。

當作業需要3個節點，則從預先啟動的10個節點分配資源，來快速響應作業。

當有更多的作業提交時，比如作業B，EMR serverless優先使用預初始化的節點。

當作業超過預置的初始化節點資源時，EMR serverless會自動申請新節點資源。

當所有作業完成后，warm pool恢復之前預初始化的容量，應用程序超額使用的工作節點將被刪除

當所有作業完成，可以選擇繼續保留初始化的節點資源、還是釋放，來控制成本。