说明
数据产品经理教程 正在编写中,欢迎大家加微信 gairuo123 (备注:数据产品教程) 提供意见、建议、纠错、催更。应大家要求,作者开办数据产品和数据分析培训班,详情 数据产品经理培训 / 数据分析培训。
操作型数据存储(英语:Operational Data Store)是一种资料架构或数据库设计的概念,为企业提供即时的,操作型数据的集合。出现原因是来自于当需要集成来自多个系统的资料,结果又要给一或多个系统使用时。
ODS全称是Operational Data Store,即操作数据存储。主要为:
通常而言,ODS层表跟业务系统保持一致,但又不完全等同于业务系统。在设计ODS物理表时,在表命名、增量/全量数据存储等方面都需要遵循一定的准则。
避免重复抽取数据 建立统一的ODS层,统一标准化处理。表的生命周期管理 一般而言,全量表保存3~7天,增量表要永久保存。
无下游任务的表 该表没有被下游任务使用,这种情况下要及时下线同步任务,避免造成资源的浪费,这部分涉及涉及元数据治理。
集成来自多个系统的资料,应先创建资料模型(data model)。由于ODS并不属于特定的系统,因此其资料模型的设计应为主题导向式(subject-oriented),实现方法与数据仓库无异。ODS数据集成用于最低粒度的、一天内发生频率最高的实时的或者近乎实时的查询应用。通常ODS不会被设计成用来做历史数据分析或者趋势分析工作,那是数据仓库的功能。ODS通常会被用来当做数据仓库的数据来源。ODS保存的数据窗口较小,即时间跨度不大,抽取数据的频率可以是几分钟、几小时;数据仓库保存的几乎是一个公司的所有历史数据。为求快速建置以及呈现来源系统资料,实务上常见许多企业采取的做法是直接将来源系统的资料以类似复制的方式至来源系统以外的数据库,将它视为来源资料的复本,而没有进行真正的资料集成。
资料给多个系统使用的方法,包括可以将其包装成SOA的'服务'、进行分析或报表、也可以再将资料透过ETL的方式发送至其他系统。
相较于数据仓库,ODS较偏向作业(operational)面的用途,通常资料有较频繁的更新以及较短的历史,用于实时或者接近实时地产生操作报告。但这主要是概念上的差异,实际建置时可以创建在同一平台上,由一份资料从事两种性质的服务。
目前数据仓库厂商提出了active data warehouse概念,基本上与ODS概念极为接近,亦即数据仓库厂商认为在其解决方案中除数据仓库外也包含ODS功能。
数据同步的方式大概可以分为三大类:文件同步、表同步和日志同步。
但:
在实际生产中,很少被使用。
配置十分简单,很容易上手操作,比较适合操作型业务系统的数据同步
但:
生产中,经常被使用,适用于适用于小批量表的数据抽取。
但:
因此:
在实际的生产环境中,直连同步和日志解析是非常普遍的两种数据同步方式,随着实时技术这里需要注意的是,每种方式都有其优缺点及适用的场景,找到合适业务需要方式就是最好的方式,在解决具体问题的时候,要多方面权衡,支持业务、为业务高效赋能为要义,禁忌一堆大数据技术的简单堆砌。
ODS层是否做数据清洗一直是存在争议的,比较重的清洗工作是要留到后面数仓的ETL过程中进行处理,ODS主要保持与原系统数据一致,数据质量相关工作应用于此层。
数据清洗的主要工作是处理那些不符合要求的数据,从而提升数据质量,比如一些常见的问题:错误的数据、重复的数据。
因业务系统处理不够健全造成的,比如字符串数据后面有回车空格、日期格式不正确、日期越界等等,这些问题可在ODS层或后续处理的。
一些前端系统迁移过后的新老表融合可能会存在大量的重复历史数据,这也可以在数据清洗这一步骤中完成消除重复数据的操作。需要注意的是,在数据清洗后还需要对ODS的数据做核查,还需要对脏数据做核查校验,脏数据的校验主要集中在数据量上,如果数据量波动特别大则需要人工介入处理。
在大多数的情况下,是不需要做数据清洗处理的,可以把这个清洗环节放到后面的明细层ETL中进行处理,至于在哪里处理比较合适,值得思考。
实时数据仓库的主要思路就是:为了适应实时性,数据源中发生的更新可以立刻传送到数据仓库的动态数据中,再经过响应的转换,满足实时的要求。由于实时处理的特殊性及复杂性,很多情况下实时分析是建立在基于ODS上建立简单实时数仓,因ODS处理逻辑简单,数据链路相对较短,产出更快。
根据表的刷新频率,可以将ODS层的表分为三大类:
更新时间:2021-07-08 10:42:30 标签:数据存储 数据仓库