大模型与数据分析：探索Text-to-SQL
大模型火得一塌糊涂，作为长期泡在数据领域的人，自然要盯紧LLM在数据分析里怎么落地。市面上已经冒出来不少AI数智助手，像火山引擎VeDI的AI助手、Kyligence Copilot、ThoughtSpot这些，路子都很像——接上大模型，让数据查询和分析的效率往上跳一个台阶。说到底，这类智能数据分析助手就是靠对话式分析技术，让每个人都能随时跟数据唠嗑，系统还能根据用户反馈自己学、自己迭代，最后连数据分析的结果也能在团队里共享。
说起来，数据分析的发展其实经历了几个有意思的阶段。第一阶段是静态报表时代，传统BI和固定报表基本是给开发部门准备的，业务部门提需求，开发用报表工具整出固定报表，业务等着看结果就行。第二阶段是敏捷BI自助式分析，业务提出需求后，数据分析师可以靠敏捷BI工具快速捞数据、出结果，效率提升了不少。到了第三阶段，不管是大模型驱动的AskBI还是增强分析，思路都直接对准业务部门，核心理念是让业务自己用对话式BI工具就能搞定问题、拿到数据结果，再也不用像以前那样依赖开发部门做报表，或者等着数据分析师拿敏捷BI出结果，业务自己就能把事儿推下去。
整体方案
调研了好几家AI数智助手之后发现，实现智能数据分析的核心抓手有两个：一个是以指标为中心，另一个是大模型。业内也梳理出了如何把指标平台和AI技术落地的具体方案，核心观点很清晰——让人人都能用上数据，等于AI Copilot加上指标体系，再加上合理的成本。
指标体系说白了就是一套通用的数据语言。当大家都想用数据沟通时，第一个坎儿肯定是缺一个通用语言——就像普通话能让十几亿人自由交流一样，数据的解释权必须有一个标准一致的口径，这是数据共享和协作的前提。
指标数据最理想的使用场景是什么？要说就要有，数据得准，还能可视化展示。用户希望随时能查到自己想要的业务指标数据，大多数人其实都有自己的渠道和方法去拿数据，但问题在于得熟悉系统怎么操作，数据内容可能得提前预设好，如果要某个指标，就得等支持的人有空，或者排期开发。虽说每个人都能各显神通把数据拿到手，但从用户体验来看，操作和时间成本还是摆在那儿的。
智能化的指标应用能大幅提升数据指标的体验和效率。理想的场景是，用户对着手机说一句“告诉我昨天的DAU、用户留存、销售额”，系统就能快速准确地返回这三个指标的结果。
指标的加工处理到最终使用，中间经过的环节不少：数据沉淀、数仓加工、口径定义、报表、系统、再到用户。这条链条上最直接的方式，就是让自然语言直接对接数据。
通用方案
通用的做法是基于指标要素生产出指标的模型（提前把各种可能性都预算好），然后通过NLP技术，把自然语言翻译成SQL，直接去读指标模型。大体技术思路如下。
基于大模型
目标很清楚：靠大模型技术，让用户在灵活搜索指标时，系统能快速反馈出正确结果。
核心要聚焦两个点：一是让系统尽可能理解自然语言，准确转成可执行的SQL；二是尽可能覆盖用户的灵活需求，提高指标要素组合成指标的数量。
基于LLM生成准确可执行SQL的关键思路，就是把指标管理模型的定义、指标要素这些元数据信息，塞给LLM当prompt，用来搜索和生成指标。
Text-to-SQL
Text-to-SQL是什么
Text-to-SQL，简写T2S或者Text2SQL，顾名思义就是把文本转化成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，属于单领域，数据标注外包完成。包含80654个自然语言问题和77840个SQL语句，涉及26521张数据库表，每个库只有一张表。预测的SQL形式比较简单，基本是一个SQL主句加上0-3个WHERE子句条件。
问题示例与对应的SQL语句如下图所示。
Spider
Spider是多数据库、多表、单轮查询的Text-to-SQL数据集，也是业界公认难度最大的大规模跨领域评测榜单，2018年由耶鲁大学提出，11名耶鲁学生标注。包含10181个自然语言问题和5693个SQL语句，涉及138个领域的200多个数据库。难易程度分为简单、中等、困难、特别困难。
论文地址：https://arxiv.org/pdf/1809.08887.pdf
CSpider是西湖大学在EMNLP 2019上提出的中文Text-to-SQL数据集，把Spider作为源数据集进行问题翻译，并用SyntaxSQLNet作为基线测试，同时探索了中文带来的额外挑战，比如问题到数据库的映射、中文分词及其他语言现象。
评估指标
目前广泛使用的两个指标是执行准确率（Execution Accuracy，简称EX）和逻辑形式准确率（Exact Match，简称EM）。
执行准确率
定义：计算SQL执行结果正确的数量在数据集中的比例。缺点是有高估的可能——一个完全不同的非标准SQL，可能会查出和标准SQL相同的结果（比如空结果），这时也会被判对。
举个例子：有个学生表，想查年龄等于19的学生姓名，标准SQL是“SELECT sname FROM Student where age = 19”，执行结果null；模型预测的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列的顺序不同或查询目的完全相同但写法不同。为了解决这部分问题，有研究提出了查询匹配精度query match accuracy：把生成的SQL和标注SQL都用标准形式表示，再计算匹配精度。这种方法只解决了排序导致的误判。另外，对列和表排序并使用标准化别名来规范化SQL，也能消除不同格式导致的误判。
还是学生表的例子：想查年龄等于19的学生姓名和学生学号，标准SQL是“SELECT sname,sno FROM Student where age = 19”，执行结果（张三，123456）；模型预测的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）来显式加强编码端的对齐关系和结构信息；用树形结构解码、填槽类解码来缩小搜索解空间，提高SQL正确性；用中间表示技术提高SQL的抽象性；定义新的对齐特征，用重排序技术从beamsearch得到的多条候选里挑出正确答案；还有非常有效的数据增强方法。
基于模板和匹配的方法
SQL本质上是一个符合语法、有逻辑结构的序列，本身有很强的范式结构，所以可以采取基于模板和规则的方法。简单SQL都能被抽象成固定模板。
简单SQL模板示例：
- AGG表示聚合函数，比如求MAX、COUNT、MIN。
- COLUMN表示需要查询的目标列。
- WOP表示多个条件之间的关联规则——and/or。
- 三元组[COLUMN, OP, VALUE]构成查询条件，分别代表条件列、条件操作符（>、=、<等）、条件值。
- *表示目标列和查询条件不止一个。
基于模板和匹配的方法是早期研究方法，适用于简单SQL，定义后的SQL准确率高；但不适合复杂SQL，没定义模板的SQL识别不了。
基于Seq2Seq框架的方法
Text-to-SQL研究本质上属于NLP。NLP中常见任务大致分四种场景（N和M代表token数量）：1→N生成任务（如图片输出文本描述）、N→1分类任务（如句子情感分类）、N→N序列标注任务（如词性标注）、N→M机器翻译任务（如中文翻译成英文）。
Text-to-SQL正好符合N→M机器翻译任务，处理这类任务最主流的方法就是基于Seq2Seq框架，由编码器Encoder和解码Decoder两部分组成。所以Text-to-SQL最主流的方法也是基于Seq2Seq框架。
更多学习内容可以参考两篇综述：A Survey on Text-to-SQL Parsing: Concepts, Methods, and Future Directions和Recent Advances in Text-to-SQL: A Survey of What We Ha ve and What We Expect。
DIN-SQL
2022年底ChatGPT爆火，按理说LLM凭借强大的逻辑推理、上下文学习和情景联系，应该能超过seq2seq、BERT这些模型。但用少样本、零样本提示方法让LLM解决NL2SQL，效果反而比不上之前的模型。今天分享的这篇来自NLP顶会的论文正好解决了这个问题——怎么改进Prompt让LLM超越以前的方法，并且在Spider数据集上霸榜。
论文原文：DIN-SQL: Decomposed In-Context Learning of Text-to-SQL with Self-Correction
摘要：我们研究把复杂的Text-to-SQL任务分解成更小的子任务，以及这种分解如何显著提升LLM在推理时的性能。目前，在Spider这样的挑战性数据集上，微调模型的性能和用LLM做提示方法之间有明显差距。我们证明，SQL查询的生成可以分解成子问题，把这些子问题的解决方案输入LLM，能显著提升性能。我们在三个LLM上做的实验表明，这种方法持续把简单的小样本性能提升约10%，把LLM的准确性推向或超越SOTA。在Spider的Holdout测试集上，执行准确率的SOTA是79.9，我们方法的SOTA达到85.3。我们的上下文学习方法比许多经过严格调整的模型至少高出5%。
这篇论文提出了一种基于少样本提示Few-shot Prompt的新颖方法，把Text-to-SQL任务分解成多个步骤。
编写SQL查询的思维过程可以分解为：检测与查询相关的数据库表和列；识别复杂查询的一般结构（如分组、嵌套、多重联接、集合运算等）；制定任何可识别的过程子组件；根据子问题的解决方案编写最终查询。
基于这个思维过程，Text-to-SQL方法被分解为4个模块：模式链接、查询分类和分解、SQL生成、自我修正。
如果问题被分解到正确的粒度级别，LLM就有能力解决所有这些问题。
Schema Linking Module
模式链接负责识别自然语言查询中对数据库模式和条件值的引用。这被证明有助于跨领域的通用性和复杂查询的合成，是几乎所有现有Text-to-SQL方法的关键初步步骤。在案例中，这也是LLM失败次数最多的一个类别。我们设计了基于提示的模式链接模块，提示包括从Spider训练集中随机选的10个样本，按思路链模板组织，以“让我们一步一步思考”开头，正如Kojima等人建议的那样。对于问题中每次提到的列名，都会从给定数据库模式中选择相应列及其表。同时从问题中提取可能的实体和单元格值。
Classification & Decomposition Module
对于每个连接，都可能存在未检测到正确表或连接条件的情况。随着查询中联接数量的增加，至少一个联接无法正确生成的可能性也会增加。缓解方法之一是引入一个模块来检测要连接的表。此外，有些查询有过程组件，比如不相关的子查询，可以独立生成并与主查询合并。
为此，我们引入查询分类和分解模块。该模块把每个查询分为三类：简单、非嵌套复杂和嵌套复杂。简单类包括无需连接或嵌套的单表查询；非嵌套类包括需要连接但没有子查询的查询；嵌套类中的查询可以需要连接、子查询和集合操作。类标签对查询生成模块很重要，不同查询类用不同提示。除了类标签，查询分类和分解还检测要为非嵌套和嵌套查询连接的表集，以及可能为嵌套查询检测到的任何子查询。
SQL Generation Module
查询越来越复杂时，必须加入额外的中间步骤来弥合自然语言问题和SQL语句之间的差距。这种差距在文献中被称为不匹配问题，对SQL生成构成重大挑战，因为SQL主要是为查询关系数据库设计的，而不是表示自然语言中的含义。
虽然复杂查询可以从思路链式提示中的中间步骤里受益，但这类列表可能会降低简单任务的性能。基于此，我们的查询生成由三个模块组成，每个模块针对不同类别。
对于简单类的问题，没有中间步骤的简单少量提示就够用了，示例格式
非嵌套复杂类包括需要连接的查询。错误分析表明，在简单几次提示下，找到正确的列和外键来连接两个表对LLM来说可能有挑战，特别是当查询需要连接多个表时。为了解决这个问题，我们采用中间表示来弥合查询和SQL之间的差距。文献中已有各种中间表示，其中SemQL去掉了在自然语言查询中没有明确对应的运算符JOIN ON、FROM和GROUP BY，合并了HA VING和WHERE子句；NatSQL基于SemQL构建并删除了集合运算符。我们使用NatSQL作为中间表示，它与其他模型结合使用时显示出SOTA性能。非嵌套复杂类的示例格式
嵌套复杂类是最复杂的类型，在生成最终答案前需要几个中间步骤。这类不仅包含需要使用嵌套和集合操作（如EXCEPT、UNION、INTERSECT）的子查询，还需要多个表连接。为了把问题进一步分解成多个步骤，我们对这类提示的设计方式是让LLM先解决子查询，再用它们生成最终答案。提示格式
Self-correction Module
生成的SQL有时可能缺少或冗余关键字，比如DESC、DISTINCT和聚合函数。对多个LLM的经验表明，大模型里这些问题不太常见（GPT-4比CodeX错误更少），但仍然存在。为此，我们提出自我纠正模块，指示模型纠正这些小错误。
这是在零样本设置中实现的，只向模型提供有错误的代码，要求模型修复错误。我们设计了两种不同的提示：通用和温和。通用提示要求模型识别并纠正“BUGGY SQL”中的错误；温和提示不假设SQL有错误，而是要求模型检查潜在问题，并提供一些检查子句的提示。评估表明，通用提示在CodeX模型中效果更好，温和提示对GPT-4更有效。
效果对比
在Spider测试集上，用GPT-4实现了最高的执行精度，用CodeX Da vinci实现了第三高的执行精度。
指标体系
什么是指标体系
聊一个人是否健康时，常会说起体温、血压、体脂率这些词。体检报告上罗列几十项指标，综合起来能看出一个人的健康状况，某项指标飘红就说明身体某个机能出了问题。
同样，判断一家公司的经营情况，可以通过指标来监控业务，但一个指标往往解决不了复杂问题，需要用多个指标从不同维度评估业务——这就是指标体系。
指标体系，就是从不同维度梳理业务，把指标有系统地组织起来，形成一个整体。
指标的理解
理解指标必须先明确两个重要概念：度量和维度。一个正确的指标必须包括两者。比如“性别”是维度，“男性数量”、“女性数量”、“男性占比”、“女性占比”是度量；“城市”是维度，“一线城市占比”、“省会城市数量”、“GDP大于1万亿的城市数量”是包含了维度和度量的指标。
指标都是汇总计算出来的，有聚合过程。单笔订单金额不能算指标，统计一天的总金额才算。指标需要维度进行多方面的描述分析，维度可以根据需要无限扩展。比如月汽车销量，可以加城市维度、品牌维度、是否贷款维度，变成城市月汽车销量、大众汽车城市月销量、有贷款的大众汽车城市月销量。
通过表格理解指标
一维表格
不存在单维表格，单一的值不能是指标。比如下面这个表格：
| 成交金额 |
| 2000 |
因为它没有描述是谁的成交金额，单独一个值无法指代什么事物、动作，以及什么时间周期内产生的聚合度量。
二维表格——时间周期
任何指标统计都离不开时间周期，几乎所有指标都会涉及时间——对一段时间内发生的业务进行统计，比如过去24小时、一个自然日、自然周、这一年、从月初到现在等。如果在表格里描述指标，最少得是二维表格（至少两列）。加入时间周期后得到：
| 时间 | 成交金额 |
| day1 | 2000 |
| 最近7天 | 5000 |
业务范围
如果确定了业务范围，比如业务范围=【短视频】，度量是播放次数，时间范围定在“天”：
| 时间周期 | 业务 | 播放次数 |
| day1 | 短视频 | xxxx |
| day2 | 短视频 | xxxx |
| dayn | 短视频 | xxxx |
业务这一列用于描述度量的业务范围，一般称为业务修饰词。但通常表格里不会这么放，第二列造成冗余，所以一般简化为两列，把业务范围和度量合并：
| 时间周期 | 短视频播放次数 |
| day1 | xxxx |
| day2 | xxxx |
| day3 | xxxx |
业务范围和维度的区别
业务范围其实也是维度，只不过在指标计算过程中，会从最宏观的一面开始，习惯性定义一个范围：要统计哪个业务的数据？你有4家水果店，别人问日销售额，你可能会反问是哪家门店，还是所有门店（相当于自己的生意范围）？它本身就是一个维度（视角）来统计的。把它抽离出来，是为了方便指标的管理和认知。公司大了、分支业务多了，问DAU多少肯定会带上业务前缀。
多维表格
如果二维表格是最小集，加入更多维度和度量，就变成多维表格。比如修饰词=【短视频】，加入维度=【终端】和【是否会员】：
| 时间周期 | 终端 | 是否会员 | 短视频播放vv |
| day1 | ios | 是 | xxxx |
| day1 | 安卓 | 是 | xxxx |
| day1 | ios | 否 | xxxx |
| day1 | 安卓 | 否 | xxxx |
| day1 | all | all | xxxx |
| day2 | ios | 是 | xxxx |
| day2 | 安卓 | 是 | xxxx |
也可以在此基础上增加度量，比如增加【播放时长】：
| 时间周期 | 终端 | 是否会员 | 短视频播放vv | 短视频播放时长 |
| day1 | ios | 是 | xxxx | xxxx |
| day1 | 安卓 | 是 | xxxx | xxxx |
| day1 | ios | 否 | xxxx | xxxx |
| day1 | 安卓 | 否 | xxxx | xxxx |
| day1 | all | all | xxxx | xxxx |
多维表格的表头格式就是：【维度1】【维度2】【维度3】【维度n…】【度量1】【度量2】【度量3】【度量n…】。
每一行的维度+单一度量都是一个指标
这里有一个重要的思想统一：上面多维表中的每一行都是一个指标，每一行形成了指标的基本要求——【维度】+【度量】。日常中经常出现一种情况，用户沟通指标时没有按“每一行是一个独立指标”来看待。比如“会员在ios端的播放vv”和“会员在安卓端的播放vv”是两个不同指标。很多人会认为“指标是播放vv，会员、终端都是描述指标的维度”——这种理解也没问题，只是视角不同。“指标是播放vv，会员、终端都是描述指标的维度”是典型的管理视角，一行一个指标是应用视角。描述指标时，就是确定在这一行的数字上。如果按管理视角看，指标就会有很多行。多个人有多种理解方式，一定会产生沟通成本。
条件限定
上面的多维表是正确表达指标的一种理想状态，认为每一行都是一个可解释的指标。但实际使用中，光靠【维度】+【时间周期】+【度量】不一定能完成指标的描述。
用户会随业务需求产生很多临时分析需要，随时对指标设置条件。比如上面表格中的指标【短视频播放时长】，需要对用户分类，就会加条件限制：播放时长大于1小时的用户，非会员且播放时长大于1小时的用户。这个例子中，把指标【短视频播放时长】和维度【是否会员】做了条件限制，用于描述指标【短视频用户数】。
| 时间周期 | 终端 | 条件限定 | 短视频用户数 |
| day1 | ios | 【播放时长】>1小时 | xxxx |
| day1 | 安卓 | 【播放时长】>1小时&非会员 | xxxx |
这种情况非常常见，比如大于18岁的用户、本科及以上学历、用户登录次数大于3等。度量、维度值，都可以当条件作用于其他指标。
以上情况统称为条件限定，它扩大了指标的灵活性，可以根据实际业务需要对数据进行剪裁。条件限定和维度值的区别：比如“IOS端”是一个维度值，单独来看IOS端的短视频用户数，IOS端可以表达维度，也可以用于条件限定，但维度值是确定且单一的，不能组合。条件限定是灵活的，可以用度量来限制，也可以组合各种维度值，是灵活多变的。
总结
- 单独存在的度量、维度都不是指标。
- 用表格描述指标的最小集是二维表，单独一列没有任何意义，不具备可读性。
- 绝大多数指标都是多维表形态：【维度1】【维度2】【维度3】【维度n…】【度量1】【度量2】【度量3】【度量n…】。
| 时间周期 | 维度1 | 维度2 | 维度n | 度量1 | 度量2 |
| 日期 | 城市 | 品类 | 渠道 | 成交金额 | 成交订单数 |
- 业务范围帮助缩小和明确了处理数据、理解指标的范围。
- 如果维度不断增多，数据表就会很宽，也就是常说的“大宽表”。
- 条件限定的加入，产生了更灵活的指标形式。
指标模型
原子指标
原子指标是数据分析中最小的可度量单元，通常是一个数值或计数，是数据分析的基础，用来描述某个特定事件、行为或状态，比如销售额、访问量、转化率等。原子指标通常是不可再分的。
按上面的例子，原子指标可以理解为度量，比如【销售金额】【播放时长】【访问次数】，这些度量不可拆解。
原子指标用于明确业务的统计口径和计算逻辑，具备以下特性：
- 原子指标是对指标统计口径算法的一个抽象，等于业务过程（原子的业务动作）+ 统计方式。比如支付（事件）金额（度量），曝光（事件）次数（度量）。
- 原子指标不会独立存在，必须结合业务范围、维度进行组合才有意义。
- 原子指标加维度，可以理解为一个度量在不同视角下的变化。
原子指标通常是其他指标的基础，理解它是指标管理模型中非常重要的一环。
派生指标
派生指标在业务限定范围内，由原子指标、时间周期、维度三大要素构成，用于统计目标指标在具体时间、维度、业务条件下的数值表现，反映某一业务活动的状况。
上面多维表中的每一行都是一个派生指标，业务中用到的指标都是派生指标。
不同派生指标可能具有相同的原子指标，这样就定义了一种等价关系，属于相同原子指标的构成了对指标体系的划分。每个划分中，存在一个可以派生出其他指标的最小派生指标，即最细粒度。
复合指标
派生指标的另一个类型是复合指标。可以单独独立出来，也可以归为原子指标，取决于如何做数据开发和应用。几个例子：
- 平均销售价格：由销售额和销售量计算得出，反映每个产品的平均售价。原子指标是销售额和销售量。
- 转化率：由访问量和转化量计算得出，反映每个渠道的转化效果。原子指标是访问量和转化量。
- 客户生命周期价值：由客户平均购买金额、购买频率和客户保留率计算得出，反映每个客户对企业的贡献价值。原子指标是客户购买金额、购买频率和客户保留率。
上面三个例子都是在原子指标间进行计算的原子级复合指标。也可以通过两个派生指标计算复合指标，比如“最近7天浙江iPhone的平均销售价格 = 近7天浙江iPhone的销售额 / 近7天浙江iPhone的销售量”。
指标要素
上面介绍了很多概念，核心思想是统一对指标的认知和理解。每个概念单独理解可能没有整体感受。看下图来形成整体理解。
我们把【原子指标】【时间周期】【业务范围】【维度】【条件限定】统称为指标要素，它们是指标的实体组织。
- 原子指标就是度量，确定统计目标和聚合方法。
- 时间周期是一种特殊维度，确定统计的时间范围，从什么时间开始、什么时间结束。
- 业务范围是一种特殊维度，确定统计目标的范围。
- 【时间周期】和【业务范围】单独拿出来，是为了更好表达指标的意义。
- 条件限定是对统计数据进行自由剪裁的过程。
- 维度是观察统计目标的视角，可以有“无限个”维度。
指标要素的SQL表达方式
基于指标要素，可以和SQL关联起来理解，便于了解数据的加工和实现过程，从技术视角理解指标要素。
先了解SQL的大结构
SQL的核心作用是从数据表中提取数据。操作对象是表，所以可以理解为：去哪张表里、以什么条件、取哪些数据、用什么方法计算数据。
SELTECT --选取哪些字段：提供字段的各种计算方式，比如SUM, MIN, MAX, 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等大规模秒级响应技术已经很成熟，这种空间换时间的方式依然非常受用，从成本角度非常划算。
命名的统一性
如果用指标要素的管理理念来生产和管理指标，用户在使用指标时可以做到名称统一。
回顾来看，所有应用的指标都可以认为是派生指标。派生指标的元素中，哪些参与命名、哪些不参与命名：
指标命名规范性直接影响使用者对指标的理解，影响整个指标使用效果。命名不规范会导致认知偏差，出现不同名称同一指标，甚至同一指标不同名称的情况，增加沟通对齐成本。
指标命名基本原则：简短易懂，便于传播，不易出现理解偏差。
- 时间周期：必须参与命名，比如累计、昨日、月度、周。时间周期最直接圈定统计范围，需要明确展示在指标名称上，避免歧义。
- 原子指标：必须参与命名，指标的核心。
- 业务范围：可参与命名。如果系统或使用场景流程做得比较好，可不参与命名。比如进入“视频业务”的专属分析系统，系统对业务有明确划分板块，进入“电影”板块时，指标名称就不用带“电影”业务范围，“昨日电影播放量”直接写成“播放量”即可。
- 条件限定：不参与命名。条件限定有两个重要特性：容易变长，且出现在指标建立之后的灵活应用上，是临时性效果。比如“昨日播放量”加条件是“大于18岁，中国地区，IOS端，会员，近30天未登录”，如果参与命名就成了“会员IOS端中国区大于18岁近30天未登录的昨日播放量”，读起来很别扭。而且很多条件限定是临时提出的，比如年龄大于18岁可能随时调到16岁，如果把1到100岁都当限定条件，指标会无限膨胀，增大开发、管理和使用成本。
- 维度：不参与指标命名。维度和条件限定一样，具有无限扩展的情况，且无法从语言上让指标易于理解。比如“昨日播放量”支持维度销售渠道、城市、端、业务类型，加入维度后命名是“昨日播放量销售渠道城市端业务类型”，指标变得不可读。实际情况是维度在分析过程中参与GROUP BY过程，比如表格分组、报表下钻，指标命名带上维度没有意义，可以在应用过程中告知用户支持什么维度。
一致性与生态
运用指标要素的指标管理模型，本质上是抽象加收敛的过程：确定少量指标要素，覆盖大多数使用指标，减少开发、运维、管理和认知成本。一致性问题也可以在这个模型中被解决。
业务基于这个模型思路构建指标模型，并用系统管理，作为整个生态的底层基础。
建立在这个模型之上，可以对接更上层的应用系统，比如报表工具、业务分析系统、用户管理系统、经营分析系统等涉及指标应用的场景，让整个业务和数据分析系统生态都利用起这个模型的思想。
总结
上面分享的方案很理想，但真正能不能应用起来是另一回事。现实是，一个小小的指标可能经历多个团队、多年、多次治理，都达不到好效果；对用户来说，指标体系建设以及使用需要一定的学习和理解成本。
数据指标是一个需要认准解决方案（流程、标准、组织）、长期持续做下去的事情。如果出现中断或反复，沉淀的经验不能继承，就很难达到指标准确、及时好用的状态。学习成本和运营同样是非常重要的因素。再简单的指标，也需要读懂口径、需要明确指标在哪里看到最准、数据出问题要找谁——需要一个完善的指标体系建设。
-
- 关于宇宙的好的网名有哪些
- 角色扮演 | 1
- 网名