什么叫即席查询

什么叫即席查询

这个仅当是笔记

以前一直不知道什么叫即席查询,今天重新看了一遍《SQLSERVER企业级管理平台》,才明白什么叫“即席查询”

下面这句话是我个人总结的:

什么叫即席查询
AD-HOC :以单独的SQL语句的形式执行的查询就是即席查询,比如说:在C#程序里嵌入的SQL语句,或者在SSMS里的新建查询窗口

自己键入的SQL代码就是即席查询。

而将SQL代码放入存储过程里面,以存储过程或者函数或者触发器来执行的查询就不是即席查询,即席:当场,就是当场去查询,当然,这个当场不是当场写代码的意思啦

-------------------------------------------华丽的分割线---------------------------------------------------------

那么,即席查询是不是没有执行计划的缓存的呢?

在《SQLSERVER企业级管理平台》里是这样说的

adhoc:即席查询

Adhoc语句
一组包含select,insert,update,delete的批处理指令。对这样的指令,只有前后完全一致
包括字母的大小写,空格,回车换行都一致,SQL才认为是两条一样的语句,才能够重用执行计划。所以这个要求还是挺高的

1 --例如,运行下面的指令,连续两次查询sys.[syscacheobjects]视图
2 DBCC freeproccache
3 GO
4 SELECT * FROM sys.[syscacheobjects]
5 go
6 SELECT * FROM [sys].[syscacheobjects]
7 go

在第二个结果集里会看到两个adhoc的执行计划。他们的差别就在于一个有回车一个没有回车

但是如果语句是一样的,那么第二句话就可能会重用前面的执行计划。所以adhoc语句并不一定没有执行计划的重用

1 --例如下面,把同样的一句话跑两遍,会发现只有一个执行计划,而且他被使用过两次
2 --(字段usecount=2)
3 
4 DBCC freeproccache
5 GO
6 SELECT  * FROM sys.[syscacheobjects]
7 go
8 SELECT * FROM sys.[syscacheobjects]
9 go

SQL2005以后,可以在单个数据库上开启强制参数化。也就是说,对于在这个数据库下运行的大部分语句,

SQL都会先参数化,再运行。如果应用经常用adhoc方式调用一样的语句,强制参数化可能会有所帮助

 

 ----------------------------------------------华丽的分割线------------------------------------------------------------------------

 那么分布式查询会不会重用执行计划呢?

我使用下面代码测试了一下

 1 --第一次执行的时候,先清空执行计划缓存,第二次执行就要把DBCC freeproccache注释掉
 2 DBCC freeproccache
 3 GO
 4 
 5 
 6 SELECT * FROM 
 7 OPENROWSET('microsoft.jet.oledb.4.0','C:\Users\Administrator\Desktop\Course.mdb';'admin';'',Course_baseinfo) 
 8 GO
 9 
10 SELECT [cacheobjtype],[objtype],[dbid],[usecounts],[sql]  FROM sys.[syscacheobjects]
11 WHERE [dbid]=1
12 go

根据usecounts字段,每执行一次都会递增,说明是有重用执行计划的

附上测试用的mdb文件,记得使用分布式查询的时候需要安装office的哦,如果是64位操作系统,需要安装64位 Microsoft.ACE.OLEDB.12.0

http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/58c4c61e-fa86-4809-bf7d-21bacb055d3e

文件地址:http://files.cnblogs.com/lyhabc/Course.rar

 如果有不对的地方,欢迎大家拍砖o(∩_∩)o

