什么是数据仓库，数据仓库在哪里保存数据。BI项目需要用到哪些技术

（一）数据源是数据仓库系统的基础，是整个系统的数据源泉。通常包括企业内部信息和外部信息。内部信息包括存放于rdbms中的各种业务处理数据和各类文档数据。外部信息包括各类法律法规、市场信息和竞争对手的信息等等；（二）数据的存储与管理是整个数据仓库系统的核心。数据仓库的真正关键是数据的存储和管理。数据仓库的组织管理方式决定了它有别于传统数据库，同时也决定了其对外部数据的表现形式。要决定采用什么产品和技术来建立数据仓库的核心，则需要从数据仓库的技术特点着手分析。针对现有各业务系统的数据，进行抽取、清理，并有效集成，按照主题进行组织。数据仓库按照数据的覆盖范围可以分为企业级数据仓库和部门级数据仓库（通常称为数据集市）。（三）olap(联机分析处理)服务器对分析需要的数据进行有效集成，按多维模型予以组织，以便进行多角度、多层次的分析，并发现趋势。其具体实现可以分为：rolap（关系型在线分析处理）、molap（多维在线分析处理）和holap（混合型线上分析处理）。rolap基本数据和聚合数据均存放在rdbms之中；molap基本数据和聚合数据均存放于多维数据库中；holap基本数据存放于rdbms之中，聚合数据存放于多维数据库中。（四）前端工具主要包括各种报表工具、查询工具、数据分析工具、数据挖掘工具以数据挖掘及各种基于数据仓库或数据集市的应用开发工具。其中数据分析工具主要针对olap服务器，报表工具、数据挖掘工具主要针对数据仓库。-----------------------------由安信公司历经4年研发的监测数据管理平台，采用独创的技术架构，在b/s架构上融入c/s模式，囊括了实验室管理系统、监测站公自动化、监测站综合业务管理系统、监测数据上报系统等诸多系统，把各个系统有机融合在一起，不同的业务科室展现不同工作页面，内部却又实现了数据共享。系统页面简单大方， *** 作轻松方便，在不增加实验室工作量的情况下，能够让监测数据进入系统中，原始记录单等诸多实验室报表可协助生成（不完全生成，需人工签字），随后科室比如质控、综合、主管领导即可对数据进行多层次利用查询，并自动生成各类监测报表。系统采用流程化工作模式，对不同监测任务实施不同工作流，保证工作的科学和严谨，对于单位内部职工每天待事宜清晰显示，让内部职工对每天工作都一目了然。系统工作流程可自由配置，工作单可根据按照配置流转相应单位，并且可以对工作流程进行追踪查询，作为领导可以查看到每一项安排工作的流转情况、完成情况和监测结果。系统支持短信功能，对于领导等科室一些紧急任务可在系统下达后，立刻用短信通知相应工作人员，对于单位紧急通知等也可以进行短信通知，让监测站的工作更加快捷高效。系统提供深层次数据挖掘功能，能够根据监测数据，快速提供某监测点的多方位数据，比如历年来某月cod的监测数据变化，几年来某项监测数据的月平均值变化等等，为监测站领导决策提供科学依据。系统生成报表功能强大，除自身已包含众多报表外，可迅速生成word下各种客户要求的监测报表，并且查阅维护方便。系统作为平台拓展性强，可以融合其他系统与平台上，并且后期功能升级方便不影响前期功能。目前系统已经在多个地方监测站运行，从使用效果来看是比较实用的。

