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

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

一、整體方案

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

指標(biāo)體系給到我們的是一個(gè)通用的數(shù)據(jù)語言，當(dāng)我們每一個(gè)人都用數(shù)據(jù)來溝通時(shí)，我們遇到的第一個(gè)障礙一定是缺乏通用的語言。就像普通話讓13 億中國人能夠自由溝通，數(shù)據(jù)的解釋權(quán)有一個(gè)標(biāo)準(zhǔn)一致的口徑也是非常重要的，是數(shù)據(jù)共享和協(xié)作的前提。

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

智能化的指標(biāo)應(yīng)用可以大幅提高數(shù)據(jù)指標(biāo)的用戶體驗(yàn)和效率。我們希望的場景是，用戶對著手機(jī)：“告訴我昨天的DAU、用戶留存、銷售額”，系統(tǒng)就能快速的反饋給用戶這三個(gè)指標(biāo)的結(jié)果，并且是準(zhǔn)確的。

指標(biāo)的加工處理到使用中間有很多過程，從數(shù)據(jù)沉淀->數(shù)倉加工->口徑定義->報(bào)表->系統(tǒng)->用戶，中間流程最直接的方式就是自然語言直接對接到數(shù)據(jù)。

通用方案

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

基于大模型

目標(biāo)：通過大模型技術(shù)，打造用戶在靈活搜索指標(biāo)的時(shí)候能夠快速反饋給用戶正確的指標(biāo)體驗(yàn)。

核心聚焦：

1. 讓系統(tǒng)盡可能的去理解自然語言，并準(zhǔn)確的把它轉(zhuǎn)換成可執(zhí)行的SQL。
2. 盡最大的可能覆蓋用戶的靈活需求，提高指標(biāo)要素組合的成指標(biāo)的組合數(shù)量。

基于LLM生成準(zhǔn)確可執(zhí)行SQL的關(guān)鍵思路：把指標(biāo)管理模型的定義、指標(biāo)要素等元數(shù)據(jù)信息送給LLM當(dāng)作prompt進(jìn)行指標(biāo)搜索與生成。

二、Text-to-SQL

Text-to-SQL（簡寫為T2S，或者是Text2SQL），顧名思義就是把文本轉(zhuǎn)化為SQL語言，更學(xué)術(shù)一點(diǎn)的定義是：把數(shù)據(jù)庫領(lǐng)域下的自然語言（Natural Language，簡寫為NL）問題，轉(zhuǎn)化為在關(guān)系型數(shù)據(jù)庫中可以執(zhí)行的結(jié)構(gòu)化查詢語言（Structured Query Language，簡寫為SQL）。

Text-to-SQL是什么

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

數(shù)據(jù)集

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

數(shù)據(jù)集的分類有單領(lǐng)域和交叉領(lǐng)域；有單輪對話和多輪對話；有簡單問題和復(fù)雜問題；有中文語言和英文語言；有單張表和多張表等。重點(diǎn)介紹兩個(gè)數(shù)據(jù)集：WikiSQL、Spider。

WikiSQL

WikiSQL數(shù)據(jù)集是目前規(guī)模最大的Text-to-SQL數(shù)據(jù)集，由2017年美國的Salesforce公司提出，場景來源于Wikipedia，屬于單領(lǐng)域。數(shù)據(jù)標(biāo)注采用外包。

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

Spider

Spider數(shù)據(jù)集是多數(shù)據(jù)庫、多表、單輪查詢的Text-to-SQL數(shù)據(jù)集，也是業(yè)界公認(rèn)難度最大的大規(guī)模跨領(lǐng)域評測榜單，由2018年耶魯大學(xué)提出，由11名耶魯大學(xué)學(xué)生標(biāo)注。

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

Spider數(shù)據(jù)集論文地址：https://arxiv.org/pdf/1809.08887.pdf。

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

評估指標(biāo)

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

執(zhí)行準(zhǔn)確率

定義：計(jì)算SQL執(zhí)行結(jié)果正確的數(shù)量在數(shù)據(jù)集中的比例。

缺點(diǎn)：存在高估的可能。因?yàn)橐粋€(gè)完全不同的非標(biāo)準(zhǔn)的SQL可能查出于與標(biāo)準(zhǔn)SQL相同的結(jié)果（例如，空結(jié)果），這時(shí)也會判為正確。

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

