當今大模型如此火熱，作為一名數據同學，持續在關注LLM是如何應用在數據分析中的，也關注到很多公司推出了AI數智助手的產品，比如火山引擎數智平臺VeDI—AI助手、 Kyligence Copilot AI數智助理、ThoughtSpot等，通過接入人工智能大模型，提升數據處理和查詢分析的效率。智能數據分析助手，采用對話式分析技術，每個普通人都可以與數據進行隨時隨地的實時交互，根據用戶的使用反饋，不斷學習，自我迭代找到答案，并在團隊內分享對數據的見解。

簡單分析一下數據分析的發展階段：第一階段，以靜態報表為主，傳統BI和靜態報表基本上都是面向開發部門的，業務部門提出需求之后，由開發根據報表工具開發出固定的報表，然后業務部門查看報表結果。第二階段，敏捷BI自助式分析，在業務部門提出需求之后，數據分析可以基于敏捷BI的工具幫助業務部門快速獲取所需的數據，幫助他們獲得所需要的結果。第三階段，不管是基于大模型的AskBI還是增強分析，都是直接面向業務的，其理念是業務部門直接使用對話式BI工具能夠解決問題，獲得所需的數據結果。這一過程無需像之前那樣依賴開發部門開發報表，或者數據分析師基于敏捷BI再提供數據結果，而是直接由業務部門推進落地。

一、整體方案

通過多家數AI數智助手調研，實現智能數據分析的核心有：一是以指標為中心，二是大模型。其中也分享出了如何把指標平臺+AI技術落地方案，提出了：人人用數=AI Copilot + 指標體系 + 合理成本的關鍵技術觀點。

指標體系給到我們的是一個通用的數據語言，當我們每一個人都用數據來溝通時，我們遇到的第一個障礙一定是缺乏通用的語言。就像普通話讓13 億中國人能夠自由溝通，數據的解釋權有一個標準一致的口徑也是非常重要的，是數據共享和協作的前提。

指標數據最理想的使用場景就是，想要就有，數據準確，可視化展示。用戶期望能夠隨時查看自己想要的業務指標數據，絕大多數人都有自己的使用指標的渠道和方法，但是需要用戶熟悉系統的操作、數據內容可能會根據需求提前預設好，如果是需要指標的話，就依賴支持者的時間了，或者需要排期開發。雖然每個人都各顯其通能夠拿到數據，但于用戶體驗來說，還是需要有操作和時間成本。

智能化的指標應用可以大幅提高數據指標的用戶體驗和效率。我們希望的場景是，用戶對著手機：“告訴我昨天的DAU、用戶留存、銷售額”，系統就能快速的反饋給用戶這三個指標的結果，并且是準確的。

指標的加工處理到使用中間有很多過程，從數據沉淀->數倉加工->口徑定義->報表->系統->用戶，中間流程最直接的方式就是自然語言直接對接到數據。

通用方案

通用做法是基于指標要素生產出指標的模型（提前預算好所有的可能），通過NLP技術，將自然語言轉譯成SQL，直接讀取指標模型，大概的技術思路如下：

基于大模型

目標：通過大模型技術，打造用戶在靈活搜索指標的時候能夠快速反饋給用戶正確的指標體驗。

核心聚焦：

1. 讓系統盡可能的去理解自然語言，并準確的把它轉換成可執行的SQL。
2. 盡最大的可能覆蓋用戶的靈活需求，提高指標要素組合的成指標的組合數量。

基于LLM生成準確可執行SQL的關鍵思路：把指標管理模型的定義、指標要素等元數據信息送給LLM當作prompt進行指標搜索與生成。

二、Text-to-SQL

Text-to-SQL（簡寫為T2S，或者是Text2SQL），顧名思義就是把文本轉化為SQL語言，更學術一點的定義是：把數據庫領域下的自然語言（Natural Language，簡寫為NL）問題，轉化為在關系型數據庫中可以執行的結構化查詢語言（Structured Query Language，簡寫為SQL）。

Text-to-SQL是什么

Text-to-SQL任務相對正式的定義：在給定關系型數據庫（或表）的前提下，由用戶的提問生成相應的SQL查詢語句。下圖是spider數據集的樣例，問題：有哪些系的教師平均工資高于總體平均值，請返回這些系的名字以及他們的平均工資。可以看到該問題對應的SQL語句是很復雜的，并且有嵌套關系。

數據集

常見的數據集有GenQuery、Scholar、WikiSQL、Spider、Spider-SYN、Spider-DK、Spider-SSP、CSpider、SQUALL、DuSQL、ATIS、SparC、CHASE等。

數據集的分類有單領域和交叉領域；有單輪對話和多輪對話；有簡單問題和復雜問題；有中文語言和英文語言；有單張表和多張表等。重點介紹兩個數據集：WikiSQL、Spider。

WikiSQL

WikiSQL數據集是目前規模最大的Text-to-SQL數據集，由2017年美國的Salesforce公司提出，場景來源于Wikipedia，屬于單領域。數據標注采用外包。

1. 包含了80654個自然語言問題，77840個SQL語句。
2. 包含了26521張數據庫表，1個數據庫只有1張表。
3. 預測的SQL語句形式比較簡單，基本為一個SQL主句加上0-3個WHERE子句條件限制構成，如下圖所示：

