网硕互联帮助中心要理解数据仓库的分层，首先需要明确其核心目标：通过结构化的层级划分，解决数据从业务系统到业务应用的 “(raw data → clean data → valuable information)” 转化问题，最终实现降低复杂度、提升数据质量、增强复用性、支持灵活分析的目的。
业界主流的数据仓库分层（以 “离线数仓” 为例，实时数仓在此基础上衍生）通常遵循 “自下而上” 的数据流逻辑，分为 6 大核心层级：ODS 层（操作数据存储层）→ DIM 层（维度层）→ DWD 层（数据明细层）→ DWS 层（数据汇总层）→ DWT 层（数据主题层）→ ADS 层（应用数据服务层）。以下将对每个层级进行 “定义 – 作用 – 数据来源 – 数据特点 – 存储内容 – 处理方式 – 应用场景 – 注意事项” 的全维度拆解，并补充分层原则与实践案例。
一、数据仓库分层的整体意义
在深入单层级前，先明确分层的底层逻辑 —— 为何必须分层？
二、各层级详细拆解
1. 第一层：ODS 层（Operational Data Store，操作数据存储层）
ODS 层是数据仓库的 “入口”，直接对接业务系统，保留原始数据特征，是整个数仓的 “数据原材料仓库”。
| 核心定义 | 同步业务系统的原始数据，不做深度加工，仅进行 “轻量级处理”，确保数据与业务源一致。 |
| 核心作用 | 1. 避免直接操作业务数据库（减少业务库压力）； 2. 保留原始数据（用于数据回溯、业务问题排查，如 “某笔订单在业务系统中存在，为何报表中没有？”）； 3. 为下游 DWD 层提供 “未经污染” 的原始数据。 |
| 数据来源 | – 业务数据库：MySQL/Oracle/PostgreSQL 等 OLTP 数据库（如订单表、用户表、支付表）； – 日志数据：用户行为日志（如 APP 点击日志、页面浏览日志）、系统日志； – 外部数据：API 接口（如第三方支付回调数据）、文件（CSV/Excel）。 |
| 数据特点 | 1. 原始性：字段名、字段类型、数据格式与业务系统高度一致（如业务库中 “order_dt” 是 varchar 类型，ODS 层也保留该类型，不直接转为 date）； 2. 增量 / 全量同步：根据业务表特性选择（如订单表用增量，字典表用全量）； 3. 含 “脏数据”：可能包含重复值、缺失值、异常值（如订单金额为负数）； 4. 按业务表划分：不按主题整合（如业务库有 “order_main” 和 “order_detail”，ODS 层也分别存储为 “ods_order_main” 和 “ods_order_detail”）。 |
| 存储内容 | 示例（电商场景）： – ods_order_main：订单主表（order_id, user_id, order_time, pay_status, total_amount, create_user, create_time…）； – ods_user_log：用户行为日志（user_id, action_type, page_url, action_time, device_id…）； – ods_product_info：商品表（product_id, product_name, price, stock, category_id, update_time…）。 |
| 处理方式 | 以 “Extract（抽取）+ Load（加载）” 为主，仅做轻量级 Transform（转换）： 1. 格式统一：如日期字段统一为 “yyyy-MM-dd HH:mm:ss”（业务库可能有 “yyyyMMdd” 格式）； 2. 字段映射：如业务库 “user_no” 统一命名为 “user_id”（规范字段名）； 3. 数据同步：全量同步（如字典表，每天覆盖）、增量同步（如订单表，按 “create_time” 同步 T-1 数据）、CDC 同步（实时场景，捕获数据变更）； 4. 冗余存储：保留删除数据（如业务库软删除字段 “is_delete”，ODS 层不过滤，便于回溯）。 |
| 应用场景 | 1. 数据回溯：如排查 “2024 年 5 月 1 日的订单数据丢失” 问题，直接查询 ODS 层原始数据； 2. 业务系统对账：如核对数仓数据与业务库数据是否一致； 3. 特殊明细查询：如业务需要 “未清洗的原始订单日志”。 |
| 注意事项 | 1. 存储周期：ODS 层数据量大（尤其是日志），需按 “冷热数据” 分层存储（如近期数据存 HDFS，历史数据归档到对象存储 OSS）； 2. 同步策略：避免高峰时段同步（如业务系统凌晨 2 点对账，ODS 同步改到凌晨 4 点）； 3. 元数据记录：记录同步来源（如 “ods_order_main 来自 MySQL 订单库”）、同步频率（T+1）、同步状态（成功 / 失败）。 |
2. 第二层：DIM 层（Dimension Layer，维度层）
DIM 层是数仓的 “业务视角定义层”，存储描述业务实体的属性信息（如用户、商品、时间），为事实表（DWD/DWS）提供 “分析维度”（如按 “地域” 分析订单量，按 “时间” 钻取销售额）。
| 核心定义 | 存储维度表（描述 “是谁、是什么、何时、何地” 的表），是数仓中 “相对稳定” 的数据，支撑多维度分析（切片、钻取、旋转）。 |
| 核心作用 | 1. 统一维度口径：如 “地域维度” 在所有事实表中均关联同一 “dim_region” 表，避免 “北京” 在 A 表是 “北京市”、在 B 表是 “北京” 的不一致； 2. 减少数据冗余：维度属性（如用户 “地域”）仅在 DIM 层存储，事实表仅存 “维度键”（如 user_id），通过关联查询属性； 3. 支持缓慢变化维度（SCD）：处理维度属性的变化（如用户等级从 “普通” 升级为 “VIP”）。 |
| 数据来源 | – 业务系统基础表：如用户表（user_info）、商品分类表（product_category）、地域表（region）； – 外部标准数据：如国家统计局地域编码表、节假日表（用于 “时间维度” 的 “是否节假日” 字段）； – 人工维护数据：如商品标签表（由运营人员维护 “是否爆款”）。 |
| 数据特点 | 1. 变化缓慢：维度属性更新频率低（如用户的 “注册时间” 不变，“地域” 可能半年变一次）； 2. 主键唯一：每个维度表有唯一主键（如 dim_user 的 user_id，dim_product 的 product_id），用于关联事实表； 3. 属性丰富：包含描述性字段（如 dim_user 的 gender、age、register_channel）； 4. 无度量值：仅存储属性，不存储 “订单金额”“销量” 等度量指标。 |
| 存储内容 | 常见维度表分类及示例： – 时间维度表（dim_date）：最核心的公共维度，包含所有分析用的时间粒度（date, year, quarter, month, week, day, day_of_week, is_holiday, is_workday…）； – 用户维度表（dim_user）：user_id, user_name, gender, age_group, register_time, register_channel, region_id, user_level, member_expire_time…； – 商品维度表（dim_product）：product_id, product_name, brand, category_id, category_name, price, spec, launch_time, is_on_shelf…； – 地域维度表（dim_region）：region_id, region_name, parent_region_id, region_level（省 / 市 / 区）, province, city, district…。 |
| 处理方式 | 1. 维度整合：将分散在多个业务库的维度数据整合（如用户的 “会员等级” 在会员库，“注册渠道” 在用户库，整合到 dim_user）； 2. 缓慢变化维度（SCD）处理： – SCD1（覆盖更新）：属性变化时直接覆盖旧值（如用户 “手机号” 变更，无需追溯历史）； – SCD2（新增行）：属性变化时新增一条记录，用 “生效时间”“失效时间” 标记（如用户等级从 “普通”→“VIP”，新增一条 VIP 记录，旧记录标记失效，便于追溯历史等级下的行为）； – SCD3（新增列）：属性变化时新增字段存储历史值（如 “current_level” 和 “previous_level”，适用于仅需保留最近一次变化）； 3. 维度编码规范：如地域编码采用国家标准（6 位行政编码），避免自定义编码导致混乱。 |
| 应用场景 | 所有需要 “维度分析” 的场景： 1. 按时间维度钻取：如 “2024 年 Q2 销售额→5 月销售额→5 月 1 日销售额”； 2. 按用户维度切片：如 “北京地区 25-30 岁女性用户的订单量”； 3. 按商品维度旋转：如 “家电品类下各品牌的销量占比”。 |
| 注意事项 | 1. 维度一致性：同一维度在全数仓中唯一（如 “用户维度” 仅存一份 dim_user，不允许各层单独建用户表）； 2. SCD 策略选择：根据业务需求决定（如需要追溯用户历史等级，用 SCD2；无需追溯，用 SCD1）； 3. 时间维度表预生成：提前生成未来 3-5 年的时间数据（如 2024-2028 年的 dim_date），避免后续缺失。 |
3. 第三层：DWD 层（Data Warehouse Detail，数据明细层）
DWD 层是数仓的 “数据清洗与规范化层”，基于 ODS 层原始数据和 DIM 层维度数据，进行深度清洗、整合、结构化，形成 “干净的明细事实表”，是整个数仓的 “数据基石”。
| 核心定义 | 对 ODS 层数据进行 “去脏、补全、规范” 处理，按 “业务主题”（如订单主题、支付主题、用户行为主题）组织明细数据，为上层汇总（DWS）提供 “高质量明细原料”。 |
| 核心作用 | 1. 解决数据质量问题：去除重复、缺失、异常数据，确保下游数据准确； 2. 统一数据口径：如 “订单金额” 在 ODS 层可能有 “应付金额”“实付金额”，DWD 层明确 “order_amount（应付）”“pay_amount（实付）”； 3. 整合业务数据：将分散在多个 ODS 表中的同一主题数据整合（如 ODS 的 “order_main” 和 “order_detail” 整合为 DWD 的 “dwd_order_detail”）。 |
| 数据来源 | – 主要：ODS 层的业务表、日志表； – 辅助：DIM 层的维度表（用于关联维度键，如将 ODS 的 “user_no” 关联为 DIM 的 “user_id”）。 |
| 数据特点 | 1. 明细粒度：保留最细的业务粒度（如每一笔订单的明细行、每一次用户点击的日志）； 2. 数据干净：无重复值（如同一订单 ID 仅存一条）、无缺失值（如 “支付时间” 缺失时标记为 “9999-12-31”）、无异常值（如订单金额 > 100 万时标记为异常，单独处理）； 3. 主题导向：按业务主题划分（如订单主题、支付主题、物流主题），而非按业务表划分； 4. 关联维度键：仅存储维度主键（如 user_id、product_id），不冗余维度属性（如 user_name、product_name，需关联 DIM 表查询）。 |
| 存储内容 | 示例（电商订单主题）： – dwd_order_detail（订单明细事实表）： 字段：order_detail_id, order_id, user_id, product_id, order_time, pay_time, ship_time, receive_time, quantity, product_price, order_amount（应付）, pay_amount（实付）, discount_amount（优惠）, pay_status, ship_status, refund_status, create_time（数据加工时间）… 说明：整合了 ODS 的 “order_main”（订单主信息）和 “order_detail”（商品明细），清洗了 “order_time 为空”“pay_amount 为负” 的数据，关联了 dim_user 的 user_id 和 dim_product 的 product_id。 |
| 处理方式 | 核心是 “ETL 中的 Transform（转换）”，步骤如下： 1. 数据清洗： – 去重：如按 “order_detail_id” 删除重复记录； – 补缺失值：如 “product_id 为空” 的订单标记为 “异常订单”，单独存储到 “dwd_order_abnormal”； – 修正异常值：如 “order_amount>100 万” 的订单，人工确认后要么修正为正确值，要么标记为异常； – 格式统一：如 “order_time” 从 varchar 转为 date 类型，“pay_status” 统一为 “0（未支付）/1（已支付）/2（退款）”。 2. 数据整合： – 关联表：如 ODS 的 “order_main” 和 “order_detail” 通过 “order_id” 关联，补充 “pay_status”“ship_status” 等字段； – 跨业务整合：如线上订单（来自电商 APP）和线下订单（来自门店系统）整合到同一 “dwd_order_detail” 表，用 “order_channel” 区分。 3. 数据结构化： – 按主题建表：如 “支付主题” 建 “dwd_pay_detail”，包含 “pay_id, order_id, user_id, pay_time, pay_amount, pay_method” 等字段； – 分区存储：按 “order_time”（如按天分区），便于后续按时间查询。 |
| 应用场景 | 1. 明细数据查询：如 “查询用户 ID=123 在 2024 年 5 月 1 日的所有订单明细”； 2. 业务问题深度排查：如 “某笔订单为何退款？”，可查 dwd_order_detail 的 “refund_status” 和 “refund_time”； 3. 为 DWS 层提供明细数据：如 DWS 层 “用户日订单汇总” 需基于 dwd_order_detail 的明细数据聚合。 |
| 注意事项 | 1. 清洗规则文档化：每一条清洗规则（如 “order_amount 为空则标记为异常”）都需记录到元数据系统，避免后续维护混乱； 2. 明细粒度不可粗：DWD 层是 “最细粒度”，若粒度太粗（如按订单主表汇总），会导致后续无法拆分到商品维度； 3. 异常数据单独存储：不丢弃异常数据，而是存储到 “异常表”（如 dwd_order_abnormal），便于后续分析问题原因。 |
4. 第四层：DWS 层（Data Warehouse Service，数据汇总层）
DWS 层是数仓的 “预计算与复用层”，基于 DWD 层的明细数据，按不同分析维度和指标进行聚合计算，形成 “汇总事实表”，避免上层应用重复计算，提升查询效率。
| 核心定义 | 按 “分析维度 + 指标” 预计算汇总数据，为 ADS 层（应用层）或业务查询提供 “即查即用” 的汇总结果，是数仓的 “效率核心”。 |
| 核心作用 | 1. 减少重复计算：如 “用户日订单金额” 在 DWS 层预计算，ADS 层的日报、BI 分析可直接使用，无需每次从 DWD 明细重新聚合； 2. 提升查询效率：汇总数据量远小于明细数据（如 DWD 有 10 亿条订单明细，DWS 按用户 + 天汇总后仅 1000 万条），查询速度提升 10-100 倍； 3. 统一指标口径：如 “日活用户” 的定义（“当日有订单行为的用户”）在 DWS 层固化，全公司所有应用使用同一指标。 |
| 数据来源 | – 主要：DWD 层的明细事实表（如 dwd_order_detail、dwd_pay_detail）； – 辅助：DIM 层的维度表（如按 “region_id” 汇总时，关联 dim_region 获取 “省份” 维度）。 |
| 数据特点 | 1. 汇总粒度：粒度比 DWD 粗，按 “分析维度组合” 划分（如 “用户 + 天”“商品 + 省份 + 月”“地域 + 季度”）； 2. 度量值聚合：存储聚合后的指标（如 sum (order_amount)、count (order_id)、avg (pay_amount)）； 3. 多维度覆盖：支持常见分析维度组合（如 “时间 + 用户”“时间 + 商品 + 地域”）； 4. 增量更新：每天仅计算 T-1 的汇总数据，避免全量重算（如 “用户日订单汇总” 每天新增 T-1 的用户数据）。 |
| 存储内容 | 示例（电商场景常见 DWS 表）： 1. dws_user_day_order（用户日订单汇总表）： 维度：user_id, date（订单日期）； 指标：order_count（订单数）, order_amount（应付总额）, pay_amount（实付总额）, discount_amount（优惠总额）, refund_count（退款订单数）, refund_amount（退款总额）… 2. dws_product_region_month_sales（商品 – 地域 – 月销量汇总表）： 维度：product_id, region_id, month（销售月份）； 指标：sales_count（销量）, sales_amount（销售额）, avg_price（平均售价）, top_day（销量最高日）… 3. dws_region_quarter_pay（地域 – 季度支付汇总表）： 维度：region_id, quarter（季度）； 指标：pay_count（支付订单数）, pay_amount（支付总额）, pay_user_count（支付用户数）, avg_pay_amount（客单价）… |
| 处理方式 | 核心是 “聚合计算”，步骤如下： 1. 确定聚合维度：基于业务需求梳理核心维度组合（如运营需要 “用户 + 天”，销售需要 “地域 + 季度”）； 2. 定义指标逻辑：明确每个指标的计算规则（如 “客单价 = pay_amount/pay_user_count，且 pay_user_count>0”），并录入元数据； 3. 增量聚合计算： – 全量计算（小数据量）：如 “地域 + 季度” 汇总，数据量小，可每月全量重算； – 增量计算（大数据量）：如 “用户 + 天” 汇总，每天仅计算 T-1 的 DWD 数据，然后与历史汇总表合并（如 dws_user_day_order = 历史表 + T-1 汇总结果）； 4. 维度关联补充：如汇总 “地域 + 季度” 数据时，关联 dim_region 获取 “省份名称”，便于上层理解。 |
| 应用场景 | 1. 常规业务监控：如运营查看 “当日用户订单总量”“昨日退款率”； 2. 快速报表生成：如财务的 “月度地域支付报表” 直接使用 dws_region_quarter_pay； 3. BI 灵活分析：如用 Tableau 连接 dws_product_region_month_sales，快速生成 “各省份家电销量趋势图”。 |
| 注意事项 | 1. 维度组合适度：避免维度组合过多（如 “用户 + 商品 + 地域 + 小时”）导致表数量爆炸，仅覆盖 80% 的高频需求； 2. 指标口径固化：指标逻辑一旦确定，不轻易修改（如 “客单价” 定义修改后，需重新计算历史数据，成本高）； 3. 数据校验：每天对比 DWS 汇总数据与 DWD 明细数据的总和（如 dws_user_day_order 的 pay_amount 总和应等于 dwd_order_detail 的 pay_amount 总和），确保聚合正确。 |
5. 第五层：DWT 层（Data Warehouse Topic，数据主题层）
DWT 层是数仓的 “业务全景整合层”，按业务主题（如用户主题、商品主题、营销主题）整合 DWS 层的汇总数据，形成 “同一主题的全量数据视图”，为深度业务分析（如用户画像、商品生命周期）提供支撑。
| 核心定义 | 以 “业务主题” 为单位，整合该主题下的所有相关数据（包括历史累计数据、趋势数据），形成 “主题域数据集市”，是数仓的 “业务深度支撑层”。 |
| 核心作用 | 1. 整合主题数据：如 “用户主题” 整合用户的 “基本信息（DIM）、订单行为（DWS）、支付行为（DWS）、活跃行为（DWS）”，形成完整的用户视图； 2. 存储累计数据：如 “用户总消费金额”“商品累计销量”，避免每次查询都累加历史数据； 3. 支撑深度分析：为用户画像、商品健康度分析、营销效果复盘等场景提供 “一站式数据”。 |
| 数据来源 | – 主要：DWS 层的各汇总表（如 dws_user_day_order、dws_user_day_active、dws_user_day_pay）； – 辅助：DIM 层的主题维度表（如 dim_user）、DWD 层的关键明细数据（如用户首次订单时间）。 |
| 数据特点 | 1. 主题导向：围绕一个业务主题组织（如用户主题、商品主题、营销主题），而非按维度或指标划分； 2. 全量历史：存储该主题的所有历史数据（如用户主题表存储从用户注册到当前的所有累计指标）； 3. 粗粒度 + 多指标：粒度比 DWS 粗（如用户主题按 “用户” 粒度，而非 “用户 + 天”），包含该主题的所有核心指标（如用户的订单、支付、活跃、会员指标）； 4. 趋势特征：包含趋势类指标（如用户近 7 天 / 30 天活跃天数、商品近 3 个月销量增长率）。 |
| 存储内容 | 示例（用户主题表）： – dwt_user_profile（用户主题全景表）： 字段： – 基本属性：user_id, user_name, gender, age_group, register_time, register_channel, region_id, user_level…（来自 dim_user）； – 累计订单指标：total_order_count（总订单数）, total_order_amount（总应付）, total_pay_amount（总实付）, first_order_time, last_order_time…（来自 dws_user_day_order 累计）； – 活跃指标：total_active_days（总活跃天数）, active_days_7d（近 7 天活跃）, active_days_30d（近 30 天活跃）, last_active_time…（来自 dws_user_day_active 累计）； – 会员指标：member_status（是否会员）, member_start_time, member_expire_time, member_total_amount（会员期消费）…（来自 dws_user_day_member）； – 更新时间：update_time（每日更新）。 |
| 处理方式 | 核心是 “主题整合与累计计算”，步骤如下： 1. 主题划分：与业务部门对齐，明确核心主题（如电商的 “用户、商品、订单、营销、物流” 五大主题）； 2. 指标梳理：梳理每个主题的核心指标（如用户主题的 “累计消费、活跃天数、会员等级”）； 3. 累计计算： – 增量累计：如 “total_order_count = 昨日 total_order_count + 今日 dws_user_day_order 的 order_count”； – 趋势计算：如 “active_days_7d = 近 7 天 dws_user_day_active 中 active=1 的天数”； 4. 数据整合：将同一主题的 DWS 汇总数据、DIM 维度数据关联，整合到一张主题表中（如 dwt_user_profile = dim_user + 累计订单指标 + 累计活跃指标 + 会员指标）。 |
| 应用场景 | 1. 用户画像分析：基于 dwt_user_profile 的 “age_group、total_pay_amount、active_days_30d” 划分用户群体（如 “高价值活跃用户”“沉睡用户”）； 2. 商品生命周期分析：基于 dwt_product_profile 的 “launch_time、total_sales、sales_growth_3m、refund_rate” 判断商品处于 “导入期、成长期、成熟期、衰退期”； 3. 营销效果复盘：基于 dwt_marketing_profile 的 “campaign_id、total_click、total_convert、convert_rate、roi” 评估营销活动效果。 |
| 注意事项 | 1. 主题边界清晰：避免主题重叠（如 “订单主题” 和 “支付主题” 需明确边界，支付数据属于支付主题，不重复存储到订单主题）； 2. 累计指标可追溯：记录累计指标的计算逻辑（如 “total_pay_amount 包含退款吗？”），便于问题排查； 3. 更新频率适配业务：如用户主题表每天更新（T+1），营销主题表可按活动周期更新（如活动结束后更新）。 |
6. 第六层：ADS 层（Application Data Service，应用数据服务层）
ADS 层是数仓的 “最终出口”，直接为业务应用提供数据支持，将数仓中的 “数据” 转化为业务能直接使用的 “信息”。
| 核心定义 | 按具体业务需求（如报表、BI、API 接口）组织数据，是数仓与业务应用的 “桥梁”，也是业务用户能直接感知到的层级。 |
| 核心作用 | 1. 满足业务直接需求：如为销售部门提供 “月度地域销售报表”，为运营部门提供 “日活 dashboard”； 2. 降低业务使用门槛：数据格式、指标名称贴合业务习惯（如 “客单价” 而非 “平均支付金额”）； 3. 适配应用格式：如为 BI 工具提供兼容格式，为业务系统提供 API 接口数据。 |
| 数据来源 | – 主要：DWS 层的汇总表、DWT 层的主题表； – 少数情况：DWD 层的明细表（如特殊业务需要 “未汇总的原始订单数据”）。 |
| 数据特点 | 1. 业务导向：完全按业务需求定义字段和格式（如销售报表需要 “地域名称、季度、销售额、同比、环比、目标额、完成率”）； 2. 低粒度：通常是最终汇总结果（如 “全国 Q2 销售额”“北京地区 5 月家电销量”）； 3. 格式友好： – 报表场景：字段名中文化（如 “地域”“销售额”）、包含计算字段（如 “同比增长率”）； – API 场景：输出 JSON 格式，字段名符合接口规范（如 “regionName”“salesAmount”）； 4. 时效性适配：实时 dashboard 需实时数据，月度报表需 T+1 数据。 |
| 存储内容 | 示例（电商业务场景）： 1. ads_sales_region_quarter（销售 – 地域 – 季度报表）： 字段：地域名称（region_name）, 季度（quarter）, 销售额（sales_amount）, 去年同期销售额（last_year_same_quarter）, 同比增长率（yoy_growth）, 上季度销售额（last_quarter）, 环比增长率（mom_growth）, 销售目标（target_amount）, 完成率（completion_rate）… 2. ads_operation_daily（运营日报表）： 字段：日期（date）, 新增用户数（new_user_count）, 日活用户数（dau）, 订单数（order_count）, 支付金额（pay_amount）, 客单价（avg_pay_amount）, 订单转化率（order_convert_rate）… 3. ads_user_portrait_api（用户画像 API 表）： 字段：user_id, user_level, age_group, region, total_pay_amount, active_days_30d, user_tag（如 “高价值活跃”“沉睡”）…（JSON 格式输出）。 |
| 处理方式 | 核心是 “数据按需加工”，步骤如下： 1. 需求拆解：明确业务需求的 “字段、指标、格式、时效性”（如销售报表需要 “地域到市级、包含同比环比、Excel 格式、每月 1 日出上月数据”）； 2. 指标最终计算：计算业务需要的派生指标（如 “同比增长率 =(当前销售额 – 去年同期)/ 去年同期 * 100%”，需处理 “去年同期为 0” 的情况）； 3. 格式转换： – 报表场景：将数据导出为 Excel/CSV，或存储到 MySQL 供报表工具（如 FineReport）读取； – BI 场景：将数据同步到 ClickHouse/Impala 等 OLAP 引擎，提升可视化查询速度； – API 场景：将数据封装为 JSON 格式，通过 API 接口提供给业务系统（如 CRM 系统）； 4. 数据筛选：仅保留业务需要的数据（如月度报表仅保留近 3 年数据，避免冗余）。 |
| 应用场景 | 1. 固定报表：如销售日报（每天 8 点生成）、财务月报（每月 1 日生成）、管理层季报（每季度初 5 日生成）； 2. BI 可视化：如用 Tableau/PowerBI 连接 ads_operation_daily，生成 “日活趋势图”“订单转化率漏斗图”； 3. 业务系统接口：如给会员系统提供 “高价值用户列表”（来自 ads_user_portrait_api），用于精准营销； 4. 临时查询：如业务人员通过 SQL 查询 ads_sales_region_quarter，获取 “北京 2024Q2 家电销售额”。 |
| 注意事项 | 1. 需求对齐：与业务方反复确认需求（如 “同比增长率是否包含退款”），避免数据交付后返工； 2. 数据准确性校验：每次生成 ADS 数据后，与业务系统核对（如 ADS 的 “支付金额” 需与支付系统的 “总支付额” 一致）； 3. 时效性保障：实时场景（如 dashboard）需用实时数仓的 ADS 层（基于 Flink 实时计算），非实时场景（如月报）用离线数仓的 ADS 层； 4. 权限控制：敏感数据（如用户手机号）在 ADS 层需脱敏（如显示为 “138****1234”），避免数据泄露。 |
三、分层的灵活性与扩展
上述 6 层是 “理想型” 数仓分层，实际落地时需根据公司规模、业务复杂度、数据量灵活调整：
- 小公司（数据量 <100GB）：可合并层级，如 “ODS→DWD→DWS/ADS”（跳过 DWT，DWS 直接支撑 ADS）；
- 中大型公司（数据量 100GB-10TB）：采用标准 6 层，重点建设 DWD（数据质量）和 DWS（复用效率）；
- 大型公司（数据量 > 10TB）：在标准 6 层基础上增加 “公共层（Common Layer）”，存储跨主题的公共指标（如 “日活用户数”），进一步提升复用性。
实时数仓的分层差异
实时数仓（如基于 Flink/Hudi 构建）在离线分层基础上，新增 “实时接入层” 和 “实时计算层”：
- 实时接入层（CDC 层）：通过 CDC（Change Data Capture）捕获业务库实时变更（如订单新增 / 修改）；
- 实时 ODS 层（Real-time ODS）：存储实时接入的原始数据（如 Kafka Topic）；
- 实时 DWD 层（Real-time DWD）：实时清洗、整合 CDC 数据，形成实时明细事实表（如 Hudi 表）；
- 实时 DWS 层（Real-time DWS）：实时聚合计算（如 Flink SQL 实时汇总 “用户分钟级订单金额”）；
- 实时 ADS 层（Real-time ADS）：实时推送数据到 dashboard（如 DataV）或业务系统。
四、分层核心原则与最佳实践
五、总结
数据仓库的分层本质是 “将复杂的数据处理流程拆解为多个简单、可控的步骤”，从 “原始数据（ODS）” 到 “干净明细（DWD）”，再到 “汇总复用（DWS）”，最后到 “业务应用（ADS）”，每一层都承担明确的职责，共同支撑企业的数据分析与决策。
理解分层的关键不是死记 “6 层名称”，而是掌握 “每一层为何存在、解决什么问题、如何服务于业务”—— 只有结合业务需求设计的分层，才是 “有用的数仓”，而非 “空中楼阁”。
评论前必须登录！
注册