探求Text 大模型与数据剖析

当今大模型如此炽热，作为一名数据同窗，继续在关注LLM是如何运行在数据剖析中的，也关注到很多公司推出了AI数智助手的产品，比如火山引擎数智平台VeDI—AI助手、 Kyligence CopilotAI数智助理、ThoughtSpot等，经过接入人工智能大模型，优化数据处置和查问剖析的效率。智能数据剖析助手，驳回对话式剖析技术，每个普通人都可以与数据启动随时随地的实时交互，依据用户的经常使用反应，始终学习，自我迭代找到答案，并在团队内分享对数据的见地。

繁难剖析一下数据剖析的开展阶段：第一阶段，以静态报表为主，传统BI和静态报表基本上都是面向开发部门的，业务部门提出需求之后，由开发依据报表工具开收回固定的报表，而后业务部门检查报表结果。第二阶段，矫捷BI自助式剖析，在业务部门提出需求之后，数据剖析可以基于矫捷BI的工具协助业务部门极速失掉所需的数据，协助他们取得所须要的结果。第三阶段，不论是基于大模型的AskBI还是增强剖析，都是间接面向业务的，其理念是业务部门间接经常使用对话式BI工具能够处置疑问，取得所需的数据结果。这一环节无需像之前那样依赖开发部门开发报表，或许数据剖析师基于矫捷BI再提供数据结果，而是间接由业务部门推动落地。

一、全体打算

经过多家数AI数智助手调研，成功智能数据剖析的外围有：一是以目的为中心，二是大模型。其中也分享出了如何把目的平台+AI技术落中央案，提出了：人人用数=AI Copilot + 目的体系 + 正当老本的关键技术观念。

目的体系给到咱们的是一个通用的数据言语，当咱们每一团体都用数据来沟通时，咱们遇到的第一个阻碍必定是不足通用的言语。就像普通话让13 亿中国人能够自在沟通，数据的解释权有一个规范分歧的口径也是十分关键的，是数据共享和单干的前提。

目的数据最理想的经常使用场景就是，想要就有，数据准确，可视化展现。用户希冀能够随时检查自己想要的业务目的数据，绝大少数人都有自己的经常使用目的的渠道和方法，然而须要用户相熟系统的操作、数据内容或许会依据需求提早预设好，假设是须要目的的话，就依赖允许者的期间了，或许须要排期开发。虽然每团体都各显其通能够拿到数据，但于用户体验来说，还是须要有操作和期间老本。

智能化的目的运行可以大幅提高数据目的的用户体验和效率。咱们宿愿的场景是，用户对着手机：“通知我昨天的DAU、用户留存、开售额”，系统就能极速的反应给用户这三个目的的结果，并且是准确的。

目的的加工处置到经常使用两边有很多环节，从数据积淀->数仓加工->口径定义->报表->系统->用户，两边流程最间接的方式就是人造言语间接对接到数据。

通用打算

通用做法是基于目的要素消费出目的的模型（提早估算好一切的或许），经过NLP技术，将人造言语转译成SQL，间接读取目的模型，大略的技术思绪如下：

基于大模型

目的：经过大模型技术，打造用户在灵敏搜查目的的时刻能够极速反应给用户正确的目的体验。

外围聚焦：

基于LLM生成准确可行动SQL的关键思绪：把目的控制模型的定义、目的要素等元数据消息送给LLM当作prompt启动目的搜查与生成。

二、Text-to-SQL

Text-to-SQL（简写为T2S，或许是Text2SQL），望文生义就是把文本转化为SQL言语，更学术一点的定义是：把数据库畛域下的人造言语（Natural Language，简写为NL）疑问，转化为在相关型数据库中可以行动的结构化查问言语（Structured QueryLanguage，简写为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。

Spider数据集是少数据库、多表、单轮查问的Text-to-SQL数据集，也是业界公认难度最大的大规模跨畛域评测榜单，由2018年耶鲁大学提出，由11名耶鲁大学在校生标注。

