本次分享人為螞蟻集團的王高航老師，分享題目為螞蟻指標系統的設計與實踐，王高航老師自 2016 年加入螞蟻集團以來，一直在數據中臺領域深耕。在此期間，參與了螞蟻新老兩代數據平臺的研發并主導了多個核心子產品。目前，王高航老師負責螞蟻數據中臺的數據架構與治理、數據建模、資產管理、安全合規等產品的研發。

一、指標系統的問題定義

1、什么是指標系統

首先需要明確什么是指標。從統計學角度看，指標是綜合體現總體數量特征的概念和數值。在數據倉庫體系中，指標是其核心產物，它是信息層面的一種載體。從 DIKW 模型的角度分析，指標必須滿足一些基本要求，包括準確性、完整性、及時性和一致性。

另一方面，系統是由若干相互作用、相互依賴的組成部分構成的，具有特定功能的有機整體。這里的核心概念是“有機”，因為指標并不是一個孤立的技術，而是與人有著非常緊密的互動，構成了一個有機的整體。

指標系統包括三個層次：

• 首先，概念層，它是公司核心概念的載體，如交易額和日活用戶等，雖然高度抽象，但對于整個系統來說至關重要。
• 在確立了概念之后，為了確保其權威性和持續性，需要建立一套與之配套的流程機制，這是第二層。這一層的作用是確保概念能夠得到有效地實施和推廣，為公司的業務發展提供有力的支撐。
• 最后，第三層是產品化的載體，通常是一個內容型產品，如指標平臺或指標中臺。第三層雖然重要，但在實踐中發現，許多平臺過于強調這一層，而忽略了上面兩層的重要性。實際上，對于指標中臺或指標系統來說，最重要的是上面兩層，尤其是第一層。如果沒有前兩層的基礎，僅靠產品化載體是很難實現其持續發揮效果的。

2、指標系統的常見問題

（1）在概念層面

我們面臨的主要是二義性的問題。具體來說，是同名不同義、同義不同名、或者指標間值沖突的情況。為了解決這些問題，需要對各個領域的概念達成共識。

（2）在流程機制層面

需要關注的是如何確保指標的持續保鮮和有效迭代。盡管在短期內研發一批指標相對容易，但長期保持這些指標的活力和有效性卻非常有挑戰性。為了解決這一問題，我們需要從機制和流程的角度出發，建立相應的保障措施，以確保指標的持續優化和更新。

（3）在產品層面

主要解決的是效率問題。這包括指標定義、研發運維以及進一步下鉆分析的效率。為了提升效率，我們需要對相關結構進行優化，并借助人工智能技術進行輔助，提高指標工具和平臺的使用效果，降低不必要的成本和時間消耗。

綜上，我們需要在概念、流程機制和產品三個層面上分別解決二義性、持續保鮮和效率問題。通過共識領域概念、設計流程機制、核心結構優化及人工智能輔助等手段，更好地應對這些挑戰，提升指標系統的有效性和應用價值。

二、指標系統設計

1、如何進行概念共識

接下來介紹如何構建指標系統。首先從第一層開始，即概念共識。概念共識是整個指標系統的基石，沒有概念共識整個指標系統只是一個空中樓閣，只能在短期、局部發布有限的價值。下面我們展開介紹一下如何進行概念共識。

（1）共識的模式

一是通過 BI 驅動的方式。因為 BI 是連接業務和數據工程師的橋梁，能夠在實際溝通交流中進行一些抽象和翻譯，從而形成完整的指標體系。

另一種方式是由數據架構師驅動。因為他們作為數據工程師的代表，對整個領域有更深入的認識，能夠進行全局的抽象和概念定義。

對于無法實現全成員共識的情況，就只能在角色內部共識，然后在交互的時候進行語言的翻譯，翻譯的工作可以由數據工程師或 BI 來完成。

（2）關于共識范圍的問題

不能期待所有成員都能達成共識，特別是在一個比較大的組織內。因此，共識的范圍需要根據具體情況進行劃分。可以通過組織架構視角、業務領域視角或消費場景視角來實現。例如，按公司級、部門級或團隊級進行劃分，或者基于業務領域抽象進行范圍劃分。或者，也可以根據具體的消費場景來決定共識的范圍。

