各位嘉賓、朋友們，下午好。今天上午，我們公司的 CEO 已經(jīng)在主會(huì)場(chǎng)的第一場(chǎng)分享了關(guān)于我們公司的情況。可能大家對(duì) Aloudata 還不太熟悉，我們是一家成立不久的初創(chuàng)公司。之前我們的團(tuán)隊(duì)成員在阿里螞蟻工作了一二十年，深知數(shù)據(jù)領(lǐng)域尤其是供給側(cè)在服務(wù)業(yè)務(wù)時(shí)存在許多痛點(diǎn)。因此，我們希望通過一些新技術(shù)來幫助大家解決日常工作中的問題。

我今天的分享主要分為三部分。第一部分，我們將探討在當(dāng)前業(yè)務(wù)對(duì)接過程中存在的問題，以及是否有新的方法可以幫助我們解決這些問題。第二部分，我將介紹我們創(chuàng)業(yè)后開發(fā)的產(chǎn)品化解決方案——第三代指標(biāo)平臺(tái)。我會(huì)說明這個(gè)產(chǎn)品具備哪些能力，以及它能為企業(yè)帶來哪些價(jià)值。第三部分，我將分享這個(gè)產(chǎn)品在不同行業(yè)客戶中的一些真實(shí)落地案例。

一、ETL 的原罪與 NoETL 全新思路

首先，我們知道，近年來每個(gè)企業(yè)和行業(yè)都在進(jìn)行數(shù)字化轉(zhuǎn)型。在這個(gè)過程中，數(shù)據(jù)人員收到的業(yè)務(wù)部門數(shù)據(jù)需求越來越多，對(duì)數(shù)據(jù)的時(shí)效性要求也越來越高。我們發(fā)現(xiàn)，傳統(tǒng)的數(shù)據(jù)從業(yè)人員通常通過開發(fā)大量面向業(yè)務(wù)場(chǎng)景的寬表和匯總表來快速響應(yīng)業(yè)務(wù)需求。這導(dǎo)致整個(gè)數(shù)據(jù)管道和數(shù)據(jù)鏈路變得越來越長(zhǎng)。許多數(shù)據(jù)同學(xué)會(huì)抱怨，他們的數(shù)據(jù)加工鏈路有上百層，一旦出現(xiàn)問題，他們很難快速排查并定位問題。

需求的顯著增長(zhǎng)讓數(shù)據(jù)管理的難度越來越大。我們認(rèn)為，這背后的問題主要是因?yàn)閭鹘y(tǒng) ETL 作業(yè)進(jìn)行了大量的反范式寬表和匯總表的加工。這種加工方式使得在整個(gè)數(shù)據(jù)處理過程中，很難在效率、質(zhì)量和成本之間達(dá)到平衡。例如，如果一個(gè)業(yè)務(wù)需求需要快速響應(yīng)，我們可能就沒有時(shí)間去進(jìn)行充分的數(shù)據(jù)校驗(yàn)和優(yōu)化。

此外，如果需要避免重復(fù)開發(fā)，需要不同業(yè)務(wù)線的 ETL 工程師彼此溝通，是不是我們數(shù)倉(cāng)里面已經(jīng)沉淀了這么一張表，是不是已經(jīng)開發(fā)好了這個(gè)字段。這種協(xié)同溝通的成本會(huì)很高，時(shí)間可能會(huì)很長(zhǎng)。所以，在這種情況下，為了保證效率，可能就會(huì)存在數(shù)據(jù)的大量重復(fù)開發(fā)，會(huì)存在口徑的差異?？赡懿煌臉I(yè)務(wù)提的需求是同一個(gè)指標(biāo)，但拿到的結(jié)果是不同的。

如果我要解決這個(gè)質(zhì)量問題，避免重復(fù)開發(fā)，那前期就要投入大量的協(xié)同溝通成本，要把這個(gè)模型設(shè)計(jì)得很好。這個(gè)時(shí)候，業(yè)務(wù)可能又等不及，因?yàn)闃I(yè)務(wù)會(huì)覺得我只是提了一個(gè)簡(jiǎn)單的需求，為什么要等這么長(zhǎng)時(shí)間。所以就導(dǎo)致我們現(xiàn)在陷入了這種成本、效率、質(zhì)量的不可能三角。

那到底有沒有可能破解這個(gè)不可能的三角呢？其實(shí)從整個(gè) MECE 原則來拆分，我們剛剛講到導(dǎo)致不可能三角的原罪是因?yàn)樽隽舜罅康姆捶妒?ETL 開發(fā)寬表和匯總表的作業(yè)。那我們是不是可以不去加工寬表匯總表，這樣就把這個(gè)問題的源頭解決掉了？

大家也知道，今天企業(yè)的數(shù)據(jù)量越來越大，那今天我們的查詢引擎技術(shù)還沒有發(fā)展到足夠支撐這么大的數(shù)據(jù)量的直查，所以看起來這條路是不可行的。

那我們換個(gè)思路，如果要通過人工保證它的質(zhì)量，保證不要做重復(fù)開發(fā)，需要很大的協(xié)同溝通成本，那是不是能夠把人工的工作變成由系統(tǒng)來做，因?yàn)橄到y(tǒng)會(huì)知道到底開發(fā)了哪些表，做了哪些指標(biāo)的加工。這里我們先給出一個(gè)結(jié)論就是可以從原來的人工加工變成 NoETL 自動(dòng)化，并基于該理念開發(fā)了一款自動(dòng)化的指標(biāo)平臺(tái)——Aloudata CAN。

Aloudata CAN 如何實(shí)現(xiàn) NoETL 自動(dòng)化呢？其核心機(jī)制主要依托于兩項(xiàng)關(guān)鍵技術(shù)能力。首先是語義化，其次是自動(dòng)化。

