一、現(xiàn)代數(shù)據(jù)分析的趨勢及現(xiàn)狀

首先和大家分享下數(shù)據(jù)分析的趨勢及現(xiàn)狀。

1、數(shù)據(jù)分析及商業(yè)智能發(fā)展史

這里的商業(yè)智能指的是更廣泛意義上的商業(yè)智能，不僅是大家所理解的可視化，也包含數(shù)據(jù)洞察和輔助決策。

商業(yè)智能（BI）這一概念始于1958年。在上世紀70年代到90年代間，BI經歷了1.0和2.0階段的發(fā)展。在2000年前后，形成了完整的理論及工具體系，出現(xiàn)了統(tǒng)一和寡頭式的發(fā)展。到2010年以后，隨著QlikView和Tableau的興起，數(shù)據(jù)分析出現(xiàn)了巨大的變革，首先是由IT端逐漸轉向由業(yè)務端等終端去完成；另外，由周報、月報、季報等報表分析逐漸轉向歸因分析等精細化運營分析。在這個過程中，數(shù)據(jù)分析人員需要具備統(tǒng)計、業(yè)務、數(shù)據(jù)等跨領域的知識儲備，這樣才能夠迅速地根據(jù)數(shù)據(jù)分析結果解決業(yè)務問題，并推動數(shù)據(jù)為業(yè)務賦能。

(資料圖片)

2、數(shù)據(jù)分析主要趨勢

數(shù)據(jù)分析的未來，從數(shù)據(jù)需求層面和整體趨勢層面分別有以下主要趨勢：

（1）數(shù)據(jù)需求層面

①精確性

現(xiàn)有的數(shù)據(jù)分析不管是使用Tableau還是PowerBI等分析工具，都是通過數(shù)倉中的數(shù)據(jù)去創(chuàng)建分析模型，通過分析模型去處理數(shù)據(jù)分析，最終數(shù)據(jù)計算和指標定義是在這些分析工具中完成的。

由于企業(yè)中存在不同的業(yè)務體系及數(shù)據(jù)團隊，當同時存在多個數(shù)據(jù)分析工具時，數(shù)據(jù)的可信度就會存在差異。比如銷售量、銷售額和利潤率等指標在財務報表和銷售分析中就可能出現(xiàn)不一致的情況，此時數(shù)據(jù)分析的結果是存疑的，精確性需要提高。

②敏捷性

隨著業(yè)務的靈活發(fā)展，一些原有的經營指標，其生命周期由3-5年變得越來越短。特別是隨著新的業(yè)務渠道和模式的出現(xiàn)，會引起一些原有的指標統(tǒng)計口徑發(fā)生變更，分析維度會隨著變更，原來的常規(guī)報表分析可能只需要5到10個維度，現(xiàn)在的報表可能需要10到100個維度去快速使用。

③實時性

目前的報表分析實效要求已經是天級，用T+1的數(shù)據(jù)生成報表，之前會有周報、月報的級別。目前業(yè)務人員開始提出T+0.X或者T+0的數(shù)據(jù)報表，以實現(xiàn)更好更及時的接觸業(yè)務情況，促進業(yè)務發(fā)展。

敏捷性和實時性的結合將使得數(shù)據(jù)體系的復雜性越來越高，使得數(shù)據(jù)表越來越多。不同的業(yè)務場景會用到不同的數(shù)據(jù)中間件，一些金融性企業(yè)在Hadoop平臺上甚至會用到10個以上的中間件。這種情況下，下游人員和應用將很難使用這些工具和數(shù)據(jù)。

（2）整體趨勢層面

①全民數(shù)據(jù)分析

在ChatGPT等人工智能工具出現(xiàn)之后，全民數(shù)據(jù)分析將從概念被推進到落地，按Gartner預測在未來的2-5年所有人都將需要具備數(shù)據(jù)分析能力。

數(shù)據(jù)分析的整體邏輯將可能是通過對話的方式完成指標和數(shù)據(jù)的查詢。數(shù)據(jù)分析人員將不僅僅是原有的數(shù)據(jù)分析師和IT人員，也將是一線業(yè)務人員，比如銷售人員和客服人員，都將能夠直接去完成數(shù)據(jù)分析。

②主動數(shù)據(jù)驅動