# groundtruth_SQL
SELECT sname FROM Student where age = 19；
# SQL執(zhí)行結(jié)果
null


# predict_SQL
SELECT sname FROM Student where age = 20；
# SQL執(zhí)行結(jié)果
null

邏輯形式準(zhǔn)確率

定義：計(jì)算模型生成的SQL和標(biāo)注SQL的匹配程度。

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

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

# groundtruth_SQL
SELECT sname,sno FROM Student where age = 19；
# SQL執(zhí)行結(jié)果
張三，123456


# predict_SQL
SELECT sno，sname FROM Student where age = 19；
# SQL執(zhí)行結(jié)果
123456，張三

研究方法

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

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

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

基于模板和匹配的方法

因?yàn)檩敵鯯QL本質(zhì)上：是一個(gè)符合語法、有邏輯結(jié)構(gòu)的序列，本身具有很強(qiáng)范式結(jié)構(gòu)，所以可以采取基于模板和規(guī)則的方法。簡單SQL語句都可以抽象成如下圖：

簡單SQL模板示例：

1. AGG表示聚合函數(shù)，如求MAX，計(jì)數(shù)COUNT，求MIN。
2. COLUMN表示需要查詢的目標(biāo)列。
3. WOP表示多個(gè)條件之間的關(guān)聯(lián)規(guī)則“與and /或 or”
4. 三元組 [COLUMN, OP, VALUE] 構(gòu)成了查詢條件，分別代表?xiàng)l件列、條件操作符（>、=、<等）、條件值。
5. *表示目標(biāo)列和查詢條件不止一個(gè)！

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

基于Seq2Seq框架的方法

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

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

可以發(fā)現(xiàn)的是，Text-to-SQL任務(wù)是符合N -> M機(jī)器翻譯任務(wù)的，處理機(jī)器翻譯任務(wù)最主流的方法是基于Seq2Seq框架方法，Seq2Seq是一種基于序列到序列模型的神經(jīng)網(wǎng)絡(luò)架構(gòu)，它由兩個(gè)部分組成：編碼器Encoder和解碼Decoder。因此，Text-to-SQL最主流的方法也是基于Seq2Seq框架。

更多學(xué)習(xí)和研究Text-to-SQL相關(guān)內(nèi)容，可以參考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領(lǐng)域的最新進(jìn)展：關(guān)于我們所擁有該領(lǐng)域的知識以及和所期盼的發(fā)展方向的綜述。

三、DIN-SQL

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

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

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

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

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

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

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

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

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

Schema Linking Module

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

Classification & Decomposition Module

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

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

SQL Generation Module

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

雖然更復(fù)雜的查詢可以從思路鏈?zhǔn)教崾局辛谐鲋虚g步驟中受益，但此類列表可能會降低更簡單任務(wù)的性能（Wei 等人，2022b）。在相同的基礎(chǔ)上，我們的查詢生成由三個(gè)模塊組成，每個(gè)模塊針對不同的類別。

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

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

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

Self-correction Module

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

這是在零樣本設(shè)置中實(shí)現(xiàn)的，其中僅向模型提供有錯(cuò)誤的代碼，并要求模型修復(fù)錯(cuò)誤。我們?yōu)樽晕壹m正模塊提出了兩種不同的提示：通用和溫和。通過通用提示，我們要求模型識別并糾正“BUGGY SQL”中的錯(cuò)誤。另一方面，溫和提示并不假設(shè) SQL 查詢有錯(cuò)誤，而是要求模型檢查任何潛在問題，并提供有關(guān)要檢查的子句的一些提示。我們的評估表明，通用提示可以在 CodeX 模型中產(chǎn)生更好的結(jié)果，而溫和的提示對于 GPT-4 模型更有效。除非另有明確說明，否則 DINSQL 中的默認(rèn)自我更正提示對于 GPT-4 設(shè)置為“溫和”，對于 CodeX 設(shè)置為“通用”。

效果對比

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

四、指標(biāo)體系

什么是指標(biāo)體系

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

同樣，判斷一家公司的經(jīng)營情況，可以通過指標(biāo)對業(yè)務(wù)進(jìn)行監(jiān)控，可往往一個(gè)指標(biāo)沒辦法解決復(fù)雜的業(yè)務(wù)問題，這就需要使用多個(gè)指標(biāo)從不同維度來評估業(yè)務(wù)，也就是使用指標(biāo)體系。

