一、概述
2020年黑天鵝事件不斷出現,疫情給人們的生活也帶來了改變。在後疫情時代,伴随着雲原生技術的發展,企業尋求更加靈活、更加靈活的資料分析方案,資料湖剛好滿足這核心訴求。有不少同學問筆者,Hadoop與資料湖有啥差別?筆者認為,其一:資料湖分析支援的資料格式包括非結構化與半結構化。雖然HDFS可以存圖檔,但是一般還是有視訊&圖檔的專門的伺服器的,原因存儲計算不分離情況下,大資料硬體存圖檔不經濟; 其二:資料湖往往跟雲結合更加緊密,因為存儲計算分離以後,存儲與計算可以單獨發展。計算可以跟業務系統錯峰排程,再結合不同公司計算任務的差異,可以增強彈性能力。其三:資料湖的技術與資料倉庫進一步融合,如Hudi支援資料實時寫入、事務與更新。
阿裡雲雲原生資料湖分析DLA,在這樣的背景下誕生,曆經兩年的發展,充分結合 雲、Presto、Spark、Hudi等優勢,建構出了新一代的大資料方案。目前DLA已經服務了數千客戶,不少公司的核心數倉也是基于DLA;DLA也內建在友盟、CDN、DBS(資料庫備份)、IOT、QuickBI等産品中,間接服務了數萬客戶;
我們也重視開源與商業合作,目前,DLA是Apache PrestoDB基金會的代表;與Alluxio達成戰略合作,共同建構緩存系統;團隊有數位Apache的Committer,一起參與貢獻開源社群。
本文主要概述講述下 阿裡雲雲原生資料湖分析(簡稱DLA)為了應變分析之大變局,在2020年主要實作的一些事情。資料湖分析DLA官網連結:
https://www.aliyun.com/product/datalakeanalytics雲原生資料湖分析的基本架構如下:

DLA分為DLA Meta、DLA Lakehouse、DLA Presto、DLA Spark 四大子產品。在20年我們重寫了中繼資料子產品,增加了中繼資料與資料源之間的同步子產品,針對OSS可以發現中繼資料,簡化使用者的配置管理;在資料管理Lakehouse方向上支援了RDS MySQL實時同步到Hudi,目前正在産品化中;新增了DLA Serverless Spark子產品,支援按照Job計費,重寫了接入層,實作了多租戶的UI,并且針對OSS做Rename等核心性能優化;DLA Presto改進了掃描版的穩定性,增強核心性能,實作了CU版本的産品形态,并且保持掃描量版本與CU版本統一架構。接下來分子產品講述:
二、DLA Meta

對比開源的Hive中繼資料,DLA Meta是相容Hive meta的,支援雲上15+種資料資料源(OSS、HDFS、DB、DW)的統一視圖,引入多租戶、中繼資料發現等能力。DLA Meta追求邊際成本為0,免費提供使用的。
- 企業級權限管理:支援多賬号的權限與隔離,可以簡單的GRANT&REVOKE對子賬号賦予權限,Meta會托管OSS與DB賦予的權限,DLA Presto與DLA Spark通過内部的API拿到相應的權限,通路OSS與DB資料庫;
- 開放通路:通過OpenAPI可以直接拿到Meta的資訊,客戶自建的Spark叢集也可以使用DLA Meta;
- 擴充性強:MetaServer是無狀态的服務,可以擴充多個叢集;在中繼資料存儲采取的是多庫存儲,可以無限擴充;
- 中繼資料發現:支援OSS 數倉模式發現,SLS投遞到OSS資料發現,OTS中繼資料自動同步。支援客戶一鍵發現中繼資料,這些中繼資料也會自動維護。 典型的場景是:使用者的APP可以不斷往OSS寫新的Partition,中繼資料發現服務會自動同步Partition。
三、DLA Lakehouse
資料湖有着巨大的低成本、擴充性的優勢。但是在資料組織與維護方面,天然比數倉有着不足。不少客戶通過代碼維護一套數倉體系:基本流程為準備資料,再通過Spark&Hive清洗,建構離線的資料倉庫。 DLA目前在基于Apache Hudi實作DLA Lakehouse,主要目标是提供高效的湖倉,基本的架構圖如下圖所示:

