數(shù)據(jù)分析平民化的挑戰(zhàn)與應(yīng)對(duì)

導(dǎo)讀

近期，衡石成功舉辦了 HENGSHI SENSE 4.2 線上分享會(huì)，分享會(huì)上衡石 CEO 劉誠(chéng)忠及衡石首席數(shù)據(jù)科學(xué)家陳家耀圍繞整個(gè)數(shù)據(jù)分析產(chǎn)業(yè)的發(fā)展、行業(yè)趨勢(shì)和衡石的創(chuàng)新進(jìn)行深度探討和分享。上期推文我們分享了衡石 CEO 劉誠(chéng)忠?guī)?lái)的《Powered by BI PaaS - 讓商業(yè)分析即刻上線》。

本期推文一起來(lái)看看衡石首席數(shù)據(jù)科學(xué)家陳家耀帶來(lái)的《數(shù)據(jù)分析平民化的挑戰(zhàn)與應(yīng)對(duì)》分享。

傳統(tǒng)數(shù)據(jù)分析流程

“數(shù)據(jù)分析平民化”一直是數(shù)據(jù)分析行業(yè)的共同愿景，可以說(shuō)最近10年 BI 行業(yè)的小伙伴們都在為這個(gè)愿景努力，現(xiàn)在還在推進(jìn)的過(guò)程中。為什么這件事情這么難，我們先看看傳統(tǒng)的分析流程是怎么樣的。

一次完整的數(shù)據(jù)分析，大體上依次經(jīng)過(guò)數(shù)據(jù)接入、數(shù)據(jù)準(zhǔn)備、數(shù)據(jù)展示三個(gè)環(huán)節(jié)，這三個(gè)環(huán)節(jié)在傳統(tǒng)的流程里分別由開(kāi)發(fā)工程師、分析師和業(yè)務(wù)人員三類角色承擔(dān)。當(dāng)新的數(shù)據(jù)分析需求產(chǎn)生時(shí)，幾乎都是從最前端的業(yè)務(wù)側(cè)發(fā)起，給到數(shù)據(jù)開(kāi)發(fā)工程師，經(jīng)過(guò)層層的需求溝通，最終進(jìn)入開(kāi)發(fā)、測(cè)試、上線環(huán)節(jié)。這個(gè)流程下來(lái)，平均一個(gè)數(shù)據(jù)報(bào)表的開(kāi)發(fā)周期至少需要一周到三個(gè)月的時(shí)間。

可以看出，這是一套標(biāo)準(zhǔn)的軟件開(kāi)發(fā)流程，即使報(bào)表開(kāi)發(fā)的周期相對(duì)較短，也是以周為單位的。但分析的本質(zhì)是一種業(yè)務(wù)運(yùn)營(yíng)需求，每天都可能有新的業(yè)務(wù)問(wèn)題需要分析，它的變化頻率是以天為單位的。這就產(chǎn)生了流程中最大的矛盾點(diǎn)，業(yè)務(wù)側(cè)一直在等數(shù)據(jù)，開(kāi)發(fā)工程師疲于應(yīng)付各種報(bào)表需求。但更讓工程師痛苦的是，他們花兩周、一個(gè)月時(shí)間做出來(lái)的報(bào)表，可能實(shí)際使用兩個(gè)月不到的時(shí)間就有下線了，因?yàn)闃I(yè)務(wù)變化實(shí)在太快。

數(shù)據(jù)分析平民化趨勢(shì)：從 ETL 到 ELT

傳統(tǒng)分析流程的瓶頸，在于我們的數(shù)據(jù)準(zhǔn)備環(huán)節(jié)太重，無(wú)法應(yīng)對(duì)前端頻繁變化的分析需求。所以大家開(kāi)始思考，是否有更敏捷的方式來(lái)完成數(shù)據(jù)準(zhǔn)備呢？這就是近年來(lái)流行的ELT模式。

從上圖中可以對(duì)比看到傳統(tǒng) ETL 流程和現(xiàn)代 ELT 流程的主要差別。

在傳統(tǒng)的流程中， IT 人員負(fù)責(zé)的 scope 非常廣，包括數(shù)據(jù)接入、數(shù)倉(cāng)建模、開(kāi)發(fā)報(bào)表，業(yè)務(wù)人員只是在高度凝練之后的報(bào)表層進(jìn)行分析。而在現(xiàn)代流程中，工程師則只需負(fù)責(zé)數(shù)據(jù)接入，以及在數(shù)據(jù)湖或數(shù)倉(cāng)中簡(jiǎn)單的清理和整合工作，之后的數(shù)據(jù)建模、數(shù)據(jù)準(zhǔn)備等工作由業(yè)務(wù)人員自助完成。這樣在整個(gè)分析流程里面，很多環(huán)節(jié)不再是一個(gè)需求方與開(kāi)發(fā)方分離，需要牽扯大量跨部門溝通協(xié)作成本的過(guò)程。從而大大提升了分析的敏捷性和效率，某種程度上實(shí)現(xiàn)了分析的平民化。

