企业官网建设流程全解析

在工厂信息化建设里，最常被吐槽的一句话往往是“数据都有，但查不出来”。生产订单在 MES 里，质量检验在 QMS 里，原材料入库在 WMS 里，设备参数又落在 SCADA 或时序库里，系统之间数据格式不同、数据库不同，甚至服务器也不同。质量人员想按工单把检验结果、生产批次、设备参数放在一起看，要么等数据团队导数据，要么自己导 Excel 再 VLOOKUP，过程慢，也容易出错。联邦查询（Federated Query）就是解决这类问题的思路：不用先把数据搬到一起，而是让同一个 SQL 引擎直接连接多个数据源，把“跨库跨表查询”变成一条 SQL 就能完成的事情。本文面向制造企业的数据分析师、数据开发工程师和信息化负责人，会用最小实验把 MySQL 里的质量检验表和 PostgreSQL 里的生产工单表做跨库关联，再讲清楚查询下推、结果合并、权限控制以及生产落地时需要注意的问题。

1. 工厂数据查询难，难在数据根本不在一个库

1.1 一个典型的工厂数据分布案例

制造企业往往不是缺系统，而是系统太多。每个业务部门都有自己习惯的软件和数据库：MES 记录工单和报工，QMS 记录质量检验和缺陷，WMS 管理原材料和成品出入库，SCADA 或工业时序库保存设备点位数据，ERP 保存物料、BOM 和订单。下面是一张很常见的工厂数据分布表：

这些系统各自服务于自己的业务闭环时没问题，但一旦需要“工单维度的良率报表”或者“某批次产品的完整生产追溯”，数据就散落在至少两个库里。一个简单的查询，比如“查出 6 月所有不合格品对应的产品名称和生产线下线”，就涉及到 QMS 的检验表、MES 的工单表，甚至还要关联 ERP 的物料主数据。此时最大的障碍不是 SQL 写不出来，而是这些表根本不在同一个数据库实例里。

1.2 传统做法的三个常见做法和瓶颈

面对跨库查询，很多工厂实际采用的是下面三种做法，各有各的代价。

1. 定时 ETL 复制到数仓或数据中台。数据团队每天凌晨把各个系统的表同步到统一数仓，再建模、再提供报表。优点是口径稳定，缺点也很明显：数据至少慢半天，临时加一个字段要重新同步，而且很多小的跨库分析需求根本不需要动用整套中台。
2. 在应用层写代码逐个系统取数。让开发人员调用 MES 的接口取工单，调用 QMS 的接口取检验记录，再在内存里做匹配和聚合。数据源一多，就会出现 N 个系统乘 N 个接口的组合问题，接口慢、字段变化、联调成本都压在应用层。
3. 导出 Excel 后用 VLOOKUP 手工匹配。这是工厂里最常见的“民间方案”，适合小批量、一次性、要写得少的数据核对。但数据量超过几十万行、或者需要每天重复查询时，Excel 的内存和处理能力很快顶不住，版本还会失控。

这些方案本身没有错，但都默认了一件事情：必须先让数据搬家，才能做联合查询。联邦查询换了一个角度：数据不搬家，查询直接到原库去取。

1.3 联邦查询的定义和收益

联邦查询是指通过一个统一查询引擎，以标准 SQL 同时连接多个异构数据源，让用户像查询本地单表一样查询跨系统数据，而数据本身仍然留在原数据库中。查询引擎负责把 SQL 拆分、把能下推的计算下推到各数据源执行，再把结果合并返回。

这个设计带来的直接收益是：

• 数据不复制，不产生双份存储，也不会因为同步延迟导致“数仓里的数据和业务系统对不上”。
• 查询实时性更好，读到的是源库当前数据，而不是昨天晚上的快照。
• 统一 SQL 入口，数据分析师不用关心目标表在 MySQL 还是 PostgreSQL，只需要知道 catalog、schema 和表名。
• 权限可以收敛到查询引擎这一层，配合源库账号的最小授权，能形成统一的数据访问面。

