一、背景概述
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進行內建，可以實作工作流，定時排程等管理。
| 對比次元 | 自建Hadoop叢集 | Serverless版 |
|---|---|---|
| 内置存儲 | HDFS | 資料湖存儲OSS |
| 叢集形态 | ECS叢集，需配置Master、Core規格 | 虛拟叢集，隻需配置資源quota |
| 叢集管理 | 擴縮容、升降配 | quota調整，參數配置 |
| 售賣形态 | 執行個體型，叢集粒度，按ECS規格售賣 | 服務型，按作業實際使用CU*時收費 |
| 資源彈性 | 叢集級别 | 作業級彈性 |
| 成本效益 | 低：管控開銷+資源空閑開銷 | 高：按需付費 |
| 維護成本 | 高：運維團隊維護叢集 | 低：管理者配置設定資源 |
| 作業管理 | Livy、腳本、控制台、定時排程、作業編排 | OpenAPI、腳本、控制台、定時排程、作業編排 |
| 租戶支援 | 依賴開源，配置複雜 | Aliyun RAM |
| 學習成本 | 高：需要先學習叢集管理與配置 | 低：隻需要學習Spark開發 |
在上表中，我們在叢集運維、成本效益、作業開發等方面對比了兩種形态的差異。從使用體驗上，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）做線上分析，也會對曆史資料做複雜分析和機器學習，挖掘遊戲玩家的使用規律。
五、總結與展望
針對使用者面臨的越來越多的資料湖場景典型問題，阿裡雲DLA産品提供了一體化解決方案，從資料湖管理到資料湖分析和計算。相對于線上引擎，Spark更适合彈性計算架構，可以跟雲原生的彈性能力深度整合起來。從傳統IDC到搬站上雲到完全Serverless化，這條路徑已經被越來越被認可為雲技術的發展路徑。DLA Spark采用完全雲原生 + Serverless形式，相對于傳統的自建Hadoop在成本效益上擁有數倍的優勢。
未來，DLA Serverless Spark會面向資料湖場景做進一步深度優化：
- 更便宜：實作更細粒度的彈性繼續降低成本；
- 更快：優化Spark核心本身，特别是跟雲存儲之間做深入定制優化，提升引擎性能；
- 更好用：降低Spark開發難度，更進一步提升使用者使用體驗。
注：DLA Serverless Spark
控制台使用連結，DLA Serverless Spark
幫助文檔。