每個(gè)企業(yè)都有其獨(dú)特的行業(yè)特征和指標(biāo)建模需求，這些都是各企業(yè)之間差異化的體現(xiàn)。如何讓系統(tǒng)準(zhǔn)確理解該如何處理數(shù)據(jù)和開發(fā)指標(biāo)，這就需要第一項(xiàng)能力——強(qiáng)大的指標(biāo)定義能力。這意味著系統(tǒng)必須能夠識(shí)別出每一個(gè)指標(biāo)應(yīng)當(dāng)采用的開發(fā)邏輯，在傳統(tǒng)模式下，這些邏輯的開發(fā)通常由數(shù)據(jù)倉(cāng)庫(kù)的 ETL 工程師編寫 SQL 來完成。現(xiàn)在，我們希望通過低門檻的配置方式實(shí)現(xiàn)語義定義，讓業(yè)務(wù)人員可以通過業(yè)務(wù)語義的配置表達(dá)向系統(tǒng)明確各項(xiàng)指標(biāo)的業(yè)務(wù)計(jì)算邏輯。一旦系統(tǒng)掌握了這些邏輯，我們便能夠確保數(shù)據(jù)倉(cāng)庫(kù)和 ETL 工程師專注于數(shù)據(jù)資產(chǎn)的沉淀。

只要告訴系統(tǒng)指標(biāo)的業(yè)務(wù)計(jì)算邏輯和業(yè)務(wù)含義是什么，它就可以讓系統(tǒng)去執(zhí)行。這是第一點(diǎn)——語義化。第二點(diǎn)，可能大家會(huì)有疑問，因?yàn)榍懊嫣岬浆F(xiàn)在數(shù)據(jù)量很大，如果只是告訴了系統(tǒng)計(jì)算邏輯，它是一個(gè)虛擬化的邏輯化的，怎么能解決大數(shù)據(jù)量下的查詢性能問題呢？是否對(duì)存儲(chǔ)計(jì)算資源要求很高？

這就涉及到我們講的第二個(gè)能力：自動(dòng)化。當(dāng)我們面對(duì)大數(shù)據(jù)時(shí)，并不是真正地“干掉”了寬表和匯總表，而是把這部分從人工工作變成了系統(tǒng)自動(dòng)化去做。系統(tǒng)會(huì)根據(jù)定義的業(yè)務(wù)計(jì)算邏輯自動(dòng)翻譯成 SQL，自動(dòng)地進(jìn)行鏈路編排，生成面向業(yè)務(wù)場(chǎng)景的寬表和匯總表。

接下來再展開講一下這兩方面具體技術(shù)的實(shí)現(xiàn)邏輯。在語義化方面，Aloudata CAN 包含了六個(gè)核心能力。

第一個(gè)核心能力是讓系統(tǒng)知道指標(biāo)的計(jì)算邏輯是什么，這背后需要我們提供一個(gè)標(biāo)準(zhǔn)的指標(biāo)定義能力。

我們?cè)谧鲋笜?biāo)定義時(shí)經(jīng)常需要跨表定義指標(biāo)。如果說數(shù)倉(cāng)不做寬表的加工了，那我們?cè)趺茨軌驅(qū)崿F(xiàn)跨表的指標(biāo)定義？我們的解法是構(gòu)建一個(gè)語義模型，再在這樣的一個(gè)語義模型基礎(chǔ)之上，把指標(biāo)拆解成一些最原子的要素，比如說原子指標(biāo)、時(shí)間限定、業(yè)務(wù)限定、衍生方式等。有了這個(gè)拆解之后，實(shí)際上我們給到業(yè)務(wù)的體驗(yàn)是一些語義化、配置化的模板，不需要去寫 SQL 了。

如果不需要去寫 SQL，但系統(tǒng)查的是一個(gè) SQL，怎么能夠?qū)崿F(xiàn)這種復(fù)雜的表達(dá)呢？這背后實(shí)際上是依賴于第二點(diǎn)核心能力——一個(gè)強(qiáng)大的指標(biāo)函數(shù)體系。

這個(gè)函數(shù)體系也是我們自研的，里面包含了常規(guī)日期文本、聚合函數(shù)，也包含了復(fù)雜的窗口函數(shù)和分析函數(shù)。我們會(huì)把這樣的一個(gè)函數(shù)抽象成一些模板化，對(duì)于用戶來講，他只要去點(diǎn)點(diǎn)選選就可以在界面上配置出來一個(gè)復(fù)雜的指標(biāo)，比如說我們要去配置一個(gè)門店的銷售金額，例如在華東地區(qū)的排名。原來需要在數(shù)倉(cāng)寫 SQL，寫開窗函數(shù)去實(shí)現(xiàn)，但在 Aloudata CAN 里面，只需要通過配置化的方式，不會(huì)寫 SQL 也能定義出來。

第三點(diǎn)核心能力是自動(dòng)構(gòu)建多層次、多聚合的任務(wù) DAG（有向無環(huán)圖）。例如，在構(gòu)建指標(biāo)的第一階段，系統(tǒng)會(huì)先計(jì)算每個(gè)門店的銷售量；第二階段，根據(jù)銷售量進(jìn)行排名；第三階段，得出排名結(jié)果?；谶@種方式，無論指標(biāo)多復(fù)雜，都可以通過多層次、多聚合的方式構(gòu)建 DAG。

接著，系統(tǒng)會(huì)根據(jù)用戶配置的多層次、多聚合要求，自動(dòng)將這些配置轉(zhuǎn)化為 SQL 語句，這是第四大能力。

此外，在 SQL 翻譯過程中，也涉及性能優(yōu)化問題。這就涉及第五點(diǎn)核心能力——查詢 SQL 優(yōu)化。一是基于指標(biāo)計(jì)算本身的優(yōu)化，如關(guān)聯(lián)下推、多層 AGG 合并和裁剪；二是基于規(guī)則優(yōu)化器（RBO）進(jìn)行的優(yōu)化，如 Limit 下推、子查詢裁剪和列裁剪等。

第六點(diǎn)核心能力是自建內(nèi)存計(jì)算引擎提升查詢效率。這個(gè)計(jì)算引擎是專門針對(duì)指標(biāo)場(chǎng)景開發(fā)的，包括指標(biāo)分析器、RBO 和 CBO 的拆分、DAG 構(gòu)建、任務(wù)管理、算子級(jí)別執(zhí)行器、緩存等。

