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

1. 應對數智化分析需求，反范式 ETL 加工不堪重負

數字化轉型多年，現在很多業務人員都依賴數據來做日常決策。傳統的方式是業務提需求給 IT，IT 會根據每個特定需求開發定制化的寬表和匯總表，再做成 BI 工具里的報表。在這個過程中，會有很多反范式的 ETL 加工，使得整個數倉的數據管道越來越長、越來越深，企業數據治理的難度也越來越大。

2. ETL 工程陷入“效率、質量、成本”的不可能三角

反范式的加工給企業帶來高成本、低質量、低效率的問題。

• 高成本：IT 接到不同業務部門不同業務人員提出的需求，為了快速響應業務的需求，直接開發數據集市層表，結果導致不同 IT 之間存在大量重復的寬表和匯總表建設，占用大量存儲計算資源的消耗，帶來高成本。
• 低效率：在原來傳統的反范式 ETL 加工過程中，業務一開始提的需求是模糊化的，因為業務沒有看到數據，也想不清楚。IT 開發完交付給業務的時候，業務發現開發的需求跟原本設想的不一樣，于是就有了再改一個口徑、再加一個字段等類似的需求。整個過程存在反復溝通，IT 需要排期，業務需要等待，所以，ETL 成了數字化分析過程中一個核心的瓶頸。
• 低質量：大量重復的寬表和匯總表開發會導致同一個指標分散在不同的報表里，進而可能出現不同報表里數據對不上的問題。比如，各個業務部門去向公司領導匯報的時候，每一個部門的績效都完成得特別好，但是公司整體的績效并不是那么好。真的是各個業務部門業績完成得好，公司層面出了問題嗎？可想而知，情況肯定不是這樣的，應該是各業務部門的數據口徑不一致，最后出現了在公司總體層面數據對不上的情況。

3. 如何將“效率、質量、成本”不可能的三角變為可能？

有沒有什么辦法能解決“效率、質量、成本”不可能三角的問題呢？整體來說，有兩種思路：

第一個思路是不開發寬表匯總表。既然“不可能三角”的原罪在于人工的大量的反范式加工，那能不能不進行這樣的加工呢？早期，數據量較小，這個模式是可行的，直接開發公共層的明細表提供給業務去消費，可以大幅減少不可能三角。然而在大數據量的情況下，不做寬表和匯總表的開發很難保證性能，因此這條路行不通。

第二個思路是將人工 ETL 方式變成 NoETL。原來“不可能三角”是人工做開發，那么能不能將人工的方式變成自動化的方式？這條路是可行的。

二、如何實現數倉應用層 NoETL

1. 應用層 NoETL 自動化的前提是指標語義的標準化沉淀

把人工變成自動化的前提是讓機器和系統理解業務需要的指標的業務邏輯，即實現應用層 NoETL 自動化的前提是指標語義的標準化沉淀，也就是需要將業務指標體系以及指標的計算邏輯告訴系統。

從上圖中可以看到，原來數倉是從貼源層到公共層再到集市層的開發，現在將集市層用指標語義層代替。這樣，原來需要在集市層做大量的反范式的開發，現在只需要將業務的指標以及指標的計算邏輯通過配置化方式告訴系統即可，不需要做物理鏈路的開發實現。所以，要有指標語義標準化沉淀的過程。

2. 如何做到指標語義標準化沉淀

基于標準化語義，自動化生成反范式的寬表與匯總表。

• 首先，需要有星型模型、雪花模型等強大的模型能力。原來，在數倉里需要將維度表里的維度打寬到事實表里面生成新的寬表，或者是基于某些維度做輕粒度或重粒度的匯總加工?，F在，只需要建立明細事實表和維度表之間的邏輯關聯關系，無需物理打寬，保持模型的靈活性，支持靈活的跨表指標定義和靈活的維度下鉆分析。
• 需要標準化指標定義的能力，能夠把指標的計算邏輯通過標準化的方式定義出來。

有了指標標準化定義的能力和模型能力，反范式的寬表和匯總表的加工就可以實現系統自動了。系統可以自動將一個事實表和多個維度表的維度組合在一起，也可以實現多個事實表背后的不同指標和多個維度一起分析。業務人員不用關心多個指標到底來自于哪一張物理表，屏蔽了底層的技術概念，用戶感受到的是指標和維度這樣偏業務語言的概念。

原來傳統的方式為什么做不到呢？要實現指標定義能力承載在指標平臺上，要求平臺具備強大的指標語義表達能力。如果平臺沒有很強大的語義表達能力，就需要在數倉或者BI 工具里寫 SQL 開發來定義指標的計算邏輯。

怎么保證所有的指標定義都在平臺上承載。

指標定義可分成四大類：