指標(biāo)體系（Indication System）就是從不同維度梳理業(yè)務(wù)，把指標(biāo)有系統(tǒng)地組織起來，形成的一個(gè)整體。

指標(biāo)的理解

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

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

通過表格理解指標(biāo)

一維表格

不存在單維表格，單一的值不能是指標(biāo)，例如：

因?yàn)樯厦娴谋砀駴]有描述是誰的成交金額，單獨(dú)的一個(gè)值，無法描述這個(gè)值代表的什么事務(wù)、動作，以及在什么時(shí)間周期范圍內(nèi)產(chǎn)生的這個(gè)聚合度量。

二維表格 時(shí)間周期

任何指標(biāo)統(tǒng)計(jì)都離不開時(shí)間周期，可以說所有的指標(biāo)都會涉及時(shí)間。對在一個(gè)時(shí)間段內(nèi)發(fā)生的業(yè)務(wù)進(jìn)行統(tǒng)計(jì)。例如過去 24 小時(shí)，一個(gè)自然日、自然周，這一年，從月初到現(xiàn)在，往前推 30 天等等，都是時(shí)間周期。

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

業(yè)務(wù)范圍

如果確定了業(yè)務(wù)范圍，例如業(yè)務(wù)范圍=【短視頻】，度量是播放次數(shù)，并且把播放VV這個(gè)度量的時(shí)間范圍確定在天這個(gè)范圍內(nèi)：

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

業(yè)務(wù)范圍和維度的區(qū)別

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

多維表格

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

也可以在此基礎(chǔ)之上，增加度量，例如增加度量【播放時(shí)長】：

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

每一行的維度+單一度量都是一個(gè)指標(biāo)

這里有一個(gè)很重要的思想統(tǒng)一，上面的多維表中每一行都是一個(gè)指標(biāo)，每一行形成了指標(biāo)的基本要求【維度】+【度量】。

經(jīng)常會有一種情況，用戶在相互溝通指標(biāo)時(shí)，沒有按照每一行是一個(gè)獨(dú)立指標(biāo)來看待。

例如，會員在 ios 端的播放 vv 和會員在安卓端播放的 vv 是兩個(gè)不同的指標(biāo)，很多人會認(rèn)為指標(biāo)是播放 vv，會員、終端都是描述指標(biāo)的維度。這樣理解沒問題。因?yàn)橐暯遣煌！敝笜?biāo)是播放 vv，會員、終端都是描述指標(biāo)的維度“是典型的管理視角。一行一個(gè)指標(biāo)是應(yīng)用視角，在描述指標(biāo)的時(shí)候，就是確定在這一行的這個(gè)數(shù)字上，如果按照管理視角來看，那么指標(biāo)就會有很多行。

如果多個(gè)人有多個(gè)理解方式，就一定會產(chǎn)生溝通成本。

條件限定

上面的多維表是正確表達(dá)指標(biāo)的一種理想狀態(tài)，認(rèn)為每一行都是一個(gè)可以解釋的指標(biāo)。但實(shí)際使用情況不單單是用【維度】+【時(shí)間周期】+【度量】就可以完成指標(biāo)的描述的。

用戶會隨著業(yè)務(wù)的需求，有很多臨時(shí)分析需要，隨時(shí)對指標(biāo)進(jìn)行條件的設(shè)定。

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

這個(gè)例子中，把指標(biāo)【短視頻播放時(shí)長】以及維度【是否會員】做了條件限制，用于描述指標(biāo)【短視頻用戶數(shù)】。

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

以上情況我們統(tǒng)稱為條件限定，條件限定擴(kuò)大了指標(biāo)的靈活性，可以基于實(shí)際的業(yè)務(wù)需要對指標(biāo)進(jìn)行數(shù)據(jù)剪裁。

條件限定和維度值的區(qū)別：

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

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

總結(jié)

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

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

 指標(biāo)模型

原子指標(biāo)

原子指標(biāo)是指數(shù)據(jù)分析中最小的可度量單元，通常是一個(gè)數(shù)值或一個(gè)計(jì)數(shù)。原子指標(biāo)是數(shù)據(jù)分析的基礎(chǔ)，它們可以用來描述某個(gè)特定的事件、行為或狀態(tài)，如銷售額、訪問量、轉(zhuǎn)化率等。原子指標(biāo)通常是不可再分的，因?yàn)樗鼈円呀?jīng)是最小的可度量單元了。

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

