Appearance
数据集/模型
模型的目的
语义模型在数据仓库之上提供了一个灵活的分析层，旨在创建业务流程和概念的数字孪生。它允许您在集中治理的位置定义业务逻辑、指标和关系。这种被称为"左移"的实践，将分析逻辑从下游BI工具或临时查询(如AI代理生成的查询)转移到这个上游建模层。通过这种方式，您可以确保逻辑被版本化、可测试，并在所有使用场景中一致应用。
模型结构
模型代表业务实体或概念，通常映射到数据库中的表或视图。每个模型定义包含名称，并可选择性地包含描述、维度、度量、指标、过滤器和实体(关系)。
必需字段
- name: 模型的唯一标识符，通常与数据库中的表名匹配
- description: 对模型代表的业务概念的清晰解释
- 至少需要定义dimensions(维度)、measures(度量)或metrics(指标)中的一种
可选字段
- dimensions: 维度定义
- measures: 度量定义
- metrics: 指标定义
- filters: 过滤器定义
模型类型
1. 实体中心模型
代表核心业务对象或概念，通常映射到传统数据仓库中的维度表。
特点:
- 主要包含描述性维度(如客户名称、产品类别)
- 可能包含与实体直接相关的度量(如客户的信用额度)
- 通常包括基于实体属性的过滤器(如是否是高级客户)
示例: 客户、产品、员工、商店、发票
2. 事件中心模型
代表随时间发生的业务事件或交互，通常映射到事实表或事件流数据。
特点:
- 几乎总是包含时间戳维度
- 包含描述事件的维度(如页面URL、订单状态)
- 通常包含量化事件的度量(如订单金额、浏览时长)
- 通常与多个实体中心模型建立关系
示例: 页面浏览、订单、交易、登录事件、支持工单
3. 指标中心模型
围绕核心业务指标或KPI构建，通常对应于星型或雪花模式中的事实表。
特点:
- 主要包含构成核心指标的度量
- 维度通常是外键(如日期ID、客户ID)
- 主要目的是定义一个或多个重要指标(如总收入、活跃用户)
- 严重依赖关系连接回各自的维度/实体模型
示例: 月度收入、每日用户活动、营销活动表现
最佳实践
- 从实体和事件开始：大多数语义层主要围绕实体中心和事件中心模型构建
- 明确关系：清晰定义模型间关系
- 混合使用：现实数据通常需要组合使用不同模型类型
- 保持专注：每个模型应代表一个明确定义的概念
- 性能考虑：对于大型数据集，考虑使用指标中心模型进行预聚合
模型文件组织
- 每个模型定义必须放在单独的YAML文件中
- 建议按业务领域分组到子目录(如models/finance/, models/marketing/)
- 使用蛇形命名法(snake_case)命名模型
- 名称应反映业务概念而非技术表名
命名约定
- 使用蛇形命名法(如order_items)
- 选择反映业务实体或概念的名称
- 在整个语义层中保持命名模式一致
其他最佳实践
- 清晰的描述：始终包含解释模型业务意义的描述文本
- 从简单开始：从核心模型定义开始，根据需要逐步添加维度、度量等
- 与数据源对齐：概念上应与数据库表或视图对齐，但不是严格要求
- 逻辑分组：使用单独文件和子目录对相关模型进行逻辑分组