Trino、PrestoSQL 和数仓几个概念梳理

前言

最近在补一些大数据基础概念时，发现自己最容易混的不是某一个单独术语，而是这些词总是一起出现：Trino、PrestoSQL、DW、ODS/DWD/DWS/ADS、ETL/ELT、OLTP/OLAP。

单看每个词，好像都能说两句；真要把它们放到一张图里，又容易串台。

所以这次不打算按教科书方式一个个背定义，而是顺着我自己理解它们的路径，先把这些概念按职责拆开，再看它们之间到底是什么关系。

我一开始想搞清楚的几个问题

Trino 和PrestoSQL 到底是什么关系
Trino 为什么适合分析查询，但不适合做高并发事务写入
DW 和ODS/DWD/DWS/ADS 是不是一回事
ETL/ELT 和OLTP/OLAP 分别在描述哪一层东西

正文

先把这些词按“角色”拆开

一开始看这些概念时，最容易懵的点在于它们根本不在同一个维度上，但资料里经常放在一起讲。

后面梳理下来，先按角色拆开会清楚很多：

类别	术语	它到底在说什么
查询与分析引擎	`Trino` / `PrestoSQL`	怎么查多种数据源里的数据
事务型数据库	`MySQL` / `PostgreSQL` / `TiDB`	怎么承接业务写入和事务
数仓体系	`DW`	整体数据仓库怎么组织
数仓分层	`ODS` / `DWD` / `DWS` / `ADS`	数据在仓内流转到哪一步了
数据处理流程	`ETL` / `ELT`	数据是按什么顺序加工的
场景类型	`OLTP` / `OLAP`	系统偏事务，还是偏分析

看到这里其实就已经能收掉一半混乱了。

因为 Trino 不是数据库分层，ODS 也不是查询引擎，ETL 更不是某个具体产品。它们是在描述不同层面的事。

`Trino` 和 `PrestoSQL` 本质上是在说同一条技术脉络

这个问题最开始我也有点绕，后来收敛下来其实不复杂：

Presto 是早期项目
PrestoSQL 是社区分支阶段的名字
Trino 是PrestoSQL 后来的正式名称

所以现在更常见、也更应该直接记住的名字，其实就是 Trino。

它的核心价值不是“自己存很多数据”，而是用统一 SQL 去查多个异构数据源 。比如：

Hive
Iceberg
MySQL
PostgreSQL
Kafka
Elasticsearch

看到这里就能理解，Trino 更像一个分布式 SQL 查询控制台。你可以把不同地方的数据挂进来，再用一套 SQL 去做分析。

这也是它为什么很适合下面这些场景：

跨数据源联表查询
数据湖交互式分析
BI 查询
临时取数
离线数仓查询

为什么 `Trino` 不适合做高并发事务写入

这个问题如果只回答一句“因为它是 OLAP，不是 OLTP”，其实有点像没回答。

真正需要看清的是：Trino 的设计重点本来就不在事务写入控制，而在大规模查询和联邦分析。

OLTP = Online Transaction Processing，关注的是：

高频新增、修改、删除
事务一致性
并发写入
低延迟读写

这类系统常见是：

电商下单
支付系统
库存系统
用户管理系统

更合适的底座通常是：

MySQL
PostgreSQL
TiDB

而 OLAP = Online Analytical Processing，关注的是：

大批量扫描
聚合分析
报表统计
历史数据查询
多维分析

这时常见系统才会变成：

Trino
Spark SQL
Hive
ClickHouse
Doris

所以这件事不能简单理解成“Trino 不够强”，而是方向不一样。

它擅长的是查得广、查得快、能把多源数据揉到一起分析；不擅长的是像业务库那样扛高并发写入、单行更新、强事务控制。

如果场景是订单、账户、库存这种核心业务写入，先看的一定还是事务型数据库，不会优先看 Trino。

`DW` 和 `ODS/DWD/DWS/ADS` 不是一回事

这个地方我之前也容易混。

后面再看就明白了：DW 是 Data Warehouse，说的是整个数据仓库体系；ODS/DWD/DWS/ADS 是这个体系里一种很常见的数据分层方式。

