一、背景概述
1.1 什麼樣的客戶需要數據湖
在數據處理領域，數據湖相對來說是一個比較新的概念，它的提出可以很好地幫助企業應對當前數據場景越來越多、數據結構越來越複雜、數據處理的需求越來越多樣化的問題。傳統的單機數據庫技術傾向於大一統，一個數據庫可以解決數據存儲、在線交易、在線分析、離線報表等功能，好處是簡單，數據只有一份，缺點是各個功能都做了取捨，很難解決規模的問題。爲了突破數據規模的瓶頸，大數據技術更傾向於針對單獨領域做深度定製，比如海量文件存儲使用HDFS、海量對象存儲使用OSS/S3、寬表存儲使用BigTable/HBase、嵌套數據使用MongoDB、大規模TP數據使用PolarDB、大規模AP數據使用ADB/Clickhouse、日誌數據使用LogService等等。
在很多企業裏面，不同的部門業務不同，採用的數據方案也不同。在企業發展的前期，更多是靠業務模式驅動、流量驅動，數據複雜度的問題還不明顯，後期則需要精細化運營、向數據要紅利，數據管理的難度就成爲企業的痛點。數據湖的出現可以很好地解決這個痛點，這也是爲什麼各個雲廠商都推出了數據湖產品，數據湖產品和解決方案越來越得到客戶的認可。Gartner 2020年發佈的報告顯示目前已經有39%的用戶在使用數據湖，34%的用戶考慮在1年內使用數據湖。
1.2 Aliyun DLA數據湖整體方案
Aliyun數據湖分析（DLA）產品提供了數據湖的一站式解決方案。OSS對象存儲採用KV的技術架構，可以實現無限擴展，是公認的數據湖存儲底座。用戶可以通過離線ETL和在線增量ETL將在線數據和實時增量數據，同步到OSS中，然後對數據做深度的計算和分析。用戶也可以直接訪問這些在線庫，做在線的聯邦分析。爲了方便用戶管理數據湖中的數據，我們提供了統一的數據湖管理方案。數據湖管理可以統一存儲數據湖中數據的元信息給計算引擎使用，另外還提供元數據動態爬取功能，可以動態解析OSS數據目錄結構和數據格式，省去了用戶手動創建表和分區的工作。DLA同時提供了SQL和Spark兩個引擎，SQL基於Presto實現，可以實現在線分析，Spark可以實現用戶自定義代碼和複雜計算邏輯。同時，DLA跟DMS和QuickBI進行了深度集成，方便用戶實現更豐富的開發和管理邏輯。
二、DLA Serverless Spark架構解析
2.1 DLA Spark爲什麼是雲原生 + Serverless
2.1.1 數據湖天然存儲計算分離
數據湖技術處理的對象是用戶已存在的所有的數據。這裏提到兩個關鍵定語“已存在的”和“所有的”。要處理好“已存在的”原始數據，最好的方式顯然不是先將其導入到數據倉庫中，最好是能夠原地分析，使用單獨的計算資源來計算分析各種類型存儲系統中的數據，這就是存儲計算分離的架構。存儲計算分離的架構能夠做到存儲和計算的分層彈性，存儲可以無限擴展，計算能夠按需彈性調度。這裏提到了彈性計算，計算的彈性可以分很多層次：
集羣級彈性：用戶可以按需購買ECS並部署集羣，然後後再執行計算任務，任務執行完之後再釋放掉集羣；
作業級彈性：用戶每個作業都是單獨的計算資源，作業執行完之後立即釋放；
作業內彈性：一個任務在執行過程中，不同的階段所需要消耗的資源不同，典型地，分佈式作業出現長尾時，大部分資源都是空閒的，此時可以將空閒資源釋放掉；
容器內彈性：計算任務的進程在執行過程中不同時段所需要的資源不同，是否可以做到動態調節；
彈性的粒度越細，資源的利用率越高，成本也就越低。相對於傳統IDC，雲的最大的優勢之一就是彈性，數據湖天然是存儲計算分離的，跟雲彈性的能力十分匹配，數據湖場景下，雲原生 + 彈性是必然趨勢。
2.1.2 Serverless是雲的趨勢
Serverless是業內公認的雲發展的一個趨勢。其實不難理解，從IDC自建到搬站上雲再到Serverless化符合技術和客戶需求發展的規律。
在雲最初產生的時候，大家把雲計算基本等同於虛擬化技術，客戶最普遍的需求是將線下的站點搬上雲，用戶把雲當做對線下硬件的替換，企業的IT研發、運維大體跟上雲前一致。用戶對大數據系統，比如Hadoop集羣，也類似，把線下集羣換成虛擬集羣，再由專門團隊運維大數據集羣。在雲市場發展的第一階段，這種模式有用戶習慣的因素，也有性能、成本等的因素，自建跟雲產品在性能上差距不太大，在成本上甚至更便宜，客戶也擁有一定的掌控感。然而，雲的技術會繼續往精細化深入發展，從資源共享的角度來看，每套Hadoop集羣都有一套自己的管控，這些管控包括Master節點，Core節點上面的守護進程，以及配套的監控、運維管理等系統。這些資源和人力投入實際上對企業來說都只是成本，並不產生真正的計算價值。
隨着雲技術的發展，Serverless形態可以很好的解決企業在第一階段遇到的問題，企業只需要關心自己的業務開發，只爲真正參與計算的資源付費，雲產品把管控的部分統一管理起來，邊際成本可以做到很低。另外，雲產品會深度紮根於雲基礎設施，對性能、彈性、使用體驗等做持續深入優化，相對於第一階段的用戶自建模式可以實現數倍的性價比提升。最後，隨着雲產業的發展，雲產品會越來越標準化，客戶也不必擔心被雲綁定的問題。在雲市場進入第二階段，Serverless形態的產品讓企業更專注於自身業務，進一步降低運維和資源成本，讓開發者擁有更好的使用體驗以及更低的入門門檻。
2.1.3 Spark一站式解決數據湖計算需求
“所有的”意味着數據的來源途徑多種多樣，存儲位置多種多樣，數據格式多種多樣。這就要求計算引擎可以支持所有數據類型，並且可以很方便的做分析、計算，因爲數據是“已存在的”，Schema只能在讀取的時候才能確定，而不能依賴用戶把表都提前建好。Spark非常適合數據湖場景：
Spark本身內置了十分豐富的數據源連接器，接口也很方便擴展；
Spark既支持使用SQL，又支持編寫多種語言的DataFrame代碼，兼具易用性和靈活性；
Spark一站式引擎能力，同一個引擎同時提供SQL、流、機器學習、圖計算的能力；
DLA團隊將Serverless、雲原生、Spark技術優勢深度整合到一起，提供Serverless Spark產品，兼具三者優勢。下面我們將對Serverless Spark產品架構進一步解析。
2.2 自建Spark集羣 VS Serverless Spark
上圖中左半部分是傳統最常見的集羣版Spark，右邊是Serverless Spark。集羣版Spark大家都比較熟悉，每個用戶一個集羣，集羣內部擁有一套完整的Spark管控，用戶使用方式上跟傳統IDC模式一致。
Serverless Spark將管控完全多租戶化，相對於傳統的集羣模式，Serverless Spark抽象出一個虛擬集羣的概念。虛擬集羣只是承載用戶對作業進行控制的一些配置，包括網絡的配置、安全隔離的配置、計算資源Quota的配置、作業通用參數的配置等。由於是虛擬集羣，所以集羣創建基本都可以做到秒級完成。用戶創建完虛擬集羣之後，就可以往虛擬集羣提交作業，去訪問用戶在各個存儲引擎中的數據。
Serverless Spark在彈性能力上基於Aliyun Kubernetes雲原生技術深度定製，調度層可以實現秒級拉起，一分鐘可以並行拉起300個計算節點，後續還會持續優化。Serverless Spark控制服務實現了對雲資源、作業、庫表列元數據、租戶、安全等管理，對上提供阿里雲OpenAPI，用戶可以通過OpenAPI實現作業的提交和管理。另外Serverless Spark會跟其他雲產品深度集成，進一步豐富用戶的使用場景，目前Serverless Spark已經跟DMS進行集成，可以實現工作流，定時調度等管理。
在上表中，我們在集羣運維、性價比、作業開發等方面對比了兩種形態的差異。從使用體驗上，Serverless Spark可以做到開箱即用，一分鐘就可以跑通一個Spark作業；從成本上，由於將管控完全多租戶化，用戶不需要承擔這部分額外開銷，只需要實際使用付費；從運維方面，一個企業中一個管理員就可以實現整體管理工作，大大降低運維成本。
三、DLA Serverless Spark性價比**
3.1 1TB Terasort DLA Spark vs 自建Hadoop 性價比對比
我們先對比下1TB數據情況下，數據湖方案跟傳統Spark集羣方式的性價比。相關配置說明如下：
TeraSort輸入1TB + shuffle大約1TB + 輸出1TB，作業每天跑一次。
Hadoop集羣配置：單Master（4c8g） + 5個Core（8c32g），Core節點配置4塊500GB的高效雲盤。一般高效雲盤採用2備份的HDFS配置。這裏存儲空間是4 500GB 5 / 2 = 5TB。
Serverless Spark採用40CU + 2TB OSS。
對比結果如右圖所示，作業性能上Serverless Spark跟Hadoop基本持平，但是性價比差異非常大，DLA Serverless Spark會節約80%。也就是會有4-5倍的性價比提升。
需要說明的是：
Hadoop集羣配置是一個總容量5TB集羣的典型配置，一般情況下集羣不能把磁盤都用滿，要留一定buffer，否則系統可能會出現各種空間不足問題。
Serverless Spark完全按需使用存儲和計算資源。
Serverless Spark對OSS訪問實現了深度定製優化，性能相比於社區提升1倍左右。
3.2 10TB Terasort DLA Spark vs 自建Hadoop 性價比對比
對於更大規模數據，比如10TB，對比結果如上圖所示。相關配置說明：
TeraSort輸入10TB + shuffle大約10TB + 輸出10TB。作業每天跑一次。
Hadoop集羣配置：單Master（4c8g） + 5個Core（16c64g），Core節點配置8 5.5TB的本地盤。一般本地盤採用3備份的HDFS配置。這裏存儲空間是5 8 * 5.5TB / 3 = 73TB。
Serverless Spark採用80CU + 50TB OSS。
我們發現性能上DLA Spark提升了1倍，成本反而降低了一半，性價比提升4倍。
需要說明的是：
Hadoop集羣採用的是大數據量場景下的典型配置，採用本地盤D1機型，成本相對於雲盤要便宜。由於本地盤機型要求空間比較大，16c64g的只能配置44TB的本地盤，考慮到Hadoop集羣的本地盤通常不能打太滿，爲了公平起見，我們採用OSS的空間是50TB。
在分析性能時發現，在10TB場景下，本地盤的存儲和shuffle之間會有IO帶寬上明顯的爭用，而Serverless Spark計算節點自帶essd雲盤，將shuffle盤完全獨立，對性能提升有較大的貢獻。
3.3 Serverless Spark訪問用戶自建Hadoop
用戶可以將自建Hadoop和Serverless Spark混合使用，用戶Hadoop集羣在高峯期需要更多的計算資源，用戶可以直接提交Serverless Spark來實現對計算彈性的需求。由於Serverless Spark可以做到直接跟用戶VPC打通，可以直接使用內網帶寬，經過對比兩者的性能基本持平。
四、使用場景
面向數據湖中的各種各樣的數據，Spark可以用於如下場景：
生態打通：Spark的多數據源能力，提供外部數據源批量入庫、聯邦分析能力；DLA Spark會跟雲上數據源做深度集成優化，解決穩定性問題並提升性能；
算法及用戶可編程：支持python、java、scala、R、SQL多語言，支持複雜的數據過程處理(類似PL/SQL)、機器學習等；
離線數倉(複雜分析)：支持複雜離線分析，提供天/月級別的報表等；
半結構化/非結構化處理：搭配HDFS/OSS存儲爲數據庫添加非結構化數據存儲處理能管理(CSV、XML、Parquet多種存儲)；
離線ETL：可以用於各存儲引擎之間的數據轉換、清洗、歸檔等操作；
實時計算：Spark Streaming + Hudi可以實現數據實時轉存，實現在不影響在線庫穩定性情況下，對實時數據的複雜分析；Spark Streaming實時ETL將多個MySQL大表，合併爲一個ADB寬表，避免大表在線join，提高在線分析性能。
上圖是某遊戲公司使用DLA解決數據湖場景問題的方案。用戶要對在線庫RDS做分析，但又怕影響RDS的穩定性，於是選擇採用DLA一鍵建倉功能將其同步到OSS裏面轉爲列存；用戶遊戲APP的日誌數據會接入到Kafka裏面，然後通過Spark Streaming實時寫入到OSS，數據採用Hudi增量數據湖格式。數據流入到OSS後，用戶會對數據使用DLA SQL（Presto）做在線分析，也會對歷史數據做複雜分析和機器學習，挖掘遊戲玩家的使用規律。