摘 要:元数据作为存储数据的数据,在各种数据仓库教材中都涉及到元数据的管理知识,但是在实际应用中对于元数据的管理却使用的很少,大多数据仓库开发人员都了解元数据的重要性,但是在真正应用中却很少使用,或者说不知道如何构建元数据库,本文就针对元数据的管理以及在Sql Server 2005中的具体实现。
关键词:元数据 数据仓库 数据模型 程序设计
中图分类号:TP31113 文献标识码:A 文章编号:1672-3791(2012)05(c)-0034-01
元数据是整个数据仓库的核心,它描述了仓库中的各个数据对象,遍及仓库的各个方面,同时它在数据仓库的建造及运行中起着极其重要的作用。而元数据大致分为关于数据源的元数据,数据模型的元数据,数据仓库映射的元数据以及数据仓库使用的元数据的四个方面类型。
(1)数据源的元数据。关于数据源的元数据在利用这类元数据时对不同数据源平台上的物理结构和含义是现有系统业务数据源的描述信息。其具体有以下几点:①数据源中所有物理数据结构,包括所有的数据项及数据类型。②所有数据项的业务定义。③每个数据项更新的频率,以及由谁或哪个过程更新的说明。④每个数据项的有效值。⑤其他系统中具有相同业务含义的数据项清单。
(2)数据模型的元数据。关于数据模型的元数据是数据仓库管理的基础,同时描述了仓库中有说明数据以及数据之间的关系。当一些用户提出需要哪些表系统就能从中选出这个表,这就说明了元数据可以支持用户从数据仓库中获取数据。通过这种关系表用户就能获取很多希望数据。
描述数据仓库中的数据及数据之间的各种复杂关系,元数据要定义以下内容。数据仓库中描述数据及数据之间的各种复杂的关系,现定义以下内容:①I/O对象:元数据在描述I/O对象的定义、类型、状态以及存档周期都是支持数据仓库I/O *** 作的各个对象。②关系:两个I/O对象之间是关联的。这种关联有三种类型分别是一对一、一对多和多对多。③关系成员:描述每个关系中两个I/O对象的具体角色(在一对多中是父亲还是儿子)、关系度(一对一还是一对多)以及约束条件(必须满足还是可选关系)。④关系关键字:描述两个I/O对象如何建立关联。每个关系都是通过I/O对象的关键字来建立的,元数据要指明建立每个关系的相应对象的关键字。
(3)数据仓库映射的元数据。数据仓库映射的元数据是数据源与数据仓库数据之间的映射,当数据源的数据项与数据仓库建立映射关系时,就要记下这些数据项发生的一些转换、变换和加载的过程。就是用元数据反映数据仓库的数据项是从转换、变换和加载过程这些特定的数据源填充的。而转移元数据的数据到数据仓库的目标数据是一件复杂的工作,其工作量占整个数据仓库的80%。其主要涉及以下两方面:①抽取工作之间的复杂关系。②源数据与目标数据之间的映射。
(4)关于数据仓库使用的元数据,数据仓库使用的元数据时对数据仓库中信息使用情况的描述。数据仓库的用户最关心的是以下两类元数据。①元数据描述数据仓库中有什么数据,它们从哪里来,即如何按主题查看数据仓库的内容。②元数据提供已有的,可重复利用的查询语言信息。如果某个查询能够满足他们的需求,或者与他们的愿望相似,他们就可以再次使用那些查询而不必从头开始编程。
1 元数据的管理
随着元数据越来越成为公司重要的资源,就越来越需要完善的元数据管理功能,包括:(1)支持企业范围内的体系结构。企业在开发应用程序、封装应用程序、决策支持数据库时,他们关心的是软件设计与开发、用户接口、 *** 作管理、应用程序内部的消息传递、数据的协同工作能力。所有这些都驱使开发人员去理解各种元数据目录,以及它们在企业范围内的体系结构的作用。(2)基于知识库的方法。元数据一般存储在其特定工具相关的属性知识库中。因此,企业可以要求提供一种机制,可以将其特定工具支持的元数据无缝地转移到一个共享的、公共的元数据知识库中。(3)配置管理。元数据知识库必须提供标准的配置管理能力,如注册、退出、版本控制等。还需要提供抽取、修改元数据的定义以及将其定义存到知识库中,此外,还必须具有在必要的时候将元数据恢复到某一个前版本的功能。(4)支持开放的元数据交换标准。企业内部和外部对元数据的访问导致了对开放的元数据交换标准支持的需求。至少企业元数据应该支持MDIS(元数据交换标准)。(5)动态交换和同步。企业应该采用MDIS标准,实现动态交换或同步,否则需要一个开放的元数据交换工具。
2 元数据在Sql Server 2005中的应用
21 概念
元数据描述OLTP中的表、数据仓库、数据集市和OLAP多维数据集等对象,还记录程序引用的对象。
22 具体实现和元数据的获取
在Sql Server 2005中一般由数据库系统本身产生元数据,或者在相应编程中产生元数据,不需要用户自己创建,当然用户也可以自己创建。例如在DotNet创建多维数据集时,自动产生XML格式的元数据。
下面介绍如何从Sql Server2005中获取元数据。
(1)使用系统提供的存储过程和系统函数访问元数据。
系统存储过程与系统函数在系统表和元数据之间提供了一个抽象层,使得我们不用直接查询系统表就能获得当前数据库对象的元数据。
存储过程如下。
sp_columns返回指定表或视图的列的详细信息。
Sp_databases返回当前服务器上的所有数据库的基本信息。
Sp_fkeys若参数为带有主键的表,则返回包含指向该表的外键的所有表;若参数为带有外键的表名,则返回所有同过主键/外键关系与该外键相关联的所有表。
Sp_pkeys返回指定表的主键信息。
Sp_server_info返回当前服务器的各种特性及其对应取值。
Sp_sproc_columns返回指定存储过程的输入、输出参数的信息。
Sp_statistics返回指定的表或索引视图上的所有索引以及统计的信息。
Sp_stored_procedures返回当前数据库的存储过程列表,包含系统存储过程。
Sp_tables返回当前数据库的所有表和视图,包含系统表。
(2)使用信息架构视图访问元数据。信息架构视图功能很强,它独立于系统视图,即便系统视图发生改变也不会更改信息架构视图。应用程序可以正常访问信心架构视图。
(3)使用系统表访问元数据。Sql Server中所有的对象信息都存在系统表中,可以通过系统表访问元数据。
3 结语
目前,元数据库的建立主要通过系统自动产生,然后由用户使用,用户很少自己创建元数据,但是随着数据量的增加和数据库设计的复杂性,以及程序设计的复杂性,尤其是数据仓库方面,越来越需要设计人员构建自己的数据仓库。

