一、什麼是數據湖方案
數據湖當前在國內外是比較熱的方案,MarketsandMarkets市場調研顯示預計數據湖市場規模在2024年會從2019年的79億美金增長到201美金。一些企業已經構建了自己的雲原生數據湖方案,有效解決了業務痛點;還有很多企業在構建或者計劃構建自己的數據湖,Gartner 2020年發佈的報告顯示目前已經有39%的用戶在使用數據湖,34%的用戶考慮在1年內使用數據湖。在構建自己的數據湖之前還是需要充分評估什麼是數據湖、數據湖方案能夠帶來什麼價值、如何快速構建數據湖。
1.1 什麼是數據湖
Wikipedia上說數據湖是一類存儲數據自然/原始格式的系統或存儲,通常是對象塊或者文件,包括原始系統所產生的原始數據拷貝以及為了各類任務而產生的轉換數據,包括來自於關係型數據庫中的結構化數據(行和列)、半結構化數據(如CSV、日誌、XML、JSON)、非結構化數據(如email、文檔、PDF等)和二進制數據(如圖像、音頻、視頻)。
從上面可以總結出數據湖具有以下特性:
- 數據來源:原始數據、轉換數據
- 數據類型:結構化數據、半結構化數據、非結構化數據、二進制
- 數據湖存儲:可擴展的海量數據存儲服務
1.2 數據湖方案價值
數據湖的定義可以看出相比較數據庫、數據倉庫等,數據湖要處理的數據類型更加開放、更加複雜。數據庫主要是處理結構化數據的聯機事務;數據倉庫主要處理大數據量結構化數據的分析。而數據湖主要是對海量的結構化、半結構化、非結構化、二進制數據進行存儲,同時還需要對這些數據進行管理和價值挖掘。接下來可以看下雲上沉澱的典型數據湖方案:
方案一:一站式端到端數據湖存儲、管理、分析&計算方案
- 場景:企業在構建數據湖方案時,期望構建完整、通用、可擴展的解決方案,涉及到數據攝入、數據存儲、數據管理、數據價值挖掘全鏈路,同時需要有上下游工具的支持。
- 方案價值:數據攝入側支持一鍵建湖、流式入湖歸檔數據到OSS存儲;數據管理側支持對Database、文本、流式數據統一到OSS上面構建元數據管理;數據分析及計算側支持通過Serverless Spark進行ETL及複雜計算、Serverless SQL(兼容 Presto)進行交互式查詢。工具對接側支持對接DMS調度、業務APP、QuickBI來進行管理。
方案二:OSS 大規模數據(自由編程)清洗&機器學習方案
- 場景:企業對存儲在OSS上面的大規模數據需要進行多種計算負載處理,比如ETL、機器學習、圖計算等,同時利用python、java、scala、R等生態進行自由編程。
- 方案價值:DLA Serverless Spark能夠友好的支持該場景。彈性方面Serverless Spark完全彈性,1分鐘啟動300個節點進行計算;生態方面Serverless Spark的多數據源能力,提供外部數據源批量入庫、聯邦分析能力;算法及Code方面支持 Python、用戶Code、機器學習等原生KPI;離線數倉(複雜分析)方面支持複雜分析,提供天/月級別的報表等。
方案三:不同類型數據源聯邦查詢分析方案
- 場景:企業的業務系統數據一般存儲在數據庫比如MySQL、MongoDB等;日誌數據因為數據量大的特性會存儲在OSS上面。通過數據湖分析方案能夠讓這兩種數據進行聯邦查詢,釋放數據價值。
- 方案價值:DLA Serverless SQL(兼容Presto)支持15種以上的數據源,能夠滿足95%的聯邦分析數據源對接。DLA Serverless SQL支持高效的交互式查詢,在讀寫數據源端做了大量下推優化。DLA Serverless SQL通過JDBC可以對接包括DMS、QuickBI、tableau等系統滿足業務開發需求。
二、構建數據湖方案面臨的挑戰
上面的兩個數據湖方案是各大企業在阿里雲上面通過實踐沉澱下來的。還是有不少企業會問這兩個數據湖方案確實很有價值,但是在落地的過程中總是會遇到一些問題,導致方案落地緩慢,比如:
- 如何構建數據的統一管理視圖:OSS不像數據庫及數據倉庫具有元數據管理系統,導致海量數據存儲後難以管理。另外各個數據庫、數據倉庫等系統有自己的元數據,形成了數據孤島,難以進行統一管理,釋放數據聯邦分析價值;
- 如何構建多租戶的權限管理:如果全域數據都使用數據湖方案管理,企業多部門研發人員共同使用數據湖挖掘價值,但是缺少有效的數據租戶及權限隔離,產生數據風險;
- 如何自動化的構建元數據:OSS上面的文件量巨大、且這些數據是動態增長變化的;如果手動創建元數據一方面效率低,同時無法滿足動態更新的需求;
- 如何簡單的進行數據入湖:為了滿足數據寫入的實時性,比如日誌場景數據的入口是在類似Kafka、Loghub等消息系統,這些數據怎麼高效的歸檔到OSS進行後續的分析?存儲在數據庫中的數據以前為了節省成本,以及保證穩定性,通常會只保留最近一段時間的數據,在有數據湖方案後,想要把這些數據歸檔到數據湖做後續的分析,那麼如何簡單高效的歸檔到OSS數據湖呢?
結合用戶的這些挑戰和痛點,阿里雲數據湖分析服務DLA的數據湖管理功能可以有效的提高構建數據湖的效率,接下來一起把這些功能玩轉起來吧
三、DLA高效的數據湖管理功能
阿里雲數據湖分析服務DLA的數據湖管理功能定位為幫助用戶構建統一、安全、高效、開放的數據湖解決方案。從下面的數據湖方案整體架構圖可以看出:
- 存儲對接:數據湖管理向下管理好數據湖存儲的數據,包括構建OSS目錄的元數據系統以及方便的把流式數據及Database的數據歸檔到OSS管理起來;
- 分析與計算支持:數據湖管理向上為多種數據湖計算引擎提供統一的元數據系統,目前支持數據湖原生分析與計算引擎DLA Serverless SQL(兼容Presto)、DLA Serverless Spark;部分Hadoop&Spark生態,比如Apache Hudi;AnalyticDB、MaxCompute、EMR等系統也可以對接數據湖管理的元數據系統。
數據湖管理核心功能包括:元數據管理、元數據爬取、數據入湖、實時數據湖。下面一起來看下這些功能是如何高效的幫助構建數據湖的。
3.1 元數據管理
數據湖存儲的數據量更加大、數據格式更加豐富,為了對這些數據進行安全的管理和挖掘價值,需要一套同時具備基本管理能力、多租戶權限管理能力、擴展能力、開放能力的統一元數據系統。阿里雲數據湖分析服務DLA的元數據系統具備這些能力。
3.1.1 DLA元數據管理介紹
下面是數據湖分析服務DLA的元數據管理系統的架構圖:
- 存儲層:DLA元數據管理系統是一套多租戶的服務,管理所有用戶元數據,目前是每個regoin部署一套。智能數據路由層,用來做租戶元數據的存儲管理,能夠根據用戶元數據量級動態擴展調整;
- 核心服務層:元數據管理系統提供database、table、partition的服務進行庫、表、分區、列的管理能力,同時支持使用租戶服務、權限服務、生命週期管理,權限粒度可以支持到庫、表、列;
- 接入層:統一元數據管理服務為了支持更多計算引擎對接,同時支持通過JDBC、阿里雲OpenAPI來使用元數據服務;目前以JDBC為主,阿里雲OpenAPI對接進行中。身份認證支持對接阿里雲RAM賬號體系,以及DLA賬號體系。同時會有元數據相關的請求QPS監控。
- 生態層:目前這套元數據管理支持對接雲原生的數據湖分析引擎DLA Serverless SQL&Spark;開源Hadoop&Spark,其中Apache 頂級項目Hudi已經原生支持了阿里雲數據湖分析元數據HUDI-841;阿里雲數據庫備份DMS也使用這套元數據作為其備份數據湖分析的元數據系統;AnalyticDB、EMR、MaxCompute等也可以進行對接。
3.1.2 DLA元數據管理上手
- 可視化全局管理視圖
如下圖可以在阿里雲數據湖分析DLA的控制檯“元數據管理”進行元數據的操作,比如“創建Schema”、查看庫表信息、查詢數據等。
-
創建元數據
- 自動化元數據創建:可以參考3.2元數據爬取、3.3數據入湖的詳細介紹
- SQL手動創建:支持HIVE風格的DDL語法;
- SQL自動創建:支持create table like mapping語法自動識別數據源文件的列,減少手寫很多列及類型的麻煩;支持MSCK REPAIR DATABASE語法自動把Database下面的表創建好;支持MSCK REPAIR TABLE自動把table下面的分區和數據目錄創建映射好。
-
權限管理:目前支持通過JDBC進行權限的GRANT和REVOKE,通過阿里雲OpenAPI也在研發中
3.2 元數據爬取
用戶基於OSS進行數據湖存儲時,數據具有規模大、格式豐富、動態變化、非結構化字段多的特點,這種情況下手動創建的可行性及成本會比較高。
3.2.1 DLA元數據爬取介紹
元數據爬取功能可以自動為OSS上面的數據文件創建及更新數據湖元數據,方便分析和計算。具有自動探索文件數據字段及類型、自動映射目錄和分區、自動感知新增列及分區、自動對文件進行分組建表的能力。目前主要支持了自動爬取OSS上面的元數據,Database的自動元數據構建在開發中。核心功能包括:
- 自動探索格式:企業存儲在OSS上面的數據格式多種多樣,比如常見的有json、csv、parquet、orc等,同時不同文件裡面的字段數目及類型也是多種多樣的。DLA元數據爬取功能具備自動探索這些schema的能力。
- 增量發現:存儲在OSS上面的數據是動態變化的,比如用戶會向同一個目錄下面持續的上傳文件,且文件的字段數也會增加、Loghub投遞到OSS上面的文件會增量的通過日期目錄來寫入等。元數據爬取功能能夠覆蓋這些場景;
- 規模擴展:隨著要爬取的OSS上面文件規模的增大,元數據爬取任務可以自動彈性伸縮資源來保證元數據爬取任務端到端的延遲。
3.2.2 DLA元數據爬取10分鐘上手
使用DLA的元數據爬取可以通過DLA的控制檯,同時元數據爬取開放阿里雲OpenAPI也在研發中,同時也會被集成到其他雲產品中。下面一起玩轉一下元數據爬取功能:
- 創建任務:左側選擇要爬取的具體OSS路徑,右側配置爬取的元數據要存儲到DLA元數據系統的Schema名稱即可,其他高級選項根據實際需求調整。
- 任務管理:爬取任務會自動週期運行,可以通過這個界面管理任務的運行情況。支持查看任務的運行狀態、配置的修改、跳轉到DLA的SQL窗口進行快速的數據查詢。
3.3 數據入湖
企業並不是所有業務數據直接存儲在數據湖OSS中,其他的業務數據存儲主要有兩類包括消息中間件、Database,而這些數據都有歸檔存儲到數據湖OSS中進行統一計算分析的需求。因此簡單易用的數據入湖功能成為普遍的需求。
3.3.1 DLA數據入湖介紹
阿里雲數據湖分析DLA的數據入湖支持Database的全量&增量&多庫合併建入湖、支持消息中間件數據的實時入湖等能力。
-
Database一鍵建湖:主要支持全量、增量、多庫合併三種模式,其中增量模式正在開發中;核心價值如下:
- 豐富的數據源:包含OLTP的MySQL、SQLServer、POLARDB等,同時支持NoSQL的mongoDB等;
- 自動感知源庫結構變化:能夠自動識別源庫的增表、增加字段等同步更新到OSS數據湖;
- 整庫多表建湖:一鍵建湖能夠自動同步數據庫的整個Database下面所有表,而不需要每張表都去單獨配置;
- 分表&分庫合併建湖:有些業務場景為了提高OLTP的查詢性能及數據隔離性,經常會進行分庫及分表。目前某用戶使用該功能支持了8200+ SqlServer庫合併到一個DLA的庫裡面,這樣可以對分庫的數據進行中心化統一分析。
- 源庫影響最小化:數據入湖通過動態調整源庫連接數的方式、以及選擇業務低峰期歸檔,最小化對源庫的影響。
- 實時數據入湖:對於雲kafka、Loghub等消息中間、數據庫的CDC數據可以通過“實時數據入湖”方案構建數據湖。
該方案基於DLA Serverless的Spark Streaming以及數據湖增量存儲格式Apache HUDI來構建,通過HUDI增量寫入OSS的數據,同時自動在DLA的元數據系統構建元數據。詳細介紹可以參考文章,核心優勢如下:
- 全鏈路數據延遲可達分鐘級別,打造T + 0 數據湖;
- 支持數據增量存儲在OSS,支持Upsert/Delete,同時自動構建元數據管理;
- 豐富的數據源,支持阿里雲上超過95%數據源;
- 一份數據存儲在OSS,通過DLA Meta增量管理,降低存儲成本低;
3.3.2 Database一鍵建湖
使用一鍵建湖可以通過DLA的控制檯,同時可以通過數據管理DMS進行。下面主要介紹DLA控制檯的使用,關於DMS使用一鍵建湖可以參考視頻。
- 創建一鍵建湖:左側選擇數據源,可以包括RDS、PolarDB、MongoDB、ECS自建數據庫;右側配置源庫的驗證信息,以及在DLA生成的元數據名稱即可。
- 任務管理:對於週期運行的建湖任務可以進行全局的管理,以及對建好的湖進行分析。
四、展望與總結
數據湖分析DLA 是 Serverless的架構,支持 【按需與保留】 資源使用,打造最具性價比的數據湖分析平臺;
提供一站式的數據湖分析與計算服務,支持 ETL、機器學習、流、交互式分析,可以與OSS、數據庫等多種數據源搭配使用;功能包括:數據入湖,元數據管理與自動發現,支持雙引擎:【SQL(兼容Presto)分析、Spark計算服務】。其中數據湖管理這塊會朝著更易用、更開放、更可靠方向迭代。
注:數據湖管理控制檯使用鏈接,數據湖管理及DLA的幫助文檔。