• 窗口計算函數，如證券行業中看資金凈買入額在行業中的排名。
• 多層聚合嵌套，不是簡單的一次聚合。比如，在求平均的基礎之上，再去看最大值或者最小值。求近一年、月、日均 AUM 的最大值，需要進行三次聚合，第一次算出每一天 AUM，第二次算出一個月 AUM 的均值，第三次基于每個月的均值算出一年十二個月中月均/日均的最大值。類似這種多層聚合的嵌套，一千個人有一千種寫法，系統很難判斷如何表達，可以通過配置化的方式實現標準化模板化。
• 行間計算，比如近三十天的銷售量。
• 模型計算，跨多個事實表和維表之間的計算。在活動中經常遇到的場景，是先把指標變成一個標簽或者變成一個維度，再計算特定客群的表現。比如，近三十天領取消費券客戶的購買金額。

除此之外，還有常規聚合類和日期函數等，通過將函數抽象封裝成配置化的模板來支持復雜的指標計算，讓技術能力不是很強的業務分析師或者業務人員無需寫 SQL 也可以自助定義指標。原來面向業務場景的大量的反范式的寬表和匯總表一定需要 IT 開發，現在業務人員能夠自主做數據準備，不需要有很強的技術能力。

指標定義轉計算節點，支持復雜指標自動轉成一個節點。

上圖中展示了指標鏈路：先定義原子指標“銷售額”，然后在原子指標的基礎上定義派生指標“近 7 日銷售額”，又在派生指標的基礎上定義衍生指標“銷售額占比”，在衍生指標的基礎上定義復合指標“銷售額占比去年同期的增長率”。整個指標定義鏈路很復雜，涉及從原子到派生到衍生到復合再到衍生的過程，通過語義層，可以將這個鏈路變成相對 SQL 來說非常簡單的函數。

3. 指標語義+最佳數據工程實踐，實現自動化指標生產

分成三個策略：

• 自動化數據編排。多個指標和多個維度放在一起分析，比如查看不同日期、不同品類的下單量和退款量，下單量和退款量可能來自于兩個不同的事實表。自動化指標生產的時候會基于物理表的拆分邏輯，對不同的事實表進行拆分，保證數據產出的時效不受影響，同時不造成數據膨脹。自動化數據編排優化還遵循了數倉中的最佳的數據工程實踐：冗余維度屬性打寬；長周期依賴短周期；粗粒度依賴細粒度。
• 自動化代碼生成。數據編排后，系統根據指標語義自動生成優化后的最佳 SQL 供計算引擎執行。
• 自動化變更回刷。上游的數據發生變更怎么去做自動的分析和回刷呢？首先，自動化感知上游的變更有兩種方式，第一種是通過任務的 DAG 圖自動獲取上游的信息，實時進行數據回刷；第二種是通過定時任務的配置進行定期刷新。一旦上游數據發生了變更，系統會自動識別變更點及回刷范圍，自動化進行變更回刷，以保證數據的準確性。

4. 自動化指標生產的核心能力

自動化指標生產的核心能力分為兩層。

• 計算引擎層：通過內置 MPP 計算引擎或者利用企業自有的 MPP 引擎，所有的 SQL 查詢都在查詢引擎中進行，目前支持 StarRocks、Doris 等 MPP 查詢引擎。
• 物化加速層：MPP 查詢引擎之上是物化視圖的構建策略和命中策略，類似物化加速策略大腦。支持通過人工物化或者智能物化兩種策略，實現物化視圖的構建，和指定指標與維度的物化加速。同時，基于用戶查詢行為，系統自動進行查詢改寫，通知 MPP 層的查詢引擎直接查明細數據還是物化表，保證大數據量場景下的查詢性能。

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

1. 第三代指標平臺的能力

總結來說，應用層 NoETL 的核心是語義化和自動化兩個能力。通過語義化提供任意復雜指標的配置化定義，通過自動化實現指標的定義即開發。如果沒有性能問題，只要完成了語義化的定義，用戶就可以直接消費數據了，這個過程叫做定義及服務。如果數據量比較大，系統會自動化進行寬表匯總表加工，來保證查詢性能，這就是第三代指標平臺，將原來 ETL 人工開發變成了 NoETL 的自動化開發。

2. 第三代指標平臺的價值

Aloudata（大應科技）公司推出的第三代指標平臺產品名為 Aloudata CAN，實現了 NoETL 的自動化生產。

指標從定義到開發到應用是一體化的，保證業務人員能夠看懂。原來業務人員做分析的時候，面對的是數據集、物理表、字段這種偏技術的概念，現在面對的是指標和維度這些偏業務的概念，更容易理解。除了指標的業務含義外，還提供指標血緣，讓業務能夠清晰地了解指標的加工過程和口徑。同時，如果指標口徑發生了變更，平臺會保存所有的指標版本，可以進行歷史口徑版本的對比。

對于承擔數據管理職責的 IT 團隊來講，能夠實現管得住。原來大量的指標邏輯是在數倉中由不同 IT 人員開發實現的，溝通協調比較復雜，需要花費很大的成本才能保證指標口徑的一致性?，F在，針對同樣的指標進行不同維度的分析，只需要一次定義，就可以處處使用了。

同時，指標是基于公共層的明細數據生成的，保留了原來在公共層事實表和維度表的靈活性與豐富度，同一個指標能夠支持多個維度下鉆分析和任意維度的篩選組合，提供良好的用戶體驗。