原子指標(biāo)用于明確業(yè)務(wù)的統(tǒng)計(jì)口徑及計(jì)算邏輯。具備以下特性：

1. 原子指標(biāo)是對指標(biāo)統(tǒng)計(jì)口徑算法的一個(gè)抽象，等于業(yè)務(wù)過程（原子的業(yè)務(wù)動作）+ 統(tǒng)計(jì)方式。例如，支付（事件）金額（度量），曝光（事件）次數(shù)（度量）
2. 原子指標(biāo)不會獨(dú)立存在，一定是結(jié)合業(yè)務(wù)范圍，維度進(jìn)行組合才有意義
3. 原子指標(biāo)加維度可以理解為一個(gè)度量在不同視角下的變化

原子指標(biāo)通常是其他指標(biāo)的基礎(chǔ)，可以通過對原子指標(biāo)的分析來得出更高級別的指標(biāo)。理解原子指標(biāo)是整個(gè)指標(biāo)管理模型中非常重要的一環(huán)。

派生指標(biāo)

派生指標(biāo)在業(yè)務(wù)限定的范圍內(nèi)，由原子指標(biāo)、時(shí)間周期、維度三大要素構(gòu)成，用于統(tǒng)計(jì)目標(biāo)指標(biāo)在具體時(shí)間、維度、業(yè)務(wù)條件下的數(shù)值表現(xiàn)，反映某一業(yè)務(wù)活動的業(yè)務(wù)狀況。

例如上面講到的多維表中的每一行都是一個(gè)派生指標(biāo)，也就是說，業(yè)務(wù)中用到的指標(biāo)都是派生指標(biāo)。

不同的派生指標(biāo)可能具有相同的原子指標(biāo)，這樣派生指標(biāo)就定義了一種等價(jià)關(guān)系，而屬于相同的原子指標(biāo)就構(gòu)成了一個(gè)對指標(biāo)體系的劃分。在每一個(gè)劃分中，存在一個(gè)可以派生出其他指標(biāo)的最小派生指標(biāo)，即最細(xì)粒度。

復(fù)合指標(biāo)

派生指標(biāo)的另一個(gè)類型是復(fù)合指標(biāo)，如果把它單獨(dú)獨(dú)立出來也可以，如果把它歸類為原子指標(biāo)也可以，取決于我們?nèi)绾巫鰯?shù)據(jù)的開發(fā)以及應(yīng)用。先來看幾個(gè)復(fù)合指標(biāo)的例子：

1. 平均銷售價(jià)格：派生指標(biāo)是通過銷售額和銷售量計(jì)算得出的，它反映了每個(gè)產(chǎn)品的平均售價(jià)。原子指標(biāo)是銷售額和銷售量。
2. 轉(zhuǎn)化率：派生指標(biāo)是通過訪問量和轉(zhuǎn)化量計(jì)算得出的，它反映了每個(gè)渠道的轉(zhuǎn)化效果。原子指標(biāo)是訪問量和轉(zhuǎn)化量。
3. 客戶生命周期價(jià)值：派生指標(biāo)是通過客戶平均購買金額、購買頻率和客戶保留率計(jì)算得出的，它反映了每個(gè)客戶對企業(yè)的貢獻(xiàn)價(jià)值。原子指標(biāo)是客戶購買金額、購買頻率和客戶保留率。

上面三個(gè)例子都是在原子指標(biāo)間進(jìn)行計(jì)算的原子級復(fù)合指標(biāo)。

也可以通過兩個(gè)派生指標(biāo)來計(jì)算復(fù)合指標(biāo)，例如派生指標(biāo)是：最近7天浙江 iPhone  的平均銷售價(jià)格 = 近7天浙江 iPhone 的銷售額 / 近7天浙江 iPhone 的銷售量。

指標(biāo)要素

上面介紹了很多的概念，其實(shí)核心思想是統(tǒng)一對指標(biāo)的認(rèn)知和理解，每一個(gè)概念單獨(dú)去理解可能無法有一個(gè)整體的感受。可以看下圖，來完成對指標(biāo)的整體理解：

我們把【原子指標(biāo)】【時(shí)間周期】【業(yè)務(wù)范圍】【維度】【條件限定】統(tǒng)稱為指標(biāo)要素，他們是指標(biāo)的實(shí)體組織。