在選擇共識模式和范圍時，沒有絕對的標準，需要考慮各種因素。如全成員共識的優點是共識程度高，但難度也較大，對于核心角色的能力要求很高；角色內部共識的難度較低，但效果相對較差；按組織架構視角共識的難度較低，但穩定性較差；按業務領域共識的穩定性較好，但難度較高；按消費場景共識的靈活性高，但共識程度較低。

經過探索與實踐，在螞蟻內部，核心指標主要按照業務領域進行范圍劃分，并在領域內實現全成員的共識的方式。這樣既可以保證共識程度，也能保證其穩定性。

2、指標語義層的位置

指標是業務語義的核心載體，在架構層面語義層有三種不同的方式。

（1）第一種是將語義層與數據層融合

即直接在數倉中定義語義層。這種方式的好處是前期實施成本較低，只需要將已有的表、視圖等進行相應的調整即可。此外，由于數據通常由獨立的數據團隊集中管理，因此具有組織保障。然而，這種方式的缺點也很明顯，主要表現在敏捷性不足。由于是集中式團隊作業，只能由數據同學進行定義，可能會缺乏業務輸入和全局視角，導致理解成本相對較高。此外，由于語義層與物理層過度耦合，訪問性能和靈活性會受到一定限制。

（2）第二種方式是將數據獨立于數據倉庫層

把語義層單獨抽出來成為獨立的一個產品。這種方式的好處在于邏輯層與物理層的解耦，可以統一數據的訪問模型，支持各種湖倉的場景，并通過自動優化提高性能。由于是獨立出來的，因此業務理解和維護成本相對較低，BI 等人員也有共同參與構建的可能性。此外，集中式管理使得治理程度較好，可以減少一些二義性的問題。然而，這種方式的缺點在于前期成本較高，需要獨立抽取這一層，同時復雜性也相對較高。

（3）第三種方式是集成在數據的消費工具中

這種方式的好處在于高度的靈活性和敏捷性。然而，由于各自分散，很難實現一致性，且跨平臺工具難以復制和復用。因為這一層會有很多貼近消費的特殊優化，對于其他工具來說很難復用。

這三種方式沒有絕對的好壞之分，應根據公司的具體情況而定。根據模式定義和傾向性，如果只是角色內部控制，可以選擇第一種和第三種方式；如果是全成員共識，第二種方式可能更加適合；如果按組織架構共識，第一種方式較為合適；如果是業務領域共識，獨立于一層的方式更好；如果是按消費場景共識，則應選擇第三種方式。

3、構建概念共識

為了構建這個概念共識，需要借助一些工具或方法論作為支撐。

從本質上講，概念共識是統一語言的過程，而阿里之前提出的 OneData 方法論，是一個指標語言標準化的工具。這套工具對于從事指標工作的各位來說并不陌生。然而，隨著時間的推移，我們發現僅依賴這一套工具并不足夠。主要原因是，它在實踐層面更多的是從微觀的視角出發，缺乏宏觀視角。

為了彌補這一不足，我們引入了領域驅動設計這一思想。領域驅動設計并非我們的創新，而是在工程領域被廣泛采納的一種思想。引入它的目的在于增強宏觀視角，更具前瞻性以適應不斷變化的業務需求。此外，隨著數據業務化的趨勢，我們需要實現更大范圍、更深層次的語言共識。領域驅動設計的一些方法論在此過程中發揮了重要作用。

領域驅動設計的核心在于領域模型與統一語言。領域模型是對業務本質的抽象，基于業務本質進行建模。在實際操作中，需要關注兩個結合點。

首先，在宏觀層面上，基于業務本質對數據域進行劃分，這有助于領域知識的交流與共享。如果劃分僅按組織進行，那么領域知識也只能按組織劃分，這無疑增加了交流的難度。

其次，我們需要進行更大范圍的業務術語討論。這意味著在線應用架構師與數據架構師之間需要有一定的交流，能夠一起討論類似的問題，確保彼此的語言是相通的。

三、指標系統設計——機制流程設計

1、機制流程的設計

