数据架构中的ODS层

截止到现在数据架构中关于Ods层的定义、设计应用已经呈现多样化，而且也出现像数据湖这样的概念，不深究数据湖的定义与存在的意义，仅是把Ods作为分析一个深入研究的对象来做。

Ods出现时，数据仓库架构必定包含Ods（Operational Data Store)，因为ods的主要目的是为了屏蔽数据仓库与业务系统，降低他们之间的耦合。对ODS的描述不在少数，这个概念应该是90年代初提出的，郁闷派掌门inmon和球派老大kimball都有文章或著书论及，比如inmon就有一本书，Building the Operational Datastore。

inmon和kimball关于ODS的概念基本差不多，都是集成地，是面向主题地，是易变地，并且是反应当前状态地。相比较数据仓库系统的定义，发现后两个特点正好相反。但是这两派对于ODS的实现可就不一样的，inmon赞成使用高度范式化的数据模型来为ODS建模，而kimball提倡使用维度建模来实现ODS，和后面的DW、DM使用统一的维表。

ODS说我为什么这么难

从前有一个ods，用户需要它出现时，它就会出现，不需要时就会默默匿在后面，用户不同的需要，它就会表现出不同的习性，用户诉求它作为日常报表数据基础时，它就会每日从业务系统数据源去同步数据,现在很多企业都是这样T+1 的去同步数据。

后来出现了一种需求，需要在企业不同系统同步一些重要数据，例如各种重要枚举值、客户信息、订单信息、支付信息、交易信息、金融信息等，这些数据一天更新一次是无法满足企业某些人的强烈欲望，那就改成一个小时让使用者爽着。

在后来呢，企业的业务跑的太快了，业务刚上线，产品技术消耗了几天几夜上线相关与产品后已经着急的做下一个迭代去了，但是运营后台就很少有资源去完善，业务告诉数据平台，我们的运营数据查询也是属于数据，数据平台来做了吧，小时级的数据同步也无法满足应用了，客户信息、支付状态、地址等都是随时而变化的，那就上几分钟级别的吧。

再后来，秒级的 ，业务说我的明细数据怎么还不出来，投诉投诉投诉，Ods说我我罢工不干了，找个弟弟继续顶上去，实时计算等一系列的对于近乎实时日志级别处理技术就光大了，在这里不做讨论，在于近乎实时，分钟级、10分钟级别、小时级别 采用到的技术实现与代价是不同的。

ods随着业务的诉求自己也越来痛苦，人家业务都在精细化了，那我ods的方法论为啥不做更加精细化呢。

ODs类型重新分类与变化处理

对于数据仓库/数据平台来讲， 数据都是记录历史变化的，他的定义中也明确提到这一点，所以数据仓库/平台中的事实表一般都有时间或时间戳字段来支持记录的历史变化，而且不光是事实表，维表也要体现历史变化，其中，代理键就起了一定的作用，但是在业务系统是属于频繁变更记录的，很少在业务系统用保存历史数据的这个对于业务系统数据库来说是有很大很大的压力。所以在业务系统与数据平台层面存在一个缓冲区域，记录的是最近时间的业务系统的原子数据，忽略了一些历史信息。

截止到现在ods的发展这些年大家对于ods的讨论还是按照两类的标准划分，事件型(Transaction Grain)、周期快照型(Piriodic Snapshot Grain)，但是按照特性来分还可以把周期快照在拆分一种叫累积快照型(Accumulating Snapshot Grain)

系统中存在一种数据，如果用ER图表示的话，他们多是被别的数据参照，这种数据叫做“主数据”。顾名思义，这些数据是很重要的，是系统的核心数据，被引用的越多越重要。例如产品数据、客户数据，以及一系列的代码数据，都属于主数据。而主数据在ODS层中的存储一般都是选择快照型的形态存储。

• 快照型数据反应的是最近一点时刻，主数据的状态信息，例如客户的状态，客户的信用度等，他们都通过update操作将前次状态或信用度都更新掉了。

• 事件型，而另一种数据形态，记录是事件的发生，例如记录一次通话，记录一次开帐等，日志表也属于这种形态，它反应的是对数据的历史操作。这两种形态的数据一个较大的区别就是前者会不断被更新，而后者一般不会做更新操作。

• 累积快照型，它记录是一个时间点上实体的状态，这种数据从实体的生命周期一开始一直更新到生命结束，例如用户表中，从用户创建开始，用户开机、停机、状态改变都会直接更新这些数据，最后，用户销户了，更新他的有效标志，从此这条记录基本不会再修改了。从大的方向来说这个归类在周期快照型表中，表示是期末那一刻的状态值，例如充值余额可以记录在用户表中同时也可能会在月帐单表中出现。而时点值一般在事件型数据中是不会出现的。时期值一般存在于事件型核周期快照型表中，因为他表示发生值，在累积快照型中没有这种值。当然，有时候你可以从另一个角度将累积快照型看作是一种事件型表，因为前者记录实体的生命周期变化，因此这些变化，你甚至可以看作是一种事件。从而，再以用户表为例，你可以统计新增用户多少，离网用户多少等时期值。