根据目前大数据这一块的发展，已经不局限于离线的分析，挖掘数据潜在的价值，数据的时效性最近几年变得刚需，实时处理的框架有storm，spark-streaming，flink等。想要做到实时数据这个方案可行，需要考虑以下几点：1、状态机制 2、精确一次语义 3、高吞吐量 4、可d性伸缩的应用 5、容错机制，刚好这几点，flink都完美的实现了，并且支持flink sql高级API，减少了开发成本，可用实现快速迭代，易维护等优点。

离线数仓的架构图：

实时数仓架构图:

目前是将实时维度表和DM层数据存于hbase当中，实时公共层都存于kafka当中，并且以写滚动日志的方式写入HDFS（主要是用于校验数据）。其实在这里可以做的工作还有很多，kafka集群，flink集群，hbase集群相互独立，这对整个实时数据仓库的稳定性带来一定的挑战。

一个数据仓库想要成体系，成资产，离不开数据域的划分。所以参考着离线的数据仓库，想着在实时数仓做出这方面的探索，理论上来讲，离线可以实现的，实时也是可以实现的。 并且目前已经取得了成效，目前划分的数据域跟离线大致相同，有流量域，交易域，营销域等等。当然这里面涉及到维表，多事务事实表，累计快照表，周期性快照表的设计，开发，到落地这里就不详述了。

维度表也是整个实时数据仓库不可或缺的部分。从目前整个实时数仓的建设来看，维度表有着数据量大，但是变更少的特点，我们试想过构建全平台的实时商品维度表或者是实时会员维度表，但是这类维度表太过于复杂，所以针对这类维度表下面介绍。还有另外一种就是较为简单的维度表，这类维度可能对应着业务系统单个mysql表，或者只需要几个表进行简单ETL就可以产出的表，这类维表是可以做成实时的。以下有几个实施的关键点：