基于這六大能力支持的語義化能力，我們通過定義少量的原子指標(biāo)，就可以輕松實(shí)現(xiàn)大量派生指標(biāo)的應(yīng)用場(chǎng)景。在很多企業(yè)中，實(shí)際需要的原子指標(biāo)數(shù)量并不多，一條業(yè)務(wù)線可能只需要大約一百個(gè)原子指標(biāo)。過去，企業(yè)可能會(huì)基于這些原子指標(biāo)定義上千個(gè)派生指標(biāo)，導(dǎo)致了巨大的指標(biāo)管理變更成本。Aloudata CAN 的方案則可以降低這一成本，提升企業(yè)數(shù)據(jù)分析的效率與效果。

首先，我們希望通過定義少量的原子指標(biāo)來覆蓋更多派生指標(biāo)的場(chǎng)景。其次，從指標(biāo)管理的角度來看，我們知道企業(yè)中存在指標(biāo)口徑不一致的問題。雖然企業(yè)可能通過一些指標(biāo)管理工具或指標(biāo)口徑登記工具來進(jìn)行管理，但這并不能完全解決問題。我們發(fā)現(xiàn)，要真正解決這一問題的核心在于，需要將指標(biāo)的定義邏輯從數(shù)據(jù)倉(cāng)庫(kù)轉(zhuǎn)移到指標(biāo)平臺(tái)，這樣才能實(shí)現(xiàn)自動(dòng)化的同名同義校驗(yàn)，確保指標(biāo)計(jì)算邏輯沉淀在指標(biāo)平臺(tái)上，從而實(shí)現(xiàn)口徑的統(tǒng)一管理和一致性。

此外，我們還支持一些復(fù)雜的原子指標(biāo)和派生指標(biāo)的定義，這些都是通過模板化的配置來實(shí)現(xiàn)的。以上可以表明，Aloduata CAN 具備了將指標(biāo)計(jì)算邏輯告知系統(tǒng)的語義能力，系統(tǒng)知道如何計(jì)算這些指標(biāo)。

在處理大數(shù)據(jù)量時(shí)，我們可能會(huì)遇到性能問題，因此需要第二個(gè)能力——自動(dòng)化能力。這種自動(dòng)化能力實(shí)際上是通過系統(tǒng)的方式來平衡性能成本和時(shí)效性。

在自動(dòng)化方面，Aloudata CAN 是通過系統(tǒng)的方式來平衡性能成本和時(shí)效性。其核心步驟有四個(gè)。

首先是基于前面講述的指標(biāo)語義，Aloudata CAN 能夠自動(dòng)構(gòu)建進(jìn)行物化視圖，將查詢請(qǐng)求轉(zhuǎn)變成 DAG 的構(gòu)建，然后再將其拆分成多層不同的物化視圖，以此來保障整個(gè)查詢的性能和靈活性。同時(shí)也支持人工指定構(gòu)建物化視圖，例如在管理駕駛艙中，領(lǐng)導(dǎo)可能需要根據(jù)特定指標(biāo)和維度進(jìn)行快速響應(yīng)，因此可以手動(dòng)選擇這些指標(biāo)和維度，系統(tǒng)將自動(dòng)創(chuàng)建物化視圖進(jìn)行預(yù)計(jì)算，類似于以前在數(shù)據(jù)倉(cāng)庫(kù)中人工創(chuàng)建的匯總表。

在物化視圖的多層構(gòu)建策略中，越貼近明細(xì)數(shù)據(jù)的物化視圖靈活性越高，越接近結(jié)果的物化視圖性能越高。前者適用于靈活分析場(chǎng)景，后者適用于管理駕駛艙和一些固定報(bào)表的場(chǎng)景。在兩者之間，我們還可以針對(duì)復(fù)雜指標(biāo)（如先計(jì)算均值再計(jì)算排名）的整體構(gòu)建物化視圖，以及構(gòu)建行間偏移類指標(biāo)（如最近 30 天的日均交易客戶數(shù)等）的物化視圖。

在整個(gè)物化視圖的構(gòu)建過程中，我們可以根據(jù)需要調(diào)整加速的粒度，以實(shí)現(xiàn)性能和成本的最優(yōu)平衡。此外，Aloudata CAN 支持視圖依賴視圖的構(gòu)建方式，例如基于日常的聚合視圖來構(gòu)建行間偏移的物化視圖。系統(tǒng)自動(dòng)生成視圖依賴關(guān)系有助于避免重復(fù)構(gòu)建。如果系統(tǒng)檢測(cè)到已存在相應(yīng)的物化視圖，就不會(huì)進(jìn)行重復(fù)的構(gòu)建工作。

Aloduata CAN 的物化加速策略遵循了數(shù)據(jù)倉(cāng)庫(kù)中的最佳工程實(shí)踐。

第一個(gè)策略是冗余維度打?qū)?。即針?duì)常用的維度，將其與明細(xì)事實(shí)表進(jìn)行預(yù)打?qū)?，這樣上層在使用時(shí)就可以基于該明細(xì)寬表進(jìn)行計(jì)算，可以減少多次關(guān)聯(lián)帶來的計(jì)算消耗。

第二個(gè)策略是同事實(shí)同實(shí)體合并計(jì)算。如針對(duì)訂單表的多個(gè)不同的指標(biāo)，可以放在一起進(jìn)行計(jì)算，減少對(duì)事實(shí)表的多次掃描。

第三個(gè)策略是長(zhǎng)周期依賴短周期。如已有物化視圖是基于“天”粒度構(gòu)建的，那么，派生指標(biāo)中的近 7 天、本月、近 30 天等等，都可以基于該天粒度的物化視圖進(jìn)行構(gòu)建。

第四個(gè)策略是細(xì)粒度上卷聚合計(jì)算。如已有物化視圖的維度是 A、B、C、D，當(dāng)用戶新構(gòu)建的物化加速方案是基于 A、B 兩個(gè)維度時(shí)，則可以來 A、B、C、D 四個(gè)維度的物化視圖進(jìn)行上卷，避免了從原始數(shù)據(jù)進(jìn)行計(jì)算。