也就是说：

DW 是整体概念
ODS/DWD/DWS/ADS 是体系内部的加工层次

这几个分层可以先这样记：

`ODS`

ODS = Operational Data Store

这一层最接近原始业务数据，通常保留原始结构，少加工或者不加工，主要目的是把源数据先接进来，后面好追溯、好继续处理。

我会把它理解成数仓里的原料区。

`DWD`

DWD = Data Warehouse Detail

这一层开始做清洗和标准化，常见动作包括：

去重
过滤脏数据
统一字段格式
补充维度
统一业务口径

它更像“可复用的标准明细层”。

`DWS`

DWS = Data Warehouse Service

这一层通常开始围绕主题做汇总，比如：

按天汇总订单成交额
按用户汇总近 30 天活跃次数
按商品汇总销量指标

也就是主题分析需要的中间汇总层。

`ADS`

ADS = Application Data Service

这一层更接近最终交付，直接服务 BI、报表、看板或者其他数据应用。

如果要用一句更直白的话概括：

ODS 是原始数据
DWD 是干净的标准明细
DWS 是主题汇总
ADS 是最终交付

用一个小例子把数仓分层串起来

比如现在要做“每天各城市支付金额分析”，那一条典型链路大概会长这样：

层级	会做什么
`ODS`	接入原始订单表、原始支付流水
`DWD`	去重、过滤取消订单、统一支付时间、补齐城市维度
`DWS`	按日期和城市汇总支付金额、订单数、支付用户数
`ADS`	输出给 BI 报表或运营看板直接使用

写到这里，这几个层次就不太像抽象缩写了，而像一条能落到表和任务上的真实加工链路。

`ETL` 和 `ELT` 说的是加工顺序

这两个概念相对直白一点，但也容易和数仓分层混在一起。

其实它们说的不是“数据放哪”，而是“数据怎么处理”。

ETL = Extract, Transform, Load

也就是：

抽取数据
先做转换、清洗、映射
再加载到目标系统

而 ELT = Extract, Load, Transform 则是：

先把数据抽出来
先装载进目标系统
再利用目标系统内部能力做转换

所以它们的核心区别就一句话：

ETL 是先转再入库
ELT 是先入库再转换

现在很多数据湖、云数仓场景偏向 ELT，本质上也是因为目标系统本身计算能力已经够强了。

最后把这些概念放回一张图里

当我把上面几层关系拆开之后，再回来看整条链路，基本就顺了：

flowchart LR
    A["业务系统 / 日志 / 消息流"] --> B["ODS 原始层"]
    B --> C["DWD 明细标准层"]
    C --> D["DWS 主题汇总层"]
    D --> E["ADS 应用服务层"]
    B --> F["Trino / Spark / Hive 等查询或计算引擎"]
    C --> F
    D --> F
    E --> G["报表 / BI / 数据应用"]

从这张图里，至少可以先记住两件事：

ODS/DWD/DWS/ADS 是数仓内部的数据分层
Trino 更像查询分析引擎，不是核心事务型业务数据库

如果再打个工厂类比，也还算顺手：

DW 是整座工厂
ETL / ELT 是流水线
ODS 是原材料仓
DWD 是整理后的标准半成品
DWS 是按主题加工好的组件
ADS 是成品展示区
Trino 是查询控制台
MySQL / PostgreSQL / TiDB 更像前台业务交易系统

总结

这次梳理完之后，我自己比较稳定的一套记法是：

先分清“引擎、数据库、数仓、流程、场景”这几个层次，不要混着背
Trino 本质上是面向分析的分布式 SQL 查询引擎，强项是多源查询，不是事务写入
DW 是整体数仓体系，ODS -> DWD -> DWS -> ADS 是其中常见的数据加工分层
ETL/ELT 说的是处理顺序，OLTP/OLAP 说的是系统偏向

如果只是为了快速建立直觉，记住一句也够了：

Trino 负责查和分析，事务型数据库负责写和事务，数仓分层负责把数据一步步加工到能被分析和交付的状态。

菜单

分享

TrinoPrestoSQL和数仓几个概念梳理