ODS概念总结_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和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最为合适。