【离线数仓项目】——电商域ODS层开发实战

庄小焱
300 阅读11分钟

摘要

本文主要介绍了数据仓库中ODS层的开发实战，包括ODS层的定义、作用、设计特征、采集策略、开发实战、调度示例以及数据存储思考。ODS层作为数据仓库的底层，用于存储从各业务系统同步过来的原始数据，具备准实时或定时更新的能力。它为数仓中其他层提供数据缓冲，减少源系统压力，同时保留一定时间的业务数据，便于问题排查和数据补录。ODS层的设计特征包括命名规范、数据清洗前置、数据标准化等。采集策略包括增量采集、全量采集和拉链采集。开发实战部分详细介绍了ODS层数据离线同步任务、全量初始化同步、增量实时同步、同步结果查询、表数据管理和表关联等操作。最后，文章还探讨了MaxComputer中ODS层数据的存储方式。

1. ODS数据层

ODS（Operational Data Store，操作型数据存储）是数据仓库架构中非常重要的一层，通常作为数据仓库的最底层或第一层，用于存储从各业务系统同步过来的原始数据，具备准实时或定时更新的能力。

1.1. ODS层简介

ODS（操作数据存储）是一个面向主题的、集成的、可变的、当前的、详细的企业级数据集合，用于支持日常操作和数据分析的过渡层。

  • 通常对应各业务系统的结构化数据副本
  • 是数据仓库中最贴近源系统的一层

1.2. ODS层作用

作用说明
✅ 数据缓冲层为数仓中其他层（如DWD、DWS）提供数据缓冲，避免直接访问源系统，减少源系统压力
✅ 数据备份/留存ODS通常保留7-90天的业务数据，用于问题排查、数据补录
✅ 数据清洗前置只做轻度清洗，如字段映射、类型转换、过滤非法值，保持源数据原貌
✅ 数据标准化统一编码、命名、时间格式等标准
✅ 支持增量采集存储每日增量或全量数据，为后续构建增量/变更逻辑做准备
✅ 多源整合中间层为多系统的数据集成提供一个统一平台，便于后续建模

1.3. ODS层数据常见设计特征

特征内容
命名规范一般为 ods_系统名_表名，如 ods_order_info
存储周期通常保留7天～3个月，短于数仓其他层
存储方式支持全量、增量（Append模式）、快照等
数据粒度明细级，保持与源系统一致
数据延迟小于 1 天，支持 T+0 或 T+1 的采集模式

1.4. 交易支付场景下的ODS层表示例

  • 核心交易系统：下单、支付、退款接口
  • 清结算系统：资金清算记录
  • 渠道平台：微信/支付宝/银联回调通知数据
  • 账务系统：对账流水、入账记录

1.4.1. 表1：ods_payment_order_di

支付订单每日增量表（di = daily incremental）

字段名类型说明
idbigint支付订单唯一ID
order_nostring订单号
user_idstring用户ID
merchant_idstring商户ID
amountdecimal支付金额
currencystring币种（如 CNY）
pay_statusstring支付状态（SUCCESS/FAIL）
pay_methodstring支付方式（微信/支付宝等）
pay_timetimestamp实际支付时间
create_timetimestamp订单创建时间
update_timetimestamp最后更新时间
etl_dtdate采集日期（ODS层标准字段）

1.4.2. 表2：ods_refund_order_di

退款订单增量表

字段名类型说明
refund_idbigint退款订单ID
order_nostring原始订单号
refund_nostring退款订单号
refund_amountdecimal退款金额
refund_reasonstring退款原因
refund_statusstring状态（PENDING/SUCCESS）
refund_timetimestamp退款完成时间
create_timetimestamp退款单创建时间
update_timetimestamp最后更新时间
etl_dtdate数据采集时间

1.4.3. 表3：ods_channel_transaction_di

渠道交易流水表（如微信、支付宝、银联）

字段名类型说明
txn_idstring渠道交易流水号
order_nostring关联订单号
channel_codestring渠道编码（WECHAT、ALIPAY）
channel_txn_statusstring渠道状态码
channel_txn_timetimestamp渠道处理时间
total_feedecimal渠道扣费
settlement_feedecimal渠道结算费
response_codestring渠道响应码
etl_dtdate数据采集日期

