- 從采集系統中收集了大量的原始數據后，數據只有被整合和計算，才能被用於洞察商業規律，挖掘潛在信息，從而實現大數據價值，達到賦能於商業和創造價值的目的；
- 面對海量的數據和復雜的計算，阿里的數據計算層包括兩大體系：數據存儲及計算平台（離線計算憑他 MaxCompute、實時計算平台 StreamCompute）、數據整合及管理體系（OneData）；
一、數據開發平台
- 阿里數據崗位工作：了解需求——模型設計—— ETL 開發——測試——發布上線——日常運維——任務下線；
- 阿里數據研發特點（與傳統的數據倉庫開發（ETL）相比）：
- 業務變更頻繁——業務發展非常快，業務需求多且變更頻繁；
- 需要快速交付——業務驅動，需要快速給出結果；
- 頻繁發布上線——在集團公共層平均每個開發人員負責 500 多個任務；
- 系統環境復雜——阿里平台系統多為自研，且為了保證業務的發展，平台系統的迭代速度較快，平台的穩定性壓力較大；
1、統一計算平台
- MaxCompute：由阿里自主研發的海量數據處理平台，主要服務於海量數據的存儲和計算，提供完善的數據導入方案，以及多種經典的分布式計算模型，提供海量數據倉庫的解決方案，能夠更快速地解決用戶的海量數據計算問題，有效降低企業成本，並保障數據安全。
- MaxCompute 工作方式：采用抽象的作業處理框架，將不同場景的各種計算任務統一在同一個平台上，共享安全、存儲、數據管理、資源調度，為來自不同用戶需求的各種數據處理任務提供統一的編程接口和界面。（提供數據上傳/下載通道、SQL、MapReduce、機器學習算法、圖編程模型和流失計算模型多種計算分析服務）
1）MaxCompute 的體系架構
- MaxCompute 由四部分組成：客戶端（MaxCompute Client）、接入層（MaxCompute Front End）、邏輯層（MaxCompute Server）、計算層（Apsara Core）；
- MaxCompute 客戶端有一下幾種形式：
- Web：以 RESTful API 的方式提供離線數據處理服務；
- SDK：對 RESTful API 的封裝，目前有 Java 等版本的實現；
- CLT（Command Line Tool）：運行在 Windows/Linux 下的客戶端工具，通過 CLT 可以提交命令完成 Project 管理、DDL、DML 等操作；
- IDE：上層可視化 ETL/BI 工具，即阿里內部名稱是在雲端（D2），用戶可以基於在雲端完成數據同步、任務調度、報表生成等常見操作；
- 接入層：提供 HTTP 服務、Cache、負責均衡，實現用戶認證和服務層面的訪問控制；
- 邏輯層：又稱作控制層，是 MaxCompute 的核心部分，實現用戶空間和對象的管理、命令的解析與執行邏輯、數據對象的訪問控制與授權等功能。（在邏輯層有 Worker、Scheduler、Executor 三個角色）
- Worker：處理所有的 RESTful 請求，包括用戶空間（Project）管理操作、資源（Resource）管理操作、作業管理等，對於 SQL DML、MR等需要啟動 MapReduce 的作業，會生成 MaxCompute Instance（類似於 Hive 中的 Job），提交給 Scheduler 進一步處理；
- Scheduler：負責 MaxCompute Instance 的調度和拆解，並向計算層的計算集群詢問資源戰友情況以進行流控；
- Executor：負責 MaxCompute Instance 的執行，向計算層的計算集群幾條真正的計算任務；
- 計算層是飛天內核（Apsara Core），運行在和控制層相互獨立的計算集群上，包括 Pangu（分布式文件系統）、Fuxi（資源調度系統）、Nuwa/ZK（Namespace 服務）、Shennong（監控模塊）等；
- MaxCompute 中的元數據存儲在阿里雲計算的另一個開放服務 OTS（Open Table Service，開放結構化數據服務）中，元數據內容主要包括用戶空間元數據、Table/Partition Schema、ACL、Job 元數據、安全體系等；
2）MaxCompute 的特點
- 計算性能高且更加普惠；
- 集群規模大且穩定性高；
- 功能組件非常強大：
- MaxCompute SQL：標准 SQL 的語法，提供各類操作和函數來處理數據；
- MaxCompute MapReduce：提供 Java MapReduce 編程模型，通過接口編寫 MR 程序出了 MaxCompute 中的數據。還提供基於 MapReduce 的擴展模型 MR2，在該模型下，一個 Map 函數后可以雞兒連續多個 Reduce 函數，執行效率比普通的 MapReduce 模型高；
- MaxCompute Graph：面向迭代的圖計算出了框架，典型應用有 PageRank、但源最短距離算法、K-均值聚類算法；
- RMaxCompute：使用 R 處理 MaxCompute 中的數據；
- Volume：MaxCompute 以 Volume 的形式支持文件，管理非二維表數據；
- 安全性高
2、統一開發平台
- 開發工作流圖
- 對應於開發工作流的產品和工具
1）在雲端（D2）
- D2：集成任務開發、調試及發布、生產任務調度及大數據運維、數據權限申請及管理等功能的一站式數據開發平台，並能承接數據分析工作台的功能；
- 使用 D2 進行數據開發的流程：
- 用戶使用 IDE 進行計算節點的創建，可以是 SQL/MR 任務，也可以是 Shell 任務或者數據同步任務等，用戶需要編寫節點代碼、設置節點屬性和通過輸入輸出關聯節點間依賴。（設置好后，通過試運行平台測試計算邏輯是否正確、結果是否符合預期）
- 用戶點擊提交，節點進入開發環境中，並成為某個工作流的其中一個節點。整個工作流可以被觸發調度——可以是認為觸發（稱之為“臨時工作流”），也可以是系統自動的（稱之為“日常工作流”）。當某個節點滿足所有觸發條件后，會被下發到調度系統的執行引擎 Alisa 中，完成資源分配和執行的整個過程。
- 如果節點在開發環境中運行無誤，用戶可以點擊發布，將該節點正式提交到生產環境中，成為線上生產鏈路的一個環節；
2）SQLSCAN
- SQLSCAN：總結開發中遇到的問題（如用戶編寫的 SQL 質量差、性能低、不准守規范等），形成規則，並通過系統及研發流程保障，事前解決故障隱患，避免事后處理。
- 用戶在 D2 的IDE 中編寫代碼；
- 用戶提交代碼，D2 將代碼、調度等信息傳到 SQLSCAN；
- SQLSCAN 根據所配置的規則執行響應的規則檢驗；
- SQLSCAN 將檢查成功或者失敗的信息傳回 D2；
- D2 的 IDE 顯示 OK（成功）、WARNNING（警告）、FAILED（失敗，禁止用戶提交）等消息；
- SQLSCAN 主要有三類規則校驗：
- 代碼規范類規則；（如表命名規范、生命周期設置、表注釋等）
- 代碼質量類規則；（如調度參數使用檢查、分母為 0 提醒、NULL 值參與計算影響結果提醒、插入字段順序錯誤等）
- 代碼性能類規則；（如分區裁剪失效、掃描大表提醒、重復計算檢測等）
- SQLSCAN 規則有強規則和弱規則兩類：
- 觸發強規則：任務的提交被阻斷，必須修復代碼后才能再次提交；
- 觸發弱規則：只會顯示違反規則的提示，用戶可以繼續提交任務；
3）DQC（Data Quality Center，數據質量中心）
- DQC：通過配置數據質量校驗規則，自動在數據處理任務過程中進行數據質量方面的監控；
- DQC 主要的兩大功能：
- 數據監控：監控數據質量並報警，本身不對數據產出進行處理，需要報警接收人判斷並決定如何處理；
- 數據清洗：將不符合既定規則的數據清洗掉，保障最終數據產出不含“臟數據”，數據清洗不會觸發報警；
- DQC 數據監控規則有強規則和弱規則之分，強規則會阻斷任務的執行（將任務置於失敗狀態，其下游任務將不會被執行）；而弱規則智慧警告而不會阻斷任務的執行。
- 常見的 DQC 監控規則：主鍵監控、表數據量及波動監控、重要字段的費控監控、重要枚舉子彈的離散值監控、指標值波動監控、業務規則監控等。
-
4）在彼岸
- 在彼岸：自動化的大數據測試平台，將通用的、重復性的操作沉淀在測試平台中，避免被“人肉”，提高測試效率。
- 數據測試的典型測試方法是功能測試，主要驗證目標數據是否符合預期，主要場景：
- 新增業務需求
- 測試原因及目的：新增產品經理、運營、BI等的報表、應用或產品需求，需要開發新的 ETL 任務，此時應對上線前的 ETL 任務進行測試，確保目標數據符合業務預期，避免業務方根據錯誤數據做出決策；
- 測試方法：對目標數據和源數據進行對比，包括數據量、主鍵、字段空值、字段枚舉值、復雜邏輯（如 UDF、多路分支）等的測試；
- 數據遷移、重構、修改
- 測試遠程及目的：由於數據倉庫系統遷移、源系統業務變化、業務需求變更或重構等，需要對現有的代碼邏輯進行修改，為保證數據質量需要對修改前后的數據進行對比，包括數據量差異、字段值差異對比等，保證邏輯變更正確。
- 測試方法：對優先級大於某個閾值的任務，強制要求必須使用在彼岸進行回歸測試，在回歸測試通過后，才允許進入發布流程。
- 在彼岸的測試組件：數據測試的數據對比組件、數據分布組件、數據脫敏組件；
- 數據對比組件：支持不同集群、異構數據庫的表做數據對比。（表級對比規則主要包括數據量和全文對比；字段對比規則主要包括字段的統計值（如 SUM、AVG、MAX、MIN 等）、枚舉值、空值、去重復、長度值等。）
- 數據分布組件：提取表和字段的一些特征值，並將這些特質值與預期值進行行比對。（表級數據特質提取主要包括數據量、主鍵等；字段級數據特質提取主要包括字段枚舉值分布、空值分布、統計值（如 SUM、AVG、MAX、MIN 等）、枚舉值、空值、去重復、長度值等。）
- 數據脫敏組件：將敏感數據模糊化。（在數據安全的大前提下，實現線上數據脫敏，在保證數據安全的同事又保證數據形態的分布，以便業務聯調、數據調研和數據減緩。）
二、任務調度系統
1、背景
- 調度系統：整個大數據系統的智慧中樞。
- 在大數據環境下，每天需要處理海量的任務，多的可以達到幾十上百萬。另外，任務的類型也很復雜，有 MapReduce、Hive、SQL、Spark、Java、Shell、Python、Perl、虛擬節點等，任務之間互相依賴且需要不同的運行環境，任務調度系統就是所有任務的指揮系統。
- 傳統的數據倉庫系統中，很多是依靠 Crontab 定時任務功能進行任務調度處理的，此方式有很多弊端：
- 個任務的依賴基於執行時間實現，容易造成前面的任務未結束或失敗而后面的任務已經運行；
- 任務難以並發執行，增加了整體的處理時間；
- 無法設置任務優先級；
- 任務的管理維護很不方便，無法進行執行效果分析。
2、介紹
1）數據開發流程與調度系統的關系
- 用戶通過 D2 平台提交、發布的任務節點，需要通過調度系統，按照任務的運行順序調度運行。
2）調度系統的核心設計模型
- 兩個核心模塊：調度引擎（Phoenix Engine）、和執行引擎（Alisa）。
- 調度引擎：根據任務節點屬性以及依賴關系進行實例化，生成各類參數的實值，並生成調度樹；
- 執行引擎：根據調度引擎生成的具體任務實例和配置信息，分配 CPU、內存、運行節點等資源，在任務對應的執行環境中運行節點代碼。
3）任務狀態機模型
- 任務狀態機模型：是針對數據任務節點在整個運行生命周期的狀態訂閱，總共 6 種狀態：
4）工作流狀態機模型
- 工作狀態機模型：針對數據任務節點在調度樹中生成的工作流運行的不同狀態的定義，共有 5 找那個狀態：
5）調度引擎工作原理
- 原理：基於任務狀態機模型和工作流狀態機模型原理，以事件驅動的方式運行，為數據任務節點生成實例，並在調度樹中生成具體執行的工作流。任務節點實例在工作流狀態機、任務狀態機和事件處理器之間轉換，其中調度引擎只涉及任務狀態機的未運行和等待運行兩種狀態：
- Async Dispatcher：異步處理任務調度；
- Sync Dispatcher：同步處理任務調度；
- Task 事件處理器：任務事件處理器，與任務狀態機交互；
- DAG 事件處理器：工作流事件處理器，與工作流狀態機交互。（一個DAG 事件處理器包含若干個 Task 事件處理器。）
6）執行引擎工作原理
3、特點及應用
1）調度配置
- 常見調度配置方式：對具體任務手工配置依賴的上游任務。
- # 此方式存在兩個問題：一是配置上比較麻煩，需要知道上游依賴表的產出任務；二是上游任務修改不在產出依賴表或本身任務不再依賴某上游任務時，對調度依賴不做修改，導致依賴配置錯誤。
2）定時調度
- 根據實際需要，設定任務的運行時間，共有 5 種時間類型：分鍾、小時、日、周、月，具體可精確到秒。
3）周期調度
- 按照小時、日等時間周期運行任務，與定時調度的區別是無需指定具體的開始運行時間。
4）手動運行
- 當生產環境需要做一些數據修復或其他一次性的臨時數據操作時，可以選擇手動運行的任務類型，在開發環境（IDE）中寫好腳本后發布到生產環境，再通過手動觸發運行。
5）補數據
- 在完成數據開發的發布以后，有些表需要進行數據初始化，比如有些日增量表要補齊最近三年的歷史數據，這時就需要用到補數據任務。（可以設定需要補的時間區間，並圈定需要運行的任務節點，從而生成一個補數據的工作流，同時還能選擇並行的運行方式以節約時間。）
6）基線管理
- 基於充分利用計算資源，保證重點任務優先產出，合理安排各類優先級任務的運行，調度系統引入了按優先級分類管理的方法。
- 優先級分類從 1~9，數字越大代表優先級越高，系統會先保障高優先級任務的運行資源。
- 對於同一類優先級的任務，放到同一條基線中，可以實現按優先級不同進行分層的統一管理，並可對基線的運行時間進行預測估計，以監控是否在規定的時間內完成。
7）監控報警
- 調度系統有一套完整的監控報警系統，包括針對出錯的節點、運行超時未完成的節點，以及可能超時的基線等，設置電話、短信、郵件等不停的告警方式，實現了日常數據運維的自動化。