以上四種例子較為常見，Aloudata CAN 還設(shè)置了許多其他加速數(shù)據(jù)處理的策略。

第二步是物化視圖的調(diào)度更新機(jī)制。如果上游數(shù)據(jù)發(fā)生變化，我們需要知道何時(shí)刷新物化視圖的數(shù)據(jù)。這可以通過兩種方式實(shí)現(xiàn)：一是與上游任務(wù)對(duì)接，通過調(diào)度通知觸發(fā)實(shí)時(shí)更新；二是設(shè)置定時(shí)更新機(jī)制，系統(tǒng)會(huì)自動(dòng)處理物化視圖的變更和刷新。這種機(jī)制能夠識(shí)別哪些指標(biāo)受到影響，并針對(duì)這些指標(biāo)進(jìn)行更新。

Aloudata CAN 基于指標(biāo)的血緣關(guān)系，形成一個(gè)網(wǎng)絡(luò)算子圖譜。例如，如果一個(gè)維度表或事實(shí)表發(fā)生變更，我們不會(huì)對(duì)所有指標(biāo)進(jìn)行回刷，而是只針對(duì)受影響的指標(biāo)進(jìn)行局部回刷，以盡量減少回刷范圍。

第三步是物化視圖的命中改寫能力。用戶在使用時(shí)通常不需要知道背后使用的是哪種表，查詢時(shí)，系統(tǒng)可以根據(jù)用戶的查詢行為將查詢路由到最匹配的物化視圖上。

Aloudata CAN 通過邏輯樹的方式判斷用戶的查詢應(yīng)該路由到哪一個(gè)物化視圖，或是直接下推進(jìn)行實(shí)時(shí)計(jì)算。這種判斷可能基于 BI 工具發(fā)起的查詢，也可能是來自我們的 APP 或業(yè)務(wù)系統(tǒng)的查詢。在發(fā)起查詢時(shí)，Aloudata CAN 會(huì)遍歷物化視圖。

首先檢查是否能命中頂層的物化視圖，即是否能直接得到查詢結(jié)果。如果頂層的物化視圖沒有命中，我們會(huì)繼續(xù)向下遍歷，檢查是否有符合行間偏移的物化視圖。如果這一層也未命中，我們將繼續(xù)查找是否有符合特定粒度（如按天）的普通物化視圖。如果這些都未命中，最后我們會(huì)嘗試兜底的星型模型物化視圖。如果連兜底的物化視圖都未命中，那么我們將直接查詢底層的明細(xì)數(shù)據(jù)，并進(jìn)行實(shí)時(shí)計(jì)算。

查詢?nèi)绻卸鄠€(gè)物化視圖，Aloudata CAN 會(huì)選擇一個(gè)最優(yōu)的。這個(gè)最優(yōu)選擇基于幾個(gè)原則：數(shù)據(jù)量是否最小，指標(biāo)是否與業(yè)務(wù)需求最匹配，以及時(shí)間范圍是否最接近。

最后一步是關(guān)于物化視圖生命周期的管理。在傳統(tǒng)的數(shù)據(jù)倉(cāng)庫(kù)環(huán)境中，發(fā)布新表容易，但下線舊表難，因?yàn)?ETL 工程師不容易判斷下游是否還在使用這張表。現(xiàn)在，系統(tǒng)能夠自動(dòng)識(shí)別物化視圖是否被下游消費(fèi)，從而實(shí)現(xiàn)無效物化視圖的自動(dòng)回收，減少了維護(hù)成本和風(fēng)險(xiǎn)。

總結(jié)一下：傳統(tǒng)人工進(jìn)行的寬表和匯總表加工可以通過 NoETL 自動(dòng)化完成。這得益于兩個(gè)核心技術(shù)能力。首先是語義化能力，它允許任何指標(biāo)的計(jì)算邏輯被定義并統(tǒng)一管理，這是自動(dòng)化的前提。其次，一旦所有復(fù)雜的指標(biāo)都能被表達(dá)，我們就能實(shí)現(xiàn)這些指標(biāo)的快速計(jì)算，從而保證在大數(shù)據(jù)量下也能有良好的性能和業(yè)務(wù)響應(yīng)效率，同時(shí)確保數(shù)據(jù)的一致性。

二、第三代指標(biāo)平臺(tái)的能力與價(jià)值

我們將 Aloudata CAN 定義為第三代指標(biāo)平臺(tái)，即 NoETL 自動(dòng)化的指標(biāo)平臺(tái)。在討論第三代指標(biāo)平臺(tái)之前，我們先簡(jiǎn)單回顧一下第一代和第二代指標(biāo)平臺(tái)的特點(diǎn)。第一代指標(biāo)平臺(tái)主要是將原本線下通過 Excel 維護(hù)的指標(biāo)字典轉(zhuǎn)移到線上，實(shí)現(xiàn)了指標(biāo)口徑的登記和管理。但在這一代中，指標(biāo)的定義和開發(fā)是分離的，無法實(shí)現(xiàn)自動(dòng)化生產(chǎn)和統(tǒng)一管理。

第二代指標(biāo)平臺(tái)受到近年來國(guó)外 Headless BI 概念的啟發(fā)，將指標(biāo)平臺(tái)作為一個(gè)獨(dú)立層，位于數(shù)據(jù)倉(cāng)庫(kù)和 BI 工具之間。這一代指標(biāo)平臺(tái)嘗試解決了一些自動(dòng)化和語義化的問題，但仍然存在局限性。由于缺乏強(qiáng)大的語義化和自動(dòng)化能力，許多復(fù)雜的指標(biāo)仍需回到數(shù)據(jù)倉(cāng)庫(kù)中由 ETL 工程師處理，因此第二代平臺(tái)仍然依賴于 IT 部門來開發(fā)復(fù)雜的寬表。