目前的數(shù)據(jù)驅動方式是進行數(shù)據(jù)展示，使用大屏、報表、數(shù)據(jù)面板等方式。一些數(shù)據(jù)分析能力較強的企業(yè)已經開始逐漸改變，由人找數(shù)變成數(shù)找人。

人找數(shù)：當業(yè)務人員有數(shù)據(jù)需求時，去數(shù)據(jù)平臺上提申請，去描述需要什么樣的指標，什么樣的維度以及什么樣的報表。數(shù)找人：當一個業(yè)務事件發(fā)生時，主動向業(yè)務人員去推送相應的數(shù)據(jù)。比如每隔一個小時推送給銷售人員在該時段內其關心的數(shù)據(jù)。

③AI增強分析

隨著人工智能工具的變革性發(fā)展，主流的數(shù)據(jù)分析方式將發(fā)生改變，從現(xiàn)有的托拉拽的方式，轉變?yōu)閱柎鸬姆绞?。?shù)據(jù)分析工具甚至能夠直接給出相應的業(yè)務建議。滴普科技目前也在進行一些相關產品的實驗。

3、數(shù)據(jù)分析的現(xiàn)狀（1）數(shù)據(jù)分析的問題

從現(xiàn)狀來看，數(shù)據(jù)分析主要有三個問題：

①找數(shù)難

目前數(shù)據(jù)量級越來越大，有可能達到PT級甚至是更大的數(shù)據(jù)量。數(shù)據(jù)結構越來越復雜，涉及到幾千上萬的表，分布在不同類型的數(shù)據(jù)倉庫，比如Hive、Clickhouse、Doris等。

如何去快速拿到數(shù)據(jù)？如何驗證存疑的數(shù)據(jù)？在具體的分析過程中，即使做了很好的數(shù)據(jù)治理，快速的找到準確的數(shù)據(jù)仍是非常困難的。對于一個成熟的企業(yè)來講，可能需要2個小時去找到正確的數(shù)據(jù)。

②價值低

一些企業(yè)在建整個數(shù)據(jù)倉庫或者數(shù)據(jù)湖的過程中，大量數(shù)據(jù)已經被存放到ODS數(shù)據(jù)貼源層。真正被使用到的數(shù)據(jù)卻不到10%，特別是一些半結構化和非結構化數(shù)據(jù)，在國內這種情況更加突出。

③準確性低

因為使用的數(shù)據(jù)量相對較低，準確性低的情況在國內還不明顯。但是在國外已經是主要問題。前文已提到，同一個指標在不同報表中就可能出現(xiàn)數(shù)據(jù)不一致的情況，需要花費大量的時間去驗證數(shù)據(jù)，導致數(shù)據(jù)分析的工作內容變成了數(shù)據(jù)驗證。

（2）人員的矛盾

基于上述問題，數(shù)據(jù)分析師和業(yè)務人員在溝通中會出現(xiàn)一些矛盾：

①受理周期長VS需求變化頻繁

業(yè)務人員：你不能需求提出后1-2周才處理；

數(shù)據(jù)分析師：你不能今天確定指標內容，下個月就發(fā)生變化；

②數(shù)據(jù)實效性低VS資源緊張

業(yè)務人員：我需要T+0或者T+0.X，不是T+3也不是T+1；

數(shù)據(jù)分析師：我資源有限無法承擔過量工作內容；

③數(shù)據(jù)使用難VS直接用

業(yè)務人員：我需要可以直接使用的數(shù)據(jù)，而不是直接使用的SQL腳本。

二、通過指標實現(xiàn)敏捷高效數(shù)據(jù)分析1、目前大數(shù)據(jù)平臺如何完成數(shù)據(jù)分析（1）目前數(shù)據(jù)分析方式

接下來大概介紹下，在數(shù)據(jù)分析過程中如何完成各項處理。一個新的指標定義的模式有兩種：

①直接定義

跳過數(shù)據(jù)倉庫使用原始表或者使用清洗后的DWD層數(shù)據(jù)表（明細事實表）直接在BI完成指標的定義。

②通過匯總表定義

在數(shù)據(jù)倉庫上根據(jù)指標需要的一些維度提前完成輕度匯總，然后根據(jù)匯總表在BI進行分析和定義。

這種模式數(shù)據(jù)精確性高，更可靠；缺點是匯總表與維度的耦合性高，維度發(fā)生變化后，匯總表需要進行重構，從而影響到下游使用該表的應用。分析師更愿意新增一張匯總表，這時舊的匯總表將持續(xù)占用工作空間。

