自助分析平台搭好了,为什么业务还是天天找数据?聊聊权限、模板与联邦查询那些坑

举报
Echo_Wish 发表于 2026/06/30 08:13:05 2026/06/30
【摘要】 自助分析平台搭好了,为什么业务还是天天找数据?聊聊权限、模板与联邦查询那些坑

自助分析平台搭好了,为什么业务还是天天找数据?聊聊权限、模板与联邦查询那些坑

作者:Echo_Wish

很多企业都有这样一个场景。

老板说:“我们要建设自助式分析平台,让业务自己分析数据。”

IT部门加班三个月,上线了BI平台、拖拽报表、数据大屏、SQL查询……

结果上线一个月后。

业务同事依然每天在群里发:

“帮我查一下昨天订单。”

“能不能再导出一份Excel?”

“这个字段是什么意思?”

于是很多人开始怀疑:

是不是自助分析平台没用?

其实,并不是平台没用,而是很多企业建设的是"查询平台",而不是"分析平台"。

真正决定一个自助分析平台能不能成功的,从来不是界面漂不漂亮,而是三个容易被忽略的核心能力:

  • 权限体系(Security)
  • 模板体系(Template)
  • 联邦查询(Federation)

今天,我们就结合实际项目,好好聊聊这三个能力到底为什么这么重要。


第一件事:没有权限体系,自助分析就是数据泄漏现场

很多公司刚开始建设的时候,都有一种非常天真的想法:

大家都是自己人,开放一点没关系。

于是直接给所有人开放SQL。

结果没多久就出现这种情况:

市场部门查到了薪资数据。

采购部门看到了财务流水。

供应商甚至能看到其他供应商的数据。

这不是分析平台。

这是"数据裸奔平台"。

所以,自助分析第一原则只有一句话:

权限一定比分析能力更重要。

一个成熟的平台,一般至少要做到四层权限。

用户(User)角色(Role)数据域(Data Domain)字段(Column)(Row-Level Security)

例如:

销售A:

只能查看:

华东区域
订单数据
客户名称
销售额

销售B:

只能查看:

华南区域
订单数据
客户名称
销售额

HR:

可以查看:

员工工资
绩效
组织架构

采购:

只能查看采购订单
不能查看工资

权限控制最好不要写死在代码里。

可以采用RBAC + 数据权限配置。

例如:

class PermissionService:

    def has_access(user, dataset):

        return dataset.id in user.role.datasets

    def filter_rows(user, dataframe):

        return dataframe[
            dataframe["region"] == user.region
        ]

这样,当组织调整的时候。

改配置即可。

不用重新开发。


第二件事:为什么大家宁愿用Excel,也不用BI?

很多技术人员一直想不明白:

平台那么高级。

为什么业务就是喜欢Excel?

答案其实特别简单。

因为:

Excel里面有他们自己的模板。

真正让业务离不开的,不是工具。

而是模板。

举个例子。

采购部门每天都会看:

供应商交付率

采购金额

延期订单

库存预警

如果每次都要重新拖字段。

重新配置指标。

重新画图。

没人愿意。

真正优秀的平台,一定有模板中心。

例如:

采购分析模板

销售分析模板

库存分析模板

财务分析模板

生产分析模板

业务打开以后:

点击模板

↓

自动加载SQL

↓

自动加载指标

↓

自动加载图表

↓

直接查看

模板的数据结构甚至可以配置成JSON。

例如:

{
  "template": "销售日报",
  "dataset": "sales_order",
  "dimensions": [
    "region",
    "salesman"
  ],
  "metrics": [
    "amount",
    "profit"
  ],
  "chart": "bar"
}

平台读取以后:

自动生成:

SQL

图表

过滤条件

排序

分页

业务根本不用学SQL。

这才是真正的自助分析。


第三件事:为什么越来越多公司开始做联邦查询?

以前的数据架构:

ERP

↓

同步

↓

ODSDWBI

这种方式没有问题。

但是有一个致命缺点。

数据延迟。

很多企业:

每天凌晨同步一次。

意味着:

上午十点的数据。

要第二天才能看到。

老板问:

今天销量多少?

回答:

明天告诉您。

这就很尴尬。

于是联邦查询开始越来越流行。

所谓联邦查询,其实一句话:

数据不用搬,查询过去。

例如:

订单在MySQL。

库存在PostgreSQL。