Spider

Spider數據集是多數據庫、多表、單輪查詢的Text-to-SQL數據集，也是業界公認難度最大的大規模跨領域評測榜單，由2018年耶魯大學提出，由11名耶魯大學學生標注。

1. 10181個自然語言問題，5693個SQL語句。
2. 涉及138個不同領域的200多個數據庫。
3. 難易程度分為：簡單、中等、困難、特別困難。如下圖所示

Spider數據集論文地址：https://arxiv.org/pdf/1809.08887.pdf。

CSpider是西湖大學在EMNLP2019上提出了一個中文text-to-sql的數據集，主要是選擇Spider作為源數據集進行了問題的翻譯，并利用SyntaxSQLNet作為基線系統進行了測試，同時探索了在中文上產生的一些額外的挑戰，包括中文問題對英文數據庫的對應問題(question-to-DBmapping)、中文的分詞問題以及一些其他的語言現象。

評估指標

目前廣泛使用的是執行準確率（Execution Accuracy，簡稱EX）和邏輯形式準確率（WxactMatch，簡稱EM）。

執行準確率

定義：計算SQL執行結果正確的數量在數據集中的比例。

缺點：存在高估的可能。因為一個完全不同的非標準的SQL可能查出于與標準SQL相同的結果（例如，空結果），這時也會判為正確。

舉個例子：假如有個學生表，我們想要查詢學生表中年齡等于19的學生姓名，就如“SELECT sname FROM Student where age = 19”所示，通過數據庫執行標準SQL后得到結果為null；此時Text-to-SQL模型預測的SQL為“SELECT sname FROM Student where age = 20”，通過數據庫執行后也得到結果為null。雖然預測的SQL跟標注的SQL不一致，但是結果是一樣的，根據執行準確率指標來比較，那么就認為模型預測是正確的。

# groundtruth_SQL
SELECT sname FROM Student where age = 19；
# SQL執行結果
null


# predict_SQL
SELECT sname FROM Student where age = 20；
# SQL執行結果
null

邏輯形式準確率

定義：計算模型生成的SQL和標注SQL的匹配程度。

缺點：存在低估的可能。如一個SQL執行結果是正確的，但于標注SQL的字符串并非完全匹配，例如，只是select 列的順序不同或SQL查詢目的完全相同的不同SQL。為了解決一部分該問題，有研究指出了一種查詢匹配精度query match accuracy：將生成的SQL和標注SQL都以標準形式表示，再計算兩者匹配精度。這種方法只解決了由于排序問題而導致的誤判。另外，通過對列和表進行排序并使用標準化別名來對SQL進行規范化，也可以消除不同SQL格式導致的誤判問題。

舉個例子：同樣地，假如有個學生表，我們想要查詢學生表中年齡等于19的學生姓名和學生學號。就如“SELECT sname FROM Student where age = 19”所示，通過數據庫執行標準SQL后得到結果為（張三，123456）；此時Text-to-SQL模型預測的SQL為“SELECT sno,sname FROM Student where age = 19”，通過數據庫執行后也得到結果為（123456，張三），如果從邏輯形式準確率指標來看，因為SQL并不是一模一樣，盡管兩者只是篩選順序的語序問題，所以會認為模型預測是錯誤的。

# groundtruth_SQL
SELECT sname,sno FROM Student where age = 19；
# SQL執行結果
張三，123456


# predict_SQL
SELECT sno，sname FROM Student where age = 19；
# SQL執行結果
123456，張三

研究方法

在深度學習的研究背景下，將 Text-to-SQL看作一個類似神經機器翻譯的任務，主要采取seq2seq的模型框架。基線模型seq2seq在加入Attention、Copying等機制后，能夠在ATIS、GeoQuery數據集上達到84%的精確匹配，但是在WikiSQL上只能達到23.3%的精確匹配，37.0%的執行正確率；在Spider上則只能達到5～6%的精確匹配。

究其原因，可以從編碼和解碼兩個角度來看。首先編碼方面，自然語言問句與數據庫之間需要形成很好的對齊或映射關系，即問題中到底涉及了哪些表格中的哪些實體詞，以及問句中的詞語觸發了哪些選擇條件、聚類操作等；另一方面在解碼部分，SQL作為一種形式定義的程序語言，本身對語法的要求更嚴格（關鍵字順序固定）以及語義的界限更清晰，失之毫厘差之千里。普通的seq2seq框架并不具備建模這些信息的能力。

于是，主流模型的改進與后續工作主要圍繞著以下幾個方面展開：通過更強的表示（BERT、XLNet）、更好的結構（GNN）來顯式地加強Encoder端的對齊關系及利用結構信息；通過樹形結構解碼、填槽類解碼來減小搜索解空間，以增加SQL語句的正確性；通過中間表示等技術提高SQL語言的抽象性；通過定義新的對齊特征，利用重排序技術，對beamsearch得到的多條候選結果進行正確答案的挑選；以及非常有效的數據增強方法。

基于模板和匹配的方法