機制流程的設計是為了確保指標的持續建設及保鮮。我們在實踐過程中發現，指標系統的建設相對容易，但持續的維護和運轉卻非常困難。從因果圖上看，良好的建設和維護能夠促進消費者的使用；用的人多了，也就能促進建設和維護。但現實中這個增強回路很難運轉起來，主要從建設角度看，往往是可建可不建的狀態，有部分同學更傾向于維護在離線的 excel 中，一旦維護不足指標不保鮮，消費者就喪失信心轉而線下問人；對于消費者，指標的使用場景有限，只是偶爾去看一下的話增量價值沒有那么大，不一定會持續去推動生產者進行指標維護。

為了解決這個問題，有兩個思路，一是通過產品化及 AI 能力，提升指標管理、指標研發的效率，讓在線的指標維護管理效率高于線下表格；二是通過與消費平臺的深度集成，提升找數、取數、分析的效率。當然在前期，我們還需要依靠一些管理機制來確保系統的冷啟動。

2、權責定義

在管理機制中，有幾個關鍵角色需要詳細闡述。

首先，業務負責人是負責提出需求和建立指標模型的人。他們通常是 BI 或數據架構師，具有深厚的業務背景和專業知識。業務負責人對指標原子或業務限定有最終解釋權，需要在負責領域內制定無歧義的標準，確保指標建模的準確性和標準化。

接下來，技術負責人負責實現指標模型。他們需要選擇實現方式，確保準確實現并及時產出。技術負責人需要與業務負責人保持密切溝通，確保對指標口徑的理解保持一致，避免歧義。

最后，消費者是指標的最終使用者。他們享有知情權，對指標口徑的變更需及時了解。消費者有責任準確理解指標口徑，合理使用數據，避免濫用。

在管理機制中，各角色需明確職責，相互協作，確保指標建模、實現和消費的順利進行。

3、變更流程

基于權責劃分，我們設計了一套變更的流程。在流程中，業務負責人擁有最終解釋權，并承擔著明確實現口徑的責任，具備審批權。消費者則擁有被通知的權利，業務負責人和技術負責人應確保消費者及時獲悉相關信息。

四、指標系統設計——產品化

1、產品化載體

產品化的載體就是指標平臺，其目標是解決效率問題。平臺服務于數據管理者、指標建模者、指標研發者和消費者。

數據管理者的主要訴求是確保指標數據的準確性，避免出現任何歧義，同時關注數據質量和投入成本。指標建模者主要關注的是建模效率和建模門檻。指標研發者關心研發效率。而消費者，則更關心數據質量和消費效率。

基于這些核心訴求，指標平臺需要具備四個核心能力：

• 首先是標準化的指標口徑定義和管理能力，確保數據的準確性和一致性。
• 其次是高效的指標研發能力，快速響應業務需求。
• 第三是通過便捷的消費能力，使數據更易于獲取和使用。
• 最后是便捷的指標下鉆分析能力，幫助用戶快速定位問題并進行優化。

2、指標平臺常見結構

在業界，指標平臺已經得到了廣泛的應用。阿里集團和螞蟻集團內部也有多個指標平臺，有些是作為業務管理平臺中的指標模塊，而有些則是獨立的指標平臺。

從結構上看，指標平臺通常包括統一詞庫管理、原子指標管理以及業務限定管理。基于這些基礎，通過派生指標，可以形成一個龐大的指標庫。在這個庫中，可以進行簡單的指標運維、衍生以及提供看數、取數或指標 API 等服務。最終，物理指標會在研發平臺中完成，并異步掛載到 ADM 或 DWS 表中。

然而，從我們對指標平臺能力的要求上看，現有的指標平臺也存在一些問題。

首先是標準化指標口徑定義和管理的能力。這個結構只標準化了邏輯口徑，沒有標準化物理口徑，它的物理口徑通常隱藏在復雜的 SQL 中。因此，它只能解決單指標的二義性，無法解決多指標間的二義性，只能通過組織流程保障和統一中間層資產建設來緩解。

第二是指標下鉆分析能力。因為基于 ADM 或 DWS 有很多復雜 SQL，要做到下鉆明細是比較困難的，無法做到自動的下鉆分析，只能人為地查看 SQL 去理解口徑。

第三是需要具備高效的研發能力。基于基礎指標進行簡單衍生可以快捷生產，解決一部分效率問題。

