韩庆安 珠海世纪鼎利科技股份有限公司

关键字：大数据 ODS

一、什么是ODS

ODS（Operational Data Store），可操作的数据存储。是数据仓库体系结构中的不可缺少的一个部分，是存储整个数据仓库的数据的地方，是元数据经过ETL 抽取，再到OLAP 分析库的中转枢纽。可以这样通俗的理解：ODS 就是把一线的生产数据经过抽取、整理、清洗等一系列操作，归纳成一个相对完整、相对封闭的数据存储仓库。ODS 的构成并不是一个数据库或者一个文件服务器，应该是一系列数据库以及文件服务器的总称。

二、如何设计一个具体的ODS 层

对于系统架构设计师来说，任何一个系统的设计工作，都要建立在对业务需求的亲身调查的基础上，传统的应用软件如此，大型的数据仓库项目也应如此。俗话说：没有调查，就没有发言权。这种调查应该是方方面面的，甚至在一些问题上要精确到具体的业务场景的，比如元数据的特点、数据抽取的频率，上层OLAP 系统对ODS 层数据结构的要求等等。

结合实际调查具体项目特点的基础上，ODS 层的设计，可以总结为以下几个方面：

1.数据库的选取

ODS 层的数据来源可以定义为上层的生产数据，也就是整个系统的元数据。生产数据比较原始，数据的结构、数据的类型以及数据的产生频率都是由现场生产的特点决定的。比如电力系统的发电数据，主汽温度、汽轮机转速、二次风出口温度等，这样的数据在第一手生产数据系统里，通常是有实时数据库或者内存数据库完成采集，数据的组织比较杂乱，必须经过ETL 工具经过抽取、清洗等操作，才能进入数据仓库，也就是ODS 层。那么根据不同行业不同领域的元数据的特点，应该切合实际情况选取ODS 层的数据库模型。其中包括：关系型数据库的选择、表的结构的设计、存储空间的分配等。上述电力系统的ODS 层，结合实际情况，应选择oracle RAC 作为核心存储。一方面，oracle RAC 的性能比较好，在众多的关系型数据库产品中，性能是经过考验的；oracle RAC 提供了一系列主从复制、双机热备、DG 等措施保证数据的安全和完整，同时，也可以利用上述特点随时为ODS 层存储的数据抽象出一套业务数据库，方便一些周边业务功能的数据查询工作，而不应该整个数据仓库的性能。最主要的是，像这样的生产制造型企业，元数据以结构化数据为主，并不会出现图片、声音等非结构化数据，所以，像这样的生产制造型企业，选用oracle RAC 作为存储，是比较恰当的。

几年来，hadoop 比较流行，hadoop 的特点是以HDFS 为基础，建立在hbase 数据库上的。hadoop 的特点是可以很好地处理非结构化数据，并且采用了分布式的架构，可以进行MapReduce 计算。针对这样的特点，交通运输类项目的ods层选择可以使用hadoop作为存储，比如某市地铁项目。地铁项目包含站务系统、票务系统和乘务系统等，这样的系统产生的元数据，一定会包含大量的非结构化的数据，针对此种情形，hadoop 可以非常完美地解决这个问题，并且，hadoop 采用了分布式文件系统存储数据，可以一式多份，对数据的备份也提供了方便。

2.数据库参数的设计

就上文中提到的电力系统发电部的模型，数据库选择了oracle RAC，接下来就是一系列参数的设置。

ODS 层的关系型数据库，和传统的OLTP 型数据库，在设计思路上有本质上的区别，关心的“点”，也截然不同。就Oracle 数据库为例，对于OLTP 数据库，由于事务型数据库的DML 行为非常频繁，所以关心的点是内存使用率、各种指标的命中率、绑定变量和并发操作。对于一个OLTP 系统来说，数据库内存设计显得很重要，如果数据都可以在内存中处理，那么数据库的性能无疑会提高很多。

内存的设计通常是通过调整Oracle 和内存相关的初始化参数来实现的，比较重要的几个是内存相关的参数，包括SGA 的大小（Data Buffer，Shared Pool），PGA 大小（排序区，Hash 区等）等，这些参数在一个OLTP 系统里显得至关重要，OLTP 系统是一个数据块变化非常频繁，SQL 语句提交非常频繁的一个系统。对于数据块来说，应尽可能让数据块保存在内存当中，对于SQL 来说，尽可能使用变量绑定技术来达到SQL 的重用，减少物理I/O 和重复的SQL 解析，能极大的改善数据库的性能。

如果说OLTP 型数据库的评测指标是相应时间，那么OLAP 型数据库的指标应该是吞吐量。联机分析系统的DML 操作非常少，而且时间比较集中，即使是数据导入，也很少使用直接insert 的方式，要么是SqlLoad 加载进来的，要么是通过Kettle 等工具加载进来的。对于用户来说：它更像一个只读的数据库。这样的数据库，设计的时候内存的因素考虑的很少，应该考虑的是以下几个方面：

分区：由于数据量太过庞大，你必须设计的时候就考虑好分区处理。

索引：并不是说ODS 中的数据库就不重视相应时间，那么建立索引是提高查询效率最好的途径，但是由于每张业务表的数据量都非常庞大，你必须考虑到每次加载数据的时候删除索引，加载完毕之后再重建索引的问题，否则索引反而会给数据导入带来麻烦。

物理参数：鉴于数据在盘阵上的存储比较稳定，不会发生频繁的DML 操作。修改一些物理参数以改善数据库性能。可以考虑建立一些Bigfile Tablespace，并且将这些大文件表空间设置成Automatic Storage Management，自动存储管理。使用大文件表空间可以更好地发挥Oracle 在64 位操作系统下的存储能力。另外，将ASM 的块大小调整为16M(默认为1M)。这也是提高Oracle 存储能力的一种手段。

3.文件组设计

这里的文件组指的也是对结构化数据的存储，并非非结构化数据。

文件组的规划在ODS 层也是相当重要的一个环节，在某项目中，涉及到23 个省级系统的、各分成9 种业务类型的、分成不同的时间区段的文件组数据。这样，需要对磁盘组进行详细再详细的规划，并且对“周期”问题的考虑一定要细致、慎重，因为ETL 加载的时候，“本周期”没有加载完，“下一周期”的数据又来了。

4.数据备份

任何一个技术管理者，都明白数据备份的重要性，数据丢了，应用程序写的再花俏都功亏一篑。

目前比较流行6+1、 4+7 的备份策略。什么是6+1 和4+7 呢？就是星期日做一个全量备份，之后每天做一个增量备份，每七天为一个周期，每个月有四个周期。保留历史备份记录的话，一般保留最近一个月的，也就是最近四次的全量备份。如果配合归档数据，这样可以保证数据库在任何时间点宕机，都不丢数据。ODS 层作为数据仓库系统的一个重要组成部分，存储了整个仓库几乎全部的数据，项目开始时对你的数据做一份详细的备份计划，可以让你在数据安全的问题上，高枕无忧。