从“SQL 民工”到“甩手掌柜”：我是如何用 NoETL 让分析师自己玩数据的

掘金前端

工程师9527

2026年1月27日 11:06

别再写宽表了，兄弟，是时候把 SQL 笔扔了。

一、背景：被“下钻需求”逼疯的日常

兄弟们，不知道你们有没有经历过这种场景：

周一上午 10 点，业务方在群里@你：“大佬，上周销售额环比降了 15%，帮忙看下是哪个地区、哪个品类、哪个门店的问题？”

你打开 BI 报表，只有“大区”维度。行，先跑个 SQL 看看大区情况。

10:30，你回复：“华东区降得最厉害，占了下降额的 80%。”

11:00，业务方追问：“华东哪个城市？哪个门店？”

你心里一沉，因为现有的ads_sales_daily宽表只聚合到城市，没有门店维度。你只能硬着头皮说：“稍等，我重新跑个数。”

然后开始：

找dwd_order_detail明细表
JOIN dim_store门店维度表
写聚合 SQL，跑批（祈祷别 OOM）
导出 Excel，发邮件

下午 2 点，业务方收到邮件后，又问：“能具体到是哪个店员、哪个 SKU 的问题吗？我们想针对性培训。”

你看着dwd_order_detail里百亿级别的数据，再想想JOIN dim_user、dim_product的复杂度，以及业务方那“最好今天能给个结论”的期待……

得了，今晚又得加班写 ETL，明天才能出新的ads_sales_detail宽表。

这就是我们数据开发的日常：业务的需求是发散的，但我们的宽表是收敛的。每来一个新维度需求，就是一次CREATE TABLE AS SELECT ...的轮回。数仓的 ADS 层越建越厚，ETL 任务越排越长，我们成了名副其实的“SQL 民工”。

更崩溃的是，等你的宽表建好，业务的热点早就过了。这种“周级响应”的速度，让数据分析从“主动洞察”变成了“事后解释”。

二、探索：发现“偷懒”新姿势——NoETL 语义编织

直到我在一个技术分享会上听到了“NoETL”和“语义编织”这两个词。第一反应是：“又是个新概念忽悠人吧？”

但听完原理后，我直拍大腿：这不就是我梦寐以求的“偷懒”架构吗？

核心思想就一句话：把业务逻辑（指标、维度、关联关系）从物理表里解耦出来，变成一个虚拟的“语义层”。

什么意思？我举个例子：

以前，业务要“销售额”，我得建个ads_sales_by_region（按大区）、ads_sales_by_city（按城市）……N张宽表。

现在，我只需要在语义层里声明式地定义一次：

指标“销售额” = SUM(dwd_order_detail.order_amount)
维度“城市”来自dim_store.city
维度“门店”来自dim_store.store_name
关联关系：dwd_order_detail.store_id = dim_store.id

定义好了，就完了。不用写 ETL，不用建物理表。

当业务分析师在 BI 工具里拖拽“销售额”，想按“城市”看，再下钻到“门店”看时，系统会自动根据我定义好的语义，实时生成 SQL 去查询底层的dwd_order_detail明细表，然后JOIN dim_store，最后聚合返回结果。

从“预先物化所有结果”变成了“按需实时计算”。

先看一张架构图，逻辑很清晰：

烟囱式宽表开发 vs NoETL 语义编织.png

上边是我们熟悉的“痛苦循环”，下边是理想的“敏捷闭环”。关键是中间那个语义层，它成了“翻译官”和“调度员”。

三、剖析：这玩意儿到底怎么实现的？（技术干货）

光有理念不行，得落地。我研究了一下像 Aloudata CAN 这类指标平台的实现，发现核心是三个技术点：

1. 声明式语义建模（告别手写 SQL）

以前我们这样定义指标：

-- 传统方式：写在ETL脚本里，固化成一张表
CREATE TABLE ads_sales_daily AS
SELECT 
    date,
    region,
    SUM(order_amount) as sales_amount,
    COUNT(DISTINCT user_id) as uv
FROM dwd_order_detail
GROUP BY date, region;

现在在平台上，可能就是点点选选：

选择事实表：dwd_order_detail
选择度量：order_amount (聚合方式：SUM) -> 指标“销售额”
选择维度：date（来自事实表），region（来自关联的dim_store）
定义关联：dwd_order_detail.store_id = dim_store.id

平台背后会生成一个逻辑模型，而不是物理表。这个模型可以用一种 DSL（领域特定语言）或元数据来描述，比如：

metric:
  name: sales_amount
  definition: SUM(order_amount)
  data_source: dwd_order_detail

dimension:
  - name: date
    source: dwd_order_detail.order_date
  - name: region
    source: dim_store.region
    join: 
      left: dwd_order_detail.store_id
      right: dim_store.id

2. 自动 SQL 生成与优化（引擎的活儿）