此子產品已經有不少客戶使用,目前還缺乏産品化,是以方案提供。在接入層已經支援RDS MySQL通過DTS實時寫資料到Lakehouse中,接入層全量&增量子產品均是直接調用DLA Serverless Spark服務。
- 實時寫入:支援 MySQL資料延期10分鐘直接寫入到OSS的,寫入後,可以支援DLA Serverless Presto與DLA Serverless Spark通路。
- 自動合并小檔案:支援小檔案的自動合并,接入層對接的是DLA Serverless Spark服務,目前也正在研發彈性的Compaction機制。
- 支援多庫多表:相對于社群支援單庫單表,我們可以一次性把RDS MySQL執行個體内所有的庫與表實時同步到OSS上,并一條鍊路支援超過5000+張表的同步;
目前Lakehouse發展比較快,核心子產品Hudi我們也在跟社群保持緊密的合作,DLA也在加緊産品化中,提供在産品界面點按鈕就可以使用的體驗,并且不斷優化資料源到鍊路到格式的性能;
四、DLA Serverless Presto
DLA Serverless Presto是基于Apache PrestoDB的研發的,主要是做聯邦互動式查詢與輕量級ETL,2020年改造後架構如下:

- 提供獨享叢集:在掃描量情況下,客戶不好評估成本,需要财務固定成本;一些如Cache、通路Hive、UDF等在掃描量無法實作;DLA推出了Presto獨享叢集版本。獨享版本的資源是獨享的,财務成本基本固定的(獨享叢集也可以按時彈性),比較适合大客戶使用。掃描量版本比較實作查詢頻率比較低的客戶使用。在獨享叢集版本中,我們核心提供了 如下能力:
-
- DataCache:與Alluxio合作共同推出了DLA Presto的DataCache,具體機制參考: https://developer.aliyun.com/article/781291 ,在IO密集類型中,查詢性能可最高提升10倍;
- 分時彈性:掃描量是按照Query計費的,在獨享叢集下,也是可以彈性的。分時彈性就是使用者可以設定時間段來付費;
- 特有的資料源:如支援Hive等資料源等、Cassandra等資料源;
- 更快的性能提升:目前也在實作如Query Result Cache、Fragment Result cache、針對性算子下沉;
- 支援更多的連接配接器:過去一年我們新增支援了Hive、HDFS、KUDU、OTS ParallelScan、Cassandra、ElasticSearch、ADB PG、Oracle、Druid等;
- 穩定性改進:接入層打通底層ACK彈性排程、DLA網絡管控、SLB管控等鍊路,實作被動當機時從之前3分鐘到3秒内快速恢複,主動業務釋出時隻中斷1次連接配接、并在1s左右迅速實作連接配接切換等能力; Multi-Master實作Coordinator和Worker的優雅關閉,關閉時會等待所有SQL執行完,同時又不接受新SQL,使得我們在更新的時候從之前的使用者SQL全挂,到現在使用者的SQL可以不被影響,做到客戶無感更新;算力租戶隔離可以實時控制每個使用者的算力,算力過度使用時會實時懲罰的機制,解決了大SQL會導緻整個叢集過載的問題;
- 易用性:SQL診斷界面,我們也在不斷改進,也是接下來的重點改進方向。
未來,我們将充分與社群結合互補,不斷提升性能,支援更多的功能,提供更加友善的診斷工具,做到雲上的第一的聯邦互動式查詢引擎;
五、DLA Serverless Spark
Spark是最流行的大資料計算引擎,DLA支援Spark主要是為在湖上做大規模的ETL,并支援流計算、機器學習;比傳統自建Spark有着300%的成本效益提升,從ECS自建Spark或者Hive批處理遷移到DLA Spark可以節約50%的成本;DLA Spark架構如下圖所示:

