2. Kimball的DW/BI架构解析


  引言:DW,即Data Warehouse,数据仓库;BI,即Business Intelligence,商业智能。数据仓库存在的目的即为商业智能服务,二者相伴相生,故在此讨论DW/BI系统架构。

Kimball的DW/BI架构

  基于Kimball架构的DW/BI环境一般由业务系统(数据源系统)、ETL系统、数据展现、和商业智能应用四部分组成,如下图:
在这里插入图片描述

1. 业务系统(数据源系统)

  它们是操作型系统,用于处理企业的各种事务,如办公OA、采购管理系统、财务系统等。它们一般处于数据仓库之外,且存储的数据的格式和内容各不相同。
  这些业务系统的查询通常是浅显的,以一次一条或有限几条记录的查询方式构成常见的事务流,因而不能实现类似DW/BI系统那样广泛的、无法预料的查询功能。
  多数情况下,业务系统是一种独立的、针对特定业务的应用,它并不会与其他业务系统共享自身的业务数据和公共数据,业务系统之间是割裂的存在。

2. 获取-转换-加载(ETL)系统

  ETL,即Extract Transformation and Load,获取-转换-加载。
  “获取”(采集)是将源数据从业务系统导入数据仓库的第一步,一般情况下,出于性能的考虑,获取的过程中不会对源数据进行任何处理,而是保持数据原样。此步骤即数据仓库分层模型中的ODS(贴源层)。
  获取到数据后,需要进行多种“转换”操作,例如数据清洗、合并不同数据源的数据等。在数据仓库的分层模型中,此步骤大致可对应DWD(数据清洗)和DWS(数据轻度汇总)的操作。
  在常见的大数据平台架构中(如Lambda/Kappa架构),鉴于运行效率的差别,获取和转换两个步骤之间一般通过MQ进行解耦,以提高

<think>好的,用户现在问的是数据集市层和ADS层有什么不同。我需要先理解这两个概念分别属于数据架构中的哪个部分。根据之前的历史,用户对Kimball的多维体系结构有了解,可能是在数据仓库和数据分析的背景下提问的。 首先,数据集市层(Data Mart Layer)通常是数据仓库中的一个子集,专注于某个部门或特定业务领域的数据,比如销售、财务等。它是按照星型模型或雪花模型设计的,使用一致性维度和事实,方便用户进行OLAP分析。而ADS层(Application Data Service)听起来像是阿里巴巴数据架构中的一部分,属于应用数据服务层,主要用于支持具体的应用或业务需求,可能更偏向于汇总和加工后的数据,供前端直接使用。 需要确认ADS层的定义是否因企业而异,但通常在大数据架构中,ADS层位于数据仓库之上,对接应用层,提供高度汇总的数据或接口服务。而数据集市层更偏向于部门级的分析需求,结构上可能更规范化,遵循维度建模。 用户可能是在比较数据仓库中的不同层次,或者是在实际工作中遇到了这两个层的划分,需要明确它们的区别和应用场景。需要解释两者的定位、设计目标、数据粒度、使用场景以及技术实现上的差异。同时要避免混淆其他类似概念,如ODS、DWD、DWS等,但根据问题,可能不需要展开这些。 要确保回答结构清晰,分点对比,帮助用户逐步理解两者的不同。可能需要举例说明,比如数据集市层如何为某个部门提供分析,而ADS层如何支持具体应用的查询或报表生成。同时要强调数据集市是Kimball架构中的概念,而ADS可能是某些企业(如阿里)特有的层次,这样用户能更好地区分通用概念和特定实现。 另外,用户之前询问过Kimball的相关内容,可能在构建数据仓库时遇到了层次划分的问题,需要明确不同层的职责,以便在架构设计中合理规划。因此,回答需要结合实际应用价值,说明两者的不同如何影响数据管理和应用开发。</think>数据集市层和ADS层是数据架构中面向不同场景的数据服务层次,其核心差异体现在**定位、数据粒度、服务对象**等方面。以下是分步骤解析: --- ### **1. 定义与定位** - **数据集市层(Data Mart Layer)** - **定义**:面向**部门级或业务线**的分析需求,基于数据仓库DW)的**子集**构建,通常采用星型/雪花模型。 - **定位**:服务于特定业务领域(如销售、财务)的**分析场景**,支持OLAP查询和报表生成。 - **示例**:为销售部门提供包含“订单事实表+产品维度表”的星型模型。 - **ADS层(Application Data Service Layer)** - **定义**:面向**具体应用或业务端**的即时查询需求,属于数据仓库上层的**应用服务层**。 - **定位**:直接对接前端业务系统(如报表、API),提供**高度聚合或加工后**的数据。 - **示例**:为APP首页展示“用户昨日消费金额”提供预计算的汇总表。 --- ### **2. 设计目标对比** | **维度** | **数据集市层** | **ADS层** | |-----------------|----------------------------------------|------------------------------------| | **核心目标** | 支持灵活的多维分析 | 支撑高并发、低延迟的查询需求 | | **数据模型** | 维度建模(星型/雪花模型) | 宽表、汇总表或接口友好型结构 | | **数据粒度** | 保留明细数据,支持下钻分析 | 高度聚合,通常为日/小时级汇总 | | **服务对象** | 业务分析师、管理层 | 前端应用、实时报表、API调用 | --- ### **3. 技术实现差异** - **数据集市层**: - 依赖**ETL**从数据仓库抽取数据,按业务需求重组为维度模型。 - 存储**历史明细数据**,例如: $$ \text{订单明细表} = \{ \text{订单ID, 用户ID, 商品ID, 金额, 时间} \} $$ - 支持复杂查询(如时间序列分析、多维度交叉计算)。 - **ADS层**: - 通过**数据加工**(如预计算、物化视图)生成高可用数据。 - 存储**聚合结果**,例如: $$ \text{用户消费汇总表} = \{ \text{用户ID, 最近30天消费总额, 订单数} \} $$ - 优化查询性能,通常使用列式存储或缓存技术。 --- ### **4. 典型应用场景** - **数据集市层适用场景**: - 需要灵活分析的业务问题,例如:“分析某产品在不同地区的季度销售额趋势”。 - 使用SQL或BI工具直接查询星型模型。 - **ADS层适用场景**: - 高频且固定的查询需求,例如:“实时展示今日GMV(成交总额)”。 - 直接通过API返回JSON格式的聚合结果: ```json { "user_id": 1001, "last_payment": 158.00, "last_login": "2023-10-01" } ``` --- ### **5. 实际案例说明** - **电商平台架构示例**: 1. **数据仓库层**:存储原始订单流水(`order_raw`)。 2. **数据集市层**:基于订单流水构建“销售分析星型模型”(含时间、商品、地区维度)。 3. **ADS层**:预计算“每日用户活跃度宽表”,直接推送到APP前端。 --- ### **总结** - **数据集市层**:侧重**分析灵活性**,通过维度模型支持复杂查询。 - **ADS层**:侧重**服务效率**,通过预计算和聚合满足高并发需求。 - **关联关系**:数据通常按 `数据仓库 → 数据集市 → ADS层` 的链路流动,前者为后者提供加工基础。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

Bestaier

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值