但也要清醒一点：联邦查询不是银弹。它更适合跨系统临时取数、轻量级集成和探查式分析，不适合把 TB 级大表的复杂报表全部压在联邦查询上。后面会专门讲它和数仓、湖仓的关系。

2. 联邦查询是怎么把“多个库”变成“一张表”的

2.1 三级命名：catalog.schema.table

理解联邦查询，首先要理解它的三级命名规则。以 Trino 为例，一个完整表名是catalog.schema.table三段式：

• catalog对应一个数据源连接配置，相当于给 MySQL、PostgreSQL、Iceberg 各起一个名字。
• schema对应数据源里的逻辑空间，MySQL 里通常对应数据库名，PostgreSQL 里对应 schema。
• table对应该空间下的具体表。

启动 Trino 后，可以用下面两条命令确认数据源是否接入成功：

SHOW CATALOGS; SHOW TABLES FROM mysql.quality_db;

第一句会列出所有 catalog，第二句会列出 MySQL 的quality_db库下有哪些表。这样设计的好处是：应用层只认一套三级命名，底层数据源切换、扩容、迁移都可以通过修改 catalog 配置来隔离。

2.2 查询下推与结果合并

联邦查询的执行过程可以简化为两个阶段：下推（Pushdown）和合并（Coordinator Aggregation）。

下推是指查询引擎把自己能识别的过滤条件、投影列、甚至部分聚合计算，转换成数据源自己的 SQL，让数据源先做一层加工。例如这条查询：

SELECT order_no, product_barcode, result FROM mysql.quality_db.quality_records WHERE result = 'NG';

Trino 的 MySQL 连接器会尽量把它转换成对 MySQL 的查询，让 MySQL 先按result = 'NG'过滤，只返回必要列。这样网络上传回的数据量就不是整张表，而是过滤后的少量记录。

合并发生在查询引擎的协调节点：当两个数据源各自返回中间结果后，引擎再按照 join 条件、聚合逻辑、排序和 limit 做最后处理。跨库 join 之所以比单库 join 慢，通常不是因为引擎不会算，而是因为：

• 过滤条件没有下推，导致大量数据被拉到引擎内存里。
• join 字段在源库没有索引，源库执行时只能全表扫描。
• 查询里对字段做了函数处理，破坏了连接器做下推判断的基础。

2.3 联邦查询不是数据中台，也不是数仓

很多团队会把联邦查询和数仓、数据中台混为一谈。这里用一张表说清楚边界：

联邦查询更像是一个“数据访问层”，解决的是“不用搬数据也能查”的问题；数仓和湖仓解决的是“搬过来之后怎么建模、怎么算大规模历史数据”的问题。两者不是替代关系，而是上下游配合关系。

3. 可选技术栈：从数据库自带能力到分布式查询引擎

3.1 数据库原生联邦能力：FEDERATED 与 FDW

如果跨库场景不复杂，数据源数量少，可以先考虑数据库自带的能力。

MySQL 提供FEDERATED存储引擎，可以把远程表映射成当前实例里的本地表。用法大致如下：

CREATE TABLE remote_quality_records ( record_id BIGINT NOT NULL, order_no VARCHAR(32), product_barcode VARCHAR(64), check_time DATETIME, result VARCHAR(8) ) ENGINE=FEDERATED CONNECTION='mysql://trino:trino123@192.168.1.20:3306/quality_db/quality_records';

建好后，可以像查本地表一样查询远程表。但这个方案限制很多：很多 MySQL 发行版默认没有开启 FEDERATED 引擎；它按记录方式访问远程表，复杂 join 和大批量查询性能较差；它也只能在 MySQL 生态内部使用。

PostgreSQL 的postgres_fdw是官方自带的扩展，体验比 MySQL FEDERATED 成熟不少。以两个 PostgreSQL 库为例：