（2）目前數(shù)據(jù)使用矛盾

此時數(shù)據(jù)的膨脹和業(yè)務的靈活性也形成了一個矛盾：數(shù)據(jù)量更多，數(shù)據(jù)結構更復雜，數(shù)據(jù)湖和數(shù)據(jù)倉庫更龐雜；而業(yè)務變化更敏捷。這也是前述數(shù)據(jù)使用和數(shù)據(jù)開發(fā)的矛盾產生的原因。

①數(shù)據(jù)使用

數(shù)據(jù)消費門檻高。同樣的一個指標只要一個數(shù)據(jù)結果，而不是分散在多處的，需要自行join處理。

②數(shù)據(jù)開發(fā)

有些數(shù)據(jù)指標僅僅存在于分析過程中的SQL里，未及時沉積。當其中一個數(shù)據(jù)指標發(fā)生變化時，可能需要修改無數(shù)張實際對外的ADS層數(shù)據(jù)表。于是，各平臺中、各BI中、各下游應用中會出現(xiàn)大量的歧義數(shù)據(jù)。

2、建立統(tǒng)一語義層（1）數(shù)據(jù)開發(fā)視角

如何解決這些矛盾，目前的共識是建立統(tǒng)一語義層。

統(tǒng)一語義層通過虛擬視圖（虛擬倉庫）解決了邏輯層和物理層Mapping，并統(tǒng)一面對下游用戶完成統(tǒng)一指標定義。此時上游自動完成數(shù)據(jù)匹配，下游用戶無需關心數(shù)據(jù)來源。

（2）數(shù)據(jù)使用視角

建立統(tǒng)一語義層后，數(shù)據(jù)已經完成整體隔離。業(yè)務將不再通過數(shù)據(jù)庫訪問數(shù)據(jù)，可以直接從指標中獲取相應的數(shù)據(jù)。

如上圖案例所示，數(shù)據(jù)分析師完成指標目錄創(chuàng)建后，業(yè)務人員可以直接使用他們熟悉的術語進行指標探索，比如入貨額、退貨量、客戶增長率等。業(yè)務人員明確指標以及相關維度、時間范圍、數(shù)據(jù)粒度后，自動完成指標分析。

統(tǒng)一語義層接入方案中，數(shù)據(jù)輸出時基本于傳統(tǒng)BI一致，區(qū)別是已無需再關心指標來源和定義方式。

3、最終目標：敏捷高效

最終的目標是在指標目錄中選擇指標后，能夠快速完成指標探索。用戶無需關心數(shù)據(jù)來源，不管是來自多少數(shù)據(jù)表還是來自多少數(shù)據(jù)源；可以更多的去關心業(yè)務，真正的對業(yè)務賦能。

統(tǒng)一語義層也被稱為指標中心或者指標平臺，其核心意義就是讓業(yè)務人員忽略源頭關注結果，實現(xiàn)低門檻高效率。

三、指標中臺核心能力及技術實踐

對于統(tǒng)一語義層統(tǒng)一接入方案，滴普科技也總結了一些經驗，形成了一些產品。

1、指標平臺架構

指標平臺整體結構分為兩層：一層是指標中心，一個是數(shù)據(jù)門戶。分別面向兩類人群：數(shù)據(jù)開發(fā)人員和數(shù)據(jù)使用人員。

（1）指標中心

面向數(shù)據(jù)開發(fā)人員。數(shù)據(jù)分析師通過統(tǒng)一語義模型建立模型定義指標，發(fā)布到數(shù)據(jù)門戶。

根據(jù)實際需求，可以進行定義指標加速，配置相關監(jiān)控。

（2）數(shù)據(jù)門戶

面向數(shù)據(jù)使用人員。業(yè)務人員能夠快速的查詢指標，快速的業(yè)務探索，創(chuàng)建相應的標簽、大屏和報表，分享到釘釘、飛書等下游應用或者連接到FineBI或者FindReport等下游工具。

下游不同的應用和工具通過統(tǒng)一的數(shù)據(jù)門戶訪問數(shù)據(jù)，同樣的指標獲取同樣的數(shù)據(jù)，保障了數(shù)據(jù)準確性。

2、基于指標的數(shù)據(jù)分析協(xié)作流程

