一、現代數據分析的趨勢及現狀

首先和大家分享下數據分析的趨勢及現狀。

1、數據分析及商業智能發展史

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

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

2、數據分析主要趨勢

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

（1）數據需求層面

①精確性

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

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

②敏捷性

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

③實時性

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

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

（2）整體趨勢層面

①全民數據分析

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

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

②主動數據驅動

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

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

③AI增強分析

隨著人工智能工具的變革性發展，主流的數據分析方式將發生改變，從現有的托拉拽的方式，轉變為問答的方式。數據分析工具甚至能夠直接給出相應的業務建議。滴普科技目前也在進行一些相關產品的實驗。

3、數據分析的現狀

（1）數據分析的問題

從現狀來看，數據分析主要有三個問題：

①找數難

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

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

②價值低

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

③準確性低

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

（2）人員的矛盾

基于上述問題，數據分析師和業務人員在溝通中會出現一些矛盾：

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

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

數據分析師：你不能今天確定指標內容，下個月就發生變化；

②數據實效性低VS資源緊張

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

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

③數據使用難VS直接用

業務人員：我需要可以直接使用的數據，而不是直接使用的SQL腳本。

二、通過指標實現敏捷高效數據分析

1、目前大數據平臺如何完成數據分析

（1）目前數據分析方式

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

①直接定義

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

②通過匯總表定義

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

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

（2）目前數據使用矛盾

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

①數據使用

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

②數據開發

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

2、建立統一語義層

（1）數據開發視角

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

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

（2）數據使用視角

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

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

統一語義層接入方案中，數據輸出時基本于傳統BI一致，區別是已無需再關心指標來源和定義方式。

3、最終目標：敏捷高效

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

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

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

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

1、指標平臺架構

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

（1）指標中心

面向數據開發人員。數據分析師通過統一語義模型建立模型定義指標，發布到數據門戶。

根據實際需求，可以進行定義指標加速，配置相關監控。

（2）數據門戶

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

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

2、基于指標的數據分析協作流程

基于指標的數據分析協作流程可以梳理為兩步：

（1）數據開發人員工作

根據取數需求，完成模型和指標的新增或者修改，發布到數據門戶。

（2）數據使用人員工作

在數據平臺，完成數據指標到發現與探索，以及大屏和報表的創作，并連接到外部應用。

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

3、實現數據資源隔離

具體如何實現數據資源隔離，下面繼續進行分享：

（1）智能查詢路由

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

①即席查詢

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

②主題加速

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

③查詢緩存

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

（2）統一查詢入口

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

4、實現統一查詢語言

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

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

5、實時指標方案

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

一、結語

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

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

五、Q&A

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

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