CREATE EXTENSION IF NOT EXISTS postgres_fdw; CREATE SERVER remote_pg_server FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '192.168.1.21', port '5432', dbname 'mes_db'); CREATE USER MAPPING FOR CURRENT_USER SERVER remote_pg_server OPTIONS (user 'trino', password 'trino123'); IMPORT FOREIGN SCHEMA public FROM SERVER remote_pg_server INTO public;

之后就能在本地 PostgreSQL 中直接 join 远程表。如果目标是连接 MySQL，需要使用mysql_fdw等第三方扩展，功能和稳定性依赖社区维护，投入生产前需要做充分验证。

原生方案适合“以某个数据库为中心、外部数据源少、数据量可控”的场景。一旦数据源超过三个、数据库类型混杂，还是需要统一查询引擎。

3.2 分布式查询引擎：Trino 为什么适合工厂

Trino 是当前联邦查询场景最常用的开源分布式 SQL 查询引擎，前身是 PrestoSQL。它的核心定位就是“一个 SQL 查遍所有数据源”。Trino 通过连接器（Connector）机制接入各种存储：

• 关系型：MySQL、PostgreSQL、SQL Server、Oracle、MariaDB。
• 数据湖与文件：Hive、Iceberg、Delta Lake、Parquet、CSV。
• 其他：Kafka、ClickHouse、Doris、Elasticsearch 等。

对工厂场景而言，Trino 最有价值的地方在于：它不需要预先建模，也不要求数据搬到同一个地方，只要源库允许 JDBC 连接，就能快速接入。整套环境用 Docker 就能搭起来，非常适合先跑通最小示例再评估生产落地。

3.3 Apache Iceberg 与联邦查询的关系

最近几年，“Iceberg 联邦查询”经常和联邦查询一起被提起。Iceberg 不是查询引擎，也不直接解决“连多个数据库”的问题，它是一种开放表格式，把表结构、分区、快照、数据文件位置等元数据统一管理起来。多个引擎如 Trino、Spark、Flink 可以通过 Iceberg 读取同一批表数据。

在实际架构里，Iceberg 更多承担“湖仓底座”的角色：把历史明细数据放在 Iceberg 表里，Trino 配置一个 Iceberg catalog，再让 Trino 在同一句 SQL 里去 join Iceberg 表和 MySQL 业务表。这样既保留了冷数据的大规模分析能力，又能和实时业务系统做联合查询，属于联邦查询一种典型的进阶形态。

3.4 选型对照表

4. 最小可复现实验：跨 MySQL 和 PostgreSQL 联查生产质量数据

4.1 实验目标与数据模型

实验模拟工厂里最常做的“不合格品按工单归集”：

• 源 A：MySQL 的quality_db.quality_records，保存质量检验记录。
• 源 B：PostgreSQL 的mes_db.public.production_orders，保存生产工单主数据。
• 目标：查出所有结果为 NG 的检验记录，并关联出对应工单的产品名和生产线下线。

这个实验会用到三个容器：两个数据库容器加一个 Trino 容器。用 Docker Compose 一次性启动，便于复现和清理。

4.2 用 Docker Compose 搭起三节点环境

先创建实验目录：

mkdir -p factory-federation cd factory-federation mkdir -p init/mysql init/postgres trino/etc

在factory-federation下创建docker-compose.yml：

version: "3.8" services: mysql: image: mysql:8.0 container_name: factory-mysql environment: MYSQL_ROOT_PASSWORD: root123 MYSQL_DATABASE: quality_db MYSQL_USER: trino MYSQL_PASSWORD: trino123 ports: - "3306:3306" volumes: - ./init/mysql:/docker-entrypoint-initdb.d postgres: image: postgres:15 container_name: factory-postgres environment: POSTGRES_USER: trino POSTGRES_PASSWORD: trino123 POSTGRES_DB: mes_db ports: - "5432:5432" volumes: - ./init/postgres:/docker-entrypoint-initdb.d trino: image: trinodb/trino:latest container_name: factory-trino depends_on: - mysql - postgres ports: - "8080:8080" volumes: - ./trino/etc:/etc/trino

