統一數據管理下的敏捷分析

衡石科技

+ 關注

2022-07-29 19:46

599次閱讀

導讀

近期，衡石成功舉辦了 HENGSHI SENSE 4.1 線上分享會，分享會上衡石科技 CEO 劉誠忠，衡石科技聯合創始人&首席架構師賴林華圍繞整個數據分析市場、行業和衡石的創新為主題進行分享。上期的推文我們分享了衡石科技 CEO 劉誠忠帶來的《企服市場新物種：何為數據分析 PaaS》。

本期推文我們來看看衡石科技聯合創始人 & 首席架構師賴林華帶來的《統一數據管理下的敏捷數據分析》分享。

數據分析典型架構

眾所周知，數據分析的起點是業務系統原始數據。這其中包括 APP 數據、CRM 數據、訂單數據、倉儲數據、調查問卷等。這些數據在數據分析流中是分層存在的，如 ODS、DWD、DWM、DWS。ODS 是最原始的，業務系統里用戶的每一個點擊，每一次下單，ODS層都需要忠實地進行數據同步。

明細數據會通過不同的 ETL 任務進到數據倉庫，每一層數倉聚合粒度是不一樣的。DWD 進行數據的清洗與聚合。DWM 會按照天或者每小時進行輕度匯總。DWS則是按照業務線、產品、部門進行進一步的匯總。這些數據最終會通過 ETL 加工成不同的業務主題。這是數據分析的典型架構。

數據分析 ETL 過程

典型架構中有很多 ETL 的過程。這些過程通常需要開發工程師開發，但是需求方并不是開發工程師自己，它擁有特定的需求方。需求方本身不會寫代碼，所以大量需求溝通必不可少。溝通中的理解不到位會帶來數據處理時的數據失真，口徑不匹配，以至于最終交付結果不理想。

即使開發流程非常順利，成功交付。但一次交付的完成并不代表整件事情的結束，而是下一個“噩夢”的開始。需求是會變更的，每一次變更意味著整個流程得再次重復執行。

傳統 ETL 實現數據分析的痛點

ETL 架構下無法滿足敏捷的分析需求：

1、傳統的 ETL 數據管道每條都是定制的，計算前置、以空間換時間

敏捷性極差：新增數據源或更改數據模型邏輯時，難以及時響應、快速返回分析結果
難以復用性：提取與轉換緊耦合，每條 ETL 管道都是一個復雜的定制方案，擴展非常困難

2、業務團隊需求無法及時響應，IT 團隊疲于奔命

統一數據管理下的敏捷分析(圖3)

ETL 的趨勢

傳統的 ETL 具有歷史積累的合理性。它的 pipeline 是高度定制化的，在前端生產數據的時候能夠把數據量聚合到非常小，這樣一來便可做到展示時的快速響應。但重點是，如果滿足不了業務分析需求的話，前端展示的快與慢便失去了其意義與價值。

所以我們不能說 ETL 這個方式被完全取代了。但是可以說 ELT的趨勢是在上升的，更多的廠商、企業正在嘗試用 ELT去實現數據平臺的規劃。

ELT 趨勢上升原因：

1、企業數字化轉型：傳統數倉針對小規模數據的存儲和計算能力逐漸不能滿足企業需求

2、新業務新應用快速迭代：傳統數倉高度聚合的數據，不能滿足更多針對用戶維度行為的分析需求，針對明細數據的分析需求不斷涌現

3、Lakehouse 數據湖性能的提升：隨著分布式軟硬件的發展，針對海量數據的批量、Adhoc 的查詢技術成熟

衡石數據分析產品架構

ELT 和 ETL 架構在數據源多源異構方面差異不大。數據同步中 EL 方式下會弱化 T 的部分。

ETL 跟傳統架構不一樣的地方在于 ODS、DWD、DWS 數據不需要被分在不同的地方，比如 ODS 數據量比較大，面向的是順序讀寫存儲，所以會放在 Hive 或是 Spark 里面；DWD 放在 oracle 里面；DWS 放在 MySQL 里面。這是傳統的做法。在新的方法論下這些分層可以統一在 Lakehouse 里面進行存儲和管理。

模型指標層承載了 ELT 中 T 后置的任務。在數據源之后，我們可以直接對接模型指標層去做關鍵業務系統的模型關系構建，以及運算邏輯的確定。這些模型會形成主題數據包。數據包包含了模型和指標公式。我們最終可以基于已經構建好的數據包去支撐業務，比如基于數據包去做技術分析，做大屏或者做一些數據查詢。當然也可以把它形成 data API 或者將數據同步到各種下游。

衡石定義的是標準化的模型，這樣的模型能夠下推到底層不同的 Lakehouse 里面，能夠做到完全一致的行為和結果。技術選型時能夠比較開放的去選擇業務上面比較合適的架構進行落地，再也不需要綁定在某一種技術上面，這是未來的發展趨勢。