因為輸出SQL本質上：是一個符合語法、有邏輯結構的序列，本身具有很強范式結構，所以可以采取基于模板和規則的方法。簡單SQL語句都可以抽象成如下圖：

簡單SQL模板示例：

1. AGG表示聚合函數，如求MAX，計數COUNT，求MIN。
2. COLUMN表示需要查詢的目標列。
3. WOP表示多個條件之間的關聯規則“與and /或 or”
4. 三元組 [COLUMN, OP, VALUE] 構成了查詢條件，分別代表條件列、條件操作符（>、=、<等）、條件值。
5. *表示目標列和查詢條件不止一個！

基于模板和匹配的方法，是早期的研究方法，適用于簡單SQL，定義后的sql準確率高；不適合復雜SQL，沒有定義模板的SQL不能識別。

基于Seq2Seq框架的方法

對于Text-to-SQL研究而言，本質上屬于自然語言處理（Natural Language Processing，NLP），而在NLP領域中，常見的任務可以大概分為如下四個場景，1、N和M代表的是token的數量。

1. 1 -> N：生成任務，比如輸入為一張圖片，輸出圖片的文本描述。
2. N -> 1：分類任務，比如輸入為一句話，輸出這句話的情感分類。
3. N -> N：序列標注任務，比如輸入一句話，輸出該句話的詞性標注。
4. N -> M：機器翻譯任務，比如輸入一句中文，輸出英文翻譯。

可以發現的是，Text-to-SQL任務是符合N -> M機器翻譯任務的，處理機器翻譯任務最主流的方法是基于Seq2Seq框架方法，Seq2Seq是一種基于序列到序列模型的神經網絡架構，它由兩個部分組成：編碼器Encoder和解碼Decoder。因此，Text-to-SQL最主流的方法也是基于Seq2Seq框架。

更多學習和研究Text-to-SQL相關內容，可以參考2篇綜述文章：《A Survey on Text-to-SQL Parsing: Concepts, Methods, and Future Directions》Text-to-SQL解析的概念、方法和未來方向；《Recent Advances in Text-to-SQL: A Survey of What We Have and What We Expect》Text-to-SQL領域的最新進展：關于我們所擁有該領域的知識以及和所期盼的發展方向的綜述。

三、DIN-SQL

2022年底，ChatGPT爆火，憑借LLM強大的邏輯推理、上下文學習、情景聯系等特點，按理說LLM應該可以超過seq2seq、BERT等系列的模型，但是使用少樣本、零樣本提示方法用LLM解決NL2SQL問題效果卻比不上之前的模型。今天分享的這篇來自NLP頂級會議的論文解決了這個問題：如何改進Prompt讓LLM超越之前的方法，并讓LLM在Spider數據集上霸榜。

論文原文鏈接：DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction（地址：https://arxiv.org/abs/2304.11015）?

摘要：我們研究將復雜的文本到 SQL 任務分解為更小的子任務的問題，以及這種分解如何顯著提高大型語言模型 (LLM) 在推理過程中的性能。目前，在具有挑戰性的文本到 SQL 數據集（例如 Spider）上，微調模型的性能與使用 LLM 的提示方法之間存在顯著差距。我們證明 SQL 查詢的生成可以分解為子問題，并且這些子問題的解決方案可以輸入到 LLM 中以顯著提高其性能。我們對三個 LLM 進行的實驗表明，這種方法持續將其簡單的小樣本性能提高了大約 10%，將 LLM 的準確性推向 SOTA 或超越它。在 Spider 的 Holdout 測試集上，執行準確度方面的 SOTA 為 79.9，使用我們方法的新 SOTA 為 85.3。我們的情境學習方法比許多經過嚴格調整的模型至少高出 5%。

該論文提出了一種基于少樣本提示Few-shot Prompt的新穎方法，將Text-to-SQL的任務分解為多個步驟。

編寫SQL查詢的思維過程可以分解為：

1. 檢測與查詢相關的數據庫表和列
2. 識別更復雜查詢的一般查詢結構（例如分組、嵌套、多重聯接、集合運算等）
3. 制定任何可以識別的過程子組件
4. 根據子問題的解決方案編寫最終查詢。

基于這個思維過程，將文本到SQL任務的方法分解為4個模塊：

1. 模式鏈接
2. 查詢分類和分解
3. SQL生成
4. 自我修正

如果問題被簡單地分解到正確的粒度級別，LLM就有能解決所有的這些問題。

Schema Linking Module

模式鏈接負責識別自然語言查詢中對數據庫模式和條件值的引用。它被證明有助于跨領域的通用性和復雜查詢的綜合（Lei 等人，2020），使其成為幾乎所有現有文本到 SQL 方法的關鍵初步步驟。在我們的案例中，這也是LLM失敗次數最多的一個類別（圖 2）。我們設計了一個基于提示的模式鏈接模塊。提示包括從 Spider 數據集的訓練集中隨機選擇的 10 個樣本按照思路鏈模板（Wei 等人，2022b），提示以“讓我們一步一步思考”開頭，正如 Kojima 等人（2022）建議的那樣。對于問題中每次提到的列名，都會從給定的數據庫模式中選擇相應的列及其表。還從問題中提取可能的實體和單元格值。如下圖顯示模式鏈接模塊的輸入和輸出的示例。

