ODS概念总结

概念

DB(Database)数据库
ODS(Operational Data Store)运营数据存储
DW(Data Warehouse)数据仓储
DM(Data Market)数据集市

ODS产生背景

人们对数据的处理行为可以划分为事务型数据处理(OLTP,On-Line Transaction Processing)和分析型数据处理(OLAP,On-Line Analytic Processing)。
事务型数据处理一般放在传统的数据库(Database,DB)中进行,分析型数据处理则需要在数据仓库(Data Warehouse,DW)中进行。但是有些操作型处理并不适合放在传统的数据库上完成,也有些分析型处理不适合在数据仓库中进行,这时候就需要第三种数据存储体系,操作数据存储(Operational Data Store,ODS)系统就因此产生。它的出现,也将DB&DW两层数据架构转变成DB&ODS&DW三层数据架构。

ODS 数据的基本特征

ODS中的数据具有以下4个基本特征:
①. 面向主题的:进入ODS的数据是来源于各个操作型数据库以及其他外部数据源,数据进入ODS前必须经过 ETL过程(抽取、清洗、转换、加载等)。
②. 集成的:ODS的数据来源于各个操作型数据库,同时也会在数据清理加工后进行一定程度的综合。
③. 可更新的:可以联机修改。这一点区别于数据仓库
④. 当前或接近当前的:“当前”是指数据在存取时刻是最新的,“接近当前”是指存取的数据是最近一段时间得到的。

ODS与DW的区别

ODS在DBODSDW三层体系结构中起到一个承上启下的作用。
ODS中的数据虽然具有DW中的数据的面向主题的、集成的特点,但是也有很多区别。
(1)存放的数据内容不同
ODS中主要存放当前或接近当前的数据、细节数据,可以进行联机更新。
DW中主要存放细节数据和历史数据,以及各种程度的综合数据,不能进行联机更新。
ODS中也可以存放综合数据,但只在需要的时候生成。
(2)数据规模不同
由于存放的数据内容不同,因此DW的数据规模远远超过ODS。
(3)技术支持不同
ODS需要支持面向记录的联机更新,并随时保证其数据与数据源中的数据一致。
DW则需要支持ETL技术和数据快速存取技术等。
(4)面向的需求不同
ODS主要面向两个需求:一是用于满足企业进行全局应用的需要,即企业级的OLTP和即时的OLAP;二是向数据仓库提供一致的数据环境用于数据抽取。
DW主要用于高层战略决策,供挖掘分析使用。
(5)使用者不同
ODS主要使用者是企业中层管理人员,他们使用ODS进行企业日常管理和控制。
DW主要使用者是企业高层和数据分析人员。

DW(OLAP)场景的关键特征

  • 大多数是读请求
  • 数据总是以相当大的批(> 1000 rows)进行写入
  • 不修改已添加的数据
  • 每次查询都从数据库中读取大量的行,但是同时又仅需要少量的列
  • 宽表,即每个表包含着大量的列
  • 较少的查询(通常每台服务器每秒数百个查询或更少)
  • 对于简单查询,允许延迟大约50毫秒
  • 列中的数据相对较小: 数字和短字符串(例如,每个URL 60个字节)
  • 处理单个查询时需要高吞吐量(每个服务器每秒高达数十亿行)
  • 事务不是必须的
  • 对数据一致性要求低
  • 每一个查询除了一个大表外都很小
  • 查询结果明显小于源数据,换句话说,数据被过滤或聚合后能够被盛放在单台服务器的内存中

很容易可以看出,OLAP场景与其他流行场景(例如,OLTP或K/V)有很大的不同, 因此想要使用OLTP或Key-Value数据库去高效的处理分析查询是没有意义的,例如,使用OLAP数据库去处理分析请求通常要优于使用MongoDB或Redis去处理分析请求。

DB&ODS&DW三层架构

ODS概念总结_第1张图片
ODS和DW面向不同的用户,为不同的需求产生,因此都有不可替代的作用,两者相互结合、相互补充。
ODS在三层体系结构中扮演着承上启下的作用。
一方面,ODS在原来独立的各个DB的基础上建立了一个一致的、企业全局的、面向主题的数据环境,使原有的DB系统得到改造。
另一方面,ODS使DW卸去了数据集成、结构转换等一系列负担,对DW的数据追加通过ODS完成,大大简化的DW的数据传输接口和DW管理数据的复杂度。
ODS系统的建设,弥补了DB&DW两层体系结构的不足,但是ODS并不是必需的,当企业并不需要操作型集成信息时,基于DB&DW两层体系结构是较优的,如果需要,那么DB&ODS&DW三层体系结构则是较优的。

ODS技术选型

  • TiDB
    TiDB 是 PingCAP 公司基于 Google Spanner / F1 论文实现的开源分布式 NewSQL 数据库。TiDB 的设计目标是 100% 的 OLTP 场景和 80% 的 OLAP 场景。TiDB 具备如下 NewSQL 核心特性:

    • SQL支持 (TiDB 是 MySQL 兼容的)
    • 水平线性弹性扩展
    • 分布式事务
    • 跨数据中心数据强一致性保证
    • 故障自恢复的高可用
  • KUDU
    Kudu是Cloudera开源的新型列式存储系统,是Apache Hadoop生态圈的成员之一(incubating),专门为了对快速变化的数据进行快速的分析,填补了以往Hadoop存储层的空缺。
    kudu设计的初衷为了解决如下问题:

    • 对数据扫描(scan)和随机访问(random access)同时具有高性能,简化用户复杂的混合架构
    • 高CPU效率,使用户购买的先进处理器的的花费得到最大回报
    • 高IO性能,充分利用先进存储介质
    • 支持数据的原地更新,避免额外的数据处理、数据移动
    • 支持跨数据中心replication

    Kudu的很多特性跟HBase很像,它支持索引键的查询和修改。Cloudera曾经想过基于Hbase进行修改,然而结论是对HBase的改动非常大,Kudu的数据模型和磁盘存储都与Hbase不同。HBase本身成功的适用于大量的其它场景,因此修改HBase很可能吃力不讨好。最后Cloudera决定开发一个全新的存储系统。

    Kudu的定位是提供”fast analytics on fast data”,也就是在快速更新的数据上进行快速的查询。它定位OLAP和少量的OLTP工作流,如果有大量的random accesses,官方建议还是使用HBase最为合适。

你可能感兴趣的:(数据仓储,理论)