概念数据库(数据库)
操作数据存储库(ODS )
数据仓库(dw )数据仓库
数据市场(DM )数据集市
ODS生成背景的人们对数据的处理行为是事务型数据处理(OLTP，在线传输处理)和分析型数据处理) OLAP，在线分析处理
事务型数据处理通常需要在传统的数据库(Database，DB )中进行，分析型数据处理需要在数据仓库(Data Warehouse，DW )中进行。 但是，有些操作类型处理不适合在传统数据库中进行，有些分析类型处理不适合在数据仓库中进行。 在这种情况下，需要第三种数据存储体系，从而产生操作数据存储(ODS )系统。 它的出现将DBDW的双层数据架构转变为DBODSDW的三层数据架构。
ODS数据的基本特征ODS的数据有四个基本特征：
.面向主题：进入ODS的数据来自各操作型数据库及其他外部数据源，数据在进入ODS前必须经过ETL流程(提取、清洗、转换、加载等)。
)集成) ODS的数据来源于各操作型数据库，同时在数据清理加工后进行一定程度的集成。
.可更新：可在线修改。 这与数据仓库不同
.当前或接近当前：“当前”是指数据在访问时是最新的，“接近当前”是指访问的数据是最近得到的。
ODS和DW的区别ODS在DBODSDW的三层体系结构中起一个从上到下的作用。
ODS数据具有DW数据的主题导向、集成的特点，但存在很多差异。
)1)存放的数据内容不同
ODS主要存储当前或相近的数据、详细数据，可以在线更新。
DW主要存储详细数据、历史数据以及各种程度的综合数据，无法在线更新。
ODS也可以存储统一数据，但只在需要时生成。
)2)数据规模不同
由于存储的数据内容不同，DW的数据规模远远超过ODS。
)3)技术支持不同
ODS必须支持面向记录的在线更新，并始终确保与数据源中的数据的一致性。
DW需要支持ETL技术和数据高速接入技术等。
)4)面向的需求不同
ODS主要针对两个需求。 一是为了满足企业执行全球APP应用程序的需要，即企业级OLTP和即时OLAP。 二是为数据仓库提供一致的数据环境进行数据提取。
DW主要用于顶层战略决策，用于挖掘分析。
)5)使用者不同
ODS的主要使用者是企业动荡的翅膀，他们使用ODS进行企业的日常管理和控制。
DW的主要使用者是企业高层和数据分析人员。
dw(OLAP )场景的许多主要特征是，读请求数据总是以相当大的批处理(1000 rows )写入，并且在不更改添加的数据的情况下逐查询从数据库读取大量行，但同时需要的是列宽较少的数据这意味着一个表中包含的查询较少，通常不超过每秒几百个。 对于简单查询，允许延迟约50毫秒的列中的数据相对较小。 在数字和短字符串(例如，每URL 60字节)中处理单个查询时，需要较高的吞吐量。 每台服务器每秒最多几十亿行(事务不是必需的。 数据不需要完整性。 每个查询显示的查询结果比源数据小得多，但大表除外。 换句话说，由于OLAP场景与其他常见场景(OLTP、K/V等)大不相同，因此OLTP、key--从数据被过滤、聚合、能够容纳在一台服务器的存储器中可以明显看出例如，使用OLAP数据库处理分析请求通常比使用MongoDB或Redis处理分析请求要好
DBODSDW三层体系结构
ODS和DW面向不同的用户，是为了不同的需求而产生的，所以都有不可替代的作用，两者相互结合，相辅相成。
ODS在三层架构中起着从上到下的作用。
另一方面，ODS在原始独立数据库的基础上，构建了一致的企业全球面向主题的数据环境，改造了原始数据库系统。
另一方面，ODS在DW上消除了数据整合、结构转换等一系列负担，通过ODS向DW添加数据，大大简化了DW的数据传输接口和DW管理数据的复杂性。
ODS系统的建设弥补了DBDW双层体系结构的不足，但ODS不是必需的，如果企业不需要操作型集成信息，则基于DBDW的双层体系结构较好，如果需要，DBODSDW的三层体系结构较好。
ODS技术选型TiDB
TiDB是PingCAP公司基于谷歌spanner/f1论文实现的开源分布式NewSQL数据库。 TiDB的设计目标是100%的OLTP场景和80%的OLAP场景。 TiDB具有以下NewSQL核心功能：
s
QL支持 （TiDB 是 MySQL 兼容的）水平线性弹性扩展分布式事务跨数据中心数据强一致性保证故障自恢复的高可用KUDU
Kudu是Cloudera开源的新型列式存储系统，是Apache Hadoop生态圈的成员之一(incubating)，专门为了对快速变化的数据进行快速的分析，填补了以往Hadoop存储层的空缺。
kudu设计的初衷为了解决如下问题：
Kudu的很多特性跟HBase很像，它支持索引键的查询和修改。Cloudera曾经想过基于Hbase进行修改，然而结论是对HBase的改动非常大，Kudu的数据模型和磁盘存储都与Hbase不同。HBase本身成功的适用于大量的其它场景，因此修改HBase很可能吃力不讨好。最后Cloudera决定开发一个全新的存储系统。
Kudu的定位是提供”fast analytics on fast data”，也就是在快速更新的数据上进行快速的查询。它定位OLAP和少量的OLTP工作流，如果有大量的random accesses，官方建议还是使用HBase最为合适。