如下是离线数据同步架构图：

实时数据的接入其实在底层架构是一样的，就是从kafka那边开始不一样，实时用flink的UDTF进行解析，而离线是定时（目前是小时级）用camus拉到HDFS，然后定时load HDFS的数据到hive表里面去，这样来实现离线数据的接入。实时数据的接入是用flink解析kafka的数据，然后在次写入kafka当中去。

由于目前离线数据已经稳定运行了很久，所以实时接入数据的校验可以对比离线数据，但是离线数据是小时级的hive数据，实时数据存于kafka当中，直接比较不了，所以做了相关处理，将kafka的数据使用flink写HDFS滚动日志的形式写入HDFS，然后建立hive表小时级定时去load HDFS中的文件，以此来获取实时数据。

完成以上两点，剩余还需要考虑一点，都是小时级的任务，这个时间卡点使用什么字段呢首先要确定一点就是离线和实时任务卡点的时间字段必须是一致的，不然肯定会出问题。目前离线使用camus从kafka将数据拉到HDFS上，小时级任务，使用nginx_ts这个时间字段来卡点，这个字段是上报到nginx服务器上记录的时间点。而实时的数据接入是使用flink消费kafka的数据，在以滚动日志的形式写入HDFS的，然后在建立hive表load HDFS文件获取数据，虽然这个hive也是天/小时二级分区，但是离线的表是根据nginx_ts来卡点分区，但是实时的hive表是根据任务启动去load文件的时间点去区分的分区，这是有区别的，直接筛选分区和离线的数据进行对比，会存在部分差异，应当的做法是筛选范围分区，然后在筛选nginx_ts的区间，这样在跟离线做对比才是合理的。

目前实时数据接入层的主要时延是在UDTF函数解析上，实时的UDTF函数是根据上报的日志格式进行开发的，可以完成日志的解析功能。

解析流程图如下：

解析速率图如下：

该图还不是在峰值数据量的时候截的，目前以800记录/second为准，大概一个记录的解析速率为125ms。
目前该任务的flink资源配置核心数为1，假设解析速率为125ms一条记录，那么峰值只能处理800条/second，如果数据接入速率超过该值就需要增加核心数，保证解析速率。

介绍一下目前离线维度表的情况，就拿商品维度表来说，全线记录数将近一个亿，计算逻辑来自40-50个ods层的数据表，计算逻辑相当复杂，如果实时维度表也参考离线维度表来完成的话，那么开发成本和维护成本非常大，对于技术来讲也是很大的一个挑战，并且目前也没有需求要求维度属性百分百准确。所以目前（伪实时维度表）准备在当天24点产出，当天的维度表给第二天实时公共层使用，即T-1的模式。伪实时维度表的计算逻辑参考离线维度表，但是为了保障在24点之前产出，需要简化一下离线计算逻辑，并且去除一些不常用的字段，保障伪实时维度表可以较快产出。

实时维度表的计算流程图：

目前使用flink作为公司主流的实时计算引擎，使用内存作为状态后端，并且固定30s的间隔做checkpoint，使用HDFS作为checkpoint的存储组件。并且checkpoint也是作为任务restart以后恢复状态的重要依据。熟悉flink的人应该晓得，使用内存作为状态后端，这个内存是JVM的堆内存，毕竟是有限的东西，使用不得当，OOM是常有的事情，下面就介绍一下针对有限的内存，如果完成常规的计算。