第三個問題是通用便捷的消費能力。這個結構在，掛載的指標只能以一個指標 code 這樣一維的形式存在，但數據領域大部分消費還是以“表”這樣的二維形式，因此，這個結構下的指標要消費只能是指標取數 api 的形式，或者需要與下游數據服務進行深度打通，不夠通用。

綜上所述，現有的指標平臺結構雖然解決了很多問題，但仍不能完全滿足能力的要求。

3、螞蟻指標平臺結構

螞蟻指標平臺在近期進行了一次升級，主要涉及以下幾個關鍵方面。

首先，在原子詞庫的框架下，我們為每個詞設定了具體的物理口徑。這種物理口徑是基于數據模型進行確定的，以確保其二義性得到保障。

基于這些綁定的物理口徑，構建了一個統一詞庫。這個統一詞庫依托標準化模板，可以自動計算指標并產出，省去了手動計算這一步驟。此外，我們還為這些指標賦予了一個載體，使其能夠自動匯總到一張匯總邏輯表中。

這一結構具有幾個優勢。首先，它解決了口徑不一致的問題。由于每個詞庫都綁定了物理口徑，實現了邏輯口徑與物理口徑的標準化，因此可以更徹底地解決二義性問題。

第二點是它增強了研發效率及指標下鉆分析的能力。指標實現了定義即研發，不需要在研發模塊手動寫任務再上掛到指標中，極大地提效。另外因為最終的指標是基于綁定口徑的詞庫計算而來的，它有一個強血緣，因此很容易基于指標就回溯到相應的明細表，展開詳細口徑，進行進一步的分析。

最后針對自動研發的指標，我們將同粒度的指標自動匯總到一張“邏輯表”中，這樣下游用戶可以基于該表的模型進行數據消費，實現更通用的消費。

4、輔助指標建模

為了解決指標建模中的難點，我們引入了指標輔助建模。在實踐中，我們發現從指標抽取出四要素（如原子指標、業務限定）可能會遇到一些困難。困難主要在于缺乏統一的標準。例如，當需要查看昨日支付寶在國內線下成交金額數時，指標建模者或BI、架構師需要拆分原子指標、業務限定和統計周期。雖然統計周期相對容易處理，但原子指標和業務限定有多種拆分方式。因為沒有明確的對錯之分，這可能導致混亂。

為了解決這一問題，我們引入了一些指標的智能建模推薦。基本邏輯原理包括兩條路線：一是基于基本指標進行分詞，分詞詞庫基于業務詞條和指標詞庫。分詞后，進行分類和同義詞修正。例如，確定是“成交金額”還是“交易金額”，并確保每個指標的唯一性。另一條路線是利用大模型對業務詞條和已有詞庫進行構建，并基于大模型直接給出推薦結果。通過這些方法，可以提高指標建模的準確性和效率。

5、研發提效

關于指標 SQL 的研發提效問題，其基本原理是基于模板，每個模板對應一個基本元素，通過邏輯生成來解決問題。基礎能力比較簡單，關鍵在于如何提高場景的覆蓋率。

起初，我們通過簡單的單表模板或配置來解決問題，只能覆蓋約 30% 的情況。接下來，我們引入維度或雪花模型的指標配置，將所有維度擴展成一張虛擬大寬表，進行指標配置，解決了約 60% 的問題。

為了解決 80% 的問題，我們進一步豐富關聯關系和模型能力。例如，引入橋接表、層級維度以及復雜的關聯關系。更進一步，解決 90% 的問題則需要處理二次匯總和自關聯能力，比如一些二次匯總或者自關聯的標簽類指標。

對于更復雜的情況，我們仍在探索可能的解決方案。然而，任何解決方案都存在極限，無法達到 100% 的覆蓋率。在未來，我們需要更加關注產品交互能力，或者使用更適合的 DAX 語言來處理復雜的分析指標。

6、通用消費能力

最后，關于通用消費能力，可以通過匯總邏輯表將所有指標按維度匯總成一張虛擬寬表。用戶可見的維度和指標可以作為表的字段進行展開。對于物理層，進行一些內部自動物化處理以提高效率。