MySQL 和 PostgreSQL 官方镜像都会在首次初始化数据卷时执行docker-entrypoint-initdb.d下的 SQL 脚本，所以把建表和数据脚本放进去即可。注意：如果修改了 SQL 脚本，需要删除数据卷重新初始化，命令是docker compose down -v，实验环境可以这样重置，生产环境不要随意删卷。

4.3 准备两个库的模拟数据与账号

创建init/mysql/01_create_quality.sql，内容如下：

CREATE DATABASE IF NOT EXISTS quality_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; USE quality_db; CREATE TABLE quality_records ( record_id BIGINT PRIMARY KEY AUTO_INCREMENT, order_no VARCHAR(32) NOT NULL, product_barcode VARCHAR(64) NOT NULL, check_time DATETIME NOT NULL, result VARCHAR(8) NOT NULL, defect_code VARCHAR(16), worker VARCHAR(32), INDEX idx_order_no (order_no), INDEX idx_check_time (check_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; INSERT INTO quality_records (order_no, product_barcode, check_time, result, defect_code, worker) VALUES ('MO-2025-0001', 'BARCODE-001', '2025-06-01 08:30:00', 'OK', NULL, '王工'), ('MO-2025-0001', 'BARCODE-002', '2025-06-01 08:42:00', 'NG', 'D-101', '王工'), ('MO-2025-0002', 'BARCODE-003', '2025-06-01 09:10:00', 'NG', 'D-202', '李工'); CREATE USER 'trino'@'%' IDENTIFIED BY 'trino123'; GRANT SELECT ON quality_db.* TO 'trino'@'%';

创建init/postgres/01_create_orders.sql，内容如下：

CREATE TABLE IF NOT EXISTS public.production_orders ( order_no VARCHAR(32) PRIMARY KEY, product_name VARCHAR(64) NOT NULL, production_line VARCHAR(32) NOT NULL, plan_qty INT NOT NULL, order_date DATE NOT NULL ); INSERT INTO public.production_orders (order_no, product_name, production_line, plan_qty, order_date) VALUES ('MO-2025-0001', '控制面板 A40', '一号线', 500, '2025-05-28'), ('MO-2025-0002', '控制面板 A41', '一号线', 300, '2025-05-30'), ('MO-2025-0003', '传感器模组 S20', '二号线', 1000, '2025-06-01'); CREATE USER trino WITH PASSWORD 'trino123'; GRANT CONNECT ON DATABASE mes_db TO trino; GRANT USAGE ON SCHEMA public TO trino; GRANT SELECT ON ALL TABLES IN SCHEMA public TO trino;

这里特意不给 Trino 账号写权限，因为查询引擎只需要读。生产环境同样应遵循最小权限原则。

4.4 配置 Trino 并启动验证

在trino/etc下准备四个文件。首先是config.properties：

coordinator=true node-scheduler.include-coordinator=true http-server.http.port=8080 query.max-memory=2GB query.max-memory-per-node=1GB discovery.uri=http://localhost:8080

node.properties：

node.environment=production node.id=ffffffff-ffff-ffff-ffff-ffffffffffff node.data-dir=/data/trino

jvm.config：

-server -Xmx2G -XX:InitialRAMPercentage=80 -XX:MaxRAMPercentage=80 -XX:+UseG1GC -XX:G1HeapRegionSize=32M -XX:+ExplicitGCInvokesConcurrent -XX:+HeapDumpOnOutOfMemoryError -XX:OnOutOfMemoryError=kill -9 %p

log.properties：

io.trino=INFO

然后创建两个 catalog 文件。trino/etc/catalog/mysql.properties：

connector.name=mysql connection-url=jdbc:mysql://mysql:3306 connection-user=trino connection-password=trino123

trino/etc/catalog/postgresql.properties：

connector.name=postgresql connection-url=jdbc:postgresql://postgres:5432/mes_db connection-user=trino connection-password=trino123

注意：Trino 容器内访问 MySQL 和 PostgreSQL，要使用 Compose 服务名mysql和postgres，不能用localhost。另外，挂载配置目录时要注意容器内用户对目录的读权限，遇到 Permission denied，先检查trino/etc下文件的权限是否可读。

启动环境：

docker compose up -d docker compose ps

进入 Trino 命令行：

docker exec -it factory-trino trino

先验证 catalog：

SHOW CATALOGS; SHOW TABLES FROM mysql.quality_db; SHOW TABLES FROM postgresql.mes.public;

正常会看到mysql、postgresql、system三个 catalog，以及两个库下的表。再分别确认两边能独立查询：

SELECT count(*) FROM mysql.quality_db.quality_records; SELECT count(*) FROM postgresql.mes.public.production_orders;

4.5 执行真正的跨库关联查询

下面这条 SQL 就是本文的核心实验。它把 MySQL 里的质量检验记录和 PostgreSQL 里的生产工单按order_no关联起来：

SELECT q.order_no, p.product_name, p.production_line, q.product_barcode, q.check_time, q.result, q.defect_code FROM mysql.quality_db.quality_records q LEFT JOIN postgresql.mes.public.production_orders p ON q.order_no = p.order_no WHERE q.check_time >= TIMESTAMP '2025-06-01 00:00:00' AND q.check_time < TIMESTAMP '2025-06-02 00:00:00' AND q.result = 'NG' ORDER BY q.check_time DESC LIMIT 100;

预期结果类似：

执行这条 SQL 时，Trino 会同时连到两个数据库，各自取数后在协调节点完成 join。由于我们把时间范围和result = 'NG'都写在了查询条件里，这两个过滤能被下推到 MySQL，MySQL 只需要返回很少的记录。这就是为什么“跨库查询慢不慢，很大程度取决于条件能不能下推”。

5. 关键配置与 SQL 解释：为什么这样查能快一些

5.1 Catalog 连接参数速查

以 Trino 的 MySQL、PostgreSQL 连接器为例，常用属性如下，不同版本之间可能略有差异，部署前以对应版本文档为准：

生产环境至少要做两个动作：连接串里不写明文密码；给查询设置超时和资源上限。否则一条写坏的 SQL 就能把源库连接池打满。

5.2 谓词下推：过滤发生在数据源，而不是引擎内存

前面实验里的WHERE条件就是典型的谓词下推。为了验证某个条件是否真的下推，可以用 Trino 的 EXPLAIN 命令：

EXPLAIN (TYPE DISTRIBUTED) SELECT q.product_barcode, p.product_name FROM mysql.quality_db.quality_records q LEFT JOIN postgresql.mes.public.production_orders p ON q.order_no = p.order_no WHERE q.result = 'NG';

执行后，计划里通常会看到两个数据源各自形成独立的读取片段，MySQL 片段上的扫描节点会带上result = 'NG'的过滤语义，而不是把整张表全部搬运到 Trino。不同版本的算子名称会有差异，关键判断标准是：数据源侧先过滤，再返回引擎。

如果发现某些查询条件没有下推，问题通常出在写法上：对列做了函数运算、隐式类型转换、或者使用了连接器不支持下推的复杂表达式。处理办法是把功能型写法改写成“列范围型”写法。

5.3 影响性能的常见写法对比

5.4 查询引擎账号要最小权限

实验里已经演示了给 Trino 建只读账号。生产环境还应该做到：

• MySQL 侧只授权目标库的SELECT，不要使用 root。
• PostgreSQL 侧只授权CONNECT、USAGE和SELECT。
• 每个环境使用独立账号，密码轮换通过密钥系统完成。
• 如果需要查询多张表，逐表授权或按 schema 授权，避免SELECT ... , *的权限扩散。

MySQL 账号授权示例：

CREATE USER 'trino'@'%' IDENTIFIED BY 'strong_password'; GRANT SELECT ON quality_db.* TO 'trino'@'%';

PostgreSQL 账号授权示例：

CREATE USER trino WITH PASSWORD 'strong_password'; GRANT CONNECT ON DATABASE mes_db TO trino; GRANT USAGE ON SCHEMA public TO trino; GRANT SELECT ON ALL TABLES IN SCHEMA public TO trino;

6. 工厂生产落地时，哪些坑最值得提前规避

6.1 单库查很快、联邦查很慢的根因

一种高频现象是：直接连 MySQL 查某张表很快，但通过 Trino 跨库 join 后变慢。常见根因有三个。

第一，join key 在源库没有索引。比如quality_records.order_no没有建索引，MySQL 只能全表扫描。解决办法是在两边数据库的常用关联字段上建索引。

第二，过滤条件没有下推，整表数据被拉回 Trino。这通常是因为 SQL 写法让连接器无法识别过滤表达式，按 5.3 的表格调整写法即可。

第三，一次查询跨了两张很大的表，且没有时间范围或业务维度缩小数据量。联邦查询的定位是轻量级取数，如果业务确实需要全量大表关联，应该考虑把历史数据放进 Iceberg 或数仓，而不是长期压着线上关系库。

6.2 时区、字符集和数值精度陷阱

跨库查询最容易出现三类“看不见的差异”：

• 时区：MySQL 的DATETIME不带时区信息，PostgreSQL 的timestamptz带时区。两边直接比较时，经常出现相差 8 小时的问题。统一做法是：新表统一存 UTC，展示层再转换。
• 字符集：MySQL 如果使用latin1，中文会出现乱码。接入前要确认源表字符集，推荐统一为utf8mb4，连接 URL 里也显式声明 UTF-8。
• 数值精度：数量、重量、金额不要用浮点数，数据库用DECIMAL，例如DECIMAL(20,6)。比例和单价字段最容易因为类型不一致导致 join 结果偏差。

这些差异在单库查询时不容易暴露，一旦跨库 join，两边类型语义不同就会立刻变成脏数据。

6.3 别把在线 OLTP 系统压垮

联邦查询直接访问业务系统数据库，本质上是给 OTLP 系统增加查询负载。生产落地需要做几层保护：

1. 查询引擎账号只读，且只授予业务需要的库表。
2. 对源库设置慢查询日志和连接数告警，观察 Trino 是否把某个表的查询打到源库。
3. Trino 侧配置资源组，限制并发、内存和扫描行数。临时分析场景可以限制单查询最多扫描的数据量。
4. 对高频固定查询，不要反复走联邦查询，可以让源库先提供只读从库，或者把结果落到明细表再查询。

6.4 报表走数仓，临时分析走联邦

判断一个需求该走联邦查询还是数仓，可以从三个问题入手：

• 这个查询每天发生多少次？高频固定查询应该进数仓或湖仓。
• 数据量是否达到千万行以上？大表全量分析更适合 Iceberg 或数仓。
• 对实时性要求有多高？需要看业务系统当前状态的，走联邦；只需要看趋势的，T+1 数仓足够。

正确分工是：业务系统原库负责日常事务，联邦查询负责跨系统取数和轻量分析，数据湖仓负责大规模历史计算。三者分层配合，而不是互相替代。

6.5 上线前可复用的排查清单

• [ ] 每个数据源是否都使用只读账号，且账号权限只覆盖必要库表。
• [ ] 网络白名单是否已放开，生产环境是否启用 TLS。
• [ ] 连接密码是否已经纳入密钥管理，代码和配置文件中没有明文。
• [ ]join字段和常用时间字段在源库是否已建索引。
• [ ] 是否用EXPLAIN验证过主要查询的谓词下推。
• [ ] 两边时区和字符集是否一致。
• [ ] 是否已配置查询超时、资源组和连接池限制。
• [ ] 是否模拟过一次大表全量扫描，确认不会压垮源库。
• [ ] 是否已经添加源库连接数、慢查询、Trino 内存和查询耗时的监控。

7. 常见问题与排查路径

7.1 高频问题速查表

7.2 一条通用的联邦查询排查链路

联邦查询的排错顺序比具体报错更重要，推荐按下面链路逐层检查：

1. 先单库验证。把 SQL 拆成各自数据源的部分，在原库客户端单独执行，确认单库本身没问题。
2. 检查 catalog 连通性。执行SHOW CATALOGS、SHOW TABLES FROM catalog.schema，确认元数据可见。
3. 跑最小查询。用SELECT count(*) FROM catalog.schema.table WHERE ...验证过滤条件下推后的基础性能。
4. 再跑跨源 join。先加LIMIT 10，确认关联逻辑正确。
5. 查看执行计划。用EXPLAIN (TYPE DISTRIBUTED)确认是否出现数据源侧过滤。
6. 查看源库日志。确认没有全表扫描、没有异常慢查询。
7. 最后核对时区、字符集和字段类型。这三类差异往往在结果正确性层面暴露，而不是在报错层面。

8. 最佳实践与下一步扩展方向

8.1 联邦查询落地的四个可执行原则

第一，能下推就下推。写 SQL 时优先用列范围条件，少在过滤条件里对列套函数，查询只选必要字段。

第二，查询面就是权限面。联邦查询把很多原来“导出 Excel 后失控”的数据访问收回到统一引擎，账号必须只读、最小化、可审计。

第三，区分取数任务和分析任务。跨系统取数用联邦查询，固定报表和大规模分析进数仓或 Iceberg，不要让联邦查询长期承担重型计算。

第四，先小后大。先选一个痛点场景跑通，比如“不合格品按工单归集”，再逐步接入 WMS、ERP 和时序库，不要一开始就追求把所有系统全部联邦化。

8.2 从联邦查询走向“湖仓一体 + 联邦入口”

一个可行的进阶架构是：业务系统的实时数据继续留在原库，历史明细和需要大规模分析的冷数据进入 Iceberg 表，Trino 上层同时配置 MySQL、PostgreSQL、Iceberg 等 catalog。数据使用者只接触 Trino 的 SQL 入口，不需要知道某张表到底在业务库还是在数据湖。

这种架构的好处是既保留了实时业务查询的灵敏性，又让历史数据分析获得湖仓的扩展能力。实现时需要注意两点：一是离线入库任务的延迟要匹配分析时效要求，二是 Trino 的 catalog 命名要稳定，避免表名频繁变更导致下游混乱。

8.3 给初学者和工厂数据组的练习路径

• 第一阶段：用 PostgreSQL 的postgres_fdw连接第二个 PostgreSQL，理解“外部表”的概念。
• 第二阶段：复现本文的 Docker Compose 实验，跑通 MySQL 加 PostgreSQL 的跨库 join。
• 第三阶段：增加第三个数据源，比如把一张历史大表放到 Iceberg 中，再写同一句 SQL join 三个 catalog。
• 第四阶段：使用EXPLAIN反复改写 SQL，训练自己判断“条件是否下推、索引是否生效”。
• 第五阶段：加入权限、资源组、监控和告警，形成可上线的最小联邦查询规范。

联邦查询真正值钱的地方，不是省掉了 ETL 那几步，而是让工厂在数据仍然分散的情况下，先获得统一的取数入口。很多企业的首要问题不是“数据没有集中”，而是“根本不知道数据在哪、怎么安全地把它查出来”。用最小实验跑通联邦查询之后，你会对每个数据源的查询压力、SQL 下推、权限边界都有更具体的判断，这种能力比记住任何工具的命令都更有用。下一步再结合 Iceberg 或数仓去沉淀已经稳定的分析模型，就能逐步把“临时能查”升级成“长期好用”的工厂数据底座。