项目架构分享 —— 离线数仓

关注

原创 2025-08-21 22:24:53 752 阅读 AI 写同款· GEO 优化 ›

离线数仓-数据仓库系统数据模型就是数据组织和存储方法，它强调从业务、数据存取和使用角度合理存储数据。只有将数据有序的组织和存储起来之后，数据才能得到高性能、低成本、高效率、高质量的使用。高性能：良好的数据模型能够帮助我们快速查询所需要的数据。低成本：良好的数据模型能减少重复计算，实现计算结果的复用，降低计算成本。高效率：良好的数据模型能极大的改善用户使用数据的体验，提高使用数据的效率。高质量：良好的数据模型能改善数据统计口径的混乱，减少计算错误的可能性。事实表作为数据仓库维度建模的核心，紧紧围绕着业务过程来设计。阅读详情

项目背景

为了满足不断变化的业务需求，实现系统的高度扩展性、灵活性以及数据展现的高性能。

为什么要做离线数仓

为了整合数据和集中存储；

为了批量处理与历史分析；

为了支持决策和优化成本；

为了弥补实时数仓的短板；

用到的架构理论

分层理论

分布式处理核心理论

数据建模与存储格式理论

数据治理理论

用到的数仓理论

数据仓库概念

1991年Bill Inmon（比尔·恩门）出版了他的第一本关于数据仓库的书《Building the Data Warehouse》，标志着数据仓库概念的确立。书中指出，数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrated)、相对稳定的(Non-Volatile)、反映历史变化的(Time Variant)数据集合，用于支持管理决策(Decision-Making Support)。

离线数仓概念

离线数仓是通过‌批处理技术‌对分散的业务数据（如交易记录、日志等）进行周期性（如T+1）清洗、转换和存储的集中式数据平台，支持复杂查询与多维分析‌。例如，车险数仓通过Sqoop等工具采集业务数据，并按分层架构（ODS-DWD-DWS）组织存储，便于后续分析‌。

数据分层理论

数据应该进行分层，为了方便数据的管理和维护、数据质量控制、数据灵活分析。

分层设计有：

ods层：

dwd层：

dws层：

dim层：

tmp层：

ads层：

数据建模理论与方法之维度建模理论维度建模法

（实体建模法，范式建模法，维度建模法等）

维度建模法是一种常用的数据建模方法，特别适用于数据仓库和商业智能领域。它通过将数据组织成维度表和事实表的结构，以实现对业务过程的分析和报告。维度建模法注重对业务过程的理解和建模，以及对数据的分层和聚焦，使得数据仓库更易于使用和理解。

在维度建模法中，有两个核心概念：维度和事实。

维度（Dimensions）：维度是描述业务过程的特征或属性的数据元素。它们提供了用于分析和过滤数据的上下文信息。常见的维度包括时间、地理位置、产品、客户、销售渠道等。维度通常作为维度表的基础，每个维度表对应一个特定的业务维度。
事实（Facts）：事实是与业务过程相关的可度量的数据，即衡量业务过程中发生事件的数量或金额。事实表是存储事实数据的主要表，每个事实表通常包含多个度量（Measure）列，用于记录具体的业务指标，如销售额、销售数量、利润等。事实表通常与多个维度表进行关联，形成维度模型。
维度建模法的特点和优势包括：

简单直观：维度建模法以业务过程为中心，使数据模型更加直观和易于理解，便于业务用户参与数据分析和报表设计。
灵活可扩展：维度建模法支持灵活的数据分析和报表需求，可以方便地添加新的维度或度量，适应业务的变化和扩展。
查询性能优化：维度建模法通过合理的表设计和关联关系，优化了查询性能，使得数据检索和报表生成更高效。
可重用性和共享性：维度建模法中的维度表和事实表是可重用和共享的，可以为不同的报表和分析需求提供数据支持，避免了重复开发和数据冗余。

维度建模有三种模式：星型模式（常用），雪花模式，星座模式（常用）。

本项目采用《星型模式》

数据治理理论

管理数据质量，管理数据安全，管理元数据、主数据。

适用场景理论