日志在ClickHouse。

用户画像在Hive。

平台统一查询。

用户完全感觉不到数据来自哪里。

例如:

                BI
                 │
    ┌────────────┼────────────┐
    │            │            │
 MySQL      ClickHouse      Hive

Python演示一个简单的联邦查询思想:

class FederationQuery:

    def execute(self):

        order = mysql.query("""
        select id,amount
        from order
        """)

        stock = postgres.query("""
        select id,stock
        from inventory
        """)

        log = clickhouse.query("""
        select id,pv
        from access_log
        """)

        return (
            order
            .merge(stock,on="id")
            .merge(log,on="id")
        )

当然。

真正生产环境一般不会这样写。

而是交给:

  • Trino
  • Presto
  • StarRocks
  • Doris
  • Spark SQL

统一完成。

这样业务看到的:

始终只有一个SQL入口。


第四件事:模板 + 权限 + 联邦查询,三者缺一不可

很多项目失败。

都是因为只做了一部分。

例如:

只有权限。

不会分析。

业务不用。

只有模板。

数据不同步。

业务不用。

只有联邦查询。

没有权限。

安全事故。

所以真正的平台一般都会这样设计。

              Portal
                 │
        ┌───────────────┐
        │ Template Center│
        └───────────────┘
                 │
         SQL Generator
                 │
      Permission Engine
                 │
      Federation Engine
                 │
 ┌───────┬────────┬─────────┐
 │MySQL  │Hive    │ClickHouse│
 └───────┴────────┴─────────┘

请求流程如下:

用户登录

↓

角色认证

↓

选择模板

↓

模板生成SQL

↓

权限自动追加过滤条件

↓

联邦查询执行

↓

统一返回结果

↓

图表展示

其中最容易被忽略的一步,就是权限自动改写SQL

例如:

业务原始SQL:

SELECT region,
       SUM(amount) AS total_amount
FROM sales_order
GROUP BY region;

平台根据当前用户所属区域自动追加数据权限:

SELECT region,
       SUM(amount) AS total_amount
FROM sales_order
WHERE region = '华东'
GROUP BY region;

对于开发者来说,业务写一次SQL即可;对于平台来说,权限控制始终由统一引擎接管,避免每个报表都单独实现权限逻辑。


第五件事:未来的自助分析平台,正在从"看数据"走向"问数据"

最近两年,大模型的发展又给自助分析带来了新的变化。

以前:

SQL

↓

生成报表

现在:

输入:

最近30天销量为什么下降?

↓

AI理解业务语义

↓

自动生成SQL

↓

联邦查询

↓

自动生成图表

↓

自动输出分析报告

例如:

question = "近30天华东地区销量下降原因"

sql = llm.generate_sql(question)

result = trino.execute(sql)

report = llm.analysis(result)

print(report)

未来真正的分析平台,很可能会演变成这样一种工作方式:

业务人员不再关心数据库、表结构、字段名称,也不用学习复杂的SQL语法,只需要提出业务问题,平台就能自动完成数据查询、权限校验、跨源整合以及结果解释。这意味着,自助分析的门槛将进一步降低,而数据团队也能把更多精力放在数据治理和模型建设上,而不是每天重复写查询语句、导出Excel。


写在最后

这些年参与过不少数据平台项目,我越来越认同一句话:

自助分析平台最大的价值,不是让业务学会写SQL,而是让业务把时间花在分析问题,而不是获取数据。

一个真正成熟的平台,绝不是把数据库直接暴露给用户,而是通过权限体系保证数据安全,通过模板体系沉淀最佳实践,通过联邦查询打通数据孤岛,再借助AI降低分析门槛

很多企业花了大量预算采购BI工具,却迟迟没有达到预期效果,问题往往不在工具本身,而在于忽略了平台能力建设。没有治理能力的自助,只会带来混乱;没有模板沉淀的自助,只会增加学习成本;没有统一数据访问能力的自助,也终究会被一个个数据孤岛拖垮。

未来的数据平台,一定不是"人人都会SQL",而是"人人都能分析数据"。当业务提出问题,平台自动完成权限校验、智能选取模板、跨数据源联邦查询,并结合AI给出分析结论时,自助分析才真正完成了从"数据可见"到"数据可用",再到"数据可决策"的升级。

这,才是下一代自助式分析平台真正应该努力的方向。

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。