Classification & Decomposition Module

對于每個連接，都有可能未檢測到正確的表或連接條件。隨著查詢中聯接數量的增加，至少一個聯接無法正確生成的可能性也會增加。緩解該問題的一種方法是引入一個模塊來檢測要連接的表。此外，一些查詢具有過程組件，例如不相關的子查詢，它們可以獨立生成并與主查詢合并。

為了解決這些問題，我們引入了查詢分類和分解模塊。該模塊將每個查詢分為三類之一：簡單、非嵌套復雜和嵌套復雜。easy 類包括無需連接或嵌套即可回答的單表查詢。非嵌套類包括需要連接但沒有子查詢的查詢，而嵌套類中的查詢可以需要連接、子查詢和集合操作。類標簽對于我們的查詢生成模塊很重要，該模塊對每個查詢類使用不同的提示。除了類標簽之外，查詢分類和分解還檢測要為非嵌套和嵌套查詢以及可能為嵌套查詢檢測到的任何子查詢連接的表集。如下圖顯示分類和分解模塊的輸入和輸出的示例：

SQL Generation Module

隨著查詢變得更加復雜，必須合并額外的中間步驟來彌合自然語言問題和 SQL 語句之間的差距。這種差距在文獻中被稱為不匹配問題（Guo et al, 2019），對 SQL 生成提出了重大挑戰，這是因為 SQL 主要是為查詢關系數據庫而設計的，而不是表示自然語言中的含義。

雖然更復雜的查詢可以從思路鏈式提示中列出中間步驟中受益，但此類列表可能會降低更簡單任務的性能（Wei 等人，2022b）。在相同的基礎上，我們的查詢生成由三個模塊組成，每個模塊針對不同的類別。

對于我們劃分的簡單類別中的問題，沒有中間步驟的簡單的少量提示就足夠了。此類示例 Ej 的演示遵循格式 <Qj, Sj, Aj>，其中 Qj 和 Aj 分別給出英語和 SQL 的查詢文本，Sj 表示模式鏈接。

我們的非嵌套復雜類包括需要連接的查詢。我們的錯誤分析（第3節）表明，在簡單的幾次提示下，找到正確的列和外鍵來連接兩個表對于法學碩士來說可能具有挑戰性，特別是當查詢需要連接多個表時。為了解決這個問題，我們采用中間表示來彌合查詢和 SQL 語句之間的差距。文獻中已經介紹了各種中間表示。特別是，SemQL（Guo et al, 2019）刪除了在自然語言查詢中沒有明確對應項的運算符 JOIN ON、FROM 和 GROUP BY，并合并了 HAVING 和 WHERE 子句。NatSQL（Gan 等人，2021）基于 SemQL 構建并刪除了集合運算符。作為我們的中間表示，我們使用 NatSQL，它與其他模型結合使用時顯示出最先進的性能 (Li et al, 2023a)。非嵌套復雜類的示例 Ej 的演示遵循格式 <Qj, Sj, Ij, Aj>，其中 Sj 和 Ij 分別表示第 j 個示例的模式鏈接和中間表示。

最后，嵌套復雜類是最復雜的類型，在生成最終答案之前需要幾個中間步驟。此類可以包含不僅需要使用嵌套和集合操作（例如 EXCEPT、UNION 和 INTERSECT）的子查詢，而且還需要多個表連接的查詢，與上一個類相同。為了將問題進一步分解為多個步驟，我們對此類的提示的設計方式是LLM應首先解決子查詢，然后使用它們生成最終答案。此類提示遵循格式<Qj, Sj , <Qj1, Aj1, ..., Qjk, Ajk> , Ij, Aj>，其中k表示子問題的數量，Qji和Aji分別表示第i個問題-第一個子問題和第i個子查詢。和之前一樣，Qj 和 Aj 分別表示英語和 SQL 的查詢，Sj 給出模式鏈接，Ij 是 NatSQL 中間表示。

Self-correction Module

生成的 SQL 查詢有時可能會缺少或冗余關鍵字，例如 DESC、DISTINCT 和聚合函數。我們對多個 LLM 的經驗表明，這些問題在較大的 LLM 中不太常見（例如，GPT-4 生成的查詢比 CodeX 生成的查詢具有更少的錯誤），但仍然存在。為了解決這個問題，我們提出了一個自我糾正模塊，指示模型糾正這些小錯誤。

這是在零樣本設置中實現的，其中僅向模型提供有錯誤的代碼，并要求模型修復錯誤。我們為自我糾正模塊提出了兩種不同的提示：通用和溫和。通過通用提示，我們要求模型識別并糾正“BUGGY SQL”中的錯誤。另一方面，溫和提示并不假設 SQL 查詢有錯誤，而是要求模型檢查任何潛在問題，并提供有關要檢查的子句的一些提示。我們的評估表明，通用提示可以在 CodeX 模型中產生更好的結果，而溫和的提示對于 GPT-4 模型更有效。除非另有明確說明，否則 DINSQL 中的默認自我更正提示對于 GPT-4 設置為“溫和”，對于 CodeX 設置為“通用”。

