4. 多数据源Connector接入实战

Trino 的联邦查询能力来自 Connector：每个 Catalog 对应一个 Connector 实例，负责元数据发现、数据读取、谓词下推与写入。接入多数据源时，真正决定“能不能查、查得快不快、写得对不对”的，是 Catalog 属性、认证方式与元数据映射三件事。本节以 Hive、Iceberg、MySQL、PostgreSQL、Kafka、Elasticsearch 六类典型数据源为例，给出可直接落地的配置思路与关键参数。

一、Catalog 的统一结构与元数据映射

Trino 中一个 Catalog 由 etc/catalog/<name>.properties 定义，核心属性是 connector.name，其余属性由各 Connector 自行解析。元数据映射的本质是：把外部系统的库、表、列、分区、类型，映射为 Trino 的 schema、table、column、partition 与 Trino 类型。映射规则不同，查询语义就不同。

例如 Hive 的 database 映射为 Trino 的 schema，table 映射为 table；MySQL 的 database 同样映射为 schema，但大小写敏感性与 Hive 不同；Kafka 没有“表”的概念，需要显式声明列与消息格式，才能把 topic 映射为 table。理解这层映射，是排查“表存在但查不到列”“列类型不匹配”类问题的前提。

二、Hive 与 Iceberg：数据湖侧接入

Hive Connector 依赖 Hive Metastore（HMS）获取元数据，典型配置如下：

# etc/catalog/hive.properties
connector.name=hive
hive.metastore.uri=thrift://hms-host:9083
hive.config.resources=/etc/hadoop/conf/core-site.xml,/etc/hadoop/conf/hdfs-site.xml
hive.metastore.authentication.type=KERBEROS
hive.metastore.service.principal=hive/hms-host@EXAMPLE.COM
hive.metastore.client.principal=trino@EXAMPLE.COM
hive.metastore.client.keytab=/etc/trino/trino.keytab

关键点：hive.config.resources 必须包含 HDFS 与 HMS 的配置，否则无法解析文件路径；Kerberos 场景下 principal 与 keytab 必须与 KDC 中注册一致。元数据映射上，Hive 的 database 即 Trino schema，table 即 table，分区列在 Trino 中表现为普通列，但查询时会被下推为分区裁剪。

Iceberg Connector 支持 REST、HMS、Glue、JDBC 等多种 catalog 类型。以 REST 为例：

# etc/catalog/iceberg.properties
connector.name=iceberg
iceberg.catalog.type=rest
iceberg.rest-catalog.uri=http://iceberg-rest:8181
iceberg.rest-catalog.warehouse=s3://warehouse/
iceberg.rest-catalog.security=OAUTH2
iceberg.rest-catalog.oauth2.credential=client-id:client-secret

Iceberg 的优势在于快照隔离与隐藏分区。Trino 查询 Iceberg 表时，WHERE dt='2024-06-01' 会直接裁剪到对应快照文件，避免全表扫描。若使用 HMS 作为 Iceberg catalog，则需同时配置 iceberg.catalog.type=hive_metastore 与 hive.metastore.uri。

三、MySQL 与 PostgreSQL：关系型数据库接入

两者配置结构相似，差异在驱动与下推能力：

# etc/catalog/mysql.properties
connector.name=mysql
connection-url=jdbc:mysql://mysql-host:3306
connection-user=trino_reader
connection-password=${ENV:MYSQL_PASSWORD}
allow-drop-table=false

# etc/catalog/postgresql.properties
connector.name=postgresql
connection-url=jdbc:postgresql://pg-host:5432/appdb
connection-user=trino_reader
connection-password=${ENV:PG_PASSWORD}
postgresql.array-mapping=AS_ARRAY

元数据映射上，MySQL 的 database 映射为 schema，table 映射为 table；PostgreSQL 的 schema 映射为 schema，table 映射为 table。类型映射需注意：MySQL 的 TINYINT(1) 默认映射为 boolean，PostgreSQL 的 NUMERIC 映射为 decimal。若源端表名或列名含大写，需确认 case-insensitive-name-matching 是否开启，否则会出现“表不存在”的误判。

四、Kafka 与 Elasticsearch：消息与检索侧接入

Kafka Connector 没有“表”的元数据，必须显式声明 topic 与列：

# etc/catalog/kafka.properties
connector.name=kafka
kafka.nodes=kafka1:9092,kafka2:9092
kafka.table-names=events.user_click,events.order_pay
kafka.hide-internal-topics=true
kafka.security-protocol=SASL_SSL
kafka.sasl.mechanism=PLAIN
kafka.sasl.username=trino
kafka.sasl.password=${ENV:KAFKA_PASSWORD}

每个 topic 需在 etc/kafka/<topic>.json 中定义列与消息格式，例如 events.user_click.json 声明 user_id、event_time、page_url 三列，并指定 message 格式为 JSON。查询时 Trino 会按列解析消息，未声明的字段不可见。

Elasticsearch Connector 则把索引映射为表：

# etc/catalog/elasticsearch.properties
connector.name=elasticsearch
elasticsearch.hosts=https://es-host:9200
elasticsearch.security=PASSWORD
elasticsearch.auth.user=trino
elasticsearch.auth.password=${ENV:ES_PASSWORD}
elasticsearch.default-schema=default

索引名即表名，字段类型由 ES mapping 推断。若 ES 中某字段为 text 且未开启 fielddata，Trino 查询该列可能报错，此时应改用 keyword 子字段或调整 mapping。

五、接入后的验证与常见问题

配置完成后，用以下 SQL 验证：

SHOW CATALOGS;
SHOW SCHEMAS FROM hive;
SHOW TABLES FROM hive.default;
DESCRIBE hive.default.orders;
SELECT count(*) FROM mysql.appdb.users;
SELECT * FROM kafka.events.user_click LIMIT 10;

常见问题与判断依据：SHOW CATALOGS 无目标 Catalog，说明 properties 文件名或 connector.name 错误；SHOW TABLES 为空，检查元数据服务连通性与权限；查询报“Column not found”，检查列名大小写与映射规则；Kafka 查询返回空，检查 topic 名、消息格式与 kafka.table-names 是否一致。建议每接入一个数据源，先执行 DESCRIBE 确认列与类型，再执行 SELECT ... LIMIT 确认数据可读，最后再接入联邦查询。