既然 ELT 模式那么香，為什么在20年前大家普遍使用的是 ETL 模式呢？主要有兩大限制。

首當(dāng)其沖的是算力。在 ELT 模式中，大量計(jì)算是實(shí)時(shí)產(chǎn)生的，對(duì)計(jì)算的性能的要求很高。20年前的軟硬件環(huán)境，大部分?jǐn)?shù)據(jù)分析使用的還是面向業(yè)務(wù)處理的單機(jī)版 OLTP 數(shù)據(jù)庫(kù)，查詢1G的數(shù)據(jù)就可能需要1min 的時(shí)間；2010年之后，以 Hadoop 為代表的大數(shù)據(jù)發(fā)展，讓我們有能力處理TB甚至PB級(jí)別的數(shù)據(jù)；近年來(lái)以 Clickhouse、Doris 為代表的高性能分析型數(shù)據(jù)庫(kù)技術(shù)出現(xiàn)，以及如 SSD 硬盤等硬件升級(jí)，使得在億級(jí)數(shù)據(jù)上的秒級(jí)查詢變成可能。正是這些底層算力的提升，為從 ETL 向 ELT 的模式轉(zhuǎn)變提供了基礎(chǔ)。

第二個(gè)限制是專業(yè)門檻。數(shù)倉(cāng)建模一直都是專業(yè)性很強(qiáng)的工作。在傳統(tǒng)流程中，數(shù)據(jù)準(zhǔn)備都是開(kāi)發(fā)工程師用 SQL 建模的方式完成，這也導(dǎo)致絕大部分業(yè)務(wù)運(yùn)營(yíng)人員無(wú)法涉足這一環(huán)節(jié)。隨著各個(gè) BI 工具廠商紛紛推出了可視化拖拽的建模工具，大大降低了數(shù)據(jù)準(zhǔn)備的門檻，也讓業(yè)務(wù)人員能像傳統(tǒng)開(kāi)發(fā)工程師一樣進(jìn)行完成數(shù)據(jù)準(zhǔn)備。

分析平民化遭遇的新挑戰(zhàn)及應(yīng)對(duì)策略

雖然我們通過(guò)分析范式從 ETL 向 ELT 的轉(zhuǎn)變，逐步實(shí)現(xiàn)了分析平民化。但同時(shí)也帶來(lái)了新的挑戰(zhàn)和問(wèn)題。

挑戰(zhàn)一：性能挑戰(zhàn)

性能問(wèn)題是當(dāng)前分析范式轉(zhuǎn)變之后的最大挑戰(zhàn)。

首先，硬件算力的發(fā)展永遠(yuǎn)跟不上軟件對(duì)性能的需求。更多的復(fù)雜計(jì)算邏輯和高級(jí)分析功能被應(yīng)用，如診斷分析、預(yù)測(cè)性分析等，同時(shí)人們永遠(yuǎn)希望用最省的資源提供足夠的分析能力。

其次，在新的模式下，為了滿足分析的靈活性，人們進(jìn)行更多的實(shí)時(shí)建模，更多的底層數(shù)據(jù)被直接查詢。在 ETL 時(shí)代底層的明細(xì)數(shù)據(jù)被逐層聚合構(gòu)建聚合表，大量計(jì)算在分析前被提前完成。而在 ELT 模式下，即使有可用的聚合表，業(yè)務(wù)人員也會(huì)傾向于直接使用 DWD 層明細(xì)表，因?yàn)檫@樣他們能觸達(dá)更多的分析維度，進(jìn)行更靈活的數(shù)據(jù)探索。

最后是建模專業(yè)性上的差異。之前我們有一個(gè)專業(yè)的數(shù)倉(cāng)團(tuán)隊(duì)幫大家背負(fù)各種性能問(wèn)題，他們知道何時(shí)做索引、分區(qū)，何時(shí)該落地預(yù)計(jì)算。而現(xiàn)在，雖然可視化工具讓業(yè)務(wù)人員能自由建模，但在模型優(yōu)化和性能瓶頸等方面，他們常常無(wú)力又無(wú)心（性能優(yōu)化上的很多必要措施往往是業(yè)務(wù)邏輯上的冗余步驟，業(yè)務(wù)人員缺少相關(guān)優(yōu)化意識(shí)）

應(yīng)對(duì)一：升級(jí)基礎(chǔ)硬件和算力、借助智能數(shù)據(jù)準(zhǔn)備與建模

