數據分析平民化的挑戰(zhàn)與應對

導讀
近期,衡石成功舉辦了 HENGSHI SENSE 4.2 線上分享會,分享會上衡石 CEO 劉誠忠及衡石首席數據科學家陳家耀圍繞整個數據分析產業(yè)的發(fā)展、行業(yè)趨勢和衡石的創(chuàng)新進行深度探討和分享。上期推文我們分享了衡石 CEO 劉誠忠?guī)淼摹禤owered by BI PaaS - 讓商業(yè)分析即刻上線》。
本期推文一起來看看衡石首席數據科學家陳家耀帶來的《數據分析平民化的挑戰(zhàn)與應對》分享。
傳統(tǒng)數據分析流程
“數據分析平民化”一直是數據分析行業(yè)的共同愿景,可以說最近10年 BI 行業(yè)的小伙伴們都在為這個愿景努力,現在還在推進的過程中。為什么這件事情這么難,我們先看看傳統(tǒng)的分析流程是怎么樣的。
一次完整的數據分析,大體上依次經過數據接入、數據準備、數據展示三個環(huán)節(jié),這三個環(huán)節(jié)在傳統(tǒng)的流程里分別由開發(fā)工程師、分析師和業(yè)務人員三類角色承擔。當新的數據分析需求產生時,幾乎都是從最前端的業(yè)務側發(fā)起,給到數據開發(fā)工程師,經過層層的需求溝通,最終進入開發(fā)、測試、上線環(huán)節(jié)。這個流程下來,平均一個數據報表的開發(fā)周期至少需要一周到三個月的時間。
可以看出,這是一套標準的軟件開發(fā)流程,即使報表開發(fā)的周期相對較短,也是以周為單位的。但分析的本質是一種業(yè)務運營需求,每天都可能有新的業(yè)務問題需要分析,它的變化頻率是以天為單位的。這就產生了流程中最大的矛盾點,業(yè)務側一直在等數據,開發(fā)工程師疲于應付各種報表需求。但更讓工程師痛苦的是,他們花兩周、一個月時間做出來的報表,可能實際使用兩個月不到的時間就有下線了,因為業(yè)務變化實在太快。
數據分析平民化趨勢:從 ETL 到 ELT
傳統(tǒng)分析流程的瓶頸,在于我們的數據準備環(huán)節(jié)太重,無法應對前端頻繁變化的分析需求。所以大家開始思考,是否有更敏捷的方式來完成數據準備呢?這就是近年來流行的ELT模式。
從上圖中可以對比看到傳統(tǒng) ETL 流程和現代 ELT 流程的主要差別。
在傳統(tǒng)的流程中, IT 人員負責的 scope 非常廣,包括數據接入、數倉建模、開發(fā)報表,業(yè)務人員只是在高度凝練之后的報表層進行分析。而在現代流程中,工程師則只需負責數據接入,以及在數據湖或數倉中簡單的清理和整合工作,之后的數據建模、數據準備等工作由業(yè)務人員自助完成。這樣在整個分析流程里面,很多環(huán)節(jié)不再是一個需求方與開發(fā)方分離,需要牽扯大量跨部門溝通協作成本的過程。從而大大提升了分析的敏捷性和效率,某種程度上實現了分析的平民化。
既然 ELT 模式那么香,為什么在20年前大家普遍使用的是 ETL 模式呢?主要有兩大限制。
首當其沖的是算力。在 ELT 模式中,大量計算是實時產生的,對計算的性能的要求很高。20年前的軟硬件環(huán)境,大部分數據分析使用的還是面向業(yè)務處理的單機版 OLTP 數據庫,查詢1G的數據就可能需要1min 的時間;2010年之后,以 Hadoop 為代表的大數據發(fā)展,讓我們有能力處理TB甚至PB級別的數據;近年來以 Clickhouse、Doris 為代表的高性能分析型數據庫技術出現,以及如 SSD 硬盤等硬件升級,使得在億級數據上的秒級查詢變成可能。正是這些底層算力的提升,為從 ETL 向 ELT 的模式轉變提供了基礎。
第二個限制是專業(yè)門檻。數倉建模一直都是專業(yè)性很強的工作。在傳統(tǒng)流程中,數據準備都是開發(fā)工程師用 SQL 建模的方式完成,這也導致絕大部分業(yè)務運營人員無法涉足這一環(huán)節(jié)。隨著各個 BI 工具廠商紛紛推出了可視化拖拽的建模工具,大大降低了數據準備的門檻,也讓業(yè)務人員能像傳統(tǒng)開發(fā)工程師一樣進行完成數據準備。
分析平民化遭遇的新挑戰(zhàn)及應對策略
雖然我們通過分析范式從 ETL 向 ELT 的轉變,逐步實現了分析平民化。但同時也帶來了新的挑戰(zhàn)和問題。
挑戰(zhàn)一:性能挑戰(zhàn)
性能問題是當前分析范式轉變之后的最大挑戰(zhàn)。
首先,硬件算力的發(fā)展永遠跟不上軟件對性能的需求。更多的復雜計算邏輯和高級分析功能被應用,如診斷分析、預測性分析等,同時人們永遠希望用最省的資源提供足夠的分析能力。
其次,在新的模式下,為了滿足分析的靈活性,人們進行更多的實時建模,更多的底層數據被直接查詢。在 ETL 時代底層的明細數據被逐層聚合構建聚合表,大量計算在分析前被提前完成。而在 ELT 模式下,即使有可用的聚合表,業(yè)務人員也會傾向于直接使用 DWD 層明細表,因為這樣他們能觸達更多的分析維度,進行更靈活的數據探索。
最后是建模專業(yè)性上的差異。之前我們有一個專業(yè)的數倉團隊幫大家背負各種性能問題,他們知道何時做索引、分區(qū),何時該落地預計算。而現在,雖然可視化工具讓業(yè)務人員能自由建模,但在模型優(yōu)化和性能瓶頸等方面,他們常常無力又無心(性能優(yōu)化上的很多必要措施往往是業(yè)務邏輯上的冗余步驟,業(yè)務人員缺少相關優(yōu)化意識)
應對一:升級基礎硬件和算力、借助智能數據準備與建模
性能問題如何解決呢?一般兩條出路。一條路是提升基礎算力或加資源,這是最樸素而有效的解決方法。關鍵點是怎樣高效地加資源。使用云數倉其中一個提效路徑,基于云數倉的彈性伸縮能力,根據實際計算需求變化,波峰時快速擴容提升性能,波谷時方便地釋放資源節(jié)約成本。另一條路是智能數據建模,通過智能化的建模工具,彌補業(yè)務人員和工程師之間的專業(yè)差距。
上圖是我們總結的數據準備與建模方式的發(fā)展階段。第一階段主要是由數據開發(fā)工程師通過手寫 SQL 的方式構建數倉,性能好,但靈活性差。第二個階段是可視化建模,主要使用者是業(yè)務分析師,門檻更低,但模型專業(yè)性不如之前。第三階段是增強數據建模,業(yè)務分析師借助 BI 平臺提供的智能輔助工具,慢慢能夠像專業(yè)IT一樣構建出優(yōu)良的數據模型和數據倉庫。第四階段是AI 智能建模,我們憧憬在未來業(yè)務人員只需要表達業(yè)務邏輯和需求,平臺會自動完成背后的各種數據準備和查詢優(yōu)化。
這四個階段其實是數據準備平民化的歷程,跟自動駕駛領域的駕駛平民化發(fā)展歷程非常相似。第一階段和第二階段對應汽車的手動檔和自動檔階段;第三階段更多的人工智能元素開始加入,類似于 L2 級別的輔助自動駕駛;第四階段則相當于未來需要實現的 L4 級別的完全自動駕駛。通過智能化,消除專業(yè)門檻,釋放人力。
第四階段是我們美好的期望,但目前看距離落地實現還需要較長的時間,一方面分析自動化的復雜度完全不亞于自動駕駛,另一方面分析場景和分析數據的私密性,將導致訓練數據的獲取難度比自動駕駛要高很多。因此,預計在很長一段時間內,我們都將一直處于第三階段,在這個階段由分析人員和 BI 平臺共同配合來完成對開發(fā)工程師的補位,這就要求一方面BI平臺不斷提供更友好的智能輔助建模工具,另一方面分析師需要提升優(yōu)化意識,掌握這些智能工具的使用。
挑戰(zhàn)二:管理挑戰(zhàn)
除了性能問題,分析平民化的另一大挑戰(zhàn)是管理上的挑戰(zhàn)。ELT 模式賦予了分析師更多的自由和靈活度,但自由和規(guī)范性一直是一對矛盾體,所以分析師擁有更多自由的同時無可避免的也會引入一些混亂。
上圖是一個分析普及后數據誤用的真實案例:某公司產品團隊上線了一個新產品,在 AB 測試期間發(fā)現該產品對收入的貢獻非常好,向老板建議盡快發(fā)布,但是運營團隊周報卻提到最近兩周運營數據下降劇烈,老板無法決策,只好讓分析師花了兩周的時間排查原因,發(fā)現運營團隊分析時一個收入指標口徑有問題。此時已經了導致該產品的發(fā)布延期。
在傳統(tǒng) ETL 模式下,口徑的統(tǒng)一是在數倉團隊內部完成,在放開底層數據后,口徑的統(tǒng)一就變成了一個跨部門,甚至跨公司的事情,為數據管理帶來了巨大的挑戰(zhàn)。
從近幾年數據治理概念的興起也能發(fā)現,近年提數據治理的,很多都是從互聯網公司開始。其中一個很重要的原因,他們大部分在內部落實了 ELT 模式,某種程度上實現了分析自由,所以也逐漸暴露了由此導致的口徑混亂、數據打架等問題。
應對二:統(tǒng)一指標管理
對于數據口徑混亂的問題如何解決?還是需要有一個地方對指標和口徑進行統(tǒng)一管理,所有重要的指標,都要經過計算邏輯的統(tǒng)一定義和發(fā)布,才能被用于分析和匯報。這其實也是很多指標中臺伙伴的產品思路。
由于統(tǒng)一管理指標后,指標庫成為了絕大部分分析的基礎和前提,為了避免回退到類似ETL模式的分析困境,指標庫的管理、運維工作應該足夠輕量。只有足夠輕量,這個環(huán)節(jié)才能足夠敏捷,不會成為分析流程中的新瓶頸點。而實現指標庫輕量性的一個關鍵的點,在于業(yè)務與數據的分離。通過業(yè)務與數據的分離,定義業(yè)務指標時只需處理業(yè)務的邏輯概念即可,無需關心這些概念與底層數據表里具體計算代碼的映射和轉換。
HENGSHI SENSE 4.2新特性
衡石作為一家專注于賦能全行業(yè)的 SaaS / ISV 敏捷構建數據分析和 BI 能力的標準化軟件產品廠商,在近期發(fā)布的 HENGSHI SENSE 4.2新版本中,針對于前面探討的問題也做出了更多的優(yōu)化和提升:
賦能數據科學家:HENGSHI SENSE 數據科學模塊支持 Python,為數據科學家提供更好的語言來應對復雜的機器學習和高級分析需求。
更強大的數據源適配能力:HENGSHI SENSE 提供更強大的數據源適配能力幫助客戶接入更多的數據。如支持原生 MangoDB,避免用戶再從 MangoDB 往傳統(tǒng)關系型數據庫搬運數據,提升接入數據的效率;在 API 上對接了旺店通、石墨文檔和企業(yè)微信,后續(xù)這些接口來源的數據可以便捷地接入 HENGSHI SENSE 與其他數據做關聯分析。
HQL 升級:HENGSHI SENSE 很早就通過自定義的 HQL 語言實現了業(yè)務和數據分離,在4.2新版本中又對 HQL 進行了升級,支持用戶自定義 UDF 并擴展了 HQL 的函數體系。
可視化增強:HENGSHI SENSE 通過在布局中提供重力模式,在容器的編輯的時候,提供了編輯和分屏展示的模式,幫助分析師更加高效地去制作和編輯儀表盤。
管理與協作:分析是一個非常重管理和協作的工作,4.2新版本中新增了數據權限模式適配、跨應用復制數據集等功能,優(yōu)化大規(guī)模的團隊協作。
