浅析数仓分层：DB+ODS+DW+DM

ODS+DW+DM"/>

浅析数仓分层：DB+ODS+DW+DM

本期将从结构层面了解数据仓库分层的几个名词和简单理解。

文章目录

• • 1 理想的数据分层总体结构
  • 2 DB层：关系型数据库和非关系型数据库
  • • 2.1 关系型数据库RDB
    • 2.2 非关系型数据库NoSQL
  • 3 ODS层：操作数据存储层
  • 3.1 ODS产生背景
  • • 3.2 ODS在企业数据架构中担任的角色
    • 3.3 ODS层的特征
    • 3.4 ODS层的功能
  • 4 DW层：数据仓库

1 理想的数据分层总体结构

如图可看出理想的数据分层分为四层：

1. 源数据层DB，包括关系型数据库、非关系型数据库、以及未采集到数据库直接以文件形式存在的数据；
2. 操作数据存储层ODS，包括企业级操作型系统数据OLTP以及及时分析型系统数据OLAP;
3. 数据仓库DW/EDW层，包括数据明细层DWD，轻度汇总层MID/DWB，主题层/数据服务层DWS… (数据仓库分层并不是如上图那般简单明确，每一层分层的取舍都由架构师对业务难度、业务适用范围和现有资源的多少来决定，在文末笔者将提出生产环境较复杂的数据仓库案例模型，以供参考。)
4. 数据集市层/应用层DM。

为什么要对数据分层？

1. 清晰数据结构：对数据和表以及此层的作用域有清晰的定位和理解。
2. 方便进行数据血缘追踪：简单来讲可以这样理解，我们最终给业务诚信的是一能直接使用的张业务表，但是它的来源有很多，如果有一张来源表出问题了，我们希望能够快速准确地定位到问题，并清楚它的危害范围。关于数据血缘关系可查看笔者往期文章：数据治理：数据血缘关系分析。
3. 减少重复开发：规范数据分层，开发一些通用的中间层数据，能够减少极大的重复计算。
4. 把复杂问题简单化：讲一个复杂的任务分解成多个步骤来完成，每一层只处理单一的步骤，比较简单和容易理解。而且便于维护数据的准确性，当数据出现问题之后，可以不用修复所有的数据，只需要从有问题的步骤开始修复。
5. 屏蔽原始数据的异常。
6. 屏蔽业务的影响，不必改一次业务就需要重新接入数据。

2 DB层：关系型数据库和非关系型数据库

数据库(Database,DB)：常见的数据库分为关系型数据库和非关系层数据库。

2.1 关系型数据库RDB

​ 关系数据库（Relational Database，RDB）就是基于关系模型的数据库，也叫关系型数据库。详见关系型数据库

​ 关系模型(Relational Model): 可理解为是一个二维数据表格模型，所有信息都表现为关系中的数据值。详见关系模型

​ 关系型数据库事务必须具备ACID特性，ACID分别是Atomic原子性，Consistency一致性，
Isolation隔离性，Durability持久性。详见数据库系统中事务的ACID原则

常用的关系型数据库有：

Oracle，Microsoft SQL Server，MySQL/MariaDB，PostgreSQL，DB2/Informix，
Microsoft Access， SQLite，Teradata，SAP

2.2 非关系型数据库NoSQL

​ NoSQL最常见的解释是“non-relational”， “Not Only SQL”也被很多人接受。NoSQL仅仅是一个概念，泛指非关系型的数据库，区别于关系数据库，它们不保证关系数据的ACID特性。详见NoSQL

​ NoSQL的基本需求就是支持分布式存储，严格一致性与可用性需要互相取舍。

​ NoSQL的CAP理论：一个分布式系统不可能同时满足C(一致性)、A(可用性)、P(分区容错性)三个基本需求，并且最多只能满足其中的两项。对于一个分布式系统来说，分区容错是基本需求，否则不能称之为分布式系统，因此需要在C和A之间寻求平衡。详见CAP原则

常用的NoSQL有以下几大类：

​ 1 面向高性能并发读写的key-value数据库

​ Redis， Amazon DynamoDB， Memcached，
​ Microsoft Azure Cosmos DB和Hazelcast

​ 2 面向海量数据访问的面向文档数据库
MongoDB，Amazon DynamoDB，Couchbase，
​ Microsoft Azure Cosmos DB和CouchDB