效果對比

spider的測試集上的執行精度（EX）和邏輯匹配精度（EM），使用GTP-4實現了最高的執行精度，使用CodeX Davinci實現了第三高的執行精度。

四、指標體系

什么是指標體系

我們在討論一個人是否健康的時候，常常會說出一些名詞：體溫、血壓、體脂率等。當一份體檢報告出具時，上面會羅列數十項體檢指標，而將這些指標綜合起來考量，大概就能了解一個人的健康狀況。若其中一向指標飄紅，那就說明身體的某項機能出了問題。

同樣，判斷一家公司的經營情況，可以通過指標對業務進行監控，可往往一個指標沒辦法解決復雜的業務問題，這就需要使用多個指標從不同維度來評估業務，也就是使用指標體系。

指標體系（Indication System）就是從不同維度梳理業務，把指標有系統地組織起來，形成的一個整體。

指標的理解

理解指標必須明確兩個重要的概念【度量】和【維度】，一個正確的指標必須包括度量和維度。“性別”是維度，“男性數量”，“女性數量”，“男性占比”，“女性占比”是度量；“城市”是維度，“一線城市占比”，“省會城市數量”，“GDP 大于 1 萬億的城市數量”是包含了維度和度量的指標。

指標都是匯總計算出來的，有聚合過程。例如單筆訂單的金額不能是一個指標，統計一天的訂單金額才是指標。指標需要維度進行多方面的描述分析，維度可以根據需要可以無限擴展，例如，月汽車銷量，可以增加城市維度、品牌維度、是否貸款維度等等，就可以變成：城市月汽車銷量，大眾汽車城市月銷量、有貸款的大眾汽車城市月銷量。

通過表格理解指標

一維表格

不存在單維表格，單一的值不能是指標，例如：

因為上面的表格沒有描述是誰的成交金額，單獨的一個值，無法描述這個值代表的什么事務、動作，以及在什么時間周期范圍內產生的這個聚合度量。

二維表格 時間周期

任何指標統計都離不開時間周期，可以說所有的指標都會涉及時間。對在一個時間段內發生的業務進行統計。例如過去 24 小時，一個自然日、自然周，這一年，從月初到現在，往前推 30 天等等，都是時間周期。

如果在表格中描述指標，則一定且必須最少是一個二維表格（至少有兩列），在表格中加入時間周期，就得到了這樣的結果：

業務范圍

如果確定了業務范圍，例如業務范圍=【短視頻】，度量是播放次數，并且把播放VV這個度量的時間范圍確定在天這個范圍內：

業務這一列用于描述這個度量的業務范圍，一般稱它為業務修飾詞，但通常在表格中，不會這么存放，第二列造成了冗余，一般都簡化掉這一列，收斂成兩列的形式，把業務范圍和度量合并：

業務范圍和維度的區別

業務范圍也是維度，只不過在指標計算的過程中，會從最宏觀的一面開始，習慣性的會定義一個范圍，要統計哪個業務的數據？你有 4 家水果店，別人要問你，你的日銷售額是什么？那你可能會問，是哪家門店？或者是我所有的門店？（相當于我自己的生意范圍）它本身就是一個維度（視角）來統計的。但把它抽離出來，是方便于對指標的管理與認知。公司大了，有很多分支業務的時候，你問 DAU 是多少，肯定會帶上業務前綴的。

多維表格

如果二維表格是最小集，那么加入更多的維度和度量，這個表格就變成多維表格，例如，修飾詞=【短視頻】，加入維度=【終端】和【是否會員】則多維表格是這樣的：

也可以在此基礎之上，增加度量，例如增加度量【播放時長】：

多維表格的表頭樣式就是這樣的：【維度 1】【維度 2】【維度 3】【維度 n…】【度量 1】【度量 2】【度量 3】【度量 n…】。

每一行的維度+單一度量都是一個指標

這里有一個很重要的思想統一，上面的多維表中每一行都是一個指標，每一行形成了指標的基本要求【維度】+【度量】。

經常會有一種情況，用戶在相互溝通指標時，沒有按照每一行是一個獨立指標來看待。

例如，會員在 ios 端的播放 vv 和會員在安卓端播放的 vv 是兩個不同的指標，很多人會認為指標是播放 vv，會員、終端都是描述指標的維度。這樣理解沒問題。因為視角不同。”指標是播放 vv，會員、終端都是描述指標的維度“是典型的管理視角。一行一個指標是應用視角，在描述指標的時候，就是確定在這一行的這個數字上，如果按照管理視角來看，那么指標就會有很多行。

如果多個人有多個理解方式，就一定會產生溝通成本。

條件限定

上面的多維表是正確表達指標的一種理想狀態，認為每一行都是一個可以解釋的指標。但實際使用情況不單單是用【維度】+【時間周期】+【度量】就可以完成指標的描述的。

用戶會隨著業務的需求，有很多臨時分析需要，隨時對指標進行條件的設定。

例如上面的表中，指標【短視頻播放時長】，需要對用戶做分類，就會有一定的條件限制：播放時長大于1小時的用戶，非會員且播放時長大于 1 小時的用戶。