第三代指標(biāo)平臺(tái)的核心在于實(shí)現(xiàn)指標(biāo)的定義、開發(fā)和應(yīng)用的一體化，即所謂的“管研用一體化”。這種一體化的背后，是四大核心能力的支持。首先是指標(biāo)的規(guī)范定義能力，這不僅僅是對(duì)指標(biāo)進(jìn)行定義，還包括了指標(biāo)的治理。與以往在數(shù)據(jù)已經(jīng)開發(fā)完成后才進(jìn)行治理不同，第三代平臺(tái)希望通過事前的規(guī)范定義來避免問題的發(fā)生。由于指標(biāo)的語義已在平臺(tái)上得到了很好的沉淀，我們可以利用這些語義進(jìn)行同名同義的自動(dòng)校驗(yàn)，從而提高治理效率和準(zhǔn)確性。

總的來說，第三代指標(biāo)平臺(tái)通過強(qiáng)化語義化和自動(dòng)化，以及實(shí)現(xiàn)指標(biāo)管理的高度集成，為企業(yè)帶來了更高效和統(tǒng)一的指標(biāo)管理解決方案。就是比如說同樣的一個(gè)指標(biāo)，可能每個(gè)人首先看到的是名稱相同，我只允許它存在一個(gè)。其次，它的語義表達(dá)，即業(yè)務(wù)的口徑是一樣的，但原來可能有不同的名稱。例如在零售或電商領(lǐng)域，有的指標(biāo)叫 GMV，有的叫交易金額。實(shí)際上它們背后的邏輯是一樣的，我們的系統(tǒng)能夠自動(dòng)識(shí)別這一點(diǎn)，因?yàn)槲覀兪褂玫氖亲詣?dòng)翻譯的 SQL，我們知道它們的邏輯是相同的。因此，我們也會(huì)認(rèn)為它是一個(gè)同義不同名的指標(biāo)，并且只允許定義一次。

其次，指標(biāo)定義完成后，就可以立即使用。如果沒有性能問題，實(shí)際上因?yàn)槲覀兇鎯?chǔ)的是邏輯數(shù)據(jù)，不需要像傳統(tǒng)數(shù)倉(cāng)那樣進(jìn)行測(cè)試、發(fā)布或運(yùn)維調(diào)度任務(wù)等。通過界面化配置完成后，就可以直接使用。如果在過程中遇到性能問題，就可以使用我們之前提到的自動(dòng)化指標(biāo)生產(chǎn)，通過這種方式可以實(shí)現(xiàn)一級(jí)生產(chǎn)功能。

第三點(diǎn)是，指標(biāo)定義完成后，我們的系統(tǒng)會(huì)自動(dòng)生成一個(gè)以指標(biāo)為目錄的企業(yè)統(tǒng)一指標(biāo)體系。傳統(tǒng)上可能依靠工程師或分析師在自己的文檔中維護(hù)企業(yè)指標(biāo)體系，但對(duì)于企業(yè)來說，我們?cè)谂c客戶交流時(shí)會(huì)詢問企業(yè)有多少指標(biāo)，每個(gè)業(yè)務(wù)有多少指標(biāo)，這些指標(biāo)是如何構(gòu)成的。很少有企業(yè)能夠清楚地回答出來，因?yàn)樗麄兛赡軓奈幢P點(diǎn)過或者盤點(diǎn)的難度非常大。但有了這樣的一個(gè)指標(biāo)平臺(tái)，它會(huì)自動(dòng)生成一個(gè)指標(biāo)目錄，我們能清楚地看到企業(yè)里總共有多少指標(biāo)，每個(gè)指標(biāo)的業(yè)務(wù)邏輯是什么，每個(gè)指標(biāo)的血緣加工邏輯是什么，是基于我們數(shù)倉(cāng)的哪張表，通過哪個(gè)字段加工出來的。

此外，我們經(jīng)常會(huì)發(fā)現(xiàn)，可能在業(yè)務(wù)發(fā)展過程中，會(huì)存在指標(biāo)的口徑版本變更。原來的版本變更可能在數(shù)倉(cāng)中進(jìn)行了版本維護(hù)，也可能沒有。比如我之前在阿里做分析師時(shí)，我們會(huì)發(fā)現(xiàn)給業(yè)務(wù)看的數(shù)據(jù)下面都會(huì)有一個(gè)補(bǔ)充說明，比如什么時(shí)候我對(duì)這個(gè)口徑進(jìn)行了調(diào)整，因此調(diào)整前后數(shù)據(jù)可能會(huì)有變化。在我們的指標(biāo)目錄中，我們提供了指標(biāo)的多版本管理功能，這使我們能夠清楚地了解一個(gè)指標(biāo)在歷史上經(jīng)歷了多少次口徑的變更，并且可以明確每一個(gè)版本口徑的差異。如果需要回溯到之前的版本，我們也可以通過一鍵操作簡(jiǎn)單地回到歷史版本，這是指標(biāo)目錄中的一項(xiàng)重要功能。

此外，指標(biāo)目錄的另一個(gè)重要特點(diǎn)是能夠?qū)⑵髽I(yè)的業(yè)務(wù)知識(shí)通過產(chǎn)品化的方式沉淀下來。在當(dāng)前高員工流動(dòng)的環(huán)境中，很多企業(yè)面臨的一個(gè)問題是，員工離職后，之前在數(shù)據(jù)倉(cāng)庫(kù)中加工的邏輯信息交接不到位，新接手的員工往往需要投入大量工作量來理解和繼續(xù)之前的工作。通過 Aloudata CAN，原有的加工邏輯可以被完整地承接下來，即使發(fā)生人員變動(dòng)，也能快速對(duì)接上這些指標(biāo)的邏輯。

在指標(biāo)消費(fèi)方面，我們通過標(biāo)準(zhǔn)的 JDBC 和 API 接口，可以實(shí)現(xiàn)與企業(yè)現(xiàn)有的 BI 工具、業(yè)務(wù)系統(tǒng)以及管理駕駛艙的無縫對(duì)接。

