# BI 工具跨数据源关联能力对比(Superset , QlikSense, Tableu, Looker)

能力	Superset	Qlik Sense	Tableau	Looker
原生跨数据源关联	✖️（依赖外部引擎）	✅	✅（Data Blending / Relationships）	✅（LookML + 多连通模型）
性能等级^†	★★	★★★★★	★★★	★★★★
适用规模	单源或已 ETL 合并	10 亿＋行、秒级交互	≤数千万行、对并发敏感	云仓/湖仓为主，中大型
核心技术	SQLAlchemy + 下推	QIX 内存关联引擎	抽取文件 / Live Query	LookML + Query Push‑Down
高性能跨源关键	借助 Presto/Trino 或 ETL	全量加载➜列式压缩➜关联	主—辅表惰性 join，需 Extract	将逻辑 join 下推到云仓，或 PDT 预聚合

^{† 综合吞吐量、延迟、并发三项打分（最高 5 星）。}

# 1 | Superset

维度	说明
机制	每张 Chart 只连一个 SQLAlchemy 数据库 URI。想跨源，只能： 1) 先把多源 ETL 到同一库； 2) 把 Presto/Trino/StarRocks 这类“联邦查询引擎”本身当成一个数据源。
瓶颈	Superset 本身不做计算；性能完全取决于底层引擎。跨源 = 底层引擎能否把两个库拼起来。
典型做法	Flink ➜ ClickHouse 统一；或用 Trino 连接 MySQL＋Hive，再让 Superset 连 Trino。
优劣	+ 超轻量、开源 – 无内置跨源逻辑；实时大并发时需自行扩展底层。

底层原理 Superset 只是 SQL 透传与结果缓存。跨源逻辑必须在 另一个 SQL 层（Presto、SparkSQL、StarRocks feeder …）完成——因此无法保证“高性能”或“可交互式”体验，除非那层引擎也足够快并带列存＋并行计算。

维度	说明
机制	“QIX Associative Engine”——将多个源表全量或增量加载到内存列式索引；每个字段建位图字典，查询时只扫描相关位图并动态关联。
高性能秘诀	• 内存列存＋块压缩（≤1/10 数据大小） • 延迟计算：只在用户点击筛选时，对关联子集做聚合 • 并发共享同一 in‑memory model，响应可达亚秒。
跨源体验	数据加载脚本里 `LOAD … FROM` 可指向 Oracle、CSV、REST、Hive… 引擎自动识别主键并生成关联星型或雪花。
限制	内存容量 = 数据上限；超大规模需搭配 Qlik Server Side Extension（对接 Snowflake/BigQuery）或 On‑Demand App Generation。

底层原理

① LOAD 把异构源数据行列解耦为纯列向量； ② 重复值全局字典编码； ③ 字段之间通过 符号表 建立关联； ④ 任何筛选都变成位图 AND/OR 运算 → 聚合时只扫命中行。

维度	说明
机制	两种模式： ① Extract (TDE/Hyper) — 把源表抽取到本地列式文件，可跨源关联； ② Live Connection — 每次下推到主数据源，辅数据源在客户端进行 “Data Blending”。
性能特点	• Extract 模式快，但抽取成本高、近实时难； • Live 模式下，主表行数×辅表行数会被客户端拼接，数据量稍大即卡顿。
改进	2020.2 起推出 “Relationships”：在服务端 Hyper 引擎中按需 join，较旧版 Blending 有提升，但跨不同连接仍需 Extract。
结论	中等数据量 OK；千万行+ 多维交互会遇到带宽和客户端内存瓶颈。

底层原理 Tableau Extract → Hyper 列式数据库；跨源 join 时先把多源都变成 Hyper 表，放本地/服务器内存。Live Blending 则把主源结果集拉回客户端，再对辅源用 IN 子查询获取匹配行——网络往返明显影响响应。

维度	说明
机制	• LookML 语义层：可把多个连接（Connection）中表/视图抽象为逻辑 View； • 模型里 `join` 语法 = 定义跨库关联；运行时把 SQL 下推到支持联邦查询的云仓（BigQuery、Snowflake）或物化为 PDT（Persistent Derived Table）。
性能保障	1) 依赖底座云仓的 MPP/分布式列存； 2) 可设 `persist_for:` 把关联结果写成 PDT 自动刷新； 3) Query Caching + Aggregation Awareness 智能选最快路径。
优势	a) 逻辑层清晰、多人协作版本控制； b) 云原生扩展性，与 BigQuery/Redshift/Snowflake 等深度集成； c) 可借由 Connected Sheets / API 下游复用。
局限	On‑prem 数据源多、或无 MPP 联邦能力时，需频繁 PDT 物化→ 存储成本上升。

底层原理 LookML 编译时→生成抽象语法树；运行时根据用户 Explore 选择合适 join 路径：

若目标云仓原生支持跨库（BigQuery + External Connection / Snowflake Database Links）则直接 SQL join；
否则在云仓临时/物化表保存中间集。高并发下依赖云仓的弹性算力与列存，并通过 Caching Layer 减少重复扫描。

场景	推荐
内网、异构源众多、必须秒级交互	⭐ Qlik Sense（QIX 内存联想模型）
云数仓为核心、支持 Federated Query	⭐⭐ Looker（LookML + 云仓算力）
单源 / 已在 Trino 统一	⭐ Superset（轻量、开源）
BI 需求以可视化为主、数据量中等	⭐⭐ Tableau（Extract + Relationships）