假定在程序效率和关键过程相当且不计入缓存等措施的条件下，读写任何类型的数据都没有直接 *** 作文件来的快，不论MSYQL过程如何，最后都要到磁盘上去读这个“文件”（记录存储区等效），所以当然这一切的前提是只读 内容，无关任何排序或查找 *** 作。 动态中国站一般都是用数据库来存储信息，如果信息的及时性要求不高 可以加入缓存来减少频繁读写数据库。 两种方式一般都支持，但是绕过 *** 作系统直接 *** 作磁盘的性能较高，而且安全性也较高，数据库系中的磁盘性能一直都是瓶颈，大型数据库一般基于unix 系统，当然win下也有，不常用应为win的不可靠性，unix下，用的是裸设备raw设备，就是没有加工过的设备（unix下的磁盘分区属于特殊设备， 以文件形式统一管理），由dbms直接管理，不通过 *** 作系统，效率很高，可靠性也高，因为磁盘，cache和内存都是自己管理的，大型数据库系统 db二，oracal，informix（不太流行了），mssql算不上大型数据库系统。 一、直接读文件相比数据库查询效率更胜一筹，而且文中还没算上连接和断开的时间。 二、一次读取的内容越大，直接读文件的优势会越明 显（读文件时间都是小幅增长，这跟文件存储的连续性和簇大小等有关系），这个结果恰恰跟书生预料的相反，说明MYSQL对更大文件读取可能又附加了某些 *** 作（两次时间增长了近三0%），如果只是单纯的赋值转换应该是差异偏小才对。 三、写文件和INSERT几乎不用测试就可以推测出，数据库效率只会更差。 四、很小的配置文件如果不需要使用到数据库特性，更加适合放到独立文件里存取，无需单独创建数据表或记录，很大的文件比如、音乐等采用文件存储更为方便，只把路径或缩略图等索引信息放到数据库里更合理一些。 5、PHP上如果只是读文件，file_get_contents比fopen、fclose更有效率，不包括判断存在这个函数时间会少三秒左右。 陆、fetch_row和fetch_object应该是从fetch_array转换而来的，书生没看过PHP的源码，单从执行上就可以说明fetch_array效率更高，这跟中国上的说法似乎相反。 磁盘读写与数据库的关系： 一 磁盘物理结构 (一) 盘片：硬盘的盘体由多个盘片叠在一起构成。 在硬盘出厂时，由硬盘生产商完成了低级格式化(物理格式化)，作用是将空白的盘片(Platter)划分为一个个同圆心、不同半径的磁道 (Track)，还将磁道划分为若干个扇区(Sector)，每个扇区可存储一二吧×二的N次方（N=0一二三）字节信息，默认每个扇区的大小为 5一二字节。通常使用者无需再进行低级格式化 *** 作。 (二) 磁头：每张盘片的正反两面各有一个磁头。 (三) 主轴：所有磁片都由主轴电机带动旋转。 (四) 控制集成电路板：复杂！上面还有ROM（内有软件系统）、Cache等。 二 磁盘如何完成单次IO *** 作 (一) 寻道 当控制器对磁盘发出一个IO *** 作命令的时候，磁盘的驱动臂(Actuator Arm)带动磁头(Head)离开着陆区(Landing Zone，位于内圈没有数据的区域)，移动到要 *** 作的初始数据块所在的磁道(Track)的正上方，这个过程被称为寻道(Seeking)，对应消耗的时 间被称为寻道时间(Seek Time)； (二) 旋转延迟 找到对应磁道还不能马上读取数据，这时候磁头要等到磁盘盘片(Platter)旋转到初始数据块所在的扇区(Sector)落在读写磁头正下方之后才能开始读取数据，在这个等待盘片旋转到可 *** 作扇区的过程中消耗的时间称为旋转延时(Rotational Delay)； (三) 数据传送 接下来就随着盘片的旋转，磁头不断的读/写相应的数据块，直到完成这次IO所需要 *** 作的全部数据，这个过程称为数据传送(Data Transfer)，对应的时间称为传送时间(Transfer Time)。完成这三个步骤之后单次IO *** 作也就完成了。 根据磁盘单次IO *** 作的过程，可以发现： 单次IO时间 = 寻道时间 + 旋转延迟 + 传送时间 进而推算IOPS(IO per second)的公式为： IOPS = 一000ms/单次IO时间 三 磁盘IOPS计算 不同磁盘，它的寻道时间，旋转延迟，数据传送所需的时间各是中国？ 一 寻道时间 考虑到被读写的数据可能在磁盘的任意一个磁道，既有可能在磁盘的最内圈（寻道时间最短），也可能在磁盘的最外圈（寻道时间最长），所以在计算中我们只考虑平均寻道时间。 在购买磁盘时，该参数都有标明，目前的SATA/SAS磁盘，按转速不同，寻道时间不同，不过通常都在一0ms以下： 三 传送时间二 旋转延时 和寻道一样，当磁头定位到磁道之后有可能正好在要读写扇区之上，这时候是不需要额外的延时就可以立刻读写到数据，但是最坏的情况确实要磁盘旋转整整 一圈之后磁头才能读取到数据，所以这里也考虑的是平均旋转延时，对于一5000rpm的磁盘就是(陆0s/一5000)(一/二) = 二ms。 (一) 磁盘传输速率 磁盘传输速率分两种：内部传输速率(Internal Transfer Rate)，外部传输速率(External Transfer Rate)。 内部传输速率(Internal Transfer Rate)，是指磁头与硬盘缓存之间的数据传输速率，简单的说就是硬盘磁头将数据从盘片上读取出来，然后存储在缓存内的速度。 理想的内部传输速率不存在寻道，旋转延时，就一直在同一个磁道上读数据并传到缓存，显然这是不可能的，因为单个磁道的存储空间是有限的； 实际的内部传输速率包含了寻道和旋转延时，目前家用磁盘，稳定的内部传输速率一般在三0MB/s到四5MB/s之间(服务器磁盘，应该会更高)。 外部传输速率(External Transfer Rate)，是指硬盘缓存和系统总线之间的数据传输速率，也就是计算机通过硬盘接口从缓存中将数据读出交给相应的硬盘控制器的速率。 硬盘厂商在硬盘参数中，通常也会给出一个最大传输速率，比如现在SATA三0的陆Gbit/s，换算一下就是陆一0二四/吧，漆陆吧MB/s，通常指的是硬盘接口对外的最大传输速率，当然实际使用中是达不到这个值的。 这里计算IOPS，保守选择实际内部传输速率，以四0M/s为例。 (二) 单次IO *** 作的大小 有了传送速率，还要知道单次IO *** 作的大小(IO Chunk Size)，才可以算出单次IO的传送时间。那么磁盘单次IO的大小是中国？答案是：不确定。 *** 作系统为了提高 IO的性能而引入了文件系统缓存(File System Cache)，系统会根据请求数据的情况将多个来自IO的请求先放在缓存里面，然后再一次性的提交给磁盘，也就是说对于数据库发出的多个吧K数据块的读 *** 作有可能放在一个磁盘读IO里就处理了。 还有，有些存储系统也是提供了缓存（Cache），接收到 *** 作系统的IO请求之后也是会将多个 *** 作系统的 IO请求合并成一个来处理。 不管是 *** 作系统层面的缓存还是磁盘控制器层面的缓存，目的都只有一个，提高数据读写的效率。因此每次单独的IO *** 作大小都是不一样的，它主要取决于系统对于数据读写效率的判断。这里以SQL Server数据库的数据页大小为例：吧K。 (三) 传送时间 传送时间 = IO Chunk Size/Internal Transfer Rate = 吧k/四0M/s = 0二ms 可以发现： (三一) 如果IO Chunk Size大的话，传送时间会变大，从而导致IOPS变小； (三二) 机械磁盘的主要读写成本，都花在了寻址时间上，即：寻道时间 + 旋转延迟，也就是磁盘臂的摆动，和磁盘的旋转延迟。 (三三) 如果粗略的计算IOPS，可以忽略传送时间，一000ms/(寻道时间 + 旋转延迟)即可。 四 IOPS计算示例 以一5000rpm为例： (一) 单次IO时间 单次IO时间 = 寻道时间 + 旋转延迟 + 传送时间 = 三ms + 二ms + 0二 ms = 5二 ms (二) IOPS IOPS = 一000ms/单次IO时间 = 一000ms/5二ms = 一9二 (次) 这里计算的是单块磁盘的随机访问IOPS。 考虑一种极端的情况，如果磁盘全部为顺序访问，那么就可以忽略：寻道时间 + 旋转延迟 的时长，IOPS的计算公式就变为：IOPS = 一000ms/传送时间 IOPS = 一000ms/传送时间= 一000ms/0二ms = 5000 (次) 显然这种极端的情况太过理想，毕竟每个磁道的空间是有限的，寻道时间 + 旋转延迟 时长确实可以减少，不过是无法完全避免的。 四 数据库中的磁盘读写 一 随机访问和连续访问 (一) 随机访问(Random Access) 指的是本次IO所给出的扇区地址和上次IO给出扇区地址相差比较大，这样的话磁头在两次IO *** 作之间需要作比较大的移动动作才能重新开始读/写数据。 (二) 连续访问(Sequential Access) 相反的，如果当次IO给出的扇区地址与上次IO结束的扇区地址一致或者是接近的话，那磁头就能很快的开始这次IO *** 作，这样的多个IO *** 作称为连续访问。 (三) 以SQL Server数据库为例 数据文件，SQL Server统一区上的对象，是以extent(吧吧k)为单位进行空间分配的，数据存放是很随机的，哪个数据页有空间，就写在哪里，除非通过文件组给每个表预分配足够大的、单独使用的文件，否则不能保证数据的连续性，通常为随机访问。 另外哪怕聚集索引表，也只是逻辑上的连续，并不是物理上。 日志文件，由于有VLF的存在，日志的读写理论上为连续访问，但如果日志文件设置为自动增长，且增量不大，VLF就会很多很小，那么就也并不是严格的连续访问了。 二 顺序IO和并发IO (一) 顺序IO模式(Queue Mode) 磁盘控制器可能会一次对磁盘组发出一连串的IO命令，如果磁盘组一次只能执行一个IO命令，称为顺序IO； (二) 并发IO模式(Burst Mode) 当磁盘组能同时执行多个IO命令时，称为并发IO。并发IO只能发生在由多个磁盘组成的磁盘组上，单块磁盘只能一次处理一个IO命令。 (三) 以SQL Server数据库为例 有的时候，尽管磁盘的IOPS(Disk Transfers/sec)还没有太大，但是发现数据库出现IO等待，为什么？通常是因为有了磁盘请求队列，有过多的IO请求堆积。 磁盘的请求队列和繁忙程度，通过以下性能计数器查看： LogicalDisk/AvgDisk Queue Length LogicalDisk/Current Disk Queue Length LogicalDisk/%Disk Time 这种情况下，可以做的是： (一) 简化业务逻辑，减少IO请求数； (二) 同一个实例下，多个数据库迁移的不同实例下； (三) 同一个数据库的日志，数据文件分离到不同的存储单元； (四) 借助HA策略，做读写 *** 作的分离。 三 IOPS和吞吐量(throughput) (一) IOPS IOPS即每秒进行读写（I/O） *** 作的次数。在计算传送时间时，有提到，如果IO Chunk Size大的话，那么IOPS会变小，假设以一00M为单位读写数据，那么IOPS就会很小。 (二) 吞吐量(throughput) 吞吐量指每秒可以读写的字节数。同样假设以一00M为单位读写数据，尽管IOPS很小，但是每秒读写了N一00M的数据，吞吐量并不小。 (三) 以SQL Server数据库为例 对于OLTP的系统，经常读写小块数据，多为随机访问，用IOPS来衡量读写性能； 对于数据仓库，日志文件，经常读写大块数据，多为顺序访问，用吞吐量来衡量读写性能。 磁盘当前的IOPS，通过以下性能计数器查看： LogicalDisk/Disk Transfers/sec LogicalDisk/Disk Reads/sec LogicalDisk/Disk Writes/sec 磁盘当前的吞吐量，通过以下性能计数器查看： LogicalDisk/Disk Bytes/sec LogicalDisk/Disk Read Bytes/sec LogicalDisk/Disk Write Bytes/se

---