通過這四大能力，我們希望為企業(yè)帶來以下效果：首先，業(yè)務(wù)人員能夠更加清晰地理解指標(biāo)的口徑和計(jì)算方式，因?yàn)橹笜?biāo)平臺(tái)使得加工鏈路可視化、變更歷史可查詢。其次，對(duì)于數(shù)據(jù)人員和管理人員而言，由于所有邏輯都是在項(xiàng)目初期通過嚴(yán)格的校驗(yàn)確定的，并且通過語義化的定義，我們可以實(shí)現(xiàn)一個(gè)指標(biāo)定義一次，大量派生指標(biāo)無需重復(fù)定義，從而實(shí)現(xiàn)高效管理。最后，對(duì)于業(yè)務(wù)人員來說，他們可以更靈活地使用指標(biāo)，從各個(gè)維度消費(fèi)和分析數(shù)據(jù)，甚至可以下鉆到背后的明細(xì)數(shù)據(jù)，并基于任意維度進(jìn)行篩選。這大大提高了業(yè)務(wù)人員的工作效率和滿意度。基于我們的語義模型能力，它也能實(shí)現(xiàn)跨多個(gè)事實(shí)表的多個(gè)指標(biāo)和來自多個(gè)維度表的多個(gè)維度的綜合分析，而無需通過技術(shù)同學(xué)將多個(gè)事實(shí)表進(jìn)行匯總開發(fā)。

我們將 Aloudata CAN 的價(jià)值從供給側(cè)（IT）和消費(fèi)側(cè)（業(yè)務(wù)）進(jìn)行了總結(jié)。對(duì) IT 的價(jià)值體現(xiàn)在能夠?qū)崿F(xiàn)應(yīng)用層 NoETL，大大減少了開發(fā)和運(yùn)維的工作量。這是因?yàn)?，傳統(tǒng)數(shù)倉(cāng)通常有四層結(jié)構(gòu)：從貼源層到公共層，再到 DWS 層，最后是集市層或應(yīng)用層?，F(xiàn)在，我們讓 IT 人員專注于公共層的資產(chǎn)開發(fā)，業(yè)務(wù)場(chǎng)景端的集市層可以通過我們的指標(biāo)語義層來替代，通過指標(biāo)的定義來取代集市層的開發(fā)。這樣不僅減少了大量的開發(fā)和運(yùn)維工作量，也減少了與業(yè)務(wù)溝通和協(xié)作的成本。

對(duì)業(yè)務(wù)側(cè)的價(jià)值體現(xiàn)，首先，我們提供了一種以指標(biāo)為中心的業(yè)務(wù)自主分析體驗(yàn)。傳統(tǒng)上，許多 BI 工具還是基于數(shù)據(jù)集、表和字段這種技術(shù)邏輯的方式?，F(xiàn)在，我們提供了一種用戶只需知道他們想要分析的指標(biāo)，這些指標(biāo)實(shí)際上更貼近他們的業(yè)務(wù)語言，因此他們可以直接拖拽指標(biāo)和維度進(jìn)行分析，只要有權(quán)限即可。正如我之前提到的，他們可以選擇來自不同事實(shí)表的指標(biāo)和來自不同維度表的維度，將它們放在一起進(jìn)行圖形化分析。

此外，我們還支持一種情況指標(biāo)標(biāo)簽化的靈活需求。例如，在電商或金融行業(yè)，我們可能會(huì)經(jīng)常舉辦一些活動(dòng)，在活動(dòng)期間，我們經(jīng)常會(huì)收到大量的臨時(shí)取數(shù)需求。這些臨時(shí)取數(shù)的需求主要是希望通過特定指標(biāo)將某些客戶群體標(biāo)簽化或維度化，以便在活動(dòng)期間圈選出特定的人群。具體來說，可以通過選擇滿足特定條件的用戶 ID，例如最近一個(gè)月交易次數(shù)超過三次的用戶，來查看他們?cè)诨顒?dòng)期間是否訪問了活動(dòng)頁(yè)面、領(lǐng)取了優(yōu)惠券或購(gòu)買了商品。Aloudata CAN 使業(yè)務(wù)部門能夠自主完成這些操作。

其次，關(guān)于指標(biāo)的智能歸因，雖然許多 BI 工具提供了歸因能力，但關(guān)鍵在于歸因算法所使用的數(shù)據(jù)是明細(xì)數(shù)據(jù)還是匯總數(shù)據(jù)。傳統(tǒng)模式下，歸因算法多數(shù)使用的是已經(jīng)聚合過的數(shù)據(jù)。而在我們的指標(biāo)平臺(tái)上，建議的最佳實(shí)踐是基于公共層的明細(xì)數(shù)據(jù)來定義指標(biāo)，這樣可以進(jìn)行更深入的維度拆解，實(shí)現(xiàn)從廣度到深度的歸因分析。

最后，關(guān)于大模型的應(yīng)用。OpenAI 等機(jī)構(gòu)已經(jīng)提出，直接使用自然語言處理（NL to SQL）可能難以保證百分之百的精準(zhǔn)度。許多企業(yè)的 AI 團(tuán)隊(duì)也發(fā)現(xiàn)，盡管進(jìn)行了多次調(diào)優(yōu)，應(yīng)用場(chǎng)景仍然有限，覆蓋的場(chǎng)景不夠廣泛，或精準(zhǔn)度不足。因此，背后需要一個(gè)強(qiáng)大的語義模型來支撐大模型，確保數(shù)據(jù)質(zhì)量和業(yè)務(wù)知識(shí)的有效沉淀，這對(duì)于提高大模型的應(yīng)用效果至關(guān)重要。

我們發(fā)現(xiàn)，指標(biāo)與數(shù)據(jù)模型的結(jié)合，在許多企業(yè)內(nèi)被認(rèn)為是打造交互式對(duì)話分析體驗(yàn)的最佳途徑。我們也正與不同行業(yè)的客戶共同創(chuàng)造這樣的體驗(yàn)。當(dāng)然，目前我們尚未推出 ChatBI 的產(chǎn)品，我們正在與一些頂尖的金融客戶合作，他們擁有自己的數(shù)據(jù)模型，我們的任務(wù)是將這些底層能力與他們的模型能力相結(jié)合。我們也在考慮，下半年將朝這個(gè)方向進(jìn)一步發(fā)展。