Spider数据集论文地址：。

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 FROMStudent where age =20”，经过数据库行动后也失掉结果为null。虽然预测的SQL跟标注的SQL不分歧，然而结果是一样的，依据行动准确率目的来比拟，那么就以为模型预测是正确的。

SELECT sname FROM Student where age  ；nullSELECT sname FROM Student where age  ；null

逻辑方式准确率

定义：计算模型生成的SQL和标注SQL的婚配水平。

缺陷：存在低估的或许。如一个SQL行动结果是正确的，但于标注SQL的字符串并非齐全婚配，例如，只是select 列的顺序不同或SQL查问目的齐全相反的不同SQL。为了处置一局部该疑问，有钻研指出了一种查问婚配精度query matchaccuracy：将生成的SQL和标注SQL都以规范方式示意，再计算两者婚配精度。这种方法只处置了由于排序疑问而造成的误判。另外，经过对列和表启动排序并经常使用规范化别名来对SQL启动规范化，也可以消弭不同SQL格局造成的误判疑问。

举个例子：雷同地，假设有个在校生表，咱们想要查问在校生表中年龄等于19的在校生姓名和在校生学号。就如“SELECT sname FROM Student where age =19”所示，经过数据库行动规范SQL后失掉结果为（张三，123456）；此时Text-to-SQL模型预测的SQL为“SELECTsno,sname FROM Student where age =19”，经过数据库行动后也失掉结果为（123456，张三），假设从逻辑方式准确率目的来看，由于SQL并不是如出一辙，虽然两者只是挑选顺序的语序疑问，所以会以为模型预测是失误的。

SELECT snamesno FROM Student where age  ；张三，SELECT sno，sname FROM Student where age  ；，张三

钻研方法

在深度学习的钻研背景下，将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模板示例：

基于模板和婚配的方法，是早期的钻研方法，实用于繁难SQL，定义后的sql准确率高；不适宜复杂SQL，没有定义模板的SQL不能识别。

基于Seq2Seq框架的方法

关于Text-to-SQL钻研而言，实质上属于人造言语处置（Natural Language Processing，NLP），而在NLP畛域中，经常出现的义务可以大略分为如下四个场景，1、N和M代表的是token的数量。

可以发现的是，Text-to-SQL义务是合乎N ->M机器翻译义务的，处置机器翻译义务最干流的方法是基于Seq2Seq框架方法，Seq2Seq是一种基于序列到序列模型的神经网络架构，它由两个局部组成：编码器Encoder和解码Decoder。因此，Text-to-SQL最干流的方法也是基于Seq2Seq框架。

三、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（地址：）

摘要：咱们钻研将复杂的文本到 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查问的思想环节可以分解为：

基于这个思想环节，将文本到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 等等，它是灵敏多变的。

总结

目的模型

原子目的

原子目的是指数据剖析中最小的可度量单元，通常是一个数值或一个计数。原子目的是数据剖析的基础，它们可以用来形容某个特定的事情、行为或形态，如开售额、访问量、转化率等。原子目的通常是无法再分的，由于它们曾经是最小的可度量单元了。

依照下面的例子来说，原子目的可以了解为是度量，例如【开售金额】【播放时长】【访问次数】等等，这些度量是无法拆解的。

原子目的用于明白业务的统计口径及计算逻辑。具有以下个性：

原子目的通常是其余目的的基础，可以经过对原子目的的剖析来得出更初级别的目的。了解原子目的是整个目的控制模型中十分关键的一环。

派生目的

派生目的在业务限定的范围内，由原子目的、期间周期、维度三大要素构成，用于统计目的目的在详细期间、维度、业务条件下的数值表现，反映某一业务优惠的业务状况。

例如下面讲到的多维表中的每一行都是一个派生目的，也就是说，业务中用到的目的都是派生目的。

不同的派生目的或许具有相反的原子目的，这样派生目的就定义了一种等价相关，而属于相反的原子目的就构成了一个对目的体系的划分。在每一个划分中，存在一个可以派生出其余目的的最小派生目的，即最细粒度。