基于指標的數(shù)據(jù)分析協(xié)作流程可以梳理為兩步：

（1）數(shù)據(jù)開發(fā)人員工作

根據(jù)取數(shù)需求，完成模型和指標的新增或者修改，發(fā)布到數(shù)據(jù)門戶。

（2）數(shù)據(jù)使用人員工作

在數(shù)據(jù)平臺，完成數(shù)據(jù)指標到發(fā)現(xiàn)與探索，以及大屏和報表的創(chuàng)作，并連接到外部應用。

基于指標的數(shù)據(jù)分析協(xié)作流程實現(xiàn)了數(shù)據(jù)資源的隔離。不管是ClickHouse、Hive還是PostgreSQL、Kafka中存儲的數(shù)據(jù)資源，都能夠被有效隔離。用戶只需要關注指標。

3、實現(xiàn)數(shù)據(jù)資源隔離

具體如何實現(xiàn)數(shù)據(jù)資源隔離，下面繼續(xù)進行分享：

（1）智能查詢路由

首先是核心邏輯，需要實現(xiàn)智能查詢路由。智能查詢路由能夠根據(jù)指標智能路由到不同等數(shù)據(jù)層級。目前提供了3個層級的數(shù)據(jù)查詢：

①即席查詢

當指標數(shù)據(jù)沒有進行任何的加速和緩存的時候，會生成原有數(shù)倉的查詢SQL。

②主題加速

如果配置了相應的主題加速，會在主題加速層完成亞秒級配置，目前是4-6次。

③查詢緩存

針對的場景多是數(shù)據(jù)應用的首頁或者常規(guī)的排名查詢，能夠通過查詢緩存層實現(xiàn)毫秒級，目前能達到10-30ms。智能查詢路由給指標平臺帶來最大的改變是，下游用戶無需再選擇查詢層級和數(shù)據(jù)表，只需要制定指標和查詢條件。智能查詢路由進行自動路由，實現(xiàn)了數(shù)據(jù)消費時速度和敏捷性的平衡。

（2）統(tǒng)一查詢入口

不同下游應用包括BI商業(yè)智能、SDK應用、API應用等，通過不同的interface連接到統(tǒng)一查詢入口。然后再通過統(tǒng)一的查詢語言進行指標查詢。

4、實現(xiàn)統(tǒng)一查詢語言

首先，下游Client的不同查詢語言都被轉換為MetricsQL（指標查詢語言）標準的查詢語言。然后，QueryEngine（查詢構建引擎）根據(jù)已經完成的模型和指標進行數(shù)據(jù)源的SQL構建。如果配置了指標加速，QueryEngine就會完成加速層的SQL構建。另外，統(tǒng)一的查詢入口也支持進行數(shù)據(jù)權限管理。

QueryEngine通過指標的定義自動生成不同平臺相應的查詢SQL腳本，并支持智能路由查詢相應的數(shù)據(jù)層。

5、實時指標方案

目標是實現(xiàn)T+0實時指標方案。業(yè)務數(shù)據(jù)通過CDC等方式進入實時數(shù)倉，通過指標語義模型完成語義查詢，最終形成實時指標洞察和實時指標服務，給到下游應用。

一、結語

整個分析過程中，統(tǒng)一查詢入口保障了精確性，智能查詢路由保障了敏捷性，實時指標方案保障了實時性。

最終目標是滿足全民數(shù)據(jù)分析的需求，讓任何人都能以想要的方式去快速訪問數(shù)據(jù)。在這個過程中，他無需具有大數(shù)據(jù)的基礎知識儲備就能完成數(shù)據(jù)的整體分析。即使上游數(shù)據(jù)是很復雜一個Hadoop體系，他也能完成這樣的分析。

五、Q&AQ：在構建統(tǒng)一語義層的時,會存在兩層邏輯:一層是命中加速層，一層是非命中加速層。對應的物理存儲引擎上可能會有一定的差異，這種差異是如何處理的？

A：上游數(shù)據(jù)源基本上都會存在差異。首先是查詢語言已經被轉換為MetricsQL標準的查詢語言，QueryEngine去完成語法樹的重新構建；然后去適配不同的數(shù)據(jù)源，去完成每個數(shù)據(jù)源語法樹的適配。在這個過程中，實現(xiàn)插件式的適配能力，目前已經適配了5種數(shù)據(jù)源，仍在持續(xù)更新中。

關鍵詞：