31位大数据专家的方法、技术与思想

本图文仅供学习试读之用！

简介&试读

在写书号召发出的几天之内，我们就陆续接到来自大数据、数据分析、数据挖掘和商业智能BI领域100多位专家的报名，当然我们也力邀了一些在数据领域比较知名的朋友们加入。随后经过几轮筛选和审阅，最终有33篇稿件符合要求。

##

从业八年，Oracle11g OCP。曾就职于中科软科技股份有限公司、东软集团，现任职万达集团长白山管理公司信息部研发经理，先后担任过Oracle DBA、数据仓库架构师、技术经理等职位。2007~2012年期间，曾参与过大量、Oracl9i、10g、11g数据库系统运维管理工作，并深入研究Oracle底层存储机制、用户管理机制，为多个大型项目设计并优化数据库系统，涉及电力、移动、零售等多个行业。2012年开始正式接触大数据项目，在与“海量数据”的战斗中，曾带队完成三大数据项目关键环节设计以及开发工作。

互联网发展到今天，传统的管理系统、企业化平台已经不再是IT行业的主流。随着管理者对数据重要性的认识的转变，大数据已深入到互联网、金融、电商、生产、零售等各行各业。大数据将来必然会影响人类生产、生活的方方面面。

本文结合作者亲身经历的三个大型数据仓库实战项目，尤其是2012年耗时七个月完成的某集团数据中心DPI项目的坎坷经历，重点和读者分享大数据项目前期的系统架构设计以及技术选型的重要性和方法。

为了使本文不过于枯燥，作者在一些重要环节都穿插了项目中真实的场景描述，希望能给读者带来身临其境的感受。

系统架构

大数据项目的架构设计不同于传统J2EE企业级解决方案项目的架构设计，它更像一个系统，系统中还有系统，而并非一个独立运行的应用软件。需要考虑的出发点也不一样，并不是只考虑请求、转发、http协议，以及action如何通过配置文件去请求DB中的表那么简单。以数据仓库项目的设计工作为例，首先要考虑分几层、几个块、几个部分，圈定范围，确定每个部分要起到什么作用。即使是关系型数据库内部的设计，与OLTP事务型数据库相比，也有本质上的区别。

大数据项目的系统设计包含如下4个方面。

1.ETL

ETL（Extract-Transform-Load），是指元数据经过抽取（Extract）、转换（Transform），然后加载（Load）至ODS层的过程。

元数据是整个大数据项目的源头，大数据项目的整个链条，数据来源都可以归结为元数据。多数大数据的项目里，元数据来源于事务型数据库，也就是OLTP事务型数据库。笔者今天介绍的项目里，数据最初的来源也是OLTP这样的生产库，但是对于DPI中心机房来说，元数据则是来源于各个地级市的DPI系统。

ETL需要设计两个方面：数据加载和数据转储。

（1）数据加载：数据从文件到表的过程称之为数据的加载

最近很流行把元数据做成文件，ETL加载数据的时候，从文件load到数据库。这种情况的出现可能是出于对元数据的保护。这种类型的加载，需要缕清的就是业务类型和加载周期。首先，目标表准备接收的数据与文件组准备吐到表里的数据，类型一定是一一对应的。每个类型对应一个条线。其次，加载周期要规划好，避免上一个周期的数据还没有处理完，下一波又来了这样的被动局面。

（2）数据转储：数据从表到表的过程称之为数据的转储

两张表数据同步在IT行业应该是再常见不过的事情了。但是ETL操作的表对表的数据抽取可不是印象中的那么简单。在笔者经历过的XX保险公司的ETL操作中，由于车险理赔和准备金系统的历史数据太庞大，导致每个月25号需要体现的报表数据，需要提前10-12天开始启动存储过程。90年代该保险公司开业时，写存储过程的人并没有预料到现在的车险业务如此火爆，所以抽取算法一律是抽“全量”，每次执行所有业务的历史数据全部清除，之后重新导入。笔者优化这套存储过程时，盘阵上的数据已经几十个T，知道无力回天了，无奈之下只好重新研究算法，改变思路重写了程序。

11-1上头小程序戳一下！

由于之前的程序的致命之处在于“抽全量”，研究之后，决定把数据分好业务类型，之后每个类型分别处理，并且，ODS库里留有一段时间的数据，每个月执行程序的时候，只处理差异的部分，也就是传说中的“抽增量”。历史数据的保留可以考虑落地到磁盘，这就是近几年非常流行的“中间表”技术，代价就是用空间去换时间。

另外，ETL的设计要统观大局，不要陷入局部地区出不来。在某集团数据中心DPI这个项目里，由于笔者过分计较数据完整性，做ETL设计的时候，浪费了太多太多的时间和精力。走过这个项目，回头来看，这类OLAP分析需求的，又是如此海量数据的工程，丢上几百几千条数据，不伤大雅。对最终的分析结果，几乎没有影响。

2.ODS层

ODS（Operational Data Store），可操作的数据存储。是数据仓库体系结构中的不可缺少的一个部分，是存储整个数据仓库的数据的地方，是元数据经过ETL抽取，再到OLAP分析库的中转枢纽。

ODS中的数据库，属于OLAP数据库。在某些特殊的情况下，也具备OLTP系统的部分特征，它是“面向主题的、集成的、当前或接近当前的、不断变化的”数据。

ODS层的设计，大体分为三个方面。数据库设计、文件组设计以及数据备份。

（1）数据库设计

笔者完成某集团数据中心DPI项目的时候，数据仓库技术还没有今天这样发达，那时候像MongoDB、HBase这样的NoSQL数据库还并不流行，即使是Hadoop刚刚崭露头角，也没有像今天这样在生产环境上大规模地使用。当时即使是ODS层，用到最多的还是关系型数据库。

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

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

除了内存，没有绑定变量的SQL会对OLTP数据库造成极大的性能影响之外，还有一些因素也会导致数据库的性能下降，比如热块（hot block）的问题，当一个块被多个用户同时读取的时候，Oracle为了维护数据的一致性，需要使用Latch来串行化用户的操作，当一个用户获得了这个Latch，其他的用户就只能被迫的等待，获取这个数据块的用户越多，等待就越明显，就造成了这种热块问题。这种热块可能是数据块，也可能是回滚段块。对于数据块来讲，通常是数据块上的数据分布不均匀导致，如果是索引的数据块，可以考虑创建反向索引来达到重新分布数据的目的，对于回滚段数据块，可以适当多增加几个回滚段来避免这种争用。

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

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

该书关键词

数据实践之美

相关封面

通知

服务器已经租赁！书架将重开！目前只租到18年年底，大家别忘记继续戳小程序！

每个图文里的均可戳一次哦！

书籍试读文字内容

版权归原出版社所有，如有侵权请留言告知！

立删/歉！