复合目的

派生目的的另一个类型是复合目的，假设把它独自独立进去也可以，假设把它归类为原子目的也可以，取决于咱们如何做数据的开发以及运行。先来看几个复合目的的例子：

下面三个例子都是在原子目的间启动计算的原子级复合目的。

也可以经过两个派生目的来计算复合目的，例如派生目的是：最近7天浙江 iPhone 的平均开售多少钱 = 近7天浙江 iPhone 的开售额 / 近7天浙江 iPhone 的开售量。

目的要素

下面引见了很多的概念，其实外围理想是一致对目的的认知和了解，每一个概念独自去了解或许无法有一个全体的感触。可以看下图，来成功对目的的全体了解：

咱们把【原子目的】【期间周期】【业务范围】【维度】【条件限定】统称为目的要素，他们是目的的实体组织。

目的要素的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_listwhere order_amount > 100

【期间周期】当作限定条件出如今where条件中

-- 在订单明细表中计算2023年5月20日订单金额大于100的订复数select count(order_id)from dwd.order_listwhere order_amount > 100 AND order_date=‘2023-05-20'

【维度值】当作条件出如今where条件中

-- 在订单明细表中计算2023年5月20日订单金额大于100且在杭州出现的订复数select count(order_id)from dwd.order_listwhere 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_namefrom dwd.order_listwhere 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 等大规模秒级照应的查问技术曾经很成熟了，这种空间换期间的方式依然十分受用。从老本的角度来讲，十分划算。

命名的一致性

假设经常使用目的要素的控制理念来消费、控制目的，在用户经常使用目的的时刻，可以做到目的称号的一致性。

回忆来看，一切运行的目的都可以以为是派生目的，派生目的的目的元素中，有哪些可以介入命名，哪些不用介入命名：

目的的命名规范性，间接影响经常使用者对目的的了解，并能够影响到整个目的经常使用的成果，假设命名不规范，会造成大家认知出现偏向，经常会出现不同称号同一目的，甚至还有同一目的不同称号的状况，参放大家的沟通对齐老本。

目的命名的基本准则：冗长易懂，便于流传，不易出现了解偏向。

分歧性与生态

运用目的要素的目的控制模型，实质上是形象+收敛的环节，确定大批的目的要素，笼罩大少数的经常使用目的，增加开发、运维、控制和认知老本。分歧性疑问雷同可以在这个模型中被处置。

业务基于这个模型思绪，去构建目的模型，并用系统加以控制，当做整个生态的底层基础。

树立在这个模型之上，可以对接更下层的运行系统，例如报表工具，业务剖析系统，用户控制系统，运营剖析系统等设计到目的运行的场景中，从而让整个业务、数据剖析系统生态中都应用起这个模型的思想。

五、总结

下面分享打算是理想的，真正能不能运行起来，是另一回事。事实是，一个小小的目的，或许阅历多个团队，多年，屡次控制，都达不到好的成果；对用户来讲，目的体系树立以及经常使用须要必定的学习、了解老本。

数据目的是一个须要认准处置打算（流程、规范、组织）常年继续做下去的事情，假设出现终止或许重复，积淀的阅历不能承袭，则很难到达目的准确、及时好用的形态。学习老本以及运营雷同是一个十分关键的要素。再繁难的目的，也须要读懂口径、也须要明白目的在哪里看到的最准，数据出现了疑问要找谁，须要一个完善目的体系树立。

六、团队引见

淘天业务技术用户运营平台技术团队是一支懂用户，技术驱动的年轻队伍，以用户为中心，经过技术翻新优化用户全生命周期体验，继续为用户发明价值。团队立足体系化打造业界上游的用户增长基础设备，以媒体外投平台、ABTest平台、用户运营平台为代表的基础设备赋能阿里团体用户增长，日均处置数据量千亿规模、调用QPS千万级。

原文链接：​ ​​ ​