8.3 商业智能（BI）平台集成

8.3 商业智能（BI）平台集成

数据做完，总得让人看见

本篇是第 8 章第 3 节，也是生态章收尾，讲 Kettle 与 BI 的衔接——它产出的表如何被可视化消费。

Kettle 的终点常是 BI 工具的数据源。我们让 Kettle 把加工好的明细与汇总写入仓库的 BI 库（或单独数据集市），Tableau、PowerBI、Superset 直接连这些表出图。Kettle 负责「把数据弄干净」，BI 负责「把数据显出来」。

数据集市层由 Kettle 按主题建模：订单域、用户域各自汇总成宽表，BI 直接拖字段。我们不让 BI 连原始层做重关联，否则每次打开报表都重算，慢且不稳。加工下推到 Kettle/仓库是分工常识。

增量刷新很关键。BI 报表要求近实时，我们让 Kettle 作业按分钟级调度，只更新当日分区，避免全量重刷。配合「插入更新」或分区覆盖，报表延迟控制在可接受范围。

指标口径要统一。同一个「活跃用户」在多处定义会打架，我们把口径固化在 Kettle 的金刚转换里，BI 只消费结果，不各自重算。这样全公司看同一张数，对账不再扯皮。

权限上，BI 账号只连集市层只读，Kettle 的写入账号与 BI 读取账号分离。我们给 BI 建专属只读用户，避免报表查询意外锁住 ETL 写入，两套负载互不踩踏。

关键代码与配置

下面这段 sql 给出了可直接落地的配置，输入来自上一步、输出写入目标端：

-- Kettle 在集市层固化指标口径，BI 直接读
CREATE TABLE marts.user_active_day AS
SELECT dt, COUNT(DISTINCT user_id) AS active_users
FROM dwd_orders WHERE dt='${p_day}' GROUP BY dt;
​

口径在 Kettle 侧算好落集市，BI 只读不重算。我们所有公共指标都走这道，杜绝多口径。

<connection><name>bi_ro</name><type>PostgreSQL</type>
  <username>bi_reader</username>   <!-- 只读账号 -->
  <password>${BI_PASS}</password>
</connection>
​

BI 用只读连接集市层。读写账号分离，报表查询不锁 ETL 写，互不踩踏。

背景

报表刚上线时 BI 直接连原始层做多表大关联，打开一次查询十几秒，还锁住 ETL 写入。

操作

Kettle 增建集市宽表，BI 改为连只读集市，重关联下沉到 Kettle/仓库。

CREATE TABLE marts.order_wide AS
SELECT o.*, c.name, p.cat FROM dwd_orders o
JOIN dim_customer c ON o.cid=c.id JOIN dim_product p ON o.pid=p.id;
​

结果

报表秒开，ETL 写入不再被锁，两套负载各安其位。

解读

根因是加工位置错配。重关联不该发生在查询时，预计算到集市层才是正解，Kettle 正是干这个的。

变式

若维度变化频繁，可让集市层用视图+定时 Kettle 物化，兼顾新鲜度与查询性能。

常见误区与工程取舍

误区：BI 连原始层做重关联。预计算到集市，BI 只读。

误区：指标多处重算。口径固化在 Kettle，全公司同一口径。

取舍：读写账号分离；增量只刷当日分区，控延迟省资源。

深入：和 BI 平台怎么衔接

BI 平台（如各类可视化分析工具）需要的是「干净、稳定、可重复查询的结果数据」，而不是 Kettle 的运行过程。正确做法是：Kettle 把清洗结果写入数据集市表（或立方体的事实/维度表），BI 再去读集市，二者通过数据解耦。不要让 BI 直连 Kettle 运行时或源库——那样 BI 查询会干扰 ETL，且源库结构一变 BI 就崩。Kettle 在结束时可调用「建索引/刷新物化视图/通知 BI 缓存失效」等步骤，保证 BI 看到的是最新且一致的数据。

-- Kettle 收尾步骤：把结果写入 BI 可读的集市并刷新（输入：清洗结果；输出：BI 数据集市）
INSERT INTO bi_orders_daily (dt, user_cnt, pay_amt, status_cn)
SELECT '${p_day}', COUNT(DISTINCT user_id), SUM(amount), '已支付'
FROM   dwd_orders_clean
WHERE  dt = '${p_day}';
-- 写完后 Kettle 执行「ANALYZE TABLE bi_orders_daily」更新统计，BI 查询计划才准
​

⚠️ 常见坑（BI 集成）

• BI 直连源库：源结构一变 BI 崩，且查询干扰 ETL。
• 不做收尾刷新：统计信息过期，BI 查询慢且计划歪。
• 集市与源耦合：Kettle 与 BI 应只通过集市表这一契约解耦。

💡 关键直觉

• Kettle 与 BI 之间是「数据契约」：Kettle 产出集市，BI 消费集市，互不侵入。
• 收尾步骤（建索引/刷新统计/失效缓存）常被忘，却是 BI 看板准不准的最后一环。

工程实录：BI 读集市而非源库

BI 直连源库，源结构一变看板全崩，还干扰 ETL。

Kettle 把结果写入集市，收尾刷新统计，BI 读集市。

INSERT INTO bi_orders_daily (dt, user_cnt, pay_amt)
SELECT '${p_day}', COUNT(DISTINCT user_id), SUM(amount)
FROM   dwd_orders_clean WHERE dt='${p_day}';
-- 写后 ANALYZE TABLE 更新统计，BI 查询计划才准
​

BI 与 ETL 解耦，看板稳定。

Kettle 与 BI 之间是数据契约，互不侵入。

收尾步骤失效 BI 缓存，保证看到最新一致数据。

参数与阈值速查