利用邏輯表的查詢翻譯引擎，將用戶所有的 SQL 轉化為邏輯表，并進一步將邏輯表轉換為物理表的 SQL。這個引擎是整個系統中的核心組件。

在此基礎上，建立接入層。在這一層，我們實現了多種協議，包括 HTTP、RPC 以及 JDBC 等，以滿足不同用戶的需求。此外我們還對螞蟻內部的 Max Computer 引擎進行查詢協議的代理，用戶只需切換一個 endpoint，就可以方便地查詢邏輯表。

為了提高查詢效率，我們還引入了邏輯表加速技術，以滿足一些需要快速響應的指標服務的需求。

7、專家經驗平民化

基于業務模型的特性，通過專家經驗的積累，可以有效提升數倉的執行效率。為了實現這一目標，主要采取了以下幾個策略：

• 同源表同粒度的合并計算，以減少重復計算。
• 長短周期的漸進計算優化，避免不必要的重復計算。
• 粒度上卷的優化，基于新粒度的上卷，提高計算效率。
• 自動構建 BitMap 優化，進一步簡化計算過程。
• 在純 SQL 層面，通過 count distinct 轉 group by、full outer join 轉 union all、自動 map join 等優化。

這些策略對于專家來說是常見的優化手段，但對于剛上手的同學來說可能并不容易掌握。因此，我們通過內置優化方法，有效提升數倉的平均執行效率，為業務提供更好的支持。

8、基于 ROI 的智能物化

在邏輯表物化層面，我們根據下游的消費頻率和時間要求，對指標所在的匯總表進行智能的物化拆分和冗余處理。拆分和冗余的決策主要基于 3 個因素：

一是消費者對每個指標的時效要求，如果所有的表都被整合在一張物化表中，它受限于產出時間最慢的指標，使整體產出時效很長，所以在物化的時候需要根據時效進行分組，例如要求在九點產出數據，那么七點和七點二十的數據可以合并到同一張物化表中。同樣地，根據十點的要求，九點和九點二十的數據也可以合并在一起。

二是在邏輯表內基于消費的頻率進行計算與存儲的取舍，如果下游經常需要將某些字段頻繁地連接在一起，我們會在物化表內部進行冗余處理。

三是跨表的冗余。在實際使用時，許多維度屬性會被一起使用。為了提高性能，我們會針對一些維度屬性進行冗余處理。例如，用戶的一些信息，如姓名和性別會被冗余存儲在另一張物化表中，由系統來保障一致性。

五、業務實踐及未來展望

1、業務實踐情況

在螞蟻集團，當前已有近三萬個派生指標，其中 70% 是自動化研發的。基于 codeless 定義和自動物化的策略，數據二義性問題明顯有所改進，尤其是基于自動化的效率實現了數量級的提升。在指標計算性能方面，由于各種物化的自動化策略的應用，研發提效 10 倍以上，指標計算成本下降 20%。

在網商銀行這一典型場景中，主要面臨的問題是口徑的統一，因為各子模塊間存在口徑性的沖突，導致子業務報表合在一起時數據無法對齊。此外，敏捷性和靈活性也是指標交付中需要關注的問題。一旦指標交付出現異常波動或問題，進行二次分析的難度較大。

在指標系統的實踐中，我們采取了統一的數據模型為基礎，構建了指標模型。在此基礎上，建立了統一的指標庫，并與業務制度分析平臺進行了深度結合，這種結合使得我們能夠進行線上分析。目前已構建了數千個派生指標，其中自動化率高達 90% 以上，保證了口徑的一致性，并提升了效率。

在螞蟻安全領域，主要面臨的問題包括口徑問題、重復研發導致的計算和存儲浪費、成本增速超過預算以及依賴混亂的計算成本壓力。為了解決這些問題，數據工程師聚焦于數據建模和指標建模，而業務同學則負責派生指標的構建。通過這種方式，我們實現了上萬個派生指標，自動化率達到了 85%，交付周期從兩天縮短到一小時，計算成本平均下降了百分之三十左右。同時，指標安全性問題也得到了較好的解決。

2、未來展望

未來將更加關注大模型的運用。大模型為語義層帶來了一個寶貴的機會。

一方面大模型能夠輔助建模，降低語義層構建的成本。但短期內，大模型不會完全替代，因為業務的抽象以及一些子領域基礎數據仍比較稀缺。