性能問(wèn)題如何解決呢？一般兩條出路。一條路是提升基礎(chǔ)算力或加資源，這是最樸素而有效的解決方法。關(guān)鍵點(diǎn)是怎樣高效地加資源。使用云數(shù)倉(cāng)其中一個(gè)提效路徑，基于云數(shù)倉(cāng)的彈性伸縮能力，根據(jù)實(shí)際計(jì)算需求變化，波峰時(shí)快速擴(kuò)容提升性能，波谷時(shí)方便地釋放資源節(jié)約成本。另一條路是智能數(shù)據(jù)建模，通過(guò)智能化的建模工具，彌補(bǔ)業(yè)務(wù)人員和工程師之間的專業(yè)差距。

上圖是我們總結(jié)的數(shù)據(jù)準(zhǔn)備與建模方式的發(fā)展階段。第一階段主要是由數(shù)據(jù)開(kāi)發(fā)工程師通過(guò)手寫(xiě) SQL 的方式構(gòu)建數(shù)倉(cāng)，性能好，但靈活性差。第二個(gè)階段是可視化建模，主要使用者是業(yè)務(wù)分析師，門檻更低，但模型專業(yè)性不如之前。第三階段是增強(qiáng)數(shù)據(jù)建模，業(yè)務(wù)分析師借助 BI 平臺(tái)提供的智能輔助工具，慢慢能夠像專業(yè)IT一樣構(gòu)建出優(yōu)良的數(shù)據(jù)模型和數(shù)據(jù)倉(cāng)庫(kù)。第四階段是AI 智能建模，我們憧憬在未來(lái)業(yè)務(wù)人員只需要表達(dá)業(yè)務(wù)邏輯和需求，平臺(tái)會(huì)自動(dòng)完成背后的各種數(shù)據(jù)準(zhǔn)備和查詢優(yōu)化。

這四個(gè)階段其實(shí)是數(shù)據(jù)準(zhǔn)備平民化的歷程，跟自動(dòng)駕駛領(lǐng)域的駕駛平民化發(fā)展歷程非常相似。第一階段和第二階段對(duì)應(yīng)汽車的手動(dòng)檔和自動(dòng)檔階段；第三階段更多的人工智能元素開(kāi)始加入，類似于 L2 級(jí)別的輔助自動(dòng)駕駛；第四階段則相當(dāng)于未來(lái)需要實(shí)現(xiàn)的 L4 級(jí)別的完全自動(dòng)駕駛。通過(guò)智能化，消除專業(yè)門檻，釋放人力。

第四階段是我們美好的期望，但目前看距離落地實(shí)現(xiàn)還需要較長(zhǎng)的時(shí)間，一方面分析自動(dòng)化的復(fù)雜度完全不亞于自動(dòng)駕駛，另一方面分析場(chǎng)景和分析數(shù)據(jù)的私密性，將導(dǎo)致訓(xùn)練數(shù)據(jù)的獲取難度比自動(dòng)駕駛要高很多。因此，預(yù)計(jì)在很長(zhǎng)一段時(shí)間內(nèi)，我們都將一直處于第三階段，在這個(gè)階段由分析人員和 BI 平臺(tái)共同配合來(lái)完成對(duì)開(kāi)發(fā)工程師的補(bǔ)位，這就要求一方面BI平臺(tái)不斷提供更友好的智能輔助建模工具，另一方面分析師需要提升優(yōu)化意識(shí)，掌握這些智能工具的使用。

挑戰(zhàn)二：管理挑戰(zhàn)

除了性能問(wèn)題，分析平民化的另一大挑戰(zhàn)是管理上的挑戰(zhàn)。ELT 模式賦予了分析師更多的自由和靈活度，但自由和規(guī)范性一直是一對(duì)矛盾體，所以分析師擁有更多自由的同時(shí)無(wú)可避免的也會(huì)引入一些混亂。

上圖是一個(gè)分析普及后數(shù)據(jù)誤用的真實(shí)案例：某公司產(chǎn)品團(tuán)隊(duì)上線了一個(gè)新產(chǎn)品，在 AB 測(cè)試期間發(fā)現(xiàn)該產(chǎn)品對(duì)收入的貢獻(xiàn)非常好，向老板建議盡快發(fā)布，但是運(yùn)營(yíng)團(tuán)隊(duì)周報(bào)卻提到最近兩周運(yùn)營(yíng)數(shù)據(jù)下降劇烈，老板無(wú)法決策，只好讓分析師花了兩周的時(shí)間排查原因，發(fā)現(xiàn)運(yùn)營(yíng)團(tuán)隊(duì)分析時(shí)一個(gè)收入指標(biāo)口徑有問(wèn)題。此時(shí)已經(jīng)了導(dǎo)致該產(chǎn)品的發(fā)布延期。