1. 原子指標(biāo)：就是度量，它確定了統(tǒng)計(jì)目標(biāo)和聚合方法
2. 時(shí)間周期：是一種特殊的維度，它確定了統(tǒng)計(jì)的時(shí)間范圍，從什么時(shí)間開始，從什么時(shí)間結(jié)束
3. 業(yè)務(wù)范圍：是一種特殊的維度，它確定了統(tǒng)計(jì)目標(biāo)的范圍
4. 【時(shí)間周期】和【業(yè)務(wù)范圍】單獨(dú)拿出來，是為了更好的表達(dá)指標(biāo)的意義
5. 條件限定：是對統(tǒng)計(jì)數(shù)據(jù)進(jìn)行自由剪裁的過程
6. 維度：是用于觀察統(tǒng)計(jì)目標(biāo)的視角，可以有”無限個(gè)“維度

指標(biāo)要素的SQL表達(dá)方式

基于指標(biāo)要素，我們可以把它和 SQL 關(guān)聯(lián)起來理解。便于了解數(shù)據(jù)的加工和實(shí)現(xiàn)過程,有益于從技術(shù)的視角理解指標(biāo)要素。

先了解SQL的大結(jié)構(gòu)

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

SQL 的基本操作邏輯：

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

原子指標(biāo)對應(yīng)select

原子指標(biāo)是度量，它確定了統(tǒng)計(jì)目標(biāo)和聚合方法，在 SQL 中，它作用于 SELECT 范圍內(nèi)。可以這么理解，SELECT 范圍內(nèi)的內(nèi)容就是【原子指標(biāo)】。例如：

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

業(yè)務(wù)范圍對應(yīng)from

數(shù)據(jù)來源于哪張表，一定是確定了業(yè)務(wù)范圍，在數(shù)倉中，一般會對表進(jìn)行分類，分類的規(guī)則會基于業(yè)務(wù)來進(jìn)行，便于管理。例如：

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

條件限定對應(yīng)where

條件限定，一般體現(xiàn)在 where 條件語句中。表達(dá)以什么樣的條件來看指標(biāo)。例如：

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

【時(shí)間周期】當(dāng)作限定條件出現(xiàn)在where條件中

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

【維度值】當(dāng)作條件出現(xiàn)在where條件中

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

維度對應(yīng)group by

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

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

一張圖看指標(biāo)要素與SQL結(jié)構(gòu)的對應(yīng)關(guān)系

知曉指標(biāo)要素與 SQL 語句的對應(yīng)關(guān)系，能夠?qū)χ笜?biāo)的實(shí)現(xiàn)過程有更深層次的理解。這里最重要的意義在于用戶對指標(biāo)的定義能夠映射到技術(shù)方案上。能夠基于這層關(guān)系，對數(shù)據(jù)進(jìn)行合理的建模、開發(fā)與使用。

指標(biāo)要素管理

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

覆蓋與收斂

根據(jù)派生指標(biāo)的概念，通過【原子指標(biāo)】+【維度】+【時(shí)間周期】+【條件限定】組成了一個(gè)派生指標(biāo)，當(dāng)每一個(gè)指標(biāo)元素出現(xiàn)大于1的情況時(shí)，就會出現(xiàn)多個(gè)派生指標(biāo)，計(jì)算方法是它們的乘積。

例如上面的情況，3個(gè)【原子指標(biāo)】* 4個(gè)【維度值】* 3個(gè)【時(shí)間周期】* 2個(gè)【條件限定】= 72個(gè)派生指標(biāo)。

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

這樣對于管理有一個(gè)非常大的好處，可以基于指標(biāo)要素的組合進(jìn)行最大可能的使用覆蓋。

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

這樣做的好處在于，業(yè)務(wù)用到的絕大多數(shù)指標(biāo)，都是可以覆蓋在指標(biāo)要素組成的這些結(jié)果之內(nèi)的，指標(biāo)管理者、開發(fā)者只需要關(guān)注指標(biāo)要素的增減即可，不用根據(jù)具體的需求 CASE BY CASE 的去完成任務(wù)，大大減少了管理和開發(fā)成本，從而實(shí)現(xiàn)了”收斂“ 。

及時(shí)性提升

如果已經(jīng)確定好指標(biāo)要素【原子指標(biāo)】+【維度】+【時(shí)間周期】+【條件限定】，這些指標(biāo)就可以提前進(jìn)行計(jì)算：

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