這個例子中，把指標【短視頻播放時長】以及維度【是否會員】做了條件限制，用于描述指標【短視頻用戶數】。

這種情況非常常見，例如大于 18 歲的用戶，本科及以上學歷，用戶登錄次數大于 3 等等。度量、維度值，都可以當做條件作用于其他指標。

以上情況我們統稱為條件限定，條件限定擴大了指標的靈活性，可以基于實際的業務需要對指標進行數據剪裁。

條件限定和維度值的區別：

例如像 IOS 端，是一個維度值，單獨來看 IOS 端的短視頻用戶數，IOS 端可以表達維度，也可以用于條件限定，但是維度值是確定且單一的，它不能組合。

條件限定是靈活的，它可以用度量來限制、也可以組合各種維度值，例如渠道包括：1，系統直播 2，線下門店 3，淘寶 4、外部直播 5、分銷商，每一個數值都代表一個維度值，他是確定的觀察視角。條件限定可以是他們中任何數字的組合，比如 1 和 2，2 和 3，1 或者 2，2 或者 3，不是 1 和 2 等等，它是靈活多變的。

總結

1. 單獨存在的度量、維度都不是指標
2. 用表格描述指標的最小集是二維表，單獨一列沒有任何意義，不具備可讀性
3. 絕大多數指標都是多維表的形態：【維度 1】【維度 2】【維度 3】【維度 n…】【度量 1】【度量 2】【度量 3】【度量 n…】

1. 業務范圍幫助縮小和明確了處理數據和理解指標的范圍
2. 如果維度不斷增多，那么數據表就是一個很寬的表。也就是常說的“大寬表”
3. 條件限定的加入，產生了更靈活的指標形式

 指標模型

原子指標

原子指標是指數據分析中最小的可度量單元，通常是一個數值或一個計數。原子指標是數據分析的基礎，它們可以用來描述某個特定的事件、行為或狀態，如銷售額、訪問量、轉化率等。原子指標通常是不可再分的，因為它們已經是最小的可度量單元了。

按照上面的例子來說，原子指標可以理解為是度量，例如【銷售金額】【播放時長】【訪問次數】等等，這些度量是不可拆解的。

原子指標用于明確業務的統計口徑及計算邏輯。具備以下特性：

1. 原子指標是對指標統計口徑算法的一個抽象，等于業務過程（原子的業務動作）+ 統計方式。例如，支付（事件）金額（度量），曝光（事件）次數（度量）
2. 原子指標不會獨立存在，一定是結合業務范圍，維度進行組合才有意義
3. 原子指標加維度可以理解為一個度量在不同視角下的變化

原子指標通常是其他指標的基礎，可以通過對原子指標的分析來得出更高級別的指標。理解原子指標是整個指標管理模型中非常重要的一環。

派生指標

派生指標在業務限定的范圍內，由原子指標、時間周期、維度三大要素構成，用于統計目標指標在具體時間、維度、業務條件下的數值表現，反映某一業務活動的業務狀況。

例如上面講到的多維表中的每一行都是一個派生指標，也就是說，業務中用到的指標都是派生指標。

不同的派生指標可能具有相同的原子指標，這樣派生指標就定義了一種等價關系，而屬于相同的原子指標就構成了一個對指標體系的劃分。在每一個劃分中，存在一個可以派生出其他指標的最小派生指標，即最細粒度。

復合指標

派生指標的另一個類型是復合指標，如果把它單獨獨立出來也可以，如果把它歸類為原子指標也可以，取決于我們如何做數據的開發以及應用。先來看幾個復合指標的例子：

1. 平均銷售價格：派生指標是通過銷售額和銷售量計算得出的，它反映了每個產品的平均售價。原子指標是銷售額和銷售量。
2. 轉化率：派生指標是通過訪問量和轉化量計算得出的，它反映了每個渠道的轉化效果。原子指標是訪問量和轉化量。
3. 客戶生命周期價值：派生指標是通過客戶平均購買金額、購買頻率和客戶保留率計算得出的，它反映了每個客戶對企業的貢獻價值。原子指標是客戶購買金額、購買頻率和客戶保留率。

上面三個例子都是在原子指標間進行計算的原子級復合指標。

也可以通過兩個派生指標來計算復合指標，例如派生指標是：最近7天浙江 iPhone  的平均銷售價格 = 近7天浙江 iPhone 的銷售額 / 近7天浙江 iPhone 的銷售量。

指標要素

上面介紹了很多的概念，其實核心思想是統一對指標的認知和理解，每一個概念單獨去理解可能無法有一個整體的感受。可以看下圖，來完成對指標的整體理解：

我們把【原子指標】【時間周期】【業務范圍】【維度】【條件限定】統稱為指標要素，他們是指標的實體組織。

1. 原子指標：就是度量，它確定了統計目標和聚合方法
2. 時間周期：是一種特殊的維度，它確定了統計的時間范圍，從什么時間開始，從什么時間結束
3. 業務范圍：是一種特殊的維度，它確定了統計目標的范圍
4. 【時間周期】和【業務范圍】單獨拿出來，是為了更好的表達指標的意義
5. 條件限定：是對統計數據進行自由剪裁的過程
6. 維度：是用于觀察統計目標的視角，可以有”無限個“維度

