引言
這篇文章將給大家講解關於DolphinScheduler與AWS的EMR和Redshift的整合實踐，透過本文希望大家能更深入地瞭解AWS智慧湖倉架構，以及DolphinScheduler在實際應用中的重要性。
AWS智慧湖倉架構
首先，我們來看一下AWS經典的智慧湖倉架構圖。
這張圖展示了以S3為核心的資料湖，圍繞資料湖的是各種元件，包括資料庫、Hadoop的EMR、大資料處理、資料倉儲、機器學習、日誌查詢和全文檢索等。
這些元件形成一個完整的生態系統，確保資料能夠在企業內部自由流動，無論是從外圍到核心，還是從核心到外圍。
智慧湖倉架構的核心目標是實現資料在各個元件之間的自由移動，提升企業資料處理的靈活性和效率。
資料來源與資料採集工具
為了讓大家更直觀地理解這張圖，我們可以從左到右進行解讀。左側是各種資料來源，包括資料庫、應用程式以及資料採集和攝入工具。
這些工具包括Kinesis、MSK（託管的Kafka）和OpenSearch，都是用於高效資料攝入的優秀工具。
核心元件介紹
今天的主角是圖中圈起來的幾個關鍵元件：
- Redshift：用於資料倉儲的解決方案。
- EMR：Hadoop生態圈的大資料處理元件。
- DolphinScheduler：任務排程工具。
在大資料處理的下游，還包括BI（商業智慧）、傳統機器學習和最新的生成式AI，再往下是企業中的人、應用和裝置。這張圖展示了整個資料處理和分析的流程，使得資料處理過程更加直觀和流暢。
今天的分享主要圍繞以下兩個核心點展開：
- EMR與DolphinScheduler的實踐
- Redshift與DolphinScheduler的實踐
在此之前，我們先對EMR做一個簡要介紹。
Amazon EMR 簡介
Amazon EMR（Elastic MapReduce）是亞馬遜雲技術提供的一款雲端服務，用於輕鬆執行Hadoop生態圈的各類元件，包括Spark、Hive、Flink、HBase等。
其主要特點包括：
- 及時更新：緊跟開源社群的最新版本，30天內提供最新的開源版本更新。
- 自動彈性擴容和縮容：根據工作負載自動調整叢集規模。
- 多種計價模式：靈活組合使用不同的計價模式，實現極致價效比。
EMR與自建Hadoop叢集的比較
相比於傳統IDC機房自建Hadoop叢集，EMR具有以下優勢：
- 充分發揮原生特性
- 多種計價模式組合使用
- 自動彈性擴容和縮容
成本分析
在使用Hadoop進行資料分析和大資料處理時，企業越來越關注成本控制，而不僅僅是效能。
下圖展示了企業在IDC機房自建Hadoop叢集的成本構成，包括伺服器成本、網路成本、人工維護成本以及其他額外費用。這些成本往往非常高。
遷移到EMR的優勢
許多企業由於本地擴容困難、長週期採購流程以及升級困難等原因，逐漸將Hadoop工作負載遷移到雲上的EMR。
透過支付訂閱費用和額外支援費用，企業可以享受到以下優勢：
- 靈活的計價模式組合
- 自動彈性伸縮
- 引數調優
進一步最佳化
在完成初步最佳化後，部分企業可能仍覺得不滿足其價效比的要求，進而轉向使用EMR Serverless和EMR on EKS。這兩者本質上都是基於容器化技術，旨在實現更高的價效比。
EMR Serverless
EMR Serverless讓企業擺脫了對硬體和基礎設施的維護，更加關注上層應用和業務開發，使用者只需設定應用程式程式碼和相關引數即可。
EMR on EKS
EMR on EKS透過在Kubernetes上構建Hadoop叢集，包括Spark和Flink等元件，進一步最佳化價效比。
不僅能提高資料處理的效率和靈活性，也使得企業能夠更好地控制成本，實現業務目標。
實踐案例分享：從IDC遷移到AWS EMR
接下來透過一個真實案例，分享一個客戶從IDC遷移到AWS EMR的最佳化過程。這將幫助大家瞭解在雲上使用EMR和DolphinScheduler的具體實踐，以及如何透過這些工具實現效能和成本的雙重最佳化。
客戶背景與挑戰
該客戶原本在IDC機房採用CDH（Cloudera Distribution Hadoop），自建了一個Hadoop叢集，共有13個節點。某個任務在機房內需要13個小時才能完成。客戶希望透過遷移到雲上，降低成本並提升效率。
遷移與最佳化過程
初始遷移
客戶將其工作負載遷移到AWS雲上，採用EMR On EC2。在遷移後的初始階段，使用Hive on EMR，僅用了6個節點，任務時間縮短至10小時。此時並未進行任何調優。
接著，客戶將Hive切換為Spark，仍使用6個節點，任務時間進一步縮短至3.5小時。
透過開啟EMR的彈性伸縮功能，並將資料格式轉換為parquet，任務時間進一步縮減至2.4小時。
最終最佳化
客戶實現了叢集版EMR與EMR Serverless的混合使用，將部分工作負載遷移到EMR Serverless上，達到了極致的價效比，效能最佳化在很大程度上也代表了成本最佳化。
排程最佳化與實踐
遷移後的排程方式
在遷移到雲上的EMR On EC2後，客戶的排程方式如下：
- 任務分佈在24小時內，小任務每個大約需要20-30分鐘。
- 較大的任務集中在一天的7小時內執行。
- 超級大的任務執行時間為3-5天，甚至一週，一次執行一個月可能只需要執行兩三次。
最佳化排程
透過Apache DolphinScheduler，客戶將工作負載分別排程到EMR On EC2和EMR Serverless上。
具體做法如下：
- 小任務：放到EMR Serverless上，因為這些任務不需要3-4臺節點，10GB-20GB記憶體即可滿足需求。
- 大任務：繼續保留在EMR On EC2上，因為這些任務在雲上執行時間相對集中，則可以叢集定時開關，降低成本。
- 超級大任務：放到EMR Serverless上，透過監控每次執行的CPU和記憶體消耗，，將每次任務執行的成本視覺化，便於針對性地、持續地進行成本最佳化。
統一後設資料管理
使用AWS Glue作為統一的後設資料管理工具，使得叢集的建立、銷燬、再建立過程無需恢復後設資料或資料，同一份資料和後設資料可以在EMR On EC2和EMR Serverless之間無縫使用。
挑戰與解決方案
在此過程中，我們也遇到了一些挑戰：
- 非同步提交問題：EMR Serverless目前僅支援非同步提交，而批處理任務需要同步執行。我們透過封裝Python類庫，實現了統一的API介面，解決了這個問題。
- 日誌檢視不一致：EMR和EMR Serverless的日誌檢視方式不同。透過DolphinScheduler，我們實現了統一的日誌下載和檢視，改善了客戶體驗。
- API介面差異：EMR和EMR Serverless的API介面不同。我們透過封裝統一的API介面，減少了客戶的維護成本。
- SQL提交限制：EMR Serverless暫時不支援直接提交SQL。我們透過Python指令碼，間接實現了SQL提交。
解決方案實施
我們和客戶一起封裝了一個Python類庫，透過這個類庫，統一了EMR On EC2和EMR Serverless的任務提交、日誌查詢和狀態查詢介面。在DolphinScheduler中，客戶可以透過統一的API無縫地的在EMR Serverless 和 EMR on EC2 之間切換工作負載。
例如，在DolphinScheduler上排程到EMR On EC2時，指令碼如下：
from emr_common import Session
session_emr = Session(job_type=0)
session_emr.submit_sql("job_name","your_sql_query")
session_emr.submit_file("job_name","your_pyspark_script")
而排程到EMR Serverless時，指令碼如下：
from emr_common import Session
session_emrserverless = Session(job_type=1)
session_emrserverless.submit_sql("your_sql_query")
session_emrserverless.submit_file("job_name","your_pyspark_script"
透過Apache DolphinScheduler的引數傳遞特性，整個程式碼可以在不同引擎之間自由切換，實現了無縫排程。除了基本的job type引數之外，還有許多其他引數可供配置。
為了簡化使用者操作，系統為大部分引數設定了預設值，因此使用者通常不需要手動配置這些引數。
例如，使用者可以指定任務執行的叢集，如果不指定，系統將預設選擇第一個活躍的應用或叢集ID。
此外，使用者還可以為每個Spark任務設定driver和executor的相關引數。如果不指定這些引數，系統也會使用預設值。
封裝Session
為了實現簡化操作，我們封裝了一個session物件，這個session包含兩個子類：EMRSession和EMRServerlessSession。
根據傳入引數的不同，系統會建立相應的session物件，無論是提交SQL語句還是指令碼檔案，其介面從上到下都是一致的。
使用體驗
下面透過一些DolphinScheduler的截圖來展示其使用體驗。
上圖是DolphinScheduler上的一個Python Operator示例，包含了EMR On EC2和EMR Serverless的程式碼：
from emr_common import Session
# EMR On EC2
session_emr = Session(job_type=0)
session_emr.submit_sql("job_name","your_sql_query")
session_emr.submit_file("job_name","your_pyspark_script")
# EMR Serverless
session_emrserverless = Session(job_type=1)
session_emrserverless.submit_sql("your_sql_query")
session_emrserverless.submit_file("job_name","your_pyspark_script"
實際效果
透過上述最佳化，客戶不僅大幅縮短了任務執行時間，還實現了成本的大幅節約。
例如，在未調優情況下，任務時間從13小時縮短到10小時，而經過多次最佳化後，最終任務時間縮短到2.4小時，同時實現了叢集版本EMR和Serverless版本的混合使用。
透過這個案例，我們可以看到，透過使用AWS EMR和DolphinScheduler，企業可以在保證效能的同時，大幅降低成本，實現更高的價效比。希望這個案例能為大家在雲上進行大資料處理和最佳化提供一些借鑑和參考。
Redshift 實踐分享
Redshift是AWS推出的雲資料倉儲，已經存在十多年，是業界最成熟的雲資料倉儲之一。透過Redshift，使用者可以實現資料倉儲、資料湖和資料庫的無縫整合。
Redshift簡介
Redshift是一款分散式資料倉儲產品，支援以下功能：
- 聯合查詢與聯邦查詢：直接查詢MySQL等關聯式資料庫的資料，無需透過ETL匯入Redshift。
- 與S3資料湖的整合：透過Redshift Spectrum，直接查詢S3上的parquet等格式的資料，而無需將資料匯入Redshift。
- 與機器學習的整合：在沒有機器學習經驗的情況下，透過寫SQL就能快速且自動地完成特徵工程與模型訓練，然後進行趨勢預測、銷售預測、異常檢測等應用。
Redshift不僅支援叢集部署，還提供Serverless模式，在這種模式下，使用者無需管理負載和資源擴充套件，只需關注SQL程式碼和資料開發應用，進一步地簡化了資料開發的門檻，讓大家更加專注業務層面的開發，而不要去關注過多的關注底層的運維。
自3.0版本起，DolphinScheduler支援Redshift資料來源。透過DolphinScheduler的SQL Operator，使用者可以直接編寫Redshift的SQL，進行大資料開發和應用。
使用者可以透過拖拽介面操作，輕鬆定製DAG並監控各個任務和流程的執行情況。
併發控制
Redshift是一個OLAP資料庫，具有高吞吐量和快速計算的特點，但其併發擴充套件通常不超過50。這對於排程大量併發任務的客戶來說是一個挑戰。
為了解決這一問題，有兩個選項：
- 開啟Redshift併發擴充套件：擴充套件到預置資源的10倍容量，但會增加額外成本。
- 使用DolphinScheduler的併發控制功能：建立任務組，設定資源容量，控制排程到Redshift的任務併發，避免叢集過載。
Shell Operator實踐
在使用DolphinScheduler進行Redshift開發時，推薦使用SQL Operator，但也可以使用Shell Operator，透過sql - fxxx.sql 命令執行SQL檔案。
這種做法的好處在於可以與CICD流程整合。開發人員可以在個人電腦上透過GitLab開發程式碼，提交後自動上傳到S3桶，DolphinScheduler支援從S3桶讀取程式碼檔案，並提交到Redshift中執行。
比如說透過Jenkins實現了程式碼推送到GitLab後，自動上傳到S3儲存桶。在DolphinScheduler的資源中心建立檔案後，自動向S3寫檔案，並更新DolphinScheduler的後設資料，實現了CICD的無縫整合。
總結
今天我們分享了EMR與EMR Serverless和DolphinScheduler的整合經驗和實踐，以及Redshift與DolphinScheduler的整合實踐。以下是我個人對DolphinScheduler社群的期望和展望：
- SQL語法樹解析生成血緣關係：希望DolphinScheduler能提供基於SQL語法樹解析生成的資料血緣關係，尤其是欄位級別的血緣關係。
- 引入AI agent編排流程：希望未來DolphinScheduler能考慮引入AI agent的編排流程，或引入AI agent的Operator。
感謝大家的觀看，如果想了解更多詳情，歡迎加小助手進群交流。
本文由 白鯨開源 提供釋出支援！