各位嘉賓、朋友們，下午好。今天上午，我們公司的 CEO 已經在主會場的第一場分享了關于我們公司的情況。可能大家對 Aloudata 還不太熟悉，我們是一家成立不久的初創公司。之前我們的團隊成員在阿里螞蟻工作了一二十年，深知數據領域尤其是供給側在服務業務時存在許多痛點。因此，我們希望通過一些新技術來幫助大家解決日常工作中的問題。

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

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

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

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

此外，如果需要避免重復開發，需要不同業務線的 ETL 工程師彼此溝通，是不是我們數倉里面已經沉淀了這么一張表，是不是已經開發好了這個字段。這種協同溝通的成本會很高，時間可能會很長。所以，在這種情況下，為了保證效率，可能就會存在數據的大量重復開發，會存在口徑的差異。可能不同的業務提的需求是同一個指標，但拿到的結果是不同的。

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

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

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

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

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

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

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

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

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

第一個核心能力是讓系統知道指標的計算邏輯是什么，這背后需要我們提供一個標準的指標定義能力。

我們在做指標定義時經常需要跨表定義指標。如果說數倉不做寬表的加工了，那我們怎么能夠實現跨表的指標定義？我們的解法是構建一個語義模型，再在這樣的一個語義模型基礎之上，把指標拆解成一些最原子的要素，比如說原子指標、時間限定、業務限定、衍生方式等。有了這個拆解之后，實際上我們給到業務的體驗是一些語義化、配置化的模板，不需要去寫 SQL 了。

如果不需要去寫 SQL，但系統查的是一個 SQL，怎么能夠實現這種復雜的表達呢？這背后實際上是依賴于第二點核心能力——一個強大的指標函數體系。

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

第三點核心能力是自動構建多層次、多聚合的任務 DAG（有向無環圖）。例如，在構建指標的第一階段，系統會先計算每個門店的銷售量；第二階段，根據銷售量進行排名；第三階段，得出排名結果。基于這種方式，無論指標多復雜，都可以通過多層次、多聚合的方式構建 DAG。

接著，系統會根據用戶配置的多層次、多聚合要求，自動將這些配置轉化為 SQL 語句，這是第四大能力。

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

第六點核心能力是自建內存計算引擎提升查詢效率。這個計算引擎是專門針對指標場景開發的，包括指標分析器、RBO 和 CBO 的拆分、DAG 構建、任務管理、算子級別執行器、緩存等。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

查詢如果命中多個物化視圖，Aloudata CAN 會選擇一個最優的。這個最優選擇基于幾個原則：數據量是否最小，指標是否與業務需求最匹配，以及時間范圍是否最接近。

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

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

二、第三代指標平臺的能力與價值

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

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

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

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

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

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

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

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

在指標消費方面，我們通過標準的 JDBC 和 API 接口，可以實現與企業現有的 BI 工具、業務系統以及管理駕駛艙的無縫對接。

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

我們將 Aloudata CAN 的價值從供給側（IT）和消費側（業務）進行了總結。對 IT 的價值體現在能夠實現應用層 NoETL，大大減少了開發和運維的工作量。這是因為，傳統數倉通常有四層結構：從貼源層到公共層，再到 DWS 層，最后是集市層或應用層。現在，我們讓 IT 人員專注于公共層的資產開發，業務場景端的集市層可以通過我們的指標語義層來替代，通過指標的定義來取代集市層的開發。這樣不僅減少了大量的開發和運維工作量，也減少了與業務溝通和協作的成本。

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

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

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

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

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

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

三、第三代指標平臺做輕數倉實踐

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

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

在與我們合作前，他們面臨三個主要的痛點。首先，為了滿足業務需求，這些 IT 人員需要開發和維護大量的數據表，ETL 的運維工作量巨大，尤其在他們人手非常有限的情況下。

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

第三個痛點就是數據響應效率的問題。現在所有企業都越來越依賴數據進行業務決策，而這家客戶的數據團隊人手非常有限，快速響應業務需求的挑戰非常大。

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

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

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

這樣的做法，使得在指標開發上節省了大約 70% 的工作量。客戶評估稱，一個工程師原本一天只能開發約 3.12 個指標，但采用我們的產品后，他們半天就能處理超過 20 個基礎指標，大幅提高了開發效率。此外，產品的配置化界面，還降低了操作復雜 SQL 的門檻，讓應屆生和實習生也能輕松定義指標。

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

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

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

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

四、Q&A

Q1：關于指標中心，實際上有很多應用場景，比如用戶需要提取一些清單數據。這種數據提取可以實現嗎？

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

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

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

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

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