非实时分析‌：适用于报表生成、用户画像等时效性要求低的场景‌。
‌成本效益‌：通过离线计算降低实时处理的高资源消耗‌。
系统稳定性：通过离线计算减少对业务系统干扰。

流程

源数据分析：就是最开始的数据在哪里，日志，还是业务数据库，还是lot设备等等

主题分析：划分主题域（日志，交易）

基于维度构建总线矩阵：

根据阿里巴巴OneData方法论，明确每个主题域中有哪些业务过程后，您需要开始定义维度，并基于维度构建总线矩阵。知道维度和事实

明确统计指标：

技术选型：

Flume：抓取日志

DataX：同步数据到mysql

Hive：ETL流程处理

Airflow: 任务调度

atlas: 元数据管理

Griffin: 质量监控

Mysql：业务指标存储

数据分层：

ods ：将源数据变成一个整字符串存到这层，这些源数据是永久保存的。

dwd ：从ods层数据中构建事实表，拉链表，宽表，要注意sql性能，数据倾斜等情况，必要时做优化

dws ：以业务指标为驱动进行汇总计算，这个时候的数据范围比较大，或者说不够接近我们的主题域指标，这一步也是要注意sql性能，数据倾斜等情况，必要时做优化

dim ：从ods层构建

ads：指标数据

数据建模：星型模型（没有那么复杂的业务就不用星座模型）事实表：用户活跃记录表，事件记录表，广告记录表，订单表，订单明细表；维表：产品分类表，店铺表，商家区域表，支付方式表

指标汇总：用户汇总表，交易汇总表

指标数据生成：用户活跃数，新增用户数，留存用户数，交易订单数，广告曝光，点击等

数据下发：用DataX将指标数据表的数据下发到下游业务数据库Mysql

拓展一下几个工具比对

Flume、Sqoop和DataX的对比分析：

1. ‌核心功能定位‌

‌Flume‌：专注于日志数据采集，支持分布式部署，适合实时流式数据传输场景，如日志聚合到HDFS或Kafka‌。
‌Sqoop‌：专为Hadoop生态设计，主要用于关系型数据库与HDFS/Hive/HBase之间的批量数据交换‌。
‌DataX‌：阿里开源的异构数据源离线同步工具，支持MySQL、Oracle、HDFS等20+数据源，适用于数据仓库构建和ETL流程‌。

2. ‌性能与资源占用‌

‌内存占用‌：DataX较高，Flume中等，Sqoop依赖Hadoop资源消耗较大‌。
‌并发能力‌：DataX单机性能较好，Flume支持分布式并行采集，Sqoop依赖MapReduce并行化‌。
‌连接效率‌：Flume通过Agent集群优化网络传输，Sqoop和DataX需频繁建立JDBC连接，资源占用较高‌。

3. ‌扩展性与灵活性‌

‌数据源支持‌：DataX > Flume > Sqoop（DataX支持20+种，Flume以日志类为主，Sqoop仅限关系型数据库和Hadoop组件）‌。
‌数据转换‌：DataX支持自定义Groovy脚本，Flume通过拦截器实现简单转换，Sqoop仅支持基础列映射‌。
‌实时性‌：Flume支持实时流式传输，DataX和Sqoop仅支持离线同步‌。

4. ‌部署与运维‌

‌部署难度‌：Flume和DataX配置简单，Sqoop需依赖Hadoop生态，部署复杂度较高‌45。
‌容错机制‌：Flume具备重试和故障转移能力，DataX需依赖外部调度系统实现容错，Sqoop错误处理较繁琐‌45。
‌监控统计‌：Flume和DataX提供运行指标统计，Sqoop缺乏内置监控‌。

5. ‌适用场景建议‌

‌Flume‌：日志采集、实时数据流（如用户行为日志、IoT设备数据）‌。
‌Sqoop‌：Hadoop与关系型数据库间的批量数据迁移（如MySQL到Hive）‌。
‌DataX‌：跨异构数据源的ETL作业（如Oracle到HDFS的离线同步）‌。

如需更详细的性能参数或企业级应用案例，可参考具体工具官方文档或社区实践报告‌