第三代指標平臺 Aloudata CAN 為業務帶來的價值可以總結為兩方面：

（1）基于 Aloudata CAN 實現數倉集市層 NoETL

指標語義層替換傳統數倉中的集市層，通過指標語義層實現自動化集市層開發。

在質量方面做到百分之百的指標口徑一致。因為所有指標語義都是通過標準化、配置化的模板實現的，通過原子化指標的組裝，系統能夠提供指標重復校驗，方便知道指標的計算邏輯是否一樣，規避了“同名不同義”、“同義不同名”等二義性問題。

在效率方面也得到了提升。原來指標的開發依賴于 IT 人員，一體化后，將指標的開發和定義能力交給業務人員去做，降低了 IT 與業務的溝通成本，提高了效率。

在成本方面做到了節約。原來反范式的加工方式導致大量重復的寬表和匯總表開發，現在指標語義層通過自動化的方式可以規避重復開發。比如原來集市層做了一百張寬表和匯總表，可能因為重復開發，實際上只需要開發八十張表；八十張表里面，六十張表可以直接查詢無需物化，二十張表因為數據量比較大，系統可以自動化開發寬表和匯總表；又因為一開始 ETL 的時候不清楚業務想要什么，為避免因漏掉業務常用的維度而反復變更，會把冗余的維度放在事實表里面，造成字段利用率低?，F在系統按需進行開發，在相同的二十張寬表和匯總表里面可以減少冗余字段的開發，大大節約計算和存儲成本。

（2）Aloudata CAN，提供智能且靈活的洞察分析

上述是從“不可能三角”的視角來看價值，更偏向于管理層和 IT 方面。業務人員能感知到的則是分析的靈活性和指標數據的一致性。

原來做指標歸因依賴數倉已經開發的表，會有維度的缺失?；?Aloudata CAN 指標平臺，只要是在公共層的維度表存在的維度，都可以用來做指標歸因和下鉆分析，使得業務人員能夠找到指標波動背后的根本原因。

原來做自助探索分析的時候，希望增加一個視角來看數據，需要向 IT 提需求。現在通過 Aloudata CAN 指標平臺，可以從任意的顆粒度和維度進行分析，甚至可以拿到背后的明細數據。

目前，有很多金融行業的頭部客戶都在嘗試用大模型打造新的對話式的體驗。原來通過 NL2SQL 的方式返回數據，存在數據精準度不夠的問題，會有答非所問的情況出現。現在，基于 Aloudata CAN 指標平臺，通過指標語義層加大模型能為企業對話式分析帶來更為精準的體驗。

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

助力某證券公司實現指標統一管理與復用。

該客戶面臨的挑戰是：

• 指標口徑不一致。原來，為了響應不同的業務需求，相同的指標有不同的開發鏈路，導致了指標口徑的不一致。
• 排查耗時。因為缺少指標加工鏈路和指標血緣，排查和定位指標口徑工作量會特別大，耗費大量的時間。
• 對業務來講，靈活性不夠，缺少分析所需要的各種維度。

通過 Aloudata CAN 指標能夠解決這些問題。

• 指標規范管理，同一個指標只需要定義一次。
• 由業務人員定義派生指標。IT 只需要進行公共層事實表和維度表的數據模型開發，并進行最小顆粒度的原子指標定義。業務人員可以根據自己想要的各種場景，基于指標和維度自助地組裝出自己想要的派生指標，減少了很多 IT 的開發工作。

在傳統方式中，業務向 IT 提了三十個指標和二十個維度的分析需求，IT 在溝通過程中發現其中的五個指標和五個維度已經開發，只需要開發二十五個指標和十五個維度。IT 完成開發后，交給業務人員驗收，業務人員發現指標和維度可能少了，需要反復溝通，一般這個過程至少要循環往復兩到三輪。這樣的模式下，從需求提出到交付驗收需要兩周的周期。

通過 Aloudata CAN 指標平臺不斷地沉淀已經定義好的指標和維度，IT 就能越做越輕。同樣面對業務提出的三十個指標和二十個維度的分析需求，發現二十五個基礎指標已經定義，而且基于基礎指標的維度都已存在，就可以請業務通過拖拉拽進行自助分析了。針對原來沒有進行基礎指標定義的五個指標，雙方要溝通指標口徑定義，因為是原子指標，業務邏輯并不復雜，所以溝通過程也會很簡單。而且，IT 定義完指標后，業務可以實時進行指標預覽，業務人員能快速看到指標是否符合預期，并且可以切換不同的維度去看，如果符合預期，業務就可以驗收并進行數據分析了。

傳統的數倉基于反范式模式的開發，IT 越做越重，因為表越來越多，鏈路的依賴越來越長，問題排查也越來越難?；谥笜苏Z義層，數倉可以越做越輕，一旦做好原子指標的沉淀，就會越做越少，越做越輕松。分析效率有顯著的提升，從原來的兩周縮短到了兩天。

對于整個行業來說，可以提升創新試錯的效率。原來一輪試錯可能要一個月，現在可能僅用一周即可完成。