当分析师在 BI 里拖拽“销售额”和“城市”、“门店”时，BI 工具会向语义层发送一个查询请求（比如一个 JSON 或特定的查询语言）。

语义层引擎收到后：

解析查询意图：要查“销售额”，按“城市”和“门店”分组。
查找语义定义：找到“销售额”来自dwd_order_detail.order_amount的 SUM；“城市”和“门店”来自dim_store，需要通过store_id关联。
生成物理 SQL：
查询优化：引擎可能会根据条件自动添加分区过滤、选择更优的 JOIN 策略等。

整个过程，分析师和开发都不需要写一句 SQL。

3. 智能物化与透明加速（解决性能问题）

我知道你们在想什么：“直接查百亿明细，JOIN一堆维度表，这查询不得慢死？”

这就是智能物化引擎出场的时候了。它不再是“猜业务需要什么而提前建宽表”，而是“看业务实际查什么，再自动加速”。

管理员配置加速策略：

场景：高管驾驶舱的“核心销售日报”
策略：对“销售额”指标，按“日期、大区、产品线”组合进行预聚合加速。
平台自动创建物化视图任务（比如每天凌晨计算一次）。

查询时的智能路由：当有查询命中“销售额+日期+大区+产品线”时，引擎会进行 SQL 改写，将查询路由到已经计算好的物化视图上，而不是去扫明细表。

-- 原始查询意图（来自语义层）
SELECT date, region, product_line, SUM(order_amount) ...

-- 引擎自动改写后执行的SQL
SELECT date, region, product_line, sales_amount_precomputed 
FROM mv_sales_daily_region_productline -- 直接查询物化视图
WHERE ...

对用户完全透明，他们只知道“秒出结果”，不知道背后是走了明细还是走了加速表。这比我们手动维护一堆宽表要智能和低成本得多。

四、实战：三步走，把分析师“扶上马”

在我们团队试点时，我们走了这么三步：

第一步：统一语义，挂载存量。
- 挑了一个最痛的“销售分析”场景。
- 把现有的ads_sales_*系列宽表，先“挂载”到语义层，作为数据源之一，让分析师能先用起来，看到统一出口。
- 在语义层里，重新用声明式的方式，基于dwd_order_detail定义最核心的“销售额”、“订单量”等原子指标。
第二步：增量需求，禁止宽表。
- 立下规矩：所有新的、临时的分析需求，不准再提“建一张宽表”的工单。
- 分析师自己去语义平台，用已经定义好的指标和维度，拖拽组合。如果需要新维度（比如“会员等级”），由数据开发在语义层里关联好dim_user表即可，分钟级完成。
第三步：逐步替旧，下线宽表。
- 随着语义层的能力被验证，我们将那些使用频率低、维护成本高的陈年老宽表，一个个下线。查询都引导到语义层的逻辑模型上。
- 对于高频、核心的查询，配置智能物化加速，性能反而比老宽表更好。

五、结论：真香，但需要适应

搞了大半年，说下感受：

给数据开发带来的变化：

加班少了：告别了“业务一动嘴，开发跑断腿”的循环。临时取数需求下降 90%。
专注度高：从重复的CREATE TABLE工作中解放出来，能更专注于数据质量、模型设计和复杂的业务逻辑实现。
口径统一了：“销售额”只有一个定义，再也不会出现报表 A 和报表 B 数字对不上的灵魂拷问。

给数据分析师带来的变化：

自由了：真正实现了“任意维度下钻”。从日期到地区，到门店，到店员，到具体订单，思路不再被打断。
敢深挖了：因为能直接基于明细做归因分析，他们开始能回答“为什么”而不仅仅是“是什么”。比如能定位到“销售额下降主要是因为华东区 XX 门店的 A 商品缺货导致”，这价值就大了。
地位提升了：从“取数工具人”变成了“业务赋能者”。

当然，也有挑战：

思维转变：开发要习惯从“物理建模”转向“语义建模”；分析师要习惯自己探索，而不是张口要数。
性能调优：智能加速策略需要根据实际查询 Pattern 进行观察和调整，前期有个学习成本。
平台依赖：选一个靠谱的指标平台是关键。自己从零造轮子？我劝你慎重，这里面的水很深（查询优化、多引擎适配、元数据管理等等）。

六、最后说一句

如果你也受够了无休止的宽表开发和业务方的夺命连环 Call，真的可以了解一下 NoETL 语义编织这个方向。它不是什么银弹，但确实是解决“数据供给敏捷性”这个老大难问题的一条务实路径。

感兴趣的兄弟可以去官网白嫖个试用版测一下，自己感受一下从“SQL 苦力”到“架构师”的转变。至少，你的头发能多留几天。

阅读视图

跨境电商 ROI 算不清？我靠 NoETL 统一语义层，终于不用写 ETL 写到头秃了