另一方面語義層是大模型不可替代的領域知識中心，通過將語義層與大模型結合，將極大提升消費效率，包括自然語言找數、自然語言取數和自然語言分析等。

六、問答環節

Q1：物理口徑是如何做到綁定的？

A1：在物理口徑的綁定方面，我們需要在定義原子指標時，直接為其指定相應的口徑。具體的綁定過程可以分為兩個主要步驟。首先，選擇主表，并為其添加相應的原子指標計算口徑。其次，業務限定通常與維表相關，這可能涉及到主表或其關聯的表。在綁定過程中，我們通常不需要對時間周期進行綁定，只需要在主表指定時間字段和格式就可以了。

Q2：指標是單獨存儲的嗎？如果是單獨存儲的，是不是按照列式存儲比較好？如果維度不太固定或者多變的情況，有什么好的方案嗎？

A2：首先，指標存儲分為兩個層級。第一層是最基礎的層級，通常不會進行單獨的存儲。在物化視圖方面，如果原始數據是采用列式存儲，那么物化后依然會保持列式存儲。

對于加速后的指標服務存儲，存在多種選擇。一種方式是我們可以內置一些加速存儲的功能。另一種方式則是做加速，并存儲到目標消費平臺中。不過，數據并不會單獨存儲在目標消費平臺中。

此外，對于維度不太固定或者可能會變化的情況，我們需要考慮一些好的解決方案。目前匯總邏輯表是按照同維度進行聚合的。當維度發生變化時，比如增加或減少維度，這通常不是建表的問題。

如果引入新的維度，我們需要考慮如何迭代表結構。對于新表，我們會創建另一張匯總邏輯表，而不是在同一張表上進行操作。因為不同維度很難聚合在一起。如果硬要聚合，可能會導致數據表變得龐大而難以管理。

為了避免這種情況，我們可以考慮使用分區表來管理不同維度的數據。通過合理設置分區鍵和分區策略，可以有效地將不同維度的數據分散到不同的分區中，從而實現高效的數據存儲和管理。同時，我們還可以利用數據庫的分區功能進行查詢優化，提高查詢效率。

Q3：指標平臺應該是從明細事實表開始計算，還是從業務部門的中間表去計算？

A3：關于指標的定義，我認為應該基于語義，即數據模型這一層面。中間表和明細表是不同的概念，對于明細表，也需要具體分析。有些明細表在規范上相對收斂，而有些則較為發散。為了確保一致性，我們應從概念模型開始，這一層面具有一定的抽象性。通過這種方式，明細內層不會過于分散，明細與概念能夠更好地結合，從而更易于達到一致性。

Q4：指標的查詢對于 BI 看板來說，性能要求會比較高，性能應該從哪幾方面保障呢？

A4：關于性能這一方面，我們在螞蟻金服并沒有進行過多的研究和涉獵。主要原因在于，我們將這一領域的工作主要交給了底層引擎來處理，例如邏輯表加速等，這些都是由引擎來負責的。在我們的工作中，我們更專注于構建語義層這一塊，而不是過分關注技術層面的優化。

對于性能優化，我們采取了兩種策略。首先是把相關工作交給引擎處理，這樣可以利用它們的專業性能優化技術。其次，對于邏輯表的加速，我們并不需要處理所有的數據存儲問題，而是選擇性地加速到業務的數據分析平臺，例如 Power BI 等。這些平臺擁有專業的性能解決方案，能夠提供更加完備的性能優化服務。

Q5：派生指標是包含維度和原始指標嗎？是由業務同學來編寫嗎？

A5：對于派生指標的定義，存在不同的觀點和理解。

在實踐操作中，我們的派生指標包含統計粒度和維度兩個方面。

至于派生指標的確定，我認為業務團隊的參與是非常關鍵的。但是，這種參與是有前提條件的。首先，業務團隊需要對建立的模型和相關概念有統一的認識。如果業務團隊和數據團隊使用不同的語言，那么派生指標的確定將非常困難。此外，對于數據建模抽象能力的要求也比較高。數據工程師需要扮演數據架構師或數據建模師的角色，構建出能夠適應各種業務需求的優質模型。這樣的一種模式是比較理想的選擇，能夠確保派生指標的有效性和實用性。