- 完全支援開源的Spark文法,獨享的運作環境:DLA Serverless Spark完全相容開源的Spark文法,支援Python專享的運作環境,支援開源的算法架構;
- 彈性,每Job每計費:傳統的Spark都需要使用者事先購買好叢集,DLA支援無需購買任何的計算資源即可開箱使用Spark,相容開源Spark所有的文法;
- 重寫Serverless Spark接入層,保障Job的穩定性:對比Livy接入層,Livy存在較多的穩定性問題,比如:不能互相擴充,有單點問題,無法在DLA多租戶環境應用;為此,DLA Spark組完全重寫了Spark的接入層,力求保障長job的穩定性,深度結合雲原生的環境。
- 實作多租戶的UI服務:DLA Serverless Spark運作完成後,其UI資料會存放在使用者OSS空間,DLA提供多租戶SparkUI服務,開源查詢正在運作中及運作完成的Spark資訊,此服務完全免費。
- 多資料源,針對OSS資料源優化: 目前DLA Serverless Spark支援對接Kafka、LogHub等資料源,直接對接HDFS、HBase、OTS、PolarDB、ADB等幾乎所有的資料源的分析與回寫。并針對OSS資料源支援MetaCache與Rename等優化,在小檔案較多的情況,比開源版本提升50%的性能。
目前DLA Serverless Spark一直追求更加彈性的服務,跟開源使用體驗盡量一緻,接入層的服務會更加穩定性,PS:得益于先進的雲原生架構,目前UI服務與接入層服務是免費的。使用者隻需要為實際的資源消耗付費。
六、資料平台的演進
DLA緻力于幫助客戶建構低成本、簡單易用、彈性的資料平台,比傳統Hadoop至少節約50%的成本。具體到大資料架構,業内大資料架構有Lambda、Kappa等,目前在大公司應用基本是混合體,大資料與業務是比較強相關,随着公司規模大小不一,适用的場景不近相同,且又随着業務的發展需要不同的大資料的架構,目前還不存在包打天下的銀彈(不過每個元件都想擴充場景,替換其它元件的地盤),如果規模不小的公司隻有一個肯定會有損耗或者不是最佳的方案架構。一般随着公司規模發展,有如下趨勢(此圖挑選業内比較流行的元件):

方案四,攤開細節一點如下,在結合阿裡雲OLAP團隊的元件:

上圖中分為七塊,也是目前業内主流的資料處理模式:
- 資料源:一般是資料産生的系統,比如事務性的資料會直接存入MySQL,物聯網一般直接寫入到HBase/Lindorm系統之中;
- 實時資料處理:可以直接對接資料源,如DB CDC或者Kafka,經過流ETL後,寫入到資料倉庫或者資料湖之中;
- 離線資料湖:存離線的資料,比如CSV\JSON上傳的資料,或者離線數倉的資料;
- 專題資料倉庫:針對高并發的場景加速,一般為業務團隊直接持有;
- 聯邦互動式分析:可以跨資料源查詢,包括資料倉庫、資料湖、資料庫的資料;
- 資料應用:是資料的應用,如BI、營銷系統等。
- 資料開發平台:如計算引擎的排程,資料血緣等;
特别注明的是,Lakehouse(Hudi)會把實時資料與離線資料湖結合起來,并且會融合部分資料倉庫的能力。在實際的實踐中,Lakehouse也是作為資料湖的一部分,解決資料高效入湖,且支援高效分析。
七、鳴謝與展望2021年
DLA感謝廣大客戶的信任,目前已經服務數千客戶。在2021年,DLA會聚焦在資料湖場景下,從DLA Meta、DLA Lakehouse、DLA Serverless Spark、DLA Serverless Presto方向發力,提供更加實惠,穩定性,彈性,高性能的資料湖服務。DLA Lakehouse會不斷優化支援Kafka、Loghub、DB CDC的實時入湖;DLA Presto主打通用格式的互動式查詢,會在多資料源算子下沉,Cache等方向發力;DLA Spark會完全相容開源Spark的文法與體驗,并且在彈性層面不斷突破。