命名的統(tǒng)一性

如果使用指標(biāo)要素的管理理念來生產(chǎn)、管理指標(biāo)，在用戶使用指標(biāo)的時(shí)候，可以做到指標(biāo)名稱的統(tǒng)一性。

回顧來看，所有應(yīng)用的指標(biāo)都可以認(rèn)為是派生指標(biāo)，派生指標(biāo)的指標(biāo)元素中，有哪些可以參與命名，哪些不用參與命名：

指標(biāo)的命名規(guī)范性，直接影響使用者對指標(biāo)的理解，并能夠影響到整個(gè)指標(biāo)使用的效果，如果命名不規(guī)范，會導(dǎo)致大家認(rèn)知出現(xiàn)偏差，經(jīng)常會出現(xiàn)不同名稱同一指標(biāo)，甚至還有同一指標(biāo)不同名稱的情況，增加大家的溝通對齊成本。

指標(biāo)命名的基本原則：簡短易懂，便于傳播，不易出現(xiàn)理解偏差。

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

一致性與生態(tài)

運(yùn)用指標(biāo)要素的指標(biāo)管理模型，本質(zhì)上是抽象+收斂的過程，確定少量的指標(biāo)要素，覆蓋大多數(shù)的使用指標(biāo)，減少開發(fā)、運(yùn)維、管理和認(rèn)知成本。一致性問題同樣可以在這個(gè)模型中被解決。

業(yè)務(wù)基于這個(gè)模型思路，去構(gòu)建指標(biāo)模型，并用系統(tǒng)加以管理，當(dāng)做整個(gè)生態(tài)的底層基礎(chǔ)。

建立在這個(gè)模型之上，可以對接更上層的應(yīng)用系統(tǒng)，例如報(bào)表工具，業(yè)務(wù)分析系統(tǒng)，用戶管理系統(tǒng)，經(jīng)營分析系統(tǒng)等設(shè)計(jì)到指標(biāo)應(yīng)用的場景中，從而讓整個(gè)業(yè)務(wù)、數(shù)據(jù)分析系統(tǒng)生態(tài)中都利用起這個(gè)模型的思想。

五、總結(jié)

上面分享方案是理想的，真正能不能應(yīng)用起來，是另一回事。現(xiàn)實(shí)是，一個(gè)小小的指標(biāo)，可能經(jīng)歷多個(gè)團(tuán)隊(duì)，多年，多次治理，都達(dá)不到好的效果；對用戶來講，指標(biāo)體系建設(shè)以及使用需要一定的學(xué)習(xí)、理解成本。

數(shù)據(jù)指標(biāo)是一個(gè)需要認(rèn)準(zhǔn)解決方案（流程、標(biāo)準(zhǔn)、組織）長期持續(xù)做下去的事情，如果出現(xiàn)中斷或者反復(fù)，沉淀的經(jīng)驗(yàn)不能繼承，則很難達(dá)到指標(biāo)準(zhǔn)確、及時(shí)好用的狀態(tài)。學(xué)習(xí)成本以及運(yùn)營同樣是一個(gè)非常重要的因素。再簡單的指標(biāo)，也需要讀懂口徑、也需要明確指標(biāo)在哪里看到的最準(zhǔn)，數(shù)據(jù)出現(xiàn)了問題要找誰，需要一個(gè)完善指標(biāo)體系建設(shè)。

六、團(tuán)隊(duì)介紹

淘天業(yè)務(wù)技術(shù)用戶運(yùn)營平臺技術(shù)團(tuán)隊(duì)是一支懂用戶，技術(shù)驅(qū)動的年輕隊(duì)伍，以用戶為中心，通過技術(shù)創(chuàng)新提升用戶全生命周期體驗(yàn)，持續(xù)為用戶創(chuàng)造價(jià)值。
團(tuán)隊(duì)立足體系化打造業(yè)界領(lǐng)先的用戶增長基礎(chǔ)設(shè)施，以媒體外投平臺、ABTest平臺、用戶運(yùn)營平臺為代表的基礎(chǔ)設(shè)施賦能阿里集團(tuán)用戶增長，日均處理數(shù)據(jù)量千億規(guī)模、調(diào)用QPS千萬級。

本文轉(zhuǎn)載自大淘寶技術(shù)，作者：博通

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