Q6：有出現下鉆的時候，就是出現算子不相同的問題嗎？比如說一開始下鉆的某一層級需要去重。

A6：具體來說，我們需要將這一層向下轉換，以揭示其核心口徑，也就是還原到明細模型這一層級。一旦還原到明細模型層，系統會默認展示原子指標的算式。然而，要進行更高級的分析，你可能需要使用其他算式或添加額外條件。這就需要與我們的分析平臺相結合，輕松地替換這些算式、限定、周期或維度。

這樣的調整不僅擴大了探討的空間，還突出了基于明細模型的靈活性。另外，我想補充一點，我們的指標通常基于數據模型來定義聚合算子，這可能涉及多層聚合。這時，我們可以借助 BI 工具，進行二次或三次上卷分析。我理解一些特別復雜的分析可能會更需要借助這些工具和語言來處理。

Q7：所有的指標都是持久化之后的嗎？有沒有一些指標是動態的？比如我們實時查詢三月份到現在的成交額。

A7：根據您提供的原始內容，以下是經過改寫的嚴謹、穩重、理性、官方風格的語言：

在數據倉庫中，指標通常都是持久化的。對于一些衍生指標，例如 a 加 b 或 a 除以 b，我們不會一概而論地進行物化，而會根據實際需求和情況來決定是否將其物化。

Q8：指標的計算口徑都是通過圖形化界面配置的嗎？還是可以基于 SQL 語句配置？

A8：關鍵是看結構，以原子指標與基本算子級別的口徑綁定為例，涉及到圖形與 SQL 的結合的，有些是選擇定義 SQL。在定義好這些基礎要素后，系統將生成相應的指標，這個過程可以通過圖形化界面進行展示。

Q9：詞根的二義性怎么解決？

A9：關于詞根的二義性問題，其實我們之前已經有所涉及。要實現業務詞條的統一語言，主要有三種模式選擇：基于領域、基于組織或基于消費場景。在確定模式后，后續工作就會變得相對簡單。

如果是基于領域，就需要領域專家共同合作，采用領域驅動的方法，根據業務用例進行抽象，達成詞根的統一。基于組織的模式可能相對簡單一些，而基于消費場景的方式可能無法解決根本的安全性問題，因此建議采用基于領域的方式。

另外，關于機制流程的變動，需要非常謹慎地進行。關于領域設計的展開，需要強調的是，這些詞并不是一次性錄入系統就結束了。要讓領域詞在各種日常交流、文檔和需求提案中得到廣泛應用，以規范使用標準的詞匯。只有不斷加深對詞根的印象，才能真正達成共識，解決二義性問題。

Q10：指標主要是離線計算嗎？是存算分離的嗎？

A10：我們在此進行計算時，主要集中在最基礎的一層，采用離線計算方式，因為離線計算在效率上更具優勢。在線計算則主要用于加速和執行一些簡單的衍生操作，如組合或聚合。至于存算分離，我認為它更多地取決于底層技術架構中引擎的存算分離特性。如果底層引擎支持存算分離，我們也會采用這種架構。

Q11：派生出來的指標一般是單個類型的指標落表。但是 BI 看板經常會需要拿各種類型的派生指標，這個怎么處理？

A11：對于處理多個派生指標的問題，確實需要謹慎處理。

首先，考慮到我們現有的指標已經聚合在匯總邏輯表中，如果在 BI 工具中引入這個表，可能會出現數據量過大的情況。特別是當我們面對的是擁有數千個指標的大型邏輯表時，按需引入是必要的。

其次，為了提高效率和準確性，我們也可以考慮與下游的平臺進行整合。這樣，下游平臺可以直接引用指標列表。之后，我們可以自動將相關的數據集或底層邏輯表、物理表傳輸到下游平臺，從而幫助它們構建自己的數據模型。這種方式可以實現更為流暢和高效的數據傳輸和處理。

總結來說，處理多個派生指標的問題需要我們綜合考慮數據量、效率和準確性等多個方面。通過按需引入數據、與下游平臺深度整合等策略，我們可以更好地滿足業務需求并提升數據處理的整體效果。