第六阶段 60 · Transform 数据透视(把明细汇总成实体索引

60 · Transform 数据透视(把明细汇总成实体索引)

阶段:第六阶段 / 进阶专题

ES:Transform(pivot / latest) | PostgreSQL:物化视图(MATERIALIZED VIEW)+ 定时刷新


1. 概念

明细索引(每笔销售一条)适合检索,但不适合反复做重聚合 (慢、耗资源)。

Transform 能把明细「透视」成一个新的汇总实体索引,例如:

  • 从「每笔订单」→ 汇总成「每个客户的总消费、订单数、最近下单时间」。
  • 结果写进一个新索引,之后直接查这个索引,秒回。

两种模式:

模式 作用 类比
pivot 按 group_by + 聚合,生成汇总行 GROUP BY 结果落表
latest 按 key 取每组最新一条 DISTINCT ON (key) ORDER BY time DESC

还能设 continuous(持续):源数据变了,自动增量更新目标索引 ------ 就是「自动刷新的物化视图」。


2. PostgreSQL 对照

sql 复制代码
-- 物化视图:把明细汇总成客户维度
CREATE MATERIALIZED VIEW customer_summary AS
SELECT customer_id,
       SUM(amount)  AS total_amount,
       COUNT(*)     AS order_cnt,
       MAX(order_dt) AS last_order_dt
FROM sales
GROUP BY customer_id;

REFRESH MATERIALIZED VIEW customer_summary;   -- 定时刷新

Transform(continuous)≈ 会自动增量刷新的物化视图。


3. ES DSL

3.1 pivot:客户维度汇总

复制代码
PUT _transform/customer_summary
{
  "source": { "index": "sales_idx" },
  "dest":   { "index": "customer_summary_idx" },
  "pivot": {
    "group_by": {
      "customer_id": { "terms": { "field": "customer_id" } }
    },
    "aggregations": {
      "total_amount":  { "sum": { "field": "amount" } },
      "order_cnt":     { "value_count": { "field": "order_no.keyword" } },
      "last_order_dt": { "max": { "field": "order_dt" } }
    }
  },
  "sync": {
    "time": { "field": "order_dt", "delay": "60s" }
  }
}
  • 有 sync = continuous,源变了自动增量更新目标索引。
  • 去掉 sync = 一次性批处理(batch)。

3.2 启动 / 停止 / 预览

复制代码
POST _transform/customer_summary/_start
POST _transform/customer_summary/_stop

// 建之前先预览结果长什么样
POST _transform/_preview
{ "source": { "index": "sales_idx" }, "pivot": { ...同上... } }

3.3 latest:每个客户最新一单

复制代码
PUT _transform/customer_latest
{
  "source": { "index": "sales_idx" },
  "dest":   { "index": "customer_latest_idx" },
  "latest": {
    "unique_key": ["customer_id"],
    "sort": "order_dt"
  }
}

4. Spring Boot 实现

java 复制代码
@Component
public class Doc60Transform {

    @Autowired
    private ElasticsearchClient elasticsearchClient;

    /** 创建并启动一个 pivot transform */
    public void createCustomerSummary() throws IOException {
        elasticsearchClient.transform().putTransform(t -> t
                .transformId("customer_summary")
                .source(src -> src.index("sales_idx"))
                .dest(d -> d.index("customer_summary_idx"))
                .pivot(p -> p
                    .groupBy("customer_id", g -> g.terms(tm -> tm.field("customer_id")))
                    .aggregations("total_amount", a -> a.sum(s -> s.field("amount")))
                    .aggregations("order_cnt",    a -> a.valueCount(v -> v.field("order_no.keyword")))
                    .aggregations("last_order_dt", a -> a.max(m -> m.field("order_dt"))))
                .sync(sy -> sy.time(ti -> ti.field("order_dt").delay(dl -> dl.time("60s")))));

        elasticsearchClient.transform().startTransform(s -> s.transformId("customer_summary"));
    }

    /** 停止 */
    public void stop() throws IOException {
        elasticsearchClient.transform().stopTransform(s -> s.transformId("customer_summary"));
    }
}

import:co.elastic.clients.elasticsearch.transform.*(PutTransformRequest 等由 builder 隐式使用)。


5. 坑与最佳实践

  1. 先 _preview 再落库:确认汇总字段和粒度对,再正式建,避免返工。
  2. continuous 要有时间字段 :sync.time.field 通常用 @timestamp / order_dt,delay 留出数据到达的缓冲。
  3. 目标索引是「派生数据」:别直接写它;它由 transform 维护,需要改逻辑就重建。
  4. group_by 的 text 字段用 .keyword:同 21/43 篇。
  5. 资源占用 :continuous transform 会持续跑,注意其对集群的负载,必要时调 frequency。
  6. 和聚合的取舍 :临时分析用聚合(20~24 篇);高频、固定维度的汇总查询才值得用 transform 预计算。

相关推荐
跨境卫士苏苏39 分钟前
TikTokShop关联账户认定指引更新跨境代运营团队需要注意哪些管理责任
大数据·人工智能·市场营销·跨境电商·营销策略
迅易科技2 小时前
数据质量治理:从异常告警走向自动化根因诊断
大数据
组工部管理能手李哥2 小时前
一次政务知识库体验:AI回答之外,我更在意那行引用来源
大数据·人工智能·大模型·政务
GrowingIO技术社区2 小时前
SaaS与私有化部署怎么比较?责任、集成与成本
大数据·数据挖掘·产品
GrowingIO技术社区2 小时前
CDP项目如何评估?从业务问题到能力测试
大数据·数据分析
m0_715674432 小时前
政务泛监测体系能力排行:AI 重塑监测边界,治理的颗粒度革命
大数据·网络·人工智能·安全·网络安全·政务
GrowingIO技术社区4 小时前
多端用户身份怎么统一?OneID规则与验收清单
大数据·数据挖掘·数据分析
躺柒4 小时前
读数据安全架构设计与实践20安全政策文件体系(上)
大数据·人工智能·安全·数据安全·安全架构·安全体系
用户3610588626125 小时前
Flink 内存分配源码深度剖析:从启动计算到运行时动态分配的完整链路
大数据·flink
隔窗听雨眠8 小时前
数据中台退潮之后的企业数据架构重构
大数据·数据中台·数据架构