在傳統(tǒng) ETL 模式下，口徑的統(tǒng)一是在數(shù)倉(cāng)團(tuán)隊(duì)內(nèi)部完成，在放開(kāi)底層數(shù)據(jù)后，口徑的統(tǒng)一就變成了一個(gè)跨部門，甚至跨公司的事情，為數(shù)據(jù)管理帶來(lái)了巨大的挑戰(zhàn)。

從近幾年數(shù)據(jù)治理概念的興起也能發(fā)現(xiàn)，近年提數(shù)據(jù)治理的，很多都是從互聯(lián)網(wǎng)公司開(kāi)始。其中一個(gè)很重要的原因，他們大部分在內(nèi)部落實(shí)了 ELT 模式，某種程度上實(shí)現(xiàn)了分析自由，所以也逐漸暴露了由此導(dǎo)致的口徑混亂、數(shù)據(jù)打架等問(wèn)題。

應(yīng)對(duì)二：統(tǒng)一指標(biāo)管理

對(duì)于數(shù)據(jù)口徑混亂的問(wèn)題如何解決？還是需要有一個(gè)地方對(duì)指標(biāo)和口徑進(jìn)行統(tǒng)一管理，所有重要的指標(biāo)，都要經(jīng)過(guò)計(jì)算邏輯的統(tǒng)一定義和發(fā)布，才能被用于分析和匯報(bào)。這其實(shí)也是很多指標(biāo)中臺(tái)伙伴的產(chǎn)品思路。

由于統(tǒng)一管理指標(biāo)后，指標(biāo)庫(kù)成為了絕大部分分析的基礎(chǔ)和前提，為了避免回退到類似ETL模式的分析困境，指標(biāo)庫(kù)的管理、運(yùn)維工作應(yīng)該足夠輕量。只有足夠輕量，這個(gè)環(huán)節(jié)才能足夠敏捷，不會(huì)成為分析流程中的新瓶頸點(diǎn)。而實(shí)現(xiàn)指標(biāo)庫(kù)輕量性的一個(gè)關(guān)鍵的點(diǎn)，在于業(yè)務(wù)與數(shù)據(jù)的分離。通過(guò)業(yè)務(wù)與數(shù)據(jù)的分離，定義業(yè)務(wù)指標(biāo)時(shí)只需處理業(yè)務(wù)的邏輯概念即可，無(wú)需關(guān)心這些概念與底層數(shù)據(jù)表里具體計(jì)算代碼的映射和轉(zhuǎn)換。

HENGSHI SENSE 4.2新特性

衡石作為一家專注于賦能全行業(yè)的 SaaS / ISV 敏捷構(gòu)建數(shù)據(jù)分析和 BI 能力的標(biāo)準(zhǔn)化軟件產(chǎn)品廠商，在近期發(fā)布的 HENGSHI SENSE 4.2新版本中，針對(duì)于前面探討的問(wèn)題也做出了更多的優(yōu)化和提升：

賦能數(shù)據(jù)科學(xué)家：HENGSHI SENSE 數(shù)據(jù)科學(xué)模塊支持 Python,為數(shù)據(jù)科學(xué)家提供更好的語(yǔ)言來(lái)應(yīng)對(duì)復(fù)雜的機(jī)器學(xué)習(xí)和高級(jí)分析需求。

更強(qiáng)大的數(shù)據(jù)源適配能力：HENGSHI SENSE 提供更強(qiáng)大的數(shù)據(jù)源適配能力幫助客戶接入更多的數(shù)據(jù)。如支持原生 MangoDB，避免用戶再?gòu)?MangoDB 往傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)搬運(yùn)數(shù)據(jù)，提升接入數(shù)據(jù)的效率；在 API 上對(duì)接了旺店通、石墨文檔和企業(yè)微信，后續(xù)這些接口來(lái)源的數(shù)據(jù)可以便捷地接入 HENGSHI SENSE 與其他數(shù)據(jù)做關(guān)聯(lián)分析。

HQL 升級(jí)：HENGSHI SENSE 很早就通過(guò)自定義的 HQL 語(yǔ)言實(shí)現(xiàn)了業(yè)務(wù)和數(shù)據(jù)分離，在4.2新版本中又對(duì) HQL 進(jìn)行了升級(jí)，支持用戶自定義 UDF 并擴(kuò)展了 HQL 的函數(shù)體系。

可視化增強(qiáng)：HENGSHI SENSE 通過(guò)在布局中提供重力模式，在容器的編輯的時(shí)候，提供了編輯和分屏展示的模式，幫助分析師更加高效地去制作和編輯儀表盤。

管理與協(xié)作：分析是一個(gè)非常重管理和協(xié)作的工作，4.2新版本中新增了數(shù)據(jù)權(quán)限模式適配、跨應(yīng)用復(fù)制數(shù)據(jù)集等功能，優(yōu)化大規(guī)模的團(tuán)隊(duì)協(xié)作。