理解这三种数据形态对于数据抽取有一些帮助。数据仓库日常的ETL工作中，不可能总是处理全量数据，那个量就太大了，必须寻找增量（Ps 当然现在因为部分同学在处理数据时直接做全量快照同步，每天称呼资源最近很紧张，如果扒开内部看一下，每天存的是昨日的全量快照）。

这里的增量不是指增加的数据量，还包括修改的和删除的数据。增量的支持对数据源系统是一个很大的考验，对于快照型数据，数据源在实时变化，如何捕捉一个时间段内所有发生变化的数据？

• 一种方法是加入时间戳，所有插入、更新操作都能反应到时间戳，通过选取时间戳在某个时间周期内，就可以得到该周期内的增量数据，从而减少数据量的处理。但是这种方式没法得到删除的数据。

• 还有一种方式得到快照型数据增量，通过数据变更日志，因为每条日志反应的是记录的变化，一个时间周期内出现在日志中的主数据，就是该周期的增量。这种方式还能处理删除数据，但是到了ODS层，通常也不建议删除任何数据。

通过这两种方式获取快照型数据增量都有一些问题。主要是数据源的支持程度，例如是否有时间戳字段？日志是否记录每种主数据变化？有些系统的答案是否。例如数据源的用户表、客户表就很少有时间戳，而对日志，很可能不能反应所有数据状态变化，以前遇到过一种情况，系统有用户开机日志，停机日志，但这些日志是属于营业模块的，而当另一个信用监控模块对用户作出欠费停机处理后，日志中就没有。

接触过一些企业的数据平台，内部都在称呼ETL窗口期过长、数据计算存储资源不够，那会因为不管是什么表每张表都存的昨日全量数据、保存下就是好几年的，本来做增量处理每天变化也就几百兆，非要一次保存十几个G的全量数据。在这个处理过程中，一边是全量处理的性能矛盾，一边是增量支持不力的矛盾，需要一种平衡。

比如对于用户增量数据，在用户表中有一系列时间字段，如开户时间、开机时间、停机时间、销户时间等，通过这些时间的判断，也能得出一种增量，只不过略显麻烦，而且也不能保证数据源对这些时间的维护是一致的。

对于事件型数据，处理增量相对直观一些，因为这种数据一般都有时间字段或时间戳。但是增量抽取同样存在一些问题。主要是对历史数据的修改，严格意义上，事件发生了，既成事实，不要在修改这些数据，要修改也只是另外一次事件了。但是数据源存在这种现象去修改历史记录，甚至还有手工修改的，根本无法通过时间信息来获取增量。例如话单重批和帐务调账等操作很多都是修改历史数据。面对这种情况，有时就得作出选择，忽略这些数据变化。

再谈ods的设计

ods的设计中曾经有两种考虑，一是设计标准化的ods，和oltp系统松耦合，它从一个概念高度对企业信息模型进行建模，这接近inmon的思路。然而，谁能说他能够设计一个这样的模型，现实的项目周期压力、数据准确性压力都不允许这样做。

另一种思路，是完全按照数据源结构来设计ods，oltp表结构如何，ods表结构就是如何，到dw层再整合。从现实角度看，后一种思路更加适用，因为它可以缩短开发周期，能够很快让客户看到东西。

如果把数据仓库系统比作人的大脑，DW是深度记忆区，ODS是浅度记忆区。当人接收外界的信息后，记忆在浅度区，经过温习或者某些深刻的印象，这些信息又都被记录到深度区中。而对于DM层是否可以比作语言区域呢？通过对记忆区信息的逻辑加工，进行夸大（那些夸夸其谈的人），或进行巧妙删减（那些有意隐瞒真相的人）等等，将记忆的信息传播给外界。

ods 是夹在业务系统与数据平台系统的一层夹心饼干，假如业务的客户有相同的业务流程 但是数据模型不一样，在构建ods是基于业务模型去构建还是基于数据模型去做设计呢？

而且对于ods的模型设计也因为对于业务理解、数据理解、数据平台的实践度都有很大的关系。

现在Ods 的设计大部分还是一个业务源接口表对应Ods一张表，这样对于ODS设计是方便了，而且做ETL也好做，主要的工作也就是清洗脏数据和作一些代码转换工作。如果是存在多个ODs项目或这个因为业务各种频繁变化导致的ods存在大量累计历史表，很难形成可复用部分的，不管是在哪个阶段，对业务模型的理解和裁减恐怕也不是一件轻松的事情。

作者： 松子(李博源) 自由撰稿人，数据产品 & BI 老兵一枚。