統(tǒng)一數(shù)據(jù)管理下的敏捷分析

衡石科技

+ 關(guān)注

2022-07-29 19:46

603次閱讀

導(dǎo)讀

近期，衡石成功舉辦了 HENGSHI SENSE 4.1 線上分享會(huì)，分享會(huì)上衡石科技 CEO 劉誠忠，衡石科技聯(lián)合創(chuàng)始人&首席架構(gòu)師賴林華圍繞整個(gè)數(shù)據(jù)分析市場、行業(yè)和衡石的創(chuàng)新為主題進(jìn)行分享。上期的推文我們分享了衡石科技 CEO 劉誠忠?guī)淼摹镀蠓袌鲂挛锓N：何為數(shù)據(jù)分析 PaaS》。

本期推文我們來看看衡石科技聯(lián)合創(chuàng)始人 & 首席架構(gòu)師賴林華帶來的《統(tǒng)一數(shù)據(jù)管理下的敏捷數(shù)據(jù)分析》分享。

數(shù)據(jù)分析典型架構(gòu)

眾所周知，數(shù)據(jù)分析的起點(diǎn)是業(yè)務(wù)系統(tǒng)原始數(shù)據(jù)。這其中包括 APP 數(shù)據(jù)、CRM 數(shù)據(jù)、訂單數(shù)據(jù)、倉儲(chǔ)數(shù)據(jù)、調(diào)查問卷等。這些數(shù)據(jù)在數(shù)據(jù)分析流中是分層存在的，如 ODS、DWD、DWM、DWS。ODS 是最原始的，業(yè)務(wù)系統(tǒng)里用戶的每一個(gè)點(diǎn)擊，每一次下單，ODS層都需要忠實(shí)地進(jìn)行數(shù)據(jù)同步。

明細(xì)數(shù)據(jù)會(huì)通過不同的 ETL 任務(wù)進(jìn)到數(shù)據(jù)倉庫，每一層數(shù)倉聚合粒度是不一樣的。DWD 進(jìn)行數(shù)據(jù)的清洗與聚合。DWM 會(huì)按照天或者每小時(shí)進(jìn)行輕度匯總。DWS則是按照業(yè)務(wù)線、產(chǎn)品、部門進(jìn)行進(jìn)一步的匯總。這些數(shù)據(jù)最終會(huì)通過 ETL 加工成不同的業(yè)務(wù)主題。這是數(shù)據(jù)分析的典型架構(gòu)。

數(shù)據(jù)分析 ETL 過程

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

即使開發(fā)流程非常順利，成功交付。但一次交付的完成并不代表整件事情的結(jié)束，而是下一個(gè)“噩夢(mèng)”的開始。需求是會(huì)變更的，每一次變更意味著整個(gè)流程得再次重復(fù)執(zhí)行。

傳統(tǒng) ETL 實(shí)現(xiàn)數(shù)據(jù)分析的痛點(diǎn)

ETL 架構(gòu)下無法滿足敏捷的分析需求：

1、傳統(tǒng)的 ETL 數(shù)據(jù)管道每條都是定制的，計(jì)算前置、以空間換時(shí)間

敏捷性極差：新增數(shù)據(jù)源或更改數(shù)據(jù)模型邏輯時(shí)，難以及時(shí)響應(yīng)、快速返回分析結(jié)果
難以復(fù)用性：提取與轉(zhuǎn)換緊耦合，每條 ETL 管道都是一個(gè)復(fù)雜的定制方案，擴(kuò)展非常困難

2、業(yè)務(wù)團(tuán)隊(duì)需求無法及時(shí)響應(yīng)，IT 團(tuán)隊(duì)疲于奔命

統(tǒng)一數(shù)據(jù)管理下的敏捷分析(圖3)

ETL 的趨勢(shì)

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

所以我們不能說 ETL 這個(gè)方式被完全取代了。但是可以說 ELT的趨勢(shì)是在上升的，更多的廠商、企業(yè)正在嘗試用 ELT去實(shí)現(xiàn)數(shù)據(jù)平臺(tái)的規(guī)劃。

ELT 趨勢(shì)上升原因：

1、企業(yè)數(shù)字化轉(zhuǎn)型：傳統(tǒng)數(shù)倉針對(duì)小規(guī)模數(shù)據(jù)的存儲(chǔ)和計(jì)算能力逐漸不能滿足企業(yè)需求

2、新業(yè)務(wù)新應(yīng)用快速迭代：傳統(tǒng)數(shù)倉高度聚合的數(shù)據(jù)，不能滿足更多針對(duì)用戶維度行為的分析需求，針對(duì)明細(xì)數(shù)據(jù)的分析需求不斷涌現(xiàn)

3、Lakehouse 數(shù)據(jù)湖性能的提升：隨著分布式軟硬件的發(fā)展，針對(duì)海量數(shù)據(jù)的批量、Adhoc 的查詢技術(shù)成熟

衡石數(shù)據(jù)分析產(chǎn)品架構(gòu)

ELT 和 ETL 架構(gòu)在數(shù)據(jù)源多源異構(gòu)方面差異不大。數(shù)據(jù)同步中 EL 方式下會(huì)弱化 T 的部分。

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

模型指標(biāo)層承載了 ELT 中 T 后置的任務(wù)。在數(shù)據(jù)源之后，我們可以直接對(duì)接模型指標(biāo)層去做關(guān)鍵業(yè)務(wù)系統(tǒng)的模型關(guān)系構(gòu)建，以及運(yùn)算邏輯的確定。這些模型會(huì)形成主題數(shù)據(jù)包。數(shù)據(jù)包包含了模型和指標(biāo)公式。我們最終可以基于已經(jīng)構(gòu)建好的數(shù)據(jù)包去支撐業(yè)務(wù)，比如基于數(shù)據(jù)包去做技術(shù)分析，做大屏或者做一些數(shù)據(jù)查詢。當(dāng)然也可以把它形成 data API 或者將數(shù)據(jù)同步到各種下游。

衡石定義的是標(biāo)準(zhǔn)化的模型，這樣的模型能夠下推到底層不同的 Lakehouse 里面，能夠做到完全一致的行為和結(jié)果。技術(shù)選型時(shí)能夠比較開放的去選擇業(yè)務(wù)上面比較合適的架構(gòu)進(jìn)行落地，再也不需要綁定在某一種技術(shù)上面，這是未來的發(fā)展趨勢(shì)。