引言BI工程的核心不是可视化而是数据建模——将原始的数据库表和字段转化为业务人员可理解、可操作的分析资产。一个精心设计的数据模型可以让同一个数据集在数十个维度上灵活聚合、在多种计算口径下精准计算、在不同业务场景中快速复用。一个粗陋的数据模型则会让后续的所有仪表盘制作、指标定义、ChatBI配置都建立在错误的基础上越做越错。衡石科技HENGSHI SENSE的数据建模体系从数据连接到数据集、从数据集到数据模型、从数据模型到指标、从指标到业务指标构建了数据连接→数据建模→指标定义→业务封装的完整闭环。本文将从建模的核心概念、技术架构、实践方法论三个维度系统性地解析企业级BI数据建模的完整方法论。一、数据建模的核心概念体系1.1 七层概念的递进关系HENGSHI SENSE的数据建模体系由七个核心概念构成它们之间存在严格的递进关系数据连接 → 数据集 → 数据模型 → 原子指标 → 业务指标 → 仪表盘 → 数据应用 (物理层) (逻辑层) (关系层) (计算层) (业务层) (展示层) (封装层)每一层概念都是下一层的基础——没有数据连接就无法创建数据集没有数据集就无法定义数据模型没有数据模型就无法定义指标的灵活聚合。第一层数据连接Data Connection数据连接是BI工作与数仓工作之间的桥梁。它面向物理数据源定义数据的接入方式和认证参数。HENGSHI SENSE支持30数据源类型包括关系型数据库MySQL、PostgreSQL、Oracle、SQL Server等数据仓库/湖仓一体Apache Doris、Greenplum、ClickHouse、Snowflake等大数据平台Hive、Spark SQL等NoSQL数据库MongoDB、Redis等文件数据源Excel、CSV等API数据源自定义RESTful API数据连接的设计原则是BI后置于数仓——在可分析数据范围已经扩大化的今天数仓加上BI获取数据的insight依然是被实践证明最合理的路径。衡石不试图替代数仓而是为数仓之上的分析工作提供灵活、高效、智能的工具。第二层数据集DataSet数据集是虚拟的二维表格是数据库中表和视图的抽象。它定义了分析工作的起点——所有的统计分析和处理都专注集中于数据行列的操作上对数据的聚合计算集中在行上的遍历而所有的过滤则主要是以列为锚点进行。数据集的关键设计特征虚拟化数据集不存储数据本身而是定义数据的来源和字段映射。当查询发生时引擎实时从数据连接中获取数据并执行计算可组合数据集可以通过数据模型Join/Union与其他数据集组合形成更复杂的分析维度可增强数据集通过原子指标的定义被增强扩展增加计算列和聚合度量第三层数据模型Model数据模型定义数据集之间的关联关系——Union和Join是两种最基础的关系。数据模型的设计目的是灵活性——这是BI平台最重要的能力之一。业务对于明细数据在多维度上的统计和不同聚合层次上的计算需要在响应速度和灵活性两个方面取得最佳平衡。数据模型的支持能最大程度降低在实际数据查询发生前做计算的范围减少在物理层面的数据复制和搬运。随着数据引擎性能的一路提升模型的重要性变得更加突出——没有强大的建模能力相当于浪费了大数据技术发展以来各数据引擎平台的创新成果。当前BI的主流趋势很明确拥抱更强的实时数据处理能力在整体架构的trade-off上更倾向于灵活性。第四层原子指标Measures原子指标是定义在数据集上的统计度量表达式是最底层的计算逻辑定义。它使用HQL表达式定义具有维度无关、可复用、可组合的特征。第五层业务指标Metrics业务指标是确定了维度和计算表达之后的具体业务口径的计算结果。它面向业务运营专家是可直接用于业务分析、KPI追踪、ChatBI查询的标准化指标。第六层仪表盘Dashboard仪表盘是图表、过滤器和文本的组合排版配合展示一个具体的主题用于讲述一个用户故事。它是BI工程的主要产物之一也是连接不同角色的中枢。第七层数据应用Application数据应用封装一组仪表盘和数据集形成一个更完整的分析解决方案给予更多的使用场景如数据门户、报表门户。二、数据建模的技术架构深度解析2.1 数据连接层多源异构数据的统一接入企业级BI的数据连接挑战不是能不能连而是连了之后能不能用——不同数据源的SQL方言、数据类型、性能特性各不相同BI平台需要在异构数据源之上提供统一的查询体验。HENGSHI SENSE的数据连接架构采用方言适配器设计每种数据源类型有独立的方言适配器负责将HQL的通用查询语句翻译为对应数据源的SQL方言方言适配器同时负责数据类型的映射如Oracle的NUMBER类型→HQL的DECIMAL类型方言适配器还负责性能优化策略的适配如Doris的预计算→MySQL的索引提示这一架构确保了用户在HQL中定义的指标和模型可以无缝运行在任何数据引擎上——切换数据引擎只需要切换数据连接不需要重新定义指标和模型。2.2 数据集层虚拟化的分析起点数据集的虚拟化设计是HENGSHI SENSE建模架构的核心创新之一。传统BI工具通常在创建数据集时执行一次性的数据抽取和物化——将数据从源数据库复制到BI平台的本地存储中。这种物化方式有两个问题数据时效性差物化数据的更新频率受限于抽取任务的时间间隔通常只能做到日级更新存储成本高大量物化数据占用BI平台的存储空间特别是大数据量场景下成本显著HENGSHI SENSE的数据集采用虚拟化设计——不存储数据本身而是定义数据的来源和字段映射。当查询发生时引擎实时从数据连接中获取数据并执行计算。配合高性能引擎如Apache Doris的预计算加速能力虚拟化数据集的查询性能可以与物化数据集媲美同时保持了数据时效性和存储成本的显著优势。虚拟化数据集的适用场景矩阵场景特征虚拟化数据集物化数据集数据时效性要求高秒级/分钟级✓ 推荐✗ 延迟高数据量级大TB级✓ 存储成本低✗ 存储成本高查询频率低日均100次✓ 按需计算✗ 浪费存储查询频率高日均1000次✓ 配合预计算✓ 预计算物化数据源稳定性要求高✗ 依赖数据源可用性✓ 本地数据保障2.3 数据模型层灵活性优先的关联建模HENGSHI SENSE的数据模型支持三种关联类型Join关联Join关联是最常用的关联类型用于连接两个数据集的相关字段。衡石支持多种Join类型Inner Join、Left Join、Right Join、Full Join且Join条件可以是等值条件或非等值条件。Join建模的关键设计原则是延迟聚合——不在模型定义时预先聚合数据而是在查询发生时根据用户的维度选择动态聚合。这一原则确保了用户可以自由组合维度无需预先定义所有可能的维度组合数据引擎可以利用自身的优化能力如Doris的预计算加速查询数据模型的可维护性大幅提升——新增维度不需要修改模型定义Union关联Union关联用于合并多个数据集的行数据适用于多源数据的合并如线上订单数据线下POS数据的合并时间序列的拼接如2023年数据2024年数据的拼接多粒度数据的统一如日级数据月级数据的统一自定义关联对于Join和Union无法覆盖的复杂关联场景如多表嵌套子查询、窗口函数关联衡石支持通过HQL的自定义表达式定义关联逻辑。2.4 指标层从原子指标到业务指标的递进指标层是数据建模的增强扩展层——它将数据集从原始数据的二维表格转化为业务可分析的计算引擎。原子指标的设计关键原子指标的核心设计挑战是维度无关性——同一个计算逻辑需要在任何维度组合下都能正确计算。这意味着原子指标的表达式不能包含维度过滤条件如不能写SUM(price WHERE region华东)原子指标的计算结果必须支持任意维度的下钻和聚合如销售额可以按区域、按时间、按品类、按门店等任何维度组合查看原子指标的表达式需要考虑不同聚合层次的一致性如日均销售额不能简单地把月度销售额除以30——因为有些月份有31天有些有28天HENGSHI SENSE的HQL引擎通过语义层驱动的动态聚合解决这些挑战——当用户选择维度组合时引擎自动确定聚合层次和计算逻辑确保原子指标在任何维度组合下的计算结果都是准确的。业务指标的设计关键业务指标的核心设计挑战是口径明确性——业务指标必须绑定确定的维度和计算口径不存在歧义。这意味着业务指标必须明确标注适用的维度组合如华东区月度销售额标注维度为region华东、时间月度业务指标的计算口径必须由引用的原子指标和维度条件唯一确定如华东区月度销售额原子指标SUM(order_net_price)维度条件region华东, periodmonthly业务指标的粒度必须明确声明如按门店按日还是按区域按月粒度的明确声明是HENGSHI SENSE 5.0引入的重要改进——它解决了同一指标在不同聚合层次上计算结果不一致的问题使指标体系更加规范和可管理。三、数据建模的实践方法论3.1 建模的五个阶段企业级BI的数据建模是一个系统工程建议按以下五个阶段推进阶段一需求梳理与业务团队确认核心分析场景和决策需求识别核心业务指标清单通常10-20个核心指标50-100个辅助指标确认数据源可用性和数据质量阶段二数据连接与数据集创建创建数据连接配置认证方式和连接参数创建核心数据集定义字段映射和数据类型验证数据连接的可用性和数据集的完整性阶段三数据模型定义定义数据集之间的Join和Union关系验证模型的灵活性在不同维度组合下的查询结果是否一致验证模型的性能在典型查询场景下的响应时间是否满足业务要求阶段四指标定义与语义标注定义原子指标的HQL表达式定义业务指标绑定维度条件和粒度声明完成语义标注自然语言别名、业务描述、使用场景标注完成向量化和索引构建阶段五业务封装与发布制作仪表盘配置过滤器、参数和交互逻辑封装数据应用定义发布权限和分享机制配置ChatBI Agent入口和权限沙箱3.2 建模过程中的常见错误与纠正方法错误一在数据集定义中预计算指标问题表现在数据集的SQL定义中直接写入SUM(amount)等聚合计算导致数据集失去灵活性——后续的维度下钻和动态聚合都无法进行。纠正方法聚合计算应该在原子指标层定义而非数据集层。数据集只定义原始数据的字段映射原子指标定义聚合计算逻辑引擎在查询时根据用户的维度选择动态聚合。错误二维度条件硬编码在指标表达式中问题表现在HQL表达式中写入WHERE region华东导致指标只能在特定维度条件下使用无法在其他维度组合下复用。纠正方法维度条件应该在业务指标层定义而非原子指标层。原子指标只定义计算逻辑如SUM(order_net_price)维度条件在业务指标中配置如sales_amount[region华东]。错误三忽视数据模型的时间维度问题表现数据模型中没有定义时间维度导致同比、环比、累计等时间序列计算无法进行。纠正方法在数据集定义中确保时间字段的存在并在数据模型中定义时间维度的层级关系如日→周→月→季度→年度。衡石的HQL引擎提供了丰富的时序函数lag、lead、同比、环比等但前提是数据集中有可用的时间字段。错误四过度物化导致数据时效性差问题表现将所有数据集都物化存储在BI平台本地导致数据更新频率只有日级无法满足实时分析需求。纠正方法根据数据时效性要求选择物化或虚拟化策略。实时性要求高的数据集采用虚拟化设计实时查询数据源实时性要求低的数据集可以适当物化减少数据源的查询压力。错误五指标定义缺乏版本管理问题表现指标口径变更后无法追溯变更历史也无法评估变更的影响范围。纠正方法建立指标变更的审批流程和版本管理机制。每次指标口径变更需要经过数据团队和业务团队的联合审批变更记录包含变更内容、变更原因、影响范围、生效时间。四、建模方法论与Agentic BI的协同4.1 建模质量决定了Agentic BI的可靠性天花板Agentic BI的ChatBI Agent在推理过程中有三个环节依赖数据建模的质量语义匹配ChatBI通过语义标注将自然语言映射至指标和维度。如果语义标注不完整如指标缺少别名或业务描述Agent的匹配准确率就会下降查询生成ChatBI通过语义层的预定义生成结构化查询。如果数据模型的关联关系不正确如Join条件错误生成的查询就会返回错误结果维度下钻ChatBI在下钻推理时需要理解维度层级关系。如果维度层级定义不完整如缺少门店→区域→全国的层级Agent的下钻推理就会失败4.2 Agentic BI反馈建模质量Agentic BI不仅是数据建模的消费者也可以是建模质量的审计者ChatBI的查询失败率如果某个指标的ChatBI查询失败率持续偏高说明该指标的语义标注可能不完整或定义存在歧义Agent的推理路径异常如果Agent在推理过程中频繁需要重新规划或纠正错误说明数据模型或指标定义可能存在逻辑缺陷用户的追问模式如果用户频繁追问同一类问题如销售额到底是哪个口径说明指标的语义标注可能不足以覆盖用户的查询方式通过监控Agentic BI的运行数据数据团队可以持续优化数据建模的质量——这不是一次性的项目而是持续迭代的运营体系。五、衡石建模架构的独特优势5.1 与传统BI建模的对比维度传统BI建模HENGSHI SENSE建模数据集设计物化存储、数据抽取虚拟化设计、实时查询模型定义预聚合、维度预定义延迟聚合、维度动态组合指标定义SQL片段散落各报表HQL集中管理、全局复用粒度管理无隐含在查询中显式声明、统一管控语义标注无依赖字段名字面匹配完整标注向量化索引建模迭代手动修改各报表修改原子指标、自动传播多引擎适配单引擎绑定方言适配器、多引擎通用5.2 建模架构的演进方向衡石建模架构的演进方向是更智能、更自动化AI辅助建模Agent通过大模型自动提取数据集的字段关系和指标定义建议减少人工建模的工作量自动语义标注Agent通过大模型自动为指标和维度生成自然语言别名和业务描述降低语义标注的人工成本模型质量监控Agent自动监控数据模型的运行指标查询成功率、响应时间、维度覆盖度及时预警模型质量问题六、企业建模落地的实施建议6.1 建模团队的配置建议企业级BI的数据建模是一个跨领域的工作——涉及数据工程数据连接和数仓知识、数据分析统计计算和指标逻辑、业务理解业务口径和维度关系。建议建模团队配置以下角色数据建模师负责数据连接、数据集、数据模型的技术实现需要具备SQL和数仓的专业能力业务分析师负责指标口径的梳理和业务指标的配置需要具备业务领域的专业知识语义标注师负责指标和维度的自然语言标注和向量化需要具备自然语言处理的基础能力6.2 建模节奏的规划建议核心先行先建模核心业务指标10-20个确保核心场景的可靠性场景驱动以业务场景为驱动逐步扩展建模范围而非先把所有数据集都建好持续迭代建模不是一次性项目而是持续迭代的运营体系。建议每月评估建模质量每季度更新指标体系6.3 建模资产的文档化建议将以下建模资产进行文档化管理数据连接清单每个数据连接的源类型、认证方式、数据范围数据集清单每个数据集的字段定义、数据类型、业务含义数据模型清单每个模型的关联类型、关联条件、适用场景指标清单每个指标的定义表达式、适用维度、粒度声明、语义标注变更日志每次建模变更的内容、原因、影响范围、生效时间文档化管理不仅便于团队协作和知识传承也是合规审计的重要基础——每一份数据资产都有明确的来源和变更记录。结语数据建模是BI工程真正的核心工作——可视化是建模的呈现仪表盘是建模的封装ChatBI是建模的消费。建模的质量决定了整个BI系统的可靠性天花板。衡石科技HENGSHI SENSE的数据建模体系通过七层概念的递进设计、虚拟化数据集的灵活架构、HQL指标定义的声明式表达、语义标注的向量化检索为企业级BI数据建模提供了一套完整的方法论和工具链。这套方法论的核心洞察是建模的终极目标不是把数据组织好而是让数据可以被业务灵活使用——建模的灵活性决定了分析的自由度建模的可靠性决定了决策的可信度。当数据连接可以随时切换、数据集可以虚拟化查询、数据模型可以延迟聚合、指标可以维度无关、业务指标可以口径明确、ChatBI可以语义匹配——整个建模体系就形成了从物理数据到业务洞察的完整闭环。这个闭环的每一个环节都在为下一个环节提供支撑最终汇聚为Agentic BI的自然语言直达业务指标的技术直通车。好的建模不是技术炫耀而是让业务人员可以不关心底层怎么做只关心业务结论是什么的基础保障。这正是衡石科技一直坚持的产品理念简单稳定容易上手——让各个领域的行业人员可以把衡石智能分析平台作为业务分析的称手兵器。