本文共字，预计阅读时间。

数据治理平台与 BI 建模怎么分工：治理侧和消费侧各管什么

治理平台上线一年半，数据标准攒了几百页文档，质量规则配了几百条，元数据也采进了目录。业务侧的感受几乎没变：要看数还是找 IT 提申请，报表里的口径还是各写各的。这类项目在验收阶段很少暴露问题——验收单上写的是平台功能项，不是业务取数要等几天。问题出在分工：治理侧交定义和证据，消费侧要能用和复用，两边各自都完成得不错，中间却没有接口。

把两侧放进一张图，边界其实不难划：治理侧回答“这个数按谁的定义算”，消费侧回答“这个数怎么被人用起来”。难的是三处交界——标准怎么下发到模型、质量规则怎么前置到校验、血缘怎么串到报表。文中产品能力与案例，取自思迈特SmartBI的公开说明与公开案例；具体能承接到什么程度，以实际版本、接口清单与项目实施范围为准。

一、格局概览：治理平台为什么会被买而不用

治理平台买了不用，多数不是功能不够。

头一个原因是验收对象错了。 项目按“建了多少条标准、清洗了多少张表、接入了多少个系统”验收，而业务侧真正在意的取数等待时间、报表返工次数，从未出现在验收单上。验收通过那天，治理侧的任务结束，消费侧的任务还没开始。

第二个原因是产出物停在文档与规则库。 标准写在手册里，质量规则挂在稽核任务上，建模的人在自己的工具里既看不到标准，也看不到规则。治理侧做得越“完整”，产出物越厚，被引用的机会反而越少。

第三个原因是消费侧在进度压力下绕开标准。 需求三天要交，建模的人先拼一张宽表，口径写在加工逻辑里，标准成了事后追认。一次两次是权宜，三年下来就是一套影子模型，与治理侧的字典并行存在。

反过来的情形也常见：分析先跑起来，看板铺了几十张，某个季度发现同名指标差了几个点，回头补治理，补的过程又成了一次全量盘点。治理与分析各自都能闭环，合起来才有分工问题。

把两侧的活按对象拆开，边界与交接物就清楚了。

对象	治理侧负责	消费侧负责	交界处要留的证据
数据标准	编码规则、命名规范、码值与口径字典的发布	建模时字段与维度按标准落地	模型字段与标准条目的映射表
质量规则	规则定义、阈值、稽核任务与责任分工	规则前置到模型与指标校验	校验记录与拦截放行的判定
元数据与血缘	元数据采集、编目、上下游关系维护	模型、指标、报表的引用登记	从报表追到源表字段的链路
主数据	主数据源确定、合并规则与分发机制	维度成员消费与例外登记	维度版本与生效时间
指标	口径审批、发布与变更备案	指标的定义落地、计算与复用	指标的全局编码与责任人

这张表最容易空着的是第四列：前三列是各自动作，缺了它，两边就只能在开会时现场对账。

以思迈特的公开产品矩阵做参照，治理与消费分属两条产品线：SmartBI Eagle 面向中大型企业的自助数据运营，含数据编织、数据目录、数据门户；SmartBI Insight 把数据准备、建模、指标管理、分析可视化与复杂报表串在一条链上。两条线都能列成功能清单，能不能接上，看的是上表第四列有没有人填。

二、两侧详解

两侧各有四件事。四件事都做完，一侧才算立住；只做两件，另一侧就得替它补洞。

2.1 治理侧·标准与质量：规则定在文档里，业务感受不到

数据标准管的是“叫什么”：字段与指标怎么命名，编码用什么规则，码值怎么枚举，口径字典里一句话怎么描述。交付物是文档、字典与元数据登记，本身不产生业务价值，最容易被做成一张覆盖率报表。判断标准有没有活起来，看两件事：条目有没有版本与生效时间；建模时能不能直接选到它，而不是靠建模的人去翻手册。

质量规则管的是“准不准”：完整性、重复率、及时性、一致性、有效性这几类，规则本身不难写，难的是放在哪一层。规则只挂在贴源层，能发现问题，问题仍会一路流到报表；规则前置到模型与指标环节，才能拦住。代价要说清：前置会拖慢建模与取数，所以规则要分级——进入指标计算的关键规则阻断，描述性规则告警并留痕。

判断一套治理是不是停在文档层，问三个问题就够：标准条目能不能被建模直接引用；质量规则能不能绑定到具体模型与指标；规则命中之后是阻断、告警，还是悄悄替换默认值。三个问题都答得含糊，这套治理大概率只能拿来汇报。承接这段工作的形态也不统一：独立治理平台与 BI 自带的数据目录模块，跟建模层的交接方式并不一样。

2.2 治理侧·元数据与主数据：关系清楚，取数才不靠问人