<think>好的,用户现在问的是“北极星指标体系是什么”,我需要先确定用户对这个概念的理解程度。之前用户讨论的是大数据开发者如何提升专业素养,其中提到了北极星指标,所以可能他们是在这个上下文中遇到的术语。 北极星指标,也叫关键指标,是衡量业务成功的关键数据点。用户可能是在业务分析或数据治理的背景下接触到这个概念,需要更详细的解释。我需要先给出定义,再结合例子说明。 用户可能想知道北极星指标的作用,为什么重要,以及如何构建和应用。他们可能在实际工作中需要设定这样的指标,但不确定具体步骤或注意事项。 需要区分北极星指标与其他指标的不同,比如如何选择、如何避免常见误区。可能还需要举例说明不同行业的北极星指标,比如电商、社交、SaaS等,这样用户更容易理解。 另外,用户之前提到的是指标体系,所以可能还需要解释北极星指标与关联指标的关系,比如如何分解成二级、三级指标,形成体系。需要强调北极星指标是核心,但需要其他指标支撑。 还要注意用户的技术背景,他们可能更关注如何将北极星指标与大数据技术结合,比如数据采集、计算、可视化等。所以可以提到技术实现上的考虑,比如实时计算、数据质量监控等。 最后,确保回答结构清晰,分点说明,有定义、作用、构建步骤、案例、误区和技术实现,这样用户能全面理解。需要检查是否有专业术语需要进一步解释,比如OSM模型、AARRR模型,可能需要简要说明。</think>北极星指标体系(North Star Metric Framework)是用于衡量业务核心价值的关键指标体系,其核心思想是通过**单一核心指标**(北极星指标)和**关联指标网络**,形成业务增长与价值评估的导航系统。以下是其核心要素与技术落地的深度解析: --- ### **一、核心定义** 1. **北极星指标(North Star Metric)** - 定义:反映产品/业务**长期可持续价值**的**唯一核心指标** - 数学表达: $$ \text{NSM} = f(\text{用户价值}, \text{商业价值}, \text{可持续性}) $$ - 示例: - 电商:**7日复购用户占比** $$ \frac{\text{过去7天购买≥2次的用户数}}{\text{总活跃用户数}} \times 100\% $$ - 社交平台:**DAU/MAU 比值**(衡量用户粘性) $$ \frac{\text{日活用户数}}{\text{月活用户数}} \times 100\% $$ 2. **关联指标体系** - 由北极星指标**逐层分解**形成的指标树: ``` NSM ├── 一级驱动指标(如:用户留存率) │ ├── 二级执行指标(如:次日留存率) │ └── 二级执行指标(如:7日留存率) └── 一级防御指标(如:用户流失率) ``` - 技术实现:通过**指标血缘系统**建立关联(例如使用Apache Atlas追踪) --- ### **二、构建方法论** 1. **OSM模型(Objective-Strategy-Metric)** - Objective(目标):提升用户生命周期价值(LTV) - Strategy(策略):优化推荐算法覆盖率 - Metric(指标): $$ \text{推荐覆盖率} = \frac{\text{点击推荐商品的用户数}}{\text{总活跃用户数}} \times 100\% $$ 2. **AARRR模型分层映射** | 阶段 | 北极星衍生指标 | 技术实现示例 | |------------|---------------------------|-----------------------------| | Acquisition| 渠道获客成本(CAC) | Kafka实时采集UTM参数 | | Activation | 功能使用完成率 | Flink计算关键路径转化率 | | Revenue | ARPU(平均收入) | Spark聚合订单数据 | | Retention | 30日留存曲线 | Hive构建用户分层宽表 | | Referral | K因子(传播系数) | 社交关系图谱分析(Neo4j) | --- ### **三、技术落地关键点** 1. **数据采集标准化** - 使用**埋点SDK规范化**(如Snowplow/SensorSDK) - 字段校验规则: ```json { "user_id": {"type": "string", "regex": "^[a-f0-9]{32}$"}, "event_time": {"type": "timestamp", "range": ["now-7d", "now"]} } ``` 2. **实时计算架构** ``` App埋点 → Kafka → Flink(实时指标计算) → Druid ↘ HDFS(离线校准) → Hive ``` 3. **指标分级存储策略** | 指标级别 | 存储引擎 | 查询延迟要求 | 示例 | |----------|-----------|-------------|---------------------| | L1(核心)| Druid | <1s | 实时GMV | | L2(重要)| ClickHouse| <5s | 地域分布热力图 | | L3(归档)| Hive | 分钟级 | 年度同比分析 | --- ### **四、行业案例** 1. **视频平台** - 北极星指标:**日均观看时长 ≥ 60分钟用户占比** - 技术实现: - 使用Flink CEP检测连续观看行为 - 计算逻辑: $$ \text{达标用户} = \sum_{u=1}^n \mathbb{I}(\sum_{s=1}^m \text{duration}_s \geq 3600) $$ 2. **SaaS企业** - 北极星指标:**功能使用深度 ≥ 3个核心模块的客户数** - 数据模型: ```sql CREATE TABLE user_feature_usage ( tenant_id STRING, features MAP<STRING,INT>, last_active TIMESTAMP ) PARTITIONED BY (dt STRING); ``` --- ### **五、常见误区** 1. **指标过载** - 错误:选择5个"核心指标" - 修正:通过**主成分分析(PCA)**降维: $$ \text{保留方差} \geq 85\% \text{的主成分} $$ 2. **忽视负向指标** - 必须监控**防御指标**如: $$ \text{功能弃用率} = \frac{\text{30天未使用关键功能的用户数}}{\text{总用户数}} $$ 3. **技术实现滞后** - 典型问题:实时指标用T+1离线计算 - 解决方案:构建**Lambda架构**实现批流统一 --- ### **六、验证与迭代** 1. **AB测试验证** - 使用**双重稳健估计(Doubly Robust Estimation)**: $$ \hat{\tau} = \frac{1}{n} \sum_{i=1}^n \left[ \frac{T_i(Y_i - \hat{\mu}_1(X_i))}{\hat{e}(X_i)} + \hat{\mu}_1(X_i) \right] - \frac{1}{n} \sum_{i=1}^n \left[ \frac{(1-T_i)(Y_i - \hat{\mu}_0(X_i))}{1-\hat{e}(X_i)} + \hat{\mu}_0(X_i) \right] $$ 2. **季度复盘机制** - 技术健康度检查项: - 指标计算P99延迟 ≤ 500ms - 数据血缘覆盖率 ≥ 90% - 异常检测召回率 ≥ 85% --- 通过将北极星指标体系与大数据技术栈深度结合(如Flink实时计算、Hive离线分析、Doris即席查询),开发者可以构建业务价值与技术实现的双向闭环,最终实现数据驱动的精准决策。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值