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

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

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

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

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

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

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

那到底有沒有可能破解這個不可能的三角呢？其實從整個 MECE 原則來拆分，我們剛剛講到導(dǎo)致不可能三角的原罪是因為做了大量的反范式 ETL 開發(fā)寬表和匯總表的作業(yè)。那我們是不是可以不去加工寬表匯總表，這樣就把這個問題的源頭解決掉了？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

三、第三代指標(biāo)平臺做輕數(shù)倉實踐

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

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

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

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

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

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

于是，它實際上重新定義了指標(biāo)開發(fā)的方式：從過去需要開發(fā)大量應(yīng)用層的表，到現(xiàn)在簡化為在公共層利用指標(biāo)平臺就可以輕松地實現(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)。

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

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

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

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

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

在這個過程中，我們發(fā)現(xiàn)它改變了企業(yè)內(nèi)部業(yè)務(wù)的協(xié)作模式，特別是 IT 人員和業(yè)務(wù)人員之間的協(xié)作。他們自己總結(jié)出了一種叫做“136”的協(xié)作模式?！?36”指的是的科技人員負責(zé)語義模型關(guān)聯(lián)關(guān)系的建立，以及整個企業(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)中心，實際上有很多應(yīng)用場景，比如用戶需要提取一些清單數(shù)據(jù)。這種數(shù)據(jù)提取可以實現(xiàn)嗎？

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

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

A2：對，這確實是我們在與許多企業(yè)交流時經(jīng)常遇到的問題。首先，我們已經(jīng)落地的一些客戶，他們原本擁有自己的指標(biāo)平臺，但那個平臺僅用于指標(biāo)口徑的登記，不能實現(xiàn)指標(biāo)的實際開發(fā)。在這種情況下，我們可以通過 API 接口，讓他們在原有平臺上錄入指標(biāo)的業(yè)務(wù)邏輯，而實際的計算口徑則在我們的平臺上進行開發(fā)。

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

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