1.4.4. 📌 增量数据与全量数据说明

类型表名示例特点说明
全量ods_payment_order_dfdf = daily full，每天抽取全量数据；用于快照、比对等
增量ods_payment_order_didi = daily incremental，只采集当天变动的数据，提高效率

2. ODS层设计规范

2.1. ODS层表命名规范

表命名规范：表命名规则： {层次}{源系统表名}{保留位/delta与否} 。

  • 增量数据： {project_name}.s{源系统表名}delta。
  • 全量数据： {project_name}.s{源系统表名} 。
  • ODS ETL过程的临时表： {project_name}.tmp{临时表所在过程的输出表}{从0开始的序号} 。
  • 按小时同步的增量表： {project_name}.s{源系统表名}{delta}_{hh} 。
  • 按小时同步的全量表： {project_name}.s{源系统表名}{hh} 。
  • 当不同源系统同步到同一个Project下的表命名冲突时，您需要给同步较晚的表名加上源系统的dbname以解决冲突。

字段命名规范

  • 字段默认使用源系统的字段名。
  • 字段名与MaxCompute关键字冲突时，在源字段名后加上col，即源字段名col。
  • 同步任务命名规范

任务名：{源系统表名}[delta]。

  • 说明： 同一Project下异库同名表的任务名为 {源系统表名}{tddl的appname}[_delta] 。

任务的输出名称，即输出表的名称，需要与数据存储及生命周期管理规范保持一致。

2.2. ODS层数据质量规范

  • 每个ODS全量表必须配置唯一性字段标识。
  • 每个ODS全量表必须有注释。
  • 每个ODS全量表必须监控分区空数据。
  • 仅有监控要求的ODS表才需要创建数据质量监控规则。您可以通过DataWorks配置数据质量监控规则。
  • 建议对重要表的重要枚举类型字段进行枚举值变化及枚举值分布监控。
  • 建议对ODS表的数据量及数据记录数设置周同环比监控，如果周同环比无变化，表示源系统已迁移或下线。

2.3. 数据存储及生命周期管理规范

数据表类型存储方式最长存储保留策略
ODS流水型全量表按天分区- 不可再生情况下，永久保存。
  • 日志（数据量非常大，例如一天数据量大于100 GB）数据保留24个月。
  • 自主设置是否保留历史月初数据。
  • 自主设置是否保留特殊日期数据。 | | ODS镜像型全量表 | 按天分区 | - 重要的业务表及需要保留历史的表视情况保存。
  • ODS全量表的默认生命周期为2天，支持通过ds=max_pt(tablename)方式访问数据。 | | ODS增量表 | 按天分区 | - 有对应全量表，最多保留最近14天分区数据。
  • 无对应全量表，需要永久保留数据。 | | ODS ETL过程临时表 | 按天分区 | 最多保留最近7天分区。 | | DBSync非去重数据 | 按天分区 | 由应用通过中间层保留历史数据，默认ODS层不保留历史数据。 |

3. ODS层采集策略

在数据仓库建设中，ODS（Operational Data Store，操作型数据存储）层作为对接业务系统的第一站，其数据采集策略至关重要。常见的采集策略有：

策略是否保留历史实现复杂度存储开销实时性典型应用
增量存储否中低高明细事实表、交易流水
全量存储否低高低小维表、全量覆盖型表
拉链存储是高高中慢变维、客户历史、审计表

3.1. 增量采集策略

项目内容说明
定义仅采集自上次采集时间以来新增或发生变更的数据记录
适用场景高频变动的事实表、交易数据、日志流数据、源系统支持变更标识字段
实现方式依赖 update_time、modified_time、主键对比、日志增量（如 CDC）等方式
数据量大小较小，仅采集变更部分
是否保留历史否，仅保留当前最新状态
优点数据量小、效率高、网络及存储资源占用低
缺点依赖源系统更新标识字段，若更新字段不准确容易造成数据遗漏

3.2. 全量采集策略