做個(gè)總結(jié)：第三代指標(biāo)平臺(tái)給我們 IT 部門帶來的體驗(yàn)改變，表現(xiàn)在大幅減少指標(biāo)重復(fù)開發(fā)的工作量和運(yùn)維變更的工作量。對(duì)業(yè)務(wù)部門來說，它提供了真正處理“最后一公里”自主分析問題的體驗(yàn)，讓業(yè)務(wù)人員能夠自助完成分析工作，而不需要為增加字段或維度而頻繁聯(lián)系 IT 部門。

三、第三代指標(biāo)平臺(tái)做輕數(shù)倉(cāng)實(shí)踐

以上內(nèi)容是關(guān)于技術(shù)與產(chǎn)品的一些介紹。接下來，我們分享在一些企業(yè)中真實(shí)落地的實(shí)踐情況。由于我們團(tuán)隊(duì)來自阿里巴巴和螞蟻集團(tuán)，對(duì)電商和金融領(lǐng)域有深入了解，因此，我將舉例介紹金融行業(yè)的兩個(gè)案例，涵蓋證券和銀行業(yè)務(wù)。

首先是來自證券行業(yè)的一個(gè)客戶案例。先來了解一下這家公司的 IT 團(tuán)隊(duì)。他們沒有復(fù)雜的專職分析崗位，僅有一個(gè)技術(shù)部，而負(fù)責(zé)數(shù)據(jù)的技術(shù)人員人數(shù)也非常有限。

在與我們合作前，他們面臨三個(gè)主要的痛點(diǎn)。首先，為了滿足業(yè)務(wù)需求，這些 IT 人員需要開發(fā)和維護(hù)大量的數(shù)據(jù)表，ETL 的運(yùn)維工作量巨大，尤其在他們?nèi)耸址浅Ｓ邢薜那闆r下。

另外一個(gè)痛點(diǎn)是，證券行業(yè)的專業(yè)知識(shí)要求高，理解業(yè)務(wù)邏輯背后的細(xì)節(jié)極其困難。這常常導(dǎo)致 IT 人員與業(yè)務(wù)部門之間溝通不暢。即使 IT 部門開發(fā)了數(shù)據(jù)表，業(yè)務(wù)部門在驗(yàn)證時(shí)仍可能提出與 IT 理解不一致的需求，這樣就需要重復(fù)調(diào)整指標(biāo)口徑，極大增加了工作量和溝通成本。這家公司希望能將指標(biāo)定義的工作交由業(yè)務(wù)人員自行完成，以此減少重復(fù)溝通的時(shí)間和精力損耗。這是他們的第二個(gè)痛點(diǎn)。

第三個(gè)痛點(diǎn)就是數(shù)據(jù)響應(yīng)效率的問題?，F(xiàn)在所有企業(yè)都越來越依賴數(shù)據(jù)進(jìn)行業(yè)務(wù)決策，而這家客戶的數(shù)據(jù)團(tuán)隊(duì)人手非常有限，快速響應(yīng)業(yè)務(wù)需求的挑戰(zhàn)非常大。

在我們提供的解決方案中，企業(yè)只需處理公共層面上的明細(xì)資產(chǎn)沉淀，并圍繞行業(yè)十大模型進(jìn)行資產(chǎn)沉淀。

于是，它實(shí)際上重新定義了指標(biāo)開發(fā)的方式：從過去需要開發(fā)大量應(yīng)用層的表，到現(xiàn)在簡(jiǎn)化為在公共層利用指標(biāo)平臺(tái)就可以輕松地實(shí)現(xiàn)。舉例來說，在該企業(yè)的資管業(yè)務(wù)線上，我們將指標(biāo)分為原子指標(biāo)、派生指標(biāo)和復(fù)合指標(biāo)三種。資管業(yè)務(wù)作為證券行業(yè)的核心業(yè)務(wù)之一，業(yè)務(wù)人員便能夠利用原子指標(biāo)和維度自主組合出所需的派生指標(biāo)。

這個(gè)企業(yè)，盡管人力資源有限，卻成功地提供了一種以指標(biāo)為中心的自主分析體驗(yàn)。業(yè)務(wù)人員可以使用簡(jiǎn)單直觀的方式，靈活地進(jìn)行分析。他們的 IT 團(tuán)隊(duì)僅開發(fā)了約 80 個(gè)基礎(chǔ)和復(fù)合指標(biāo)，但有超過 300 個(gè)可供業(yè)務(wù)人員自由組合的維度。

這樣的做法，使得在指標(biāo)開發(fā)上節(jié)省了大約 70% 的工作量?？蛻粼u(píng)估稱，一個(gè)工程師原本一天只能開發(fā)約 3.12 個(gè)指標(biāo)，但采用我們的產(chǎn)品后，他們半天就能處理超過 20 個(gè)基礎(chǔ)指標(biāo)，大幅提高了開發(fā)效率。此外，產(chǎn)品的配置化界面，還降低了操作復(fù)雜 SQL 的門檻，讓應(yīng)屆生和實(shí)習(xí)生也能輕松定義指標(biāo)。

第二個(gè)案例是銀行業(yè)的，這個(gè)合作中，客戶面臨三個(gè)主要問題：首先是 BI 工具的性能問題，查詢 3s 打開率不到 70%，這是因?yàn)閿?shù)據(jù)倉(cāng)庫(kù)的性能與靈活性之間需要平衡；其次，業(yè)務(wù)分析過程中，業(yè)務(wù)部門在查看數(shù)據(jù)后常有新的需求，需要 IT 部門準(zhǔn)備數(shù)據(jù)，導(dǎo)致數(shù)據(jù)分析難以打通“最后一公里”的問題；第三，總行和分行選擇了不同的 BI 工具，導(dǎo)致無法共享和復(fù)用數(shù)據(jù)。