​ 3 面向搜索数据内容的搜索引擎
Elasticsearch，Splunk，Solr，MarkLogic和Sphinx

​ 4 面向可扩展性的分布式数据库
​ Cassandra，HBase，Microsoft Azure Cosmos DB，
​ Datastax Enterprise和Accumulo

3 ODS层：操作数据存储层

很多时候，提起数仓，有一些人会直接想到DB到DW这两层，或者有部分人会把DW中的DWD当作是ODS层，然而，实际生产环境中，我们还需要一个概念明确且和DWD界限清晰的中间数据层，那就是ODS。

参考链接：.html (ODS层简介和ODS设计)

3.1 ODS产生背景

​ 人们对数据的处理行为可以划分为操作型数据处理和分析型数据处理（详见操作型数据库和分析型数据库的区别 、OLAP、OLTP的介绍和比较），操作型数据处理一般放在传统的DB中进行，分析型数据处理则需要在DW(Data Warehouse, 数据仓库)中进行。但是并不是所有的数据处理都可以这样划分，换句话说，人们对数据的处理需求并不只有这两类，比如，有些操作型处理并不适合放在传统的数据库上完成，也有些分析型处理不适合在数据仓库中进行。这时候就需要第三种数据存储体系，操作数据存储(Operational Data Store,ODS)系统就因此产生。它的出现，也将DB~DW两层数据架构转变成DB~ODS~DW三层数据架构。

3.2 ODS在企业数据架构中担任的角色

​ 企业数据架构需要建立在统一的数据模型的基础上，由生产系统自有数据库(DB)、操作数据存储（ODS）、企业数据仓库（EDW）三个层面组成。

​ 其中，ODS层存储的是：按业务主题分类的、面向运营的准实时数据，提供统一的企业数据视图。

​ 生产系统自有数据库(DB)存储的是：该生产系统内部操作数据和基础信息数据。

​ EDW存储面向经营决策分析的历史数据和综合数据。

​ ODS对生产系统产生的数据进行清洗、过滤、转换、整合(详见数据ETL)，是提供给EDW高质量数据的重要来源之一，同时为各个生产系统提供准实时的运营报表等跨系统共享数据服务。另外，在企业运营层，对于需要同时利用跨系统的操作型数据和相关分析结果数据的协作性应用需求，ODS也起到关键支撑作用。

​ ODS系统是一个跨系统的数据共享平台，承接操作环境和分析环境。

3.3 ODS层的特征

ODS中的数据具有以下4个基本特征：

1. 面向主题的：进入ODS的数据是来源于各个操作型数据库以及其他外部数据源，数据进入ODS前必须经过 ETL过程（抽取、清洗、转换、加载等）。
2. 集成的：ODS的数据来源于各个操作型数据库，同时也会在数据清理加工后进行一定程度的综合。
3. 可更新的：可以联机修改。这一点区别于数据仓库。
4. 当前或接近当前的：“当前”是指数据在存取时刻是最新的，“接近当前”是指存取的数据是最近一段时间得到的；在这一点上，ODS存储的数据是"实时"或"伪实时"的，数据的生命周期一般是1天~30天（根据实际场景和性能来定），而DW数据仓库的数据一般存放两种数据：一是在ODS层的"实时数据"经过ETL任务后的数据明细层模型数据（DWD），二是DWD数据的归档数据，归档数据一般会存储长达十年甚至更久的历史数据。

3.4 ODS层的功能

（1）实现企业级的OLTP操作：

​ 传统的操作型数据库往往只存放企业某一类业务或者某一个部门的数据，因此无法面向企业全局数据的OLTP，而ODS可以实现。因为ODS的数据是面向整个企业进行集成汇总的，克服了原来面向应用的操作型数据库数据分散的缺陷。
（2）实现即时的OLAP操作：
​ 在数据仓库上进行OALP，往往由于数据量十分庞大而需要较长的时间。而在企业实际应用中，对于一些较低层次的决策，往往并不需要太多的历史数据，可能只需要参考当前的或者接近当前的数据就可以完成，并且要求具有较快的响应时间，因此数据仓库显然无法满足这样的要求，但是ODS可以实现。ODS中不仅有面向企业全局的细节数据和汇总数据，而且规模比数据仓库小，具有较强的实时响应能力。

4 DW层：数据仓库

未完待续…