项目内容说明
定义每次采集时获取整个表的所有数据进行同步
适用场景小表或数据量可控的维表、基础字典表、无变更标识字段的表、首次加载全量数据
实现方式全表拉取或导出，无需增量条件，支持定时调度或全覆盖
数据量大小较大，随着数据积累量增加资源开销大
是否保留历史否，只保留最新一次全量数据（除非另做版本管理）
优点实现简单、不依赖业务字段、不易遗漏数据
缺点数据重复、网络和存储压力大，难以满足实时性需求

3.3. 拉链采集策略

项目内容说明
定义为每条记录建立变更历史轨迹，记录每个版本及其生效时间段
适用场景客户信息、商品维度、组织架构、信用评级、风控状态等需记录历史版本的维度表
实现方式使用 start_time、end_time 等字段；当记录变更时插入新记录并更新旧记录的 end_time
数据量大小中到大，随着变更频率增加会产生大量历史记录
是否保留历史是，保留所有变更历史，可做时点还原
优点可支持历史分析、状态回溯、时点快照等复杂场景
缺点表设计复杂、实现逻辑复杂、查询效率相对较低

4. ODS层数据开发实战

4.1. ODS层数据离线同步任务实战

4.2. ODS层任务调度示例

4.3. ODS层全量初始化同步实战

数据集成（单表同步任务）

数据集成（构建多表同步任务）

4.4. ODS层数据增量实时同步实战

4.5. ODS层数据同步结果查询实战

4.6. ODS层表数据管理实战

4.7. ODS层表关联管理实战

5. ODS层数据思考

项目内容
存储介质MaxCompute 表（内部管理，使用列式存储）
存储形式分区表，支持全量/增量导入
表设计特点字段保持与原系统一致、规范命名、尽量不做转换
写入方式Batch（DataWorks、DataX）、Streaming（Kafka + Flink）等方式写入

5.1. MaxComputer中ods层数据怎么存储？

在 MaxCompute（原名ODPS，阿里云的大数据计算服务）中，ODS 层的数据存储方式取决于具体的数据建模和业务需求，但从技术实现上讲，它使用的是 MaxCompute 表（Table） 作为底层数据存储结构。

5.1.1. 🔍 MaxCompute 中 ODS 的定义

在数据仓库分层中：

  • ODS（Operational Data Store） 层：用于存储来自各个业务系统的原始数据，通常是全量或增量同步来的。
  • 是数据进入数据仓库的第一站，一般不做太多清洗、转换。

5.1.2. 🧱 MaxCompute 中 ODS 层数据的存储形式

在 MaxCompute 中，ODS 层的数据通常以 表（Table） 的形式存在，具体如下：

5.1.2.1. 📦 表类型：
表类型说明
Managed 表（内部表）MaxCompute 默认创建的表，数据和表元数据都由 MaxCompute 管理。
外部表（External Table）用于对接外部数据源，如 OSS、HDFS 等，元数据在 MaxCompute，数据在外部存储。
5.1.2.2. 🧾 表分区（Partition）：
  • 通常会按 dt（日期）、hour 等进行分区存储。
  • 示例表结构：
CREATE TABLE ods_user_login (
  user_id STRING,
  login_time STRING,
  device_type STRING
)
PARTITIONED BY (dt STRING);

5.1.3. 🛢️ ODS层数据存储技术

MaxCompute 底层采用了阿里云自研的分布式列式存储引擎（非 HDFS）：

  • 高压缩比（如采用 RCFile、Columnar 存储格式）
  • 支持分区裁剪、列裁剪
  • 优化读取性能、支持 PB 级别的数据量处理

5.1.4. 📂 常见 ODS 表命名规范

通常使用如下命名规范：

ods.<业务系统名>_<业务表名>
如：
ods.oms_order_detail
ods.crm_user_profile

5.1.5. 🧰 ODS层数据来源

ODS 层数据一般通过以下方式接入：

  • 数据同步工具（如 DataX、DataWorks、Canal）
  • Flink/Logstash 日志采集
  • Kafka + DataWorks/Flink 进行流式落地到 ODS 表

博文参考

help.aliyun.com/zh/datawork…

avatar
文章
阅读
粉丝