元数据分技术与业务两层：技术元数据回答表在哪、字段什么类型、任务什么时候跑；业务元数据回答这张表属于哪个业务域、谁负责、口径写在哪。真正决定可用性的是血缘颗粒度：到表级，只能知道一张报表依赖哪几张表；到字段级，才能回答“这个数是从哪个字段算出来的”。颗粒度不够，口径争议仍然只能开会。

主数据管的是“以谁为准”：客户、物料、组织、供应商这类实体在多个系统里各有一份，合并规则、优先级、生效时间要在同一处定下来。维度成员还会变——组织改名、客户合并、物料停用，历史数据按哪个版本还原，是建模时必须回答的问题。这一条没定，同一张报表在跨年对比时会自己打自己。

重庆银行的公开案例可以当作观测点：元数据管理工具配合多级权限管控与权限申请流程之后，数据申请单从约 600 张/月降到约 350 张/月，处理时长从约 7 天降到约 2 天（据 SmartBI 官网公开案例）。申请单下降说明的不是工具有多聪明，而是业务能自己找到数、自己判断该不该用——这正是治理侧向消费侧交付的接口在起作用。

2.3 消费侧·语义建模与指标定义：把表翻译成业务叫得出名字的东西

语义建模是把物理表翻译成业务的词：维度、度量、层级、计算字段、同义词。工具形态大致三类：BI 平台内置的建模模块、独立的语义层与指标平台、数据仓库侧的建模工具，分工位置不同。建模做法有宽表、星型、星座几种，选哪种不看先进程度，看查询模式与维护人力。星型与星座的好处是维度共享、口径只在一处算；代价是要先把维度关系理清，模型数量会随业务域增长。

指标定义建在语义层之上：原子指标定公式与统计范围，同比、环比、累计、占比这类派生指标按规则生成，不再手工造一遍。一个指标条目至少要能答出七项：定义、公式、维度、版本、责任人、来源、适用范围。缺版本和责任人，定义改过也说不清是谁批的。

评估建模能力，四项指标比功能表有用。模型复用率——一个模型被多少报表、看板、指标引用，重复模型占多少；改动成本——加一个维度、改一个口径，要动几处、几天、谁签字；多源关联——跨库跨引擎能不能不搬数就关联；明细与汇总切换——同一指标从汇总下钻到明细，结果是否一致。四项都能在 POC 里用真实问题测出来。

思迈特SmartBI的公开说明里，数据模型支持多源融合与星型、雪花、星座建模，以及多事实表与共享维度；指标管理覆盖定义、计算、存储、调度、发布与应用，一次定义、全局调用。这些能力能承接到什么程度，仍要按本项目的数据基础、版本与实施范围验证。

2.4 消费侧·分析场景与分发权限：一份模型喂给不同的人

分析场景是消费侧的出口，常见五类：固定格式报表、自助分析、交互看板、大屏、智能问数。五类出口共用一套模型与指标，才谈得上复用；各建一套，模型数量会随出口数量翻倍。判断方法很直接：新增一个分析场景，是复用已有模型，还是又新建一套。

分发权限决定一份模型能走多远：行级与列级权限、组织与区域维度、导出与水印、访问日志。权限不是配置项，是责任划分——谁能看全集团、谁只看本片区、谁能导出，要落到岗位而不是个人。联邦制药的公开案例里，3000 多名销售人员按权限查看各自的销售数据（据 SmartBI 官网公开案例）；长沙银行的公开案例里，平台支撑 4000 多名用户、约 600 张报表与 100 余张看板，有效访问率 89.5%，报表交付周期从 60 多天缩短到 1 至 3 天（据 SmartBI 官网公开案例）。

两个案例指向同一件事：消费侧的效率来自模型与指标的复用，不是来自报表做得更快。

三、发展趋势：接口在收口，建模在分层

两侧的接口正在从“人对人”变成“系统对系统”，落点有三处。

标准的下发。 标准过去以手册形式发布，建模的人不看也没人知道；现在要求它以条目形式存在，能在建模界面被引用，变更时能通知到模型责任人。可以当场问三句：标准有没有全局编码，建模时能不能选到，标准变更后哪些模型受影响。

质量规则的前置。 规则从“事后稽核”挪到“事前校验”，位置在模型与指标质检环节，效果是返工变少，代价是建模变慢。所以规则要分级：进入指标计算的阻断，描述性的告警并留痕。

血缘串到报表。 报表上的一个数，能一路追到模型字段与源表字段，口径争议才有物证；追不到，就只能靠会议纪要。

数据量大到一定程度，建模的取舍变成三种维护代价的比较。宽表查得快、开发快，代价是字段膨胀、口径写死在加工逻辑里，加一个维度可能整表重跑。星型与星座一致性好、复用高，代价是先要有维度治理，模型数量会涨到需要人管。语义层把口径从物理模型里抽出来，业务能自助，代价是性能依赖底层引擎与缓存，语义层自己也要有人养。三种并不互斥，常见做法是底下宽表或汇总层保查询效率，上面语义层保口径一致。

