操作型数据存储 ODS

操作型数据存储（英语：Operational Data Store)是一种资料架构或数据库设计的概念，为企业提供即时的，操作型数据的集合。出现原因是来自于当需要集成来自多个系统的资料，结果又要给一或多个系统使用时。

定义

ODS全称是Operational Data Store，即操作数据存储。主要为：

• 一个面向主题的、集成的、可变的、当前的细节数据集合
• 是介于DB和DW之间的一种过渡存储，也是数据仓库项目的可选项之一，往往是物理落地在数据仓库中，比如Hive
• 是在数据仓库中存储业务系统源数据，从数据粒度、数据结构、数据关系等各个方面都与业务系统的数据源保持一致
• 面向数据报表等批量数据查询需求、为决策支持提供当前细节数据(数据仓库的一部分)。

通常而言，ODS层表跟业务系统保持一致，但又不完全等同于业务系统。在设计ODS物理表时，在表命名、增量/全量数据存储等方面都需要遵循一定的准则。

避免重复抽取数据 建立统一的ODS层，统一标准化处理。表的生命周期管理 一般而言，全量表保存3~7天，增量表要永久保存。

无下游任务的表 该表没有被下游任务使用，这种情况下要及时下线同步任务，避免造成资源的浪费，这部分涉及涉及元数据治理。

构成

集成来自多个系统的资料，应先创建资料模型（data model）。由于ODS并不属于特定的系统，因此其资料模型的设计应为主题导向式（subject-oriented），实现方法与数据仓库无异。ODS数据集成用于最低粒度的、一天内发生频率最高的实时的或者近乎实时的查询应用。通常ODS不会被设计成用来做历史数据分析或者趋势分析工作，那是数据仓库的功能。ODS通常会被用来当做数据仓库的数据来源。ODS保存的数据窗口较小，即时间跨度不大，抽取数据的频率可以是几分钟、几小时；数据仓库保存的几乎是一个公司的所有历史数据。为求快速建置以及呈现来源系统资料，实务上常见许多企业采取的做法是直接将来源系统的资料以类似复制的方式至来源系统以外的数据库，将它视为来源资料的复本，而没有进行真正的资料集成。

资料给多个系统使用的方法，包括可以将其包装成SOA的'服务'、进行分析或报表、也可以再将资料透过ETL的方式发送至其他系统。

特点

相较于数据仓库，ODS较偏向作业（operational）面的用途，通常资料有较频繁的更新以及较短的历史，用于实时或者接近实时地产生操作报告。但这主要是概念上的差异，实际建置时可以创建在同一平台上，由一份资料从事两种性质的服务。

目前数据仓库厂商提出了active data warehouse概念，基本上与ODS概念极为接近，亦即数据仓库厂商认为在其解决方案中除数据仓库外也包含ODS功能。

数据同步

数据同步的方式大概可以分为三大类：文件同步、表同步和日志同步。

文件同步

1. 降低ODS处理多种类型数据库系统能力需求，
2. 减少了对业务系统的性能影响

但：

1. 数据的抽取过程和加载过程是分开的，由业务系统和ODS分别负责，同时接口新增和变更比较麻烦，需要较大的沟通维护成本，
2. 数据落地到文件增加了额外的上传下载工作，会造成效率比较低。

在实际生产中，很少被使用。

库表同步

配置十分简单，很容易上手操作，比较适合操作型业务系统的数据同步

但：

1. 业务规模的增长，数据同步花费的时间会越来越长，无法满足下游数仓生产的时间要求
2. 直连数据库查询数据，对数据库影响非常大，容易造成慢查询
3. 抽取增量数据需要依靠修改业务系统，新增时间戳字段，并且按时间戳增量抽取的数据准确性不能得到保障
4. 业务系统做数据补丁不更新时间戳字段将会导致漏数
5. 实时性差，只能在某个时刻抽取数据，不能满足准实时数据需求

生产中，经常被使用，适用于适用于小批量表的数据抽取。

日志同步

1. 实现实时与准实时的同步
2. 延迟可以控制在毫秒级别的、性能好、效率高，不会对源数据库造成影响

但：

1. 在业务系统做批量补数时会造成数据更新量超过处理的能力，从而导致数据延迟
2. 需要额外补数一个实时抽取的系统，从而也增加了投入和处理的复杂性

因此：

1. 从业务系统到数据仓库中的实时增量同步，广泛采取这种方式
2. 实现实时与准实时、T+1均支持

总结

在实际的生产环境中，直连同步和日志解析是非常普遍的两种数据同步方式，随着实时技术这里需要注意的是，每种方式都有其优缺点及适用的场景，找到合适业务需要方式就是最好的方式，在解决具体问题的时候，要多方面权衡，支持业务、为业务高效赋能为要义，禁忌一堆大数据技术的简单堆砌。

数据清洗

ODS层是否做数据清洗一直是存在争议的，比较重的清洗工作是要留到后面数仓的ETL过程中进行处理，ODS主要保持与原系统数据一致，数据质量相关工作应用于此层。

数据清洗的主要工作是处理那些不符合要求的数据，从而提升数据质量，比如一些常见的问题：错误的数据、重复的数据。

错误的数据

因业务系统处理不够健全造成的，比如字符串数据后面有回车空格、日期格式不正确、日期越界等等，这些问题可在ODS层或后续处理的。

重复的数据

一些前端系统迁移过后的新老表融合可能会存在大量的重复历史数据，这也可以在数据清洗这一步骤中完成消除重复数据的操作。需要注意的是，在数据清洗后还需要对ODS的数据做核查，还需要对脏数据做核查校验，脏数据的校验主要集中在数据量上，如果数据量波动特别大则需要人工介入处理。

总结

在大多数的情况下，是不需要做数据清洗处理的，可以把这个清洗环节放到后面的明细层ETL中进行处理，至于在哪里处理比较合适，值得思考。

实时性

实时数据仓库的主要思路就是：为了适应实时性，数据源中发生的更新可以立刻传送到数据仓库的动态数据中，再经过响应的转换，满足实时的要求。由于实时处理的特殊性及复杂性，很多情况下实时分析是建立在基于ODS上建立简单实时数仓，因ODS处理逻辑简单，数据链路相对较短，产出更快。

根据表的刷新频率，可以将ODS层的表分为三大类：

实时ODS

1. 与业务库的数据保持同步刷新
2. 实时分析计算，涉及的业务过程不能过多，处理的业务逻辑不能过于复杂
3. 维护成本是相对较高的

准实时ODS

1. 基本可以满足大部分的准实时需求。
2. 可以根据实际需求调整刷新频率，具有较好的灵活性。
3. 需要特别注意ETL任务的产出效率，通常这类任务的产出时间最多不能超过ODS表的刷新周期时间。
4. 比实时ODS维护成本要低些

常规ODS

1. T+1
2. 用业务系统的空闲时间进行刷新
3. 是最容易维护的

参考

• https://mp.weixin.qq.com/s/u-ky3dubK44fUFldF6bGng

---