我的数据空间

主题

数据查询 ​

场景　临时查一张表、验证一条口径、排查一个数据问题——这类即席查询不想惦记"这张表到底该用哪个引擎",也不想为了一条 SELECT 走批作业发布流程,更不想因为数据分散在湖仓和 OLAP 层两处,分析前还得先跑一个同步任务把数据搬到一起。数据查询提供统一入口,一条 SQL 能跨源联查,后面具体切给 Spark、Trino 还是 Doris,交给平台判断或自己指定。

能干什么

你想做的事配置成数据查询长这样(示意)
联表查两处不同来源的数据(比如湖里的表 + Doris 里的表)SQL 里直接跨 catalog JOIN/UNION,不用先建同步任务把数据搬到一起
不管数据在哪个引擎,直接查引擎选 AUTO,平台按语句内容自动选路
明确指定引擎下拉选 SPARK/DORIS/PRESTO(即 Trino),不再自动切换
大结果集也要拿全勾「全量查询」,不受默认预览的行数上限
SQL 写错了想提前发现点执行就有语法预检查,报错直接指出问题所在,不用等引擎跑起来才发现
回看一条历史查询用了哪个引擎、跑了多久「我的查询」历史里能看到实际引擎、状态、耗时

亮点 ​

  • 跨 Catalog 联邦查询,数据不用先搬到一起——湖仓里的 Iceberg 表和 Doris 里的 OLAP 表,只要都在这个空间里注册可见,一条 SQL 就能直接关联分析,不必先跑一趟同步任务。这也是"智能引擎"判断该走哪个引擎的关键依据之一:纯 OLAP 引擎(Doris)只能查自己那一份数据,一旦查询涉及多个来源,平台会自动换成能处理跨源联查的引擎。
  • 业务库默认不让直接查,保护的是生产系统——MySQL/PostgreSQL 这类业务数据库默认不开放给查询引擎直连,就是为了不让一条即席大查询把负载打到线上业务库;确有需要,得由管理员单独打开这个口子,不是每个空间都默认能查。
  • 不用记引擎,平台会自己选更合适的——涉及写入、建表,或者一次联查了多个数据来源,平台会交给更"全能"的引擎处理;如果只是查单一来源的简单语句,则优先选响应更快的引擎——体验上感觉不到引擎在切换,只感觉查询越来越顺手。
  • 某个引擎"卡"住了,平台会自动换一个再试——遇到查询在当前引擎里跑不通(比如用了这个引擎不认的写法),平台会自动切到能力更全的引擎重跑一次,不用自己手动切换重试;但如果问题明明是数据本身的(表不存在、没权限),换引擎也没用,平台不会做无意义的重试,会直接告诉你原因。
  • 查询也有"安全边界"——引用的每张表都得写完整名字、都要有相应权限才能查或写,删表这类高危操作干脆不放在查询框里做,得去数据管理的表详情页专门操作,避免一条 SQL 手滑删了生产表。
  • 走 Spark 的查询有独立的配额池,不会跟批作业抢资源——Spark 引擎的即席查询用的是专门申请审批的一份资源(有独立的并发查询数上限),和批/流作业的计算资源是分开算的,新空间要先申请到这份配额才能用 Spark 查询。

跨 Catalog 联邦查询 ​

一条 SQL 里用 UNION ALL 分别统计湖仓 Iceberg 表和 Doris 表的订单状态分布,对比两边口径是否一致——引用了两个不同来源,平台自动换成能处理跨源联查的 Spark 执行,2 秒内一次性返回两边的结果:

sql
SELECT 'iceberg_lake.cdc_orders' AS source_table, status, COUNT(*) AS cnt
FROM iceberg_lake.site_demo_ws10.cdc_orders
GROUP BY status
UNION ALL
SELECT 'doris_demo.orders_oltp' AS source_table, status, COUNT(*) AS cnt
FROM doris_demo.demo.orders_oltp
GROUP BY status
ORDER BY source_table, status

一条 SQL 联表统计 Iceberg 湖表与 Doris 表的订单状态分布,一次返回两边结果

三个引擎,分别负责什么 ​

Spark ​

涉及写入、建表,或者一次查询联表了多个数据来源,平台交给最"全能"的 Spark 处理。比如建一张 Iceberg 表:

sql
CREATE TABLE IF NOT EXISTS iceberg_lake.site_demo_ws10.query_auto_spark_probe (msg STRING)
USING iceberg

智能选路遇到建表这类写操作,自动换成 Spark 处理,执行记录含真实的 Kyuubi/Spark 作业提交

Trino(Presto) ​

只读、且只涉及一个可被 Trino 服务的来源时,平台优先选响应更快的 Trino。比如查一下湖仓订单表的行数和时间范围:

sql
SELECT COUNT(*) AS cnt, MIN(create_time) AS first_ts, MAX(create_time) AS last_ts
FROM iceberg_lake.site_demo_ws10.cdc_orders

智能选路命中 Trino,处理湖仓表的只读查询,秒级返回

刻意换一个 Trino 不认的写法(array(...) 函数),验证"某个引擎卡住会自动换一个再试"这条:

sql
SELECT o.id, explode(array(1,2,3)) AS x
FROM iceberg_lake.site_demo_ws10.cdc_orders o
LIMIT 3

Trino 报函数不支持而执行失败,平台自动切到 Spark 重跑并成功拿到结果:

当前引擎处理不了某个写法而执行失败,平台自动切换引擎重跑并成功

Doris ​

只读、且只涉及一个 Doris 表时,平台直接选 Doris。比如查一下 OLAP 层的销售日汇总表:

sql
SELECT * FROM doris_demo.demo.ads_sales_daily LIMIT 100

智能选路命中 Doris,处理另一空间里 Doris 表的只读查询,秒级返回

其他细节 ​

SQL 语法预检查 ​

提交前就会先做一遍语法检查,写错了立刻就知道,不用等引擎跑一圈才报错:

sql
SELEKT * FROM x

语法预检查提前拦下拼写错误,给出具体错误位置

Spark 查询配额 ​

Spark 查询用的是一份独立申请、独立审批的资源配额,和批/流作业的计算资源分开管理:

「资源管理」页里,Spark 查询引擎是独立于批/流作业资源的一份配额,有独立的审批记录

想直接写批作业固定跑一段 SQL 而不是临时查,看Spark SQL 作业;想用自然语言代替手写 SQL,看AI 敢用 · NL2SQL 语义层。

回到核心能力总览 →