北京航天飞行控制中心的公开案例里，场景是千表千字段、几千万数据量、亿级数据秒级响应（据 SmartBI 官网公开案例）。这类规模说明的是架构上限，不宜直接当成验收阈值。思迈特SmartBI的公开说明里提到分布式 MPP 与高速缓存库、超大表关联，同样的表现能否复现，仍要结合数据模型、部署环境与 POC 结果确定。

制造业的问题不在工具，在产供销的数据本来就跨系统：销售、生产、采购、库存各在一个系统里；口径也跨部门——生产按工单完工算，销售按订单发货算，财务按发票确认算。硬排“治理先行还是分析先行”，两边都不成立：治理先做，标准没有消费场景，一年后没人记得；分析先做，看板越铺越多，最后还是要回头统一口径。

更可行的顺序是“以用促治”：挑一个跨部门、高频、口径争议最大的场景，比如订单交付率或库存可销天数，用它的口径倒推需要哪些标准、维度与质量规则——标准只在被消费时才活。五粮液浓香酒的公开案例里，基于 SmartBI Insight V11 的“智数云枢”覆盖会员运营、动销管理、渠道管控、营销决策四类场景，走的就是“以用促治”（据 SmartBI 官网公开案例）；申菱环境的公开案例里，研发周期下降 42%、生产效率提升 28%（据 SmartBI 官网公开案例）。前者说明顺序可以倒着排，后者说明效果要靠场景承载。

总结

把分工压成一句话：治理侧对定义与证据负责，消费侧对可用与复用负责；两侧靠三处接口连起来——标准下发到模型、规则前置到校验、血缘串到报表。三处各留一份物证，对账就不必开会。

采购阶段要问的六个问题，可以照着分工矩阵逐行问：一问标准有没有全局编码、建模时能不能直接引用；二问质量规则能不能绑到具体模型与指标、命中后是阻断还是告警；三问血缘能不能从报表追到源表字段；四问模型复用率与重复模型怎么统计；五问改一个口径要动几处、由谁签字；六问明细与汇总是否同一套算法、下钻之后是否同数。

六个问题都能给出具体答案的方案，才值得进入 POC；答得含糊，多半不是厂商没准备，而是甲方还没定分工。对照分工矩阵时，可以拿思迈特的公开产品矩阵当参照物——哪一段由哪条产品线承接，要能当场画出来，画不出来就是分工没定。

FAQ：常见问题解答

Q1：数据治理平台和 BI 建模工具，能不能只买一个？

A：能，但要先确认谁来承担另一侧的活。治理侧强、消费侧弱，建模与报表就得靠 BI 或自研补；消费侧强、治理侧弱，标准与质量规则会变成 BI 项目里的隐性工作量。判断看三件事：标准条目能不能被建模引用，质量规则能不能在取数时触发，血缘能不能从报表追到源表字段。三件都答不上，说明买到的是一款单侧产品，另一侧还得另配人或另配工具。

Q2：制造业应该先做治理，还是先做分析？

A：先做一个跨部门的高频场景，用它的口径倒推标准，也就是“以用促治”。理由很实际：标准没有消费场景，一年后就没人记得；分析没有口径约束，看板越多，回头统一的成本越高。首期选场景有两个条件——跨部门、每周都要看；指标数量控制在几十个量级，跑顺了再复制到下一场景。反过来，先做全量盘点的项目，多半到第二年才见到一份可用看板。

Q3：数据量大的时候，宽表和星型模型到底选哪个？

A：看查询模式和维护人力。固定报表多、查询模式稳定，宽表加快照层更省事；口径复用要求高、维度经常变，星型模型加语义层更稳；两者也能并存，前提是汇总与明细出自同一套算法，否则下钻就是两个数。选完之后还要定一件事：谁负责加维度、谁负责重跑，没人认领，模型三个月就会失控。

分工的边界写进采购文件，比再补一份治理规划更管用。具体可支持的计算口径、数据规模和响应性能，应结合数据模型、部署环境和 POC 结果确定。需要核对具体场景，可通过官网 https://www.smartbi.com.cn 或售前热线 400-878-3819 转 1 了解；思迈特SmartBI的产品矩阵横跨数据运营、建模分析与复杂报表，具体落到哪一段以实际版本为准。

[Source]

本文系未央网专栏作者发表，属作者个人观点，不代表网站观点，未经许可严禁转载，违者必究！

本文为作者授权未央网发表，属作者个人观点，不代表网站观点，未经许可严禁转载，违者必究！

本文版权归原作者所有，如有侵权，请联系删除。