指標要素的SQL表達方式

基于指標要素，我們可以把它和 SQL 關聯起來理解。便于了解數據的加工和實現過程,有益于從技術的視角理解指標要素。

先了解SQL的大結構

SQL 的核心作用就是從數據表中提取數據。操作對象是表，所以可以理解為：去哪張表里，以什么樣的條件，取哪些數據，要以什么樣的方法進行數據計算

SQL 的基本操作邏輯：

SELTECT --選取哪些字段：在這里提供字段的各種計算方式，例如SUM，MIX，MIN，IF, ELSE等，對這一列數據進行操作
FROM --從哪張表取：在這里提供單表、多表關聯（JOIN,不同表提取多列合并成一張表)、多表合并 UNION（不同表，但表結構相同，上下對齊成一張表）
WHERE --以什么樣的條件：在這里和SELECT一樣提供字段的各種計算方式，來限制取值范圍
GROUP BY,ORDER BY --組合與排序。

原子指標對應select

原子指標是度量，它確定了統計目標和聚合方法，在 SQL 中，它作用于 SELECT 范圍內。可以這么理解，SELECT 范圍內的內容就是【原子指標】。例如：

select count(order_ID)—>計算訂單數
select sum(order_amount)->計算訂單金額

業務范圍對應from

數據來源于哪張表，一定是確定了業務范圍，在數倉中，一般會對表進行分類，分類的規則會基于業務來進行，便于管理。例如：

select count(order_id) 
from dwd.order_list   --在訂單明細表中計算訂單數

條件限定對應where

條件限定，一般體現在 where 條件語句中。表達以什么樣的條件來看指標。例如：

-- 在訂單明細表中計算訂單金額大于100的訂單數
select count(order_id)
from dwd.order_list
where order_amount > 100

【時間周期】當作限定條件出現在where條件中

-- 在訂單明細表中計算2023年5月20日訂單金額大于100的訂單數
select count(order_id)
from dwd.order_list
where order_amount > 100 AND order_date=‘2023-05-20'

【維度值】當作條件出現在where條件中

-- 在訂單明細表中計算2023年5月20日訂單金額大于100且在杭州發生的訂單數
select count(order_id)
from dwd.order_list
where order_amount > 100 AND order_date='2023-05-20' AND city_name='北京'

維度對應group by

維度會參與 select 過程和 group by 過程。group by 的目的是分組，分組就是為了以不同的視角去看數據。

-- 在訂單明細表中計算2023年5月20日訂單金額大于100的訂單數, 按城市分組
select count(order_id)
      ,city_name
from dwd.order_list
where order_amount>100 AND order_date='2023-05-20' 
group by city_name

一張圖看指標要素與SQL結構的對應關系

知曉指標要素與 SQL 語句的對應關系，能夠對指標的實現過程有更深層次的理解。這里最重要的意義在于用戶對指標的定義能夠映射到技術方案上。能夠基于這層關系，對數據進行合理的建模、開發與使用。

指標要素管理

上面把指標抽象成指標要素便于我們統一對指標的理解，其實更重要的目的是便于使用與管理。管理上的意義在于能夠做到指標開發使用從無邊界到有邊界的過程，逐步收斂覆蓋，另一層面能夠做好統一的標準，最后由此做基礎，向上放射到不同的系統、環境中去，形成整體的生態。

覆蓋與收斂

根據派生指標的概念，通過【原子指標】+【維度】+【時間周期】+【條件限定】組成了一個派生指標，當每一個指標元素出現大于1的情況時，就會出現多個派生指標，計算方法是它們的乘積。

例如上面的情況，3個【原子指標】* 4個【維度值】* 3個【時間周期】* 2個【條件限定】= 72個派生指標。

指標在使用的過程中，不論是口頭交談還是系統展示，都會以上圖右邊的形式來體現，【視頻業務日銷售額】誰都可以讀懂。沒有哪個用戶去把指標拆解成這些要素來溝通，除非出現數據問題。所以我們在報表、匯報、業務溝通的過程中，都是如【視頻業務日銷售額】的指標形式體現出來的。

這樣對于管理有一個非常大的好處，可以基于指標要素的組合進行最大可能的使用覆蓋。

根據業務的實際訴求，完成分析體系的建設：確定分析框架，確定分析類別，確定分析場景等等，例如用戶行為分析、業績分析、經營分析、安全性分析、競對分析、財務分析..等多個場景。基于這些分析框架，可以逐步的抽象出指標要素，確定有多少個【原子指標】+【維度】，然后就可以大致的得出，能夠覆蓋”多少個“指標了。

這樣做的好處在于，業務用到的絕大多數指標，都是可以覆蓋在指標要素組成的這些結果之內的，指標管理者、開發者只需要關注指標要素的增減即可，不用根據具體的需求 CASE BY CASE 的去完成任務，大大減少了管理和開發成本，從而實現了”收斂“ 。

及時性提升

如果已經確定好指標要素【原子指標】+【維度】+【時間周期】+【條件限定】，這些指標就可以提前進行計算：