這家銀行擁有數(shù)百到上千人的 IT 團(tuán)隊(duì)，他們選擇自建交互層面，僅在指標(biāo)語義層使用了我們的服務(wù)。通過我們提供的 API 接口，客戶能夠自助地從數(shù)據(jù)準(zhǔn)備到分析，實(shí)現(xiàn)一體化操作，顯著提升了交付效率。此外，從只能進(jìn)行客群級(jí)別的分析提升到了客戶級(jí)別的分析，并且實(shí)現(xiàn)了總行和分行使用不同 BI 工具間的指標(biāo)復(fù)用。

去年一期的合作成果包括：原本所有數(shù)據(jù)集都需要科技部 IT 團(tuán)隊(duì)處理，現(xiàn)在 65% 的工作可以由業(yè)務(wù)部門自主完成；原本在多個(gè) BI 工具中沉淀的指標(biāo)下沉到我們的指標(biāo)平臺(tái)實(shí)現(xiàn)了共享和復(fù)用；通過我們的自動(dòng)化能力，實(shí)現(xiàn)了 95% 的查詢?cè)谌雰?nèi)完成。這是一期的成果，今年我們也在繼續(xù)進(jìn)行第二期的工作。

在這個(gè)過程中，我們發(fā)現(xiàn)它改變了企業(yè)內(nèi)部業(yè)務(wù)的協(xié)作模式，特別是 IT 人員和業(yè)務(wù)人員之間的協(xié)作。他們自己總結(jié)出了一種叫做“136”的協(xié)作模式。“136”指的是的科技人員負(fù)責(zé)語義模型關(guān)聯(lián)關(guān)系的建立，以及整個(gè)企業(yè)的通用基礎(chǔ)指標(biāo)和原子指標(biāo)的加工與定義，這部分指標(biāo)占比 10%。其余的部分，許多業(yè)務(wù)部門都有自己的業(yè)務(wù)分析師，這些分析師圍繞業(yè)務(wù)條件定義通用的派生指標(biāo)，這部分占比 30%。最后，60% 的靈活需求則交給業(yè)務(wù)人員自己，讓他們像搭積木一樣選擇指標(biāo)和維度，以滿足自己的需求。這就是“136”協(xié)作模式的核心內(nèi)容。

四、Q&A

Q1：關(guān)于指標(biāo)中心，實(shí)際上有很多應(yīng)用場(chǎng)景，比如用戶需要提取一些清單數(shù)據(jù)。這種數(shù)據(jù)提取可以實(shí)現(xiàn)嗎？

A1：是的，這里面主要分為兩部分。第一部分是提取臨時(shí)數(shù)據(jù)，這種數(shù)據(jù)通常是基于公共層的明細(xì)數(shù)據(jù)定義的，比如提取用戶交易的明細(xì)數(shù)據(jù)，這種是常用的指標(biāo)，如交易金額，我們的平臺(tái)可以實(shí)現(xiàn)。第二部分是創(chuàng)新業(yè)務(wù)的指標(biāo)，這種指標(biāo)可能沒有固定下來。對(duì)于這類指標(biāo)，我們不建議在指標(biāo)平臺(tái)上處理，因?yàn)槲覀冋J(rèn)為一個(gè)指標(biāo)應(yīng)該具有一定的通用性、適用性和持續(xù)性才適合進(jìn)入指標(biāo)平臺(tái)。但是，我們發(fā)現(xiàn)很多企業(yè)的臨時(shí)數(shù)據(jù)或指標(biāo)實(shí)際上是可以通過在平臺(tái)上疊加各種篩選條件來解決的。

Q2：您好，我想詢問一下，大多數(shù)企業(yè)可能已經(jīng)擁有數(shù)據(jù)倉(cāng)庫(kù)，并且已經(jīng)建立了很多寬表，甚至已經(jīng)部署了自己的指標(biāo)系統(tǒng)，并擁有很多指標(biāo)。當(dāng)它們切換到您的系統(tǒng)時(shí)，如果在您的系統(tǒng)中定義了原子指標(biāo)，它們還需要定義一些限定詞，并配合定義復(fù)合指標(biāo)。這些內(nèi)容如何與我原有的寬表和指標(biāo)系統(tǒng)綁定，以形成物理表上的關(guān)系？

A2：對(duì)，這確實(shí)是我們?cè)谂c許多企業(yè)交流時(shí)經(jīng)常遇到的問題。首先，我們已經(jīng)落地的一些客戶，他們?cè)緭碛凶约旱闹笜?biāo)平臺(tái)，但那個(gè)平臺(tái)僅用于指標(biāo)口徑的登記，不能實(shí)現(xiàn)指標(biāo)的實(shí)際開發(fā)。在這種情況下，我們可以通過 API 接口，讓他們?cè)谠衅脚_(tái)上錄入指標(biāo)的業(yè)務(wù)邏輯，而實(shí)際的計(jì)算口徑則在我們的平臺(tái)上進(jìn)行開發(fā)。

其次，確實(shí)許多企業(yè)已經(jīng)有了大量的寬表和匯總表。我們不要求客戶放棄使用這些現(xiàn)有的表。您可以將寬表和匯總表接入到我們的指標(biāo)平臺(tái)，但這樣做無法實(shí)現(xiàn)指標(biāo)的靈活應(yīng)用。

因此，我們通常建議企業(yè)在實(shí)施過程中采取逐步策略。例如，您可以從那些經(jīng)常提出需求、痛點(diǎn)較為突出的業(yè)務(wù)線開始，先不動(dòng)原有的寬表和匯總表，而是逐步進(jìn)行優(yōu)化。比如我們最近與一家大型股份制銀行合作，他們的第二期項(xiàng)目名為“虛擬集市層”，他們計(jì)劃逐步優(yōu)化原有數(shù)據(jù)倉(cāng)庫(kù)中的內(nèi)容。我們建議從業(yè)務(wù)條件通暢、需求較多的部分開始，慢慢過渡到這種模式，因?yàn)檫@是一個(gè)漸進(jìn)的過程。