把指標要素組合的指標，提前進行預算，因為是結果集，即便是組合再多，也能控制在百萬、千萬級別，或者是分塊、分組來存儲，這樣就有數據量級小的特性，我們可以把結果存入到響應速度更快的內存數據庫中，完成”空間換時間“，解決大多數人無法等待超長時間的計算過程。即便數據科技技術發展到今天，如 SPARK、clickhouse 等大規模秒級響應的查詢技術已經很成熟了，這種空間換時間的方式依然非常受用。從成本的角度來講，非常劃算。

命名的統一性

如果使用指標要素的管理理念來生產、管理指標，在用戶使用指標的時候，可以做到指標名稱的統一性。

回顧來看，所有應用的指標都可以認為是派生指標，派生指標的指標元素中，有哪些可以參與命名，哪些不用參與命名：

指標的命名規范性，直接影響使用者對指標的理解，并能夠影響到整個指標使用的效果，如果命名不規范，會導致大家認知出現偏差，經常會出現不同名稱同一指標，甚至還有同一指標不同名稱的情況，增加大家的溝通對齊成本。

指標命名的基本原則：簡短易懂，便于傳播，不易出現理解偏差。

1. 時間周期：必須參與命名，累計、昨日、月度、周；時間周期最直接的圈定了統計的范圍，需要明確的展示在指標名稱上，簡單直接，避免不同人的理解歧義，減少錯誤發生的幾率。
2. 原子指標：必須參與命名，指標的核心。
3. 業務范圍：可參與命名，如果在系統、使用場景流程做的比較的情況下，可不用參與命名。例如，進入到”視頻業務“的專屬分析系統中，系統對業務有明確的劃分板塊，例如進入”電影“板塊，指標名稱就無需帶上【電影】這個業務范圍了，比如昨日電影播放量就可以直接寫成播放量即可。
4. 條件限定：不參與命名。條件限定有量個非常重要的特性，就是很容易變長，二是它出現在指標建立之后的靈活應用上，是臨時性效果。例如【昨日播放量】這個條件是：大于 18 歲，中國地區，IOS 端，會員，近 30 天未登錄的，如果參與命名的話就是：【會員 IOS 端中國區大于 18 歲其近 30 天未登錄的昨日播放量】這樣讀起來就非常別扭。而且組合條件還需要考慮語言的通順性，例如這樣組合【大于 18 歲中國區 IOS 端近 30 天未登錄會員昨日播放量】讀起來就會拗口。另外，很多條件限定都是臨時性提出的，例如年齡大于 18 歲，但是有可能隨時調整到 16 歲，如果按照人的年齡分布來講，我們可以從 1 歲到 100 歲這 100 個數字都當做限定條件，這樣指標就會無限增多膨脹，增大開發、管理、使用成本。
5. 維度：不參與指標命名，維度與條件限定相同，它具有無限擴展的情況，并且無法從語言上讓指標變得易于理解。例如【昨日播放量】支持維度：銷售渠道、城市、端、業務類型，加入維度后的命名是【昨日播放量銷售渠道城市端業務類型】這樣指標就變的不可讀。實際情況是維度在分析過程中參與 GROUP BY 過程，例如表格中的分組，報表中的下鉆過程，實際上指標命名帶上維度沒有意義，可以在應用的過程中，告知用戶支持什么維度。

一致性與生態

運用指標要素的指標管理模型，本質上是抽象+收斂的過程，確定少量的指標要素，覆蓋大多數的使用指標，減少開發、運維、管理和認知成本。一致性問題同樣可以在這個模型中被解決。

業務基于這個模型思路，去構建指標模型，并用系統加以管理，當做整個生態的底層基礎。

建立在這個模型之上，可以對接更上層的應用系統，例如報表工具，業務分析系統，用戶管理系統，經營分析系統等設計到指標應用的場景中，從而讓整個業務、數據分析系統生態中都利用起這個模型的思想。

五、總結

上面分享方案是理想的，真正能不能應用起來，是另一回事。現實是，一個小小的指標，可能經歷多個團隊，多年，多次治理，都達不到好的效果；對用戶來講，指標體系建設以及使用需要一定的學習、理解成本。

數據指標是一個需要認準解決方案（流程、標準、組織）長期持續做下去的事情，如果出現中斷或者反復，沉淀的經驗不能繼承，則很難達到指標準確、及時好用的狀態。學習成本以及運營同樣是一個非常重要的因素。再簡單的指標，也需要讀懂口徑、也需要明確指標在哪里看到的最準，數據出現了問題要找誰，需要一個完善指標體系建設。

六、團隊介紹

淘天業務技術用戶運營平臺技術團隊是一支懂用戶，技術驅動的年輕隊伍，以用戶為中心，通過技術創新提升用戶全生命周期體驗，持續為用戶創造價值。
團隊立足體系化打造業界領先的用戶增長基礎設施，以媒體外投平臺、ABTest平臺、用戶運營平臺為代表的基礎設施賦能阿里集團用戶增長，日均處理數據量千億規模、調用QPS千萬級。

本文轉載自大淘寶技術，作者：博通

原文鏈接：??https://mp.weixin.qq.com/s/HLDS3FEHZwoMn--x8mSGCg??