分布式数据库资源管理

第一篇：分布式数据库资源管理

分布式数据库总结

分布式数据库系统及其应用复习大纲

第一章

分布式数据库系统概述

1、理解分布式数据库系统的特点

分布式数据库系统的定义：

分布式数据库系统，通俗地说，是物理上分散而逻辑上集中的数据库系统。分布式数据库系统使用计算机网络将地理位置分散而管理和控制又需要不同程度集中的多个逻辑单位(通常是集中是数据库系统)连接起来，共同组成一个统一的数据库系统。

分布式数据库系统的特点：1物理分布性：数据不是存放在一个站点上2逻辑整体性：是与分散式数据库系统的区别3站点自治性：是与多处理机系统的区别4数据分布透明性5集中与自治相结合的控制机制6存在适当的数据冗余度7事务管理的分布性

2、能够按照不同标准描述分布式数据库系统的分类

按局部数据库管理系统的数据模型分类：同构性(homogeneous)(分为同构同质型和 同构异质型)DDBS和异构性(heterogeneous)DDBS 按分布式数据库系统的全局控制系统类型分类：全局控制集中型DDBS，全局控制分散型DDBS，全局控制可变型DDBS。

3、理解分布式数据库中数据的独立性和分布透明性

所谓数据独立性是指用户或用户程序使用分布式数据库如同使用集中式数据库那样，不必关心全局数据的分布情况，包括全局数据的逻辑分片情况、逻辑片段站点位置的分配情况，以及各站点上数据库的数据模型等。也就是说，全局数据的逻辑分片、片段的物理位置分配，各站点数据库的数据模型等情况对用户和用户程序透明。所以，在分布式数据库中分布独立性也称为分布透明性。

分布透明性包括三个层次：分片透明性(完全分布透明性)：映像2 位置透明性(中级分布透明性)：映像3 局部数据模型透明性(低级分布透明性)：映像4 无分布透明性：异构数据

第二章

分布式数据库系统设计

1、理解分布式数据库的设计目标

分布式数据库设计的目标1分布式数据库的本地性或近地性2控制数据的适当冗余3工作负荷分布4存储的能力和费用

2、理解水平分片的定义、分类和应用

水平分片是对全局关系执行“选择操作”，把具有相同性质的元组进行分组，构成若干个不相交的子集。水平分片的方法可归为初级分片和导出分片两类。

初级分片：以关系自身的属性性质为基础，执行“选择”操作，将关系分为若干个不相交的片段。例子2.1 S(S#，SNAME, AGE, SEX)

Define fragment S1 as select * from where sex=’M’ Define fragment S2 as select * from where sex=’F’ 导出分片：全局关系的导出分片不是以其自身的属性性质为基础，而是从另一个关系的属性性质或水平片段推导出来的。采用导出分片可片可使片段与片段之间的“连接”变得更容易。 例2.3 设全局关系SC(S#，C#，GRADE)，S(S#，SNAME, AGE, SEX)若要将SC划分

为男生的各门课成绩和女生的各门课成绩，这就不可能从SC本身的属性性质来执行选择，必须从关系S的属性性质或水平片段来导出。

Define fragment SC1 as select SC.S#,C#,GRADE from SC,S where SC.S#=S.S# and SEX=’M’ Define fragment SC2 as select SC.S#,C#,GRADE from SC,S where SC.S#=S.S# and SEX=’F’

如果S已经进行水平分片，分为SF和SM，分别为男生全体和女生全体，则上述的片段定义可以基于片段SF和SM导出：

Define fragment SC1 as select * from SC where S# in(select SF.S# from SF) Define fragment SC2 as select * from SC where S# in(select SM.S# from SM)

3、理解垂直分片的定义和应用

一个全局关系的垂直分片是通过“投影”操作把它的属性分为若干组。确定一个全局关系R的垂直分片需要根据应用以“同样方式”(例如具有相同的使用频率)访问的属性来进行分组。

例2.4全局关系EMP(E#，NAME，SAL，TEL，MAGNUM，DEPT)，主码为E#。主要应用有：集中在站点3上的管理性应用要求查询雇员的：NAME，SAL，TEL;和从其他站点发出的应用要求查询雇员的：NAME，DEPT，MAGNUM。

解：如果使用垂直分片：EMP1(E#，NAME，SAL，TEL)和EMP2(E#，MAGNUM，DEPT) 则NAME属性只属于一个片段，对于上述的应用，必须进行连接操作和非本地访问。

如果使用垂直群集：EMP1(E#，NAME，SAL，TEL)和EMP2(E#，NAME，MAGNUM，DEPT)

则对于上述应用，不需要执行连接操作，且可实现较好的本地性。

4、能够描述分片的基本原则

完备性原则：要把所有的数据映射到各个片断中

可重构原则：关系分片后的各个片断可重构整个关系 不相交原则：关系分片后的各个片断不能重叠

5、掌握数据片断分配的分类和常用方法

分配的简化模型有：读代价、写代价、存储代价和目标函数。

常用方法：非冗余分配设计方法(包含最佳适应法和其他方法)和冗余分配的设计方法(包含所有得益站点法和附加复制法)

6、掌握最佳适应法和所有得益站点法的基本特点 最佳适应法是对每一种分配方式进行估算，然后选择最佳的站点。这种方法不考虑把一个片段与一个相关片段放在同一站点的“相互”影响。 特点：将片断Ri分配到访问Ri次数最多的那个站点上

Bij= ∑kFkj*Nki

所有得益站点法：首先确定非复制为题的解，然后在全部站点中确定一组站点，给这组站点中的每一个站点分配片断的一个副本，这样做所得到的好处要比为此而付出的费用合算。 特点：将片断Ri的副本分配到所有得益站点j上 Bij= ∑kFkj*Rki -c*∑k ∑j’≠j Fkj*Uki

如果Bij>0，则站点j是得益站点，放置Ri的一个副本

7、能够描述DATAID-D方法设计分布式数据库的各个阶段

需求分析，概念设计，分布要求分析，全局逻辑设计，分布设计，局部逻辑设计，局部物理设计。逻辑设计分为全局逻辑设计和局部逻辑设计

8、能够根据给出的条件对关系进行具体分片，给出正确的限定关系 上边的例子。

第三章

分布式数据库系统中的查询处理和优化

1、掌握分布式数据库查询的分类 局部查询、远程查询和全局查询

2、理解关系代数运算的交换率 ∪1 (∪2 (R)) =∪2 (∪1 (R)) 条件:∪1 ∪2 是 选择操作 时总成立，∪1 ∪2 是 投影操作

时要求其属性集合相等 ∪1 与∪2 是投影和选择操作时:πA1,„An(σF(R)) =σF (πA1,„An (R)) 的条件是 F中的属性是 A1, „. An 的子集。R ∞ S = S ∞

R

R × S = S × R R ∪S = S∪ R

R ∩S = S ∩ R

R ∝ S ≠ S ∝ R

R R

3、掌握直接连接优化算法的分类

利用站点依赖信息的算法，分片与复制算法，站点依赖和数据复制结合算法，Hash划分算法

4、掌握半连接运算 见P83-84例子

5、掌握半连接和直接连接查询优化算法的区别

取决于数据传输和局部处理的相对费用;如果传输费用是主要的，采用半连接;如果本地费用是主要的，采用直接连接,

6、理解Hash划分算法的特点

1数据传送量是R;2索引方面, 比片段复制算法更低，3每个站点的连接数据量同站点依赖

7、能够描述基于半连接算法查询优化的基本原理和步骤 基本原理是在传到另一个站点做连接前，消除与连接无关的数据，减少做连接操作的数据量，从而减小传输代价

步骤：1计算每种半连接方案的代价，并从中选择一种最佳方案

2选择传输代价最小的站点，计算采用全连接的方案的代价

3比较两种方案，确定最优方案

8、能够描述基于关系代数等价变换的查询优化算法原理、算法实现步骤

原理：1查询问题——〉关系代数表达式2分析得到查询树3进行全局到片段的变换得到基于片段的查询树4利用关系代数等价变换规则的优化算法，尽可能先执行选择和投影操作 算法：1连接和合并尽可能上提(树根方向)2选择和投影操作尽可能下移(叶子方向) 实现步骤：转换一：1查询问题——〉关系代数表达式。2转换二：关系代数表达式——〉查询树。3转换三：全局查询树分拆成片段查询树。4优化：利用关系代数等价变换规则的优化算法，优化查询树，进而优化查询

9、能够根据提供的条件完成分片和复制算法应用，通过计算判断哪个关系保持分片最优 P88例3-6 考试

第四章

分布式数据库中的事务管理和恢复

1、掌握事务的四大特性

原子性(Atomicity),一致性(Consistency),持久性(Durability).隔离性( Isolation)

2、能够描述两阶段提交协议的工作流程

两阶段提交协议的基本思想是：将本地原子性提交行为的效果扩展到分布式事务, 保证了分布式事务提交的原子性, 并在不损坏Log的情况下, 实现快速故障恢复, 提高DDB系统的可靠性.

2PC把事务的提交过程分为两个阶段：第一阶段：表决阶段，目的是形成一个共同的决定 首先，协调者给所有参与者发送“准备”消息，进入等待状态 其次，参与者收到“准备”消息后，检查是否能够提交本地事务 如能，给协调者发送“建议提交”消息,进入就绪状态

如不能，给协调者发送“建议撤销”消息，可以单方面撤销

第三，协调者收到所有参与者的消息后，他就做出是否提交事务的决定， 只要有一个参与者投了反对票，就决定撤销整个事务，发送“全局撤销”消息给所有参与者，进入撤销状态

否则，就决定提交整个事务，发送“全局提交”消息给所有参与者，进入提交状态 第二个阶段：执行阶段，实现表决阶段的决定，提交或者撤销

3、掌握事务故障的分类 分布是数据库的故障

分布是数据库的故障分为站点故障和通信故障。站点故障包括事务故障、系统故障和介质故障。

事务故障包括计算溢出。完整性被破坏、操作员干预、输入或输出出错等。 通信故障分为报文故障和网络分割故障。

4、掌握分布式数据库事务执行的控制模型的分类 分为三类：主从模型，三角模型，层次控制模型

5、理解日志文件的特点

日志文件保存到磁盘上。日志 Log：记录所有对DB的操作

事务标识：每个事务给定一个具有惟一性的标识符 Log记录项 :

[start_transaction, T] [write_item, T, x, 旧值, 新值] [read_item, T, x] [commit, T] [abort, T] 写动作：写Log比写数据优先

Log存储：一般存在盘上, 还会定期备份到磁带上

6、理解分布式数据库数据更新常见方法 多站点数据更新、主文本更新法、快照方法

7、理解故障恢复时检查点知识 检查点(Checkpoint)：设置一个周期性(时间/容量)操作点 a) Log Buffer内容写入Log数据集

b) 写检查点Log信息：当前活动事务表, 每个事务最近一次Log记录在Log文件中的位置 c) DB Buffer内容写入DB d) 将本次检查点Log项在Log文件中的地址记入“重启动文件”

8、能够描述两阶段提交协议的特点：2PC协议的重要特点：1允许参与者单方面撤销事务 2一旦参与者确定了提交或撤销协议，它就不能再更改它的提议3当参与者处于就绪状态时，根据协调者发出的消息种类，它可以转换为提交状态或者撤销状态4协调者根据全局提交规则做出全局终止决定5协调者和参与者可能进入互相等待对方消息的状态，使用定时器，保证退出消息等待状态

第五章

分布式数据库中的并发控制

1、理解封锁的基本准则

1事务T在执行任何read_item(x)操作之前，必须先执行read_lock(x)或者write_lock(x)操作

2事务T在执行任何write_item(x)操作之前，必须先执行write_lock(x)操作

3如果事务T执行read_lock(x)操作,数据项x必须没有加锁或者已经加了读锁，否则事务T的这个操作不能进行

4如果事务T执行write_lock(x)操作,数据项x必须没有加锁，否则事务T的这个操作不能进行

5事务T在完成所有read_item(x)和write_item(x)操作之后，必须执行unlock(x)操作

6如果事务T已经持有数据项x上的一个读锁或者一个写锁，那么它不能再执行read_lock(x)操作

7如果事务T已经持有数据项x上的一个读锁或者一个写锁，那么它不能再执行write_lock(x)操作

8如果事务T没有持有数据项x上的一个读锁或者一个写锁，那么它不能执行unlock(x)操作

2、理解基于时标的并发控制方法

并发控制方法包含全局时标和局部时标

3、掌握死锁检测的方法分类

局部死锁：仅在一个站点上发生的死锁

全局死锁：涉及多个站点的死锁(即等待圈由多个站点组成)

4、理解一致性调度和可串行化调度的特点

一致性调度：调度可以使得数据库从一个一致性状态转变为另一个一致性状态，则称调度为一致性调度

可串行化调度：如果一个调度等价于某个串行调度，则该调度称为可串行化调度。 也就是说，该调度可以通过一系列非冲突动作的交换操作使其成为串行调度

5、能够描述死锁发生的四个必要条件：会考试 互斥条件：事务请求对资源的独占控制

等待条件：事务已持有分配给它的资源, 又去申请并等待别的资源

非抢占条件：直到资源被持有它的事务释放前, 不可能将资源强制从持有它的事务夺去 循环等待条件：存在事务互相等待的等待圈

6、能够列举并发控制算法

悲观并发控制法和乐观并发控制法

悲观并发控制法有基于封锁的算法、基于时标排序的算法和混合算法。乐观的方法也可分为基于封锁或基于时标排序的算法。

第六章

分布式数据库中的可靠性

1、理解可靠性和可用性的含义与关系

可靠性：指数据库在一给定时间间隔内不产生任何失败的概率。它强调数据库的正确性，要求数据库正确运行。通常用来描述不可修复的系统。

可用性：强调的是当需要访问数据库时，它是可用的。指在给定的时间点系统可以正常运行的概率。通常用于描述那些可以修复的系统。

两者关系：通常认为构建可用性的系统比可靠性的系统容易。两者是统一的，可靠性高的系统可用性自然是好的。

两者又是矛盾的，增加错误风险的情况下，可提高可用性;采用太谨慎的策略会降低可用性

2、理解两阶段提交协议如何转为三阶段提交协议

2PC中的状态： C(提交)状态是可提交状态, 其它为不可提交状态。Ready 状态是不可提交状态。Wait状态是不可提交状态。它们都侵犯了非阻断协议的充要条件, 从而考虑改变2PC, 使其满足非阻断协议条件。在Wait 和 Commit 之间, 或者在Ready和Commit之间加入另一种状态作为缓冲状态, 从而有了3PC协议

3、掌握分布式可靠性协议的组成。简答

可靠性协议组成 ：包括提交、终结、恢复协议。提交和恢复协议详细说明提交命令和恢复命令是如何执行的。终结协议是分布式系统特有的协议。在执行一个分布式事务时，若一个Site故障，希望其它Site也停止该事务。处理这种情况的技术就称为终止协议。

4、理解发生网络分割时冗余分布式数据库和非冗余数据库采用的处理协议

非冗余数据库：任何需要访问存储在另一网络区域里的数据项的新事务都被阻断, 等待网络修复。位于同一区域里的数据项的并发访问由并发控制算法处理。网络分割时由提交协议处理

冗余数据库：分割时, 副本可能位于不同的区域。由复制协议处理

5、能够描述三阶段提交协议中事务协调者和参与者的状态转换 P188页图6.4 考试

6、能够采用版本号法进行不一致性检测，并且应用于实际。大题 需要首先发现哪些数据部分已经不一致(不一致性检测)

然后根据发生的情况，给这些部分赋予一个最合理的值(不一致性的解法) 检测方法：采用版本号 P200页例子

第七章

分布式数据库的安全性与目录管理

1、理解分布式数据库的动态授权语句的形式

1用户对自己生成的关系拥有全权, 通过授权和收权语句完成对数据开放, 保密的存取权授予(Grant, Revoke)。授权语句授权语句：Grant <权> To <用户> With Grant Option

2访问表(AT)法

2、理解数据库的安全性含义

数据库安全性包括两个方面的内容：数据库数据的保密性和安全性。

第二篇：从Google Spanner漫谈分布式存储与数据库技术

文/曹伟

Spanner 的设计反映了 Google 多年来在分布式存储系统领域上经验的积累和沉淀，它采用了 Megastore 的数据模型，Chubby 的数据复制和一致性算法，而在数据的可扩展性上使用了 BigTable 中的技术。新颖之处在于，它使用高精度和可观测误差的本地时钟来判断分布式系统中事件的先后顺序。Spanner 代表了分布式数据库领域的新趋势——NewSQL。

Spanner 是 Google 最近公开的新一代分布式数据库，它既具有 NoSQL 系统的可扩展性，也具有关系数据库的功能。例如，它支持类似 SQL 的查询语言、支持表连接、支持事务(包括分布式事务)。Spanner 可以将一份数据复制到全球范围的多个数据中心，并保证数据的一致性。一套 Spanner 集群可以扩展到上百个数据中心、百万台服务器和上T条数据库记录的规模。目前，Google 广告业务的后台(F1)已从 MySQL 分库分表方案迁移到了 Spanner 上。

数据模型

传统的 RDBMS(例如 MySQL)采用关系模型，有丰富的功能，支持 SQL 查询语句。而 NoSQL 数据库多是在 key-value 存储之上增加有限的功能，如列索引、范围查询等，但具有良好的可扩展性。Spanner 继承了 Megastore 的设计，数据模型介于 RDBMS 和 NoSQL 之间，提供树形、层次化的数据库 schema，一方面支持类 SQL 的查询语言，提供表连接等关系数据库的特性，功能上类似于 RDBMS;另一方面整个数据库中的所有记录都存储在同一个 key-value 大表中，实现上类似于 BigTable，具有 NoSQL 系统的可扩展性。

在 Spanner 中，应用可以在一个数据库里创建多个表，同时需要指定这些表之间的层次关系。例如，图 1 中创建的两个表——用户表(Users)和相册表(Albums)，并且指定用户表是相册表的父节点。父节点和子节点间存在着一对多的关系，用户表中的一条记录(一个用户)对应着相册表中的多条记录(多个相册)。此外，要求子节点的主键必须以父节点的主键作为前缀。例如，用户表的主键(用户 ID)就是相册表主键(用户 ID+ 相册 ID)的前缀。

图 1 schema 示例，表之间的层次关系，记录排序后交错的存储

显然所有表的主键都将根节点的主键作为前缀，Spanner 将根节点表中的一条记录，和以其主键作为前缀的其他表中的所有记录的集合称作一个 Directory。例如，一个用户的记录及该用户所有相册的记录组成了一个 Directory。Directory 是 Spanner 中对数据进行分区、 复制和迁移的基本单位，应用可以指定一个 Directory 有多少个副本，分别存放在哪些机房中，例如把用户的 Directory 存放在这个用户所在地区附近的几个机房中。

这样的数据模型具有以下好处。

 一个 Directory 中所有记录的主键都具有相同前缀。在存储到底层 key-value 大表时，会被分配到相邻的位置。如果数据量不是非常大，会位于同一个节点上，这不仅提高了数据访问的局部性，也保证了在一个 Directory 中发生的事务都是单机的。

 Directory 还实现了从细粒度上对数据进行分区。整个数据库被划分为百万个甚至更多个 Directory，每个 Directory 可以定义自己的复制策略。这种 Directory-based 的数据分区方式比 MySQL 分库分表时 Table-based 的粒度要细，而比 Yahoo!的 PNUTS 系统中 Row-based 的粒度要粗。

 Directory 提供了高效的表连接运算方式。在一个 Directory 中，多张表上的记录按主键排序，交错(interleaved)地存储在一起，因此进行表连接运算时无需排序即可在表间直接进行归并。

复制和一致性

Spanner 使用 Paxos 协议在多个副本间同步 redo 日志，从而保证数据在多个副本上是一致的。Google 的工程师钟情于 Paxos 协议，Chubby、Megastore 和 Spanner 等一系列产品都是在 Paxos 协议的基础上实现一致性的。

Paxos 的基本协议很简单。协议中有三个角色：Proposer、Acceptor 和 Learner，Learner 和 Proposer 分别是读者和写者，Acceptor 相当于存储节点。整个协议描述的是，当系统中有多个 Proposer 和 Acceptor 时，每次 Proposer 写一个变量就会启动一轮决议过程(Paxos instance)，如图 2 所示。决议过程可以保证即使多个 Proposer 同时写，结果也不会在 Acceptor 节点上不一致。确切地说，一旦某个 Proposer 提交的值被大多数 Acceptor 接受，那么这个值就被选中，在整轮决议的过程中该变量就不会再被修改为其他值。如果另一个 Proposer 要写入其他值，必须启动下一轮决议过程，而决议过程之间是串行(serializable)的。

图 2 Paxos 协议正常执行流程

一轮决议过程分为两个阶段，即 prepare 阶段和 accept 阶段。

 第一阶段A：Proposer 向所有 Acceptor 节点广播 prepare 消息，消息中只包含一个序号——N。Proposer 需要保证这个序号在这轮决议过程中是全局唯一的(这很容易做到，假如系统中有两个 Proposer，那么一个 Proposer 使用1，3，5，7，9，„„，另一个 Proposer 则使用0，2，4，6，8，„„)。

第一阶段B：Acceptor 接收到 prepare 消息后，如果N是到目前为止见过的最大序号，就返回一个 promise 消息，承诺不会接受序号小于N的请求;如果已接受过其他 Proposer 提交的值，则会将这个值连同提交这个值的请求的序号一同返回。  第二阶段A：当 Proposer 从大多数 Acceptor 节点收到了 promise 消息后，就可以选择接下来要向 Acceptor 提交的值了。一般情况下，当然选原本打算写入的值，但如果从收到的 promise 消息中发现已经有其他值被 Acceptor 接受了，那么为了避免造成数据不一致的风险，这时 Proposer 就必须“大义灭亲”，放弃自己打算写入的值，从其他 Proposer 提交的序号中选择一个最大的值。接下来 Proposer 向所有的 Acceptor 节点发送 accept 包，其中包含在第一阶段中挑选的序号N和刚才选择的值V。

第二阶段B：Acceptor 收到 accept 包之后，如果N的大小不违反对其他

Proposer 的承诺，就接受这个请求，记录下值V和序号N，返回一个 ack 消息。反之，则返回一个 reject 消息。

如果 Proposer 从大多数 Acceptor 节点收到了 ack 消息，说明写操作成功。而如果在写操作过程中失败，Proposer 可以增大序号，重新执行第一阶段。

基本的 Paxos 协议可以保证值一旦被选出后就一定不会改变，但不能保证一定会选出值来。换句话说，这个投票算法不一定收敛。有两个方法可以加速收敛的过程：一个是在出现冲突后通过随机延迟把机会让给其他 Proposer，另一个是尽量让系统中只有一个 Proposer 去提交。在 Chubby 和 Spanner 系统中这两种方法都用上了，先用随机延迟的方法通过一轮 Paxos 协议，在多个 Proposer 中选举出一个 leader 节点。接下来所有的写操作都通过这个 leader 节点，而 leader 节点一般还是比较“长寿”的，在广域网环境下平均“任期”可以达到一天以上。而 Megastore 系统中没有很好地解决这个问题，所有的 Proposer 都可以发起写操作，这是 Megastore 写入性能不高的原因之一。

基本的 Paxos 协议还存在性能上的问题，一轮决议过程通常需要进行两个回合通信，而一次跨机房通信的代价为几十到一百毫秒不等，因此两个回合的通信就有点开销过高了。不过幸运的是，绝大多数情况下，Paxos 协议可以优化到仅需一个回合通信。决议过程的第一阶段是不需要指定值的，因此可以把 prepare/promise 的过程捎带在上一轮决议中完成，或者更进一步，在执行一轮决议的过程中隐式地涵盖接下来一轮或者几轮决议的第一阶段。这样，当一轮决议完成之后，其他决议的第一阶段也已经完成了。如此看来，只要 leader 不发生更替，Paxos 协议就可以在一个回合内完成。为了支持实际的业务，Paxos 协议还需要支持并发，多轮决议过程可以并发执行，而代价是故障恢复会更加复杂。

因为 leader 节点上有最新的数据，而在其他节点上为了获取最新的数据来执行 Paxos 协议的第一阶段，需要一个回合的通信代价。因此，Chubby 中的读写操作，以及 Spanner 中的读写事务都仅在 leader 节点上执行。而为了提高读操作的性能，减轻 leader 节点的负载，Spanner 还提供了只读事务和本地读。只读事务只在 leader 节点上获取时间戳信息，再用这个时间戳在其他节点上执行读操作;而本地读则读取节点上最新版本的数据。

与 Chubby、 Spanner 这种读写以 leader 节点为中心的设计相比，Megastore 体现了一定的“去中心化”设计。每个客户端都可以发起 Paxos 写操作， 而读操作则尽可能在本地执行。如果客户端发现本地数据不是最新的，会启动 catchup 流程更新数据，再执行本地读操作返回给客户端。

最后，对比下其他系统中 replication 的实现。在 BigTable 系统中每个 tablet 服务器是没有副本的，完全依赖底层 GFS 把数据存到多台机器上。数据的读写都通过单个 tablet 服务器，在 tablet 服务器出现故障的时需要 master 服务器将 tablet 指派到其他 tablet 服务器上才能恢复可用。Dynamo 系统则贯彻了“去中心化”的思想，将数据保存在多个副本上，每个副本都可以写入(update everywhere)。而不同副本同时写入的数据可能会存在不一致，则需要使用版本向量(version vector)记录不同的值和时间戳，由应用去解释或合并不一致的数据。尽管 Dynamo 系统还提供了 NWR 的方式来支持有一致性保证的读写操作，但总的来说 Dynamo 为了高可用性牺牲了一致性。ZooKeeper、MongoDB 与 Chubby、Spanner 类似，通过 leader 选举协议从多个副本中选择一个 leader，所有写操作都在经过 leader 节点序列化后，同步到其他副本上。ZooKeeper 则是在写入大多数节点后返回，而 MongoDB 主要采用异步的主从复制方式。

分布式事务

Spanner 系统中的分布式事务通过两阶段提交协议(2PC)实现。2PC 是一类特殊的一致性协议，假设一个分布式事务涉及了多个数据节点，2PC 可以保证在这些节点上的操作要么全部提交，要么全部失败，从而保证了整个分布式事务的原子性(ACID 里的A)。协议中包含两个角色：协调者(coordinator)和参与者(participant/cohort)。协调者是分布式事务的发起者，而参与者是参与了事务的数据节点。在协议最基本的形式中，系统中有一个协调者和多个参与者。

顾名思义，2PC 也包含两个阶段，即投票阶段和提交阶段(如图 3 所示)。

图 3 两阶段提交协议  在第一阶段，协调者向所有的参与者发送投票请求，每个参与者决定是否要提交事务。如果打算提交的话需要写好 redo、undo 等日志，并向协调者回复 yes 或 no。

 在第二阶段，协调者收到所有参与者的回复，如果都是 yes，那么决定提交这个事务，写好日志后向所有参与者广播提交事务的通知。反之，则中止事务并且通知所有参与者。参与者收到提交/中止事务的命令后，执行相应操作，如果提交的话还需要写日志。

协议过程包括两回合的通信，在协调者和参与者端需要多次写日志，而且整个过程中所有参与者都占有读锁、写锁，可见 2PC 开销不菲。

2PC 最令人诟病之处还不在于性能，而是在有些故障条件下，会造成所有参与者占有读锁、写锁堵塞在第二阶段，需要人工干预才能继续，存在严重的可用性隐患。假设故障发生在第二阶段，协调者在做出决定后，通知完一个参与者就宕机了，更糟糕的是被通知的这位参与者在执行完“上级指示”之后也宕机了，这时对其他参与者来说，就必须堵塞在那里等待结果。

Spanner 利用基于 Paxos 协议的复制技术，改善了 2PC 的可用性问题。2PC 协议过程中的协调者和参与者生成的日志都会利用 Paxos 协议复制到所有副本中，这样无论是协调者或参与者宕机，都会有其他副本代替它们，完成 2PC 过程而不至于堵塞。在 Paxos 协议上实现 2PC 这一思路很巧妙，Paxos 协议保证了大多数节点在线情况下的可用性，而 2PC 保证了分布式协议的一致性。

事件的顺序

传统上，在设计一个分布式系统时，都会假设每个节点的运行速度和时钟的快慢各不相同的情况，并且在节点之间进行同步的唯一方法就是异步通信。系统中的每个节点都扮演着观察者的角色，并从其他节点接收事件发生的通知。判断系统中两个事件的先后顺序主要依靠分析它们的因果关系，包括 Lamport 时钟、向量时钟等算法，而这一切都存在通信开销。

因此，Spanner 提出了一种新的思路，在不进行通信的情况下，利用高精度和可观测误差的本地时钟 (TrueTime API)给事件打上时间戳，并且以此比较分布式系统中两个事件的先后顺序。利用这个方法，Spanner 实现了事务之间的外部一致性(external consistency)(如图 4 所示)，也就是说，一个事务结束后另一个事务才开始，Spanner 可以保证第一个事务的时间戳比第二个事务的时间戳要早，从而两个事务被串行化后也一定能保持正确的顺序。

图 4 事务外部一致性的实现

TrueTime API 是一个提供本地时间的接口，但与 Linux 上 gettimeofday 接口不一样的是，它除了可以返回一个时间戳t，还会给出一个误差ε。例如，返回的时间戳是 1 分 30 秒 350 毫秒，而误差是 5 毫秒，那么真实的时间在 1 分 30 秒 345 毫秒到 355 毫秒之间。真实的系统中ε平均下来是 4 毫秒。

利用 TrueTime API，Spanner 可以保证给出的事务标记的时间戳介于事务开始的真实时间和事务结束的真实时间之间。假如事务开始时 TrueTime API 返回的时间是{t1, ε1}，此时真实时间在 t1-ε1到 t1+ε1之间;事务结束时 TrueTime API 返回的时间是{t2, ε2}，此时真实时间在 t2-ε2到 t2+ε2之间。Spanner 会在 t1+ε1和 t2-ε2之间选择一个时间点作为事务的时间戳，但这需要保证 t1+ε1小于 t2-ε2，为了保证这点，Spanner 会在事务执行过程中等待，直到 t2-ε2大于 t1+ε1时才提交事务。由此可以推导出，Spanner 中一个事务至少需要2ε的时间(平均 8 毫秒)才能完成。

由此可见，这种新方法虽然避免了通信开销，却引入了等待时间。为了保证外部一致性，写延迟是不可避免的，这也印证了 CAP 定理所揭示的法则，一致性与延迟之间是需要权衡的。

最后介绍一下 TrueTime API 的实现。TrueTime API 的实现大体上类似于网络时间协议(NTP)，但只有两个层次。第一层次，服务器是拥有高精度计时设备的，每个机房若干台，大部分机器都装备了 GPS 接收器，剩下少数机器是为 GPS 系统全部失效的情况而准备的，叫做“末日”服务器，装备了原子钟。所有的 Spanner 服务器都属于第二层，定期向多个第一层的时间服务器获取时间来校正本地时钟，先减去通信时间，再去除异常值，最后求交集。

NewSQL

六年前，BigTable 展示了一个简洁、优美、具有高可扩展性的分布式数据库系统，引起了 NoSQL 浪潮。然而 Spanner 的设计者们指出了 BigTable 在应用中遇到的一些阻力。

 缺少类似 SQL 的界面，缺少关系数据库拥有的丰富的功能。  只支持单行事务，缺少跨行事务。

需要在跨数据中心的多个副本间保证一致性。

这些来自应用开发者的需求催生了 Spanner，一个既拥有 key-value 系统的高可扩展性，也拥有关系数据库的丰富功能(包括事务、一致性等特性)的系统。这类兼顾可扩展性和关系数据库功能的产品被称为“NewSQL”，Spanner 的公开会不会开启 NewSQL 的时代呢?我们拭目以待。

总结

最后从 CAP 定理的角度来分析下 Spanner。

CAP 定理是指在网络可能出现分区故障的情况下，一致性和可用性不可得兼。形式化地说就是，P => 非(A与P)，可以更进一步地总结为，一致性和延迟之间必须进行权衡。Paxos 协议在C和A之间选择了严格的一致性，而A则降级为大多数一致性 (majority available)。

Spanner 还通过在事务中增加延迟的方法实现了外部一致性，每个事务需要至少两倍的时钟误差才能完成。如果时钟出现故障造成误差增长，那么完成事务所需的时间也就随之增长。在这里，时钟故障也应当认为是P的一种形式。在发生时钟故障(P)的情况下，为了保证一致性(C)，而必须增加延迟(A)，这一点充分印证了 CAP 定理。

从 Spanner 系统中，我们可以学习到一些经验。

 MegaStore、Spanner 和 F1 系统所选择的树形、层次化的数据库 schema 是很精妙的，它能支持高效的表连接，这既提供了类似关系模型的范式，也提供了一个合适的粒度进行数据分区，具有好的可扩展性，H-Store 也采用了这样的 schema。

 跨数据中心的多个副本间保持一致是可行的，Paxos 协议的性能可以优化到一个可接受的范围。

 在 Paxos 协议的基础之上实现的两阶段提交的可用性得到了提高。  在一个分布式系统中，本地时钟的作用可以比我们之前想象的大很多。

作者曹伟，淘宝核心系统数据库组技术专家，从事高性能服务器、IM、P2P、微博等各类型分布式系统、海量存储产品的开发，关注系统高可用性和一致性及分布式事务领域。

第三篇：分布式光伏发电并网管理流程

1、业主到当地的电网公司大厅提交《分布式电源并网申请表》及相关材料。

需准备的材料有：

一)、自然人申请需提供： 经办人身份证原件及复印件、户口本、房产证(或乡镇及以上级政府出具的房屋使用证明)项目合法性支持性文件。

二)、法人申请需提供：

1. 经办人身份证原件及复印件和法人委托书原件(或法定代表人身份证原件及复印件)。

2. 企业法人营业执照、土地证等项目合法性支持性文件。

3. 政府投资主管部门同意项目开展前请工作的批复(需核准项目)。 4. 发电项目前期工作及接入系统设计所需资料(可研等)。

2、电网企业受理并网申请，并制定接入系统方案。

3、业主确认接入系统方案，并依照实际情况进行调整重复申请。

4、电网公司出具接网意见函。

5、业主进行项目核准和工程建设。

6、业主建设完毕后提出并网验收和调试申请。

分布式电源并网调试和验收需提供的材料清单

10kv逆变器类序号 1 资料名称

施工单位资质复印件(承装(修、试)电力设施许可证、建筑企业资质证书、安全生产许可证)

2 主要设备技术参数、型式认证报告或质检证书，包括发电、逆变、变电、断路器、刀闸等设备

3 并网前单位工程调试报告(记录)

4 5 并网前单位工程验收报告(记录)

并网前设备电气试验、继电保护整定、通信联调、电能量信息采集调试记录

6 7 并网启动调试方案

项目运行人员名单(及专业资质证书复印件)

注：

1.光伏电池、逆变器等设备，需取得国家授权的有资质的检测机构检测报告。

√ √

√

√

√

√

√

√

√

√

√

√

√

√

380V项目

√

项目 √

√

35kv项目10kv旋转电机类项目

7、电网企业受理并网验收和调试申请，安装电能计量装置(原电表改装成双向电表)。

8、电网企业并网验收及调试，并与业主联合签订购售电合同及并网调度协议。

9、正式并网运行。

具体文件参见：《国家电网公司关于印发分布式电源并网服务管理规则的通知》[2014]174号

第四篇：分布式电源项目并网服务管理规则

为促进分布式电源快速发展，规范分布式电源项目并网服务工作，提高分布式电源项目并网服务水平，公司制定了《国家电网公司分布式电源并网服务管理规则(修订版)》，现予印发，请遵照执行。 国家电网公司 2014年1月28日

分布式电源项目并网服务管理规则

(修订版)

第一章总则

第一条 为促进分布式电源快速发展，规范分布式电源项目并网管理工作，提高分布式电源项目并网服务水平，践行国家电网公司“四个服务”宗旨及“欢迎、支持、服务”要求，按照公司《关于做好分布式电源并网服务工作的意见(修订版)》、《关于促进分布式电源并网管理工作的意见(修订版)》(国家电网办[2013]1781号)要求制定本规则。

第二条 按照“四个统一”、“便捷高效”和“一口对外”的基本原则，由公司统一管理模式、统一技术标准、统一工作流程、统一服务规则;进一步整合服务资源，压缩管理层级，精简并网手续，并行业务环节，推广典型设计，开辟“绿色通道”，加快分布式电源并网速度，由营销部门牵头负责分布式电源并网服务相关工作，向分布式电源项目业主提供“一口对外”优质服务。

第三条 本管理规范所称分布式电源是指在用户所在场地或附近建设安装，运行方式以用户侧自发自用为主、多余电量上网，且在配电网系统平衡调节为特征的发电设施或有电力输出的能量综合梯级利用多联供设施。包括太阳能、天然气、生物质能、风能、地热能、海洋能、资源综合利用发电(含煤矿瓦斯发电)等。

第四条 本规则适用于以下两种类型分布式电源(不含小水电)：

第一类：10千伏以下电压等级接入，且单个并网点总装机容量不超过6兆瓦的分布式电源。

第二类：35千伏电压等级接入，年自发自用大于50%的分布式电源，或10千伏电压等级接入且单个并网点总装机容量超过6兆瓦，年自发自用电量大于50%的分布式电源。

第五条 接入点为公共连接点，发电量全部上网的发电项目，小水电，除第

一、二类以外的分布式电源，本着简便高效原则做好并网服务，执行国家电网公司常规电源相关管理规定。

第六条 分布式电源发电量可以全部自用或自发自用余电上网，由用户自行选择，用户不足电量由电网提供;上、下网电量分开结算，各级供电公司应均按国家规定的电价标准全额保障性收购上网电量，为享受国家补贴的分布式电源提供补贴计量和结算服务。

第七条 分布式光伏发电、分布式风电项目不收取系统备用容量费;对分布式光伏发电自发自用电量免收可再生资源电价附加、国家重大水利工程建设基金、大中型水库移民后期扶持资金、农网还贷资金等4项针对电量征收的政府性基金。其他分布式电源系统备用容量费、基金和附加执行国家有关政策。

第八条 公司在并网申请受理、项目备案、接入系统方案制定、设计审查、电能表安装、合同和协议签署、并网验收与调试、补助电量计量和补助资金结算服务中，不收取任何服务费用。

第二章 管理职责

第九条 总部营销部负责贯彻落实国家新能源发展相关政策规定，负责制定分布式电源并网服务管理规则，对分布式电源并网服务工作开展情况进行统计、分析、监督、检查，协调解决分布式电源并网服务过程中存在的矛盾和问题。

总部发展部负责分布式电源接入管理，负责制定接入系统技术标准和规则，对分布式电源接入系统方案编审工作开展情况进行监督、检查;总部运检部负责制定分布式电源电网设备建设、实验、运维、检修相关标准并对落实情况进行监督、检查;国调中心负责制定分布式电源并网调度运行管理相关规定，并对落实情况实施监督、检查;总部财务部负责制定分布式电源电价管理相关规定，并对可再生能源补贴资金结算情况进行监督、检查;总部交易中心负责制定分布式电源上网交易管理规定。总部其他相关部门履行公司规定的专业管理职责。

第十条 省公司营销部负责细化本单位分布式电源并网服务管理要求，制定分布式电源并网服务实施细则及考核办法，负责本单位分布式电源并网及运营管理工作。

省公司发展部、财务部、运检部、调控中心、交易中心负责细化本专业分布式电源管理要求并对落实情况进行监督、检查。省公司其他相关部门履行公司规定的专业管理职责。

第十一条 地市/区县公司营销部(客户服务中心)负责分布式电源并网服务归口管理;负责受理辖区内分布式电源并网申请、组织开展现场勘查、组织审查380(220)伏接入系统方案、答复接入系统方案、答复35千伏及10千伏接入电网意见函、组织审查项目设计文件、安装电能表、组织配合380(220)伏接入项目并网验收与调试、安排380(220)伏接入项目并网运行、组织合同会签等。

地市/区县公司发展部负责组织35千伏、10千伏接入系统方案审查，出具接入电网意见函，参与380(220)伏接入系统方案审查，参与设计文件审查工作。地市/区县公司运检部负责组织实施分布式电源接入引起的公共电网改造工程，

参与现场勘查、接入系统方案和设计文件审查、并网验收与调试工作。地市/区县公司调控部门负责签订35千伏、10千伏接入项目并网调度协议，负责组织35千伏、10千伏接入项目并网验收与调试;参与接入系统方案和设计文件审查、380(220)伏接入项目并网验收调试工作。地市公司经研所负责制定接入系统方案，参与现场勘查，接入系统方案评审。地市公司其他相关部门履行公司规定的专业管理职责。

第三章 受理申请与现场勘查

第十二条 地市/区县公司营销部(客户服务中心)负责受理分布式电源业主(或电力用户)并网申请。各级供电公司应提供营业厅等多种并网申请渠道，并做好95598热线电话和95598智能互动服务网站受理业务的支撑。

第十三条 地市/县公司营销部(客户服务中心)受理客户并网申请时，应主动提供并网咨询服务，履行“一次告知”义务，接受、查验并网申请资料，协助客户填写并网申请表(见附件6),并与受理当日录入营销业务应用系统。

地市公司营销部(客户服务中心)负责将相关的申请资料存档，并送地市公司发展部，地市公司发展部通知地市公司经研所(直辖市公司为经研院，下同)制定接入系统方案，工作时限：2个工作日。

第十四条 地市/区县公司营销部(客户服务中心)负责组织地市公司发展部、运检部(检修公司)、调控中心、经研所等部门(单位)开展现场勘查。并填写现场勘查工作单，工作时限：2个工作日。

第四章 接入系统方案制定与审查

第十五条 地市公司经研所负责按照国家、行业、企业相关技术标准及规定，

参考《分布式电源接入系统典型设计》制定接入系统方案。工作时限：第一类30个工作日(其中分布式光伏发电单点并网项目10个工作日，多点并网项目20个工作日;第二类50个工作日。

第十六条 对于自然人利用自有宅基地及其住宅区域内建设的380/220伏分布式光伏发电项目，各单位可根据本地实际情况编制典型接入系统方案模板。地市/区县公司营销部(客户服务中心)在组织现场勘查时，根据典型接入系统方案模板，与客户确定接入系统方案，并抄送发展、运检等部门备案。

第十七条 地市公司营销部(客户服务中心)负责组织相关部门审定380/220伏分布式电源接入系统方案，并出具评审意见。工作时限：5个工作日。

第十八条 地市公司发展部负责组织相关部门审定35千伏、10千伏接入项目(对于多点并网项目，按并网点最高电压等级确定)接入系统方案，出具评审意见、接入电网意见函并转入地市公司营销部(客户服务中心)。工作时限：5个工作日。

第十九条 地市/区县公司营销部(客户服务中心)负责将接入系统方案确认单(附件7)，35千伏、10千伏项目接入电网意见函(附件8)告知项目业主。工作时限：3个工作日。

第二十条 对于380/220伏接入项目，在项目业主确认接入系统方案后，地市公司营销部(客户服务中心)负责将接入系统方案确认单及时抄送地市公司发展部、财务部、运检部(检修公司)、项目业主根据确认的接入系统方案开展项目核准(或备案)和工程建设等工作。

第二十一条 对于35千伏、10千伏接入项目，在项目业主确认接入方案后，地市公司发展部负责将接入系统方案确认单、接入电网意见函及时抄送地市公司财务部、运检部(检修公司)、营销部(客户服务中心)、调控中心、信通公司，并报省公司发展部备案。项目业主根据接入电网意见函开展项目核准(或备案)和工程设计等工作。

第二十二条 公司为自然人分布式光伏发电项目提供项目备案服务，对于自然人利用自有住宅及其住宅区域内建设的分布式光伏发电项目，地市公司发展部收到项目接入系统方案确认单后，根据当地能源主管部门项目备案管理办法，按月集中代自然人项目业主向当地能源主管部门进行项目备案，备案文件抄送地市公司财务部、营销部(客户服务中心)。

第五章 并网工程设计与建设

第二十三条 项目业主自行委托具备资质的设计单位，按照答复的接入系统方案开展工程设计。

第二十四条 地市/区县公司营销部(客户服务中心)负责受理项目业主设计审查申请，接受并查验客户提交的设计文件(附件9),审查合格后方可正式受理。

第二十五条 在受理客户设计审查申请后，地市公司营销部(客户服务中心)负责组织地市公司的发展部、运检部(检修公司)调控中心等部门(单位)，依照国家、行业标准以及批复的接入系统方案对设计文件进行审查，并出具审查意见(附件10)告知项目业主，项目业主根据答复意见开展接入系统工程建设等后续工作。工作时限：10个工作日。

第二十六条 因客户自身原因需要变更设计的，应将变更后的设计文件提交供电公司，审查通过后方可实施。

第二十七条 由用户出资建设的分布式电源及其接入系统工程，其设计单位、施工单位及设备材料供应单位由用户自主选择。承揽接入工程的施工单位应具备政府主管部门颁发的承装(修、试)电力设施许可证、建筑业企业资质证书、安全生产许可证。设备选型应符合国家与行业安全、节能、环保要求和标准。

第六章 电网配套工程建设

第二十八条 地市/区县公司负责分布式电源接入引起的公共电网改造工程，包括随公共电网线路架设的通信光缆及相应公共电网变电站通信设备改造等建设。其中，对于纳入公司综合计划的公共电网改造工程，执行公司现行项目管理规定;对于未纳入的，由地市公司运检部(检修公司)在项目业主确认接入系统方案后，组织地市公司经研所完成公共电网改造工程项目建议书，提出投资计划建议并送地市公司发展部，地市公司发展部安排投资计划并报省公司发展部、财务部备案。工作时限：20个工作日。

第二十九条 在收到地市公司项目建议书和投资计划备案后，省公司发展部会同财务部完成ERP建项。工作时限：5个工作日。

第三十条 在省公司完成ERP建项后，地市公司运检部(检修公司)按照公司工程建设管理程序先行组织工程实施，以满足分布式电源接入电网需求。

第七章 并网验收与调试

第三十一条 地市/区县公司营销部(客户服务中心)负责受理项目业主并网验收与调试申请，协助项目业主填写申请表(附件11)接收、审验、存档相关资料(附件12)，并报地市公司运检部(检修公司)、调控中心。工作时限：2个工作日。

第三十二条 地市公司营销部(客户服务中心)负责按照公司统一格式合同文本办理发用电合同签订工作。其中，对于发电项目业主与电力用户为同一法人的，与项目业主(即电力用户)签订发用电合同;对于发电项目业主与电力用户为不同法人的，与电力用户、项目业主签订三方发用电合同。地市公司调控中心负责起草、签订35千伏及10千伏接入项目调度协议。合同提交地市公司财务、法律等相关部门会签。其中，自发自用余电上网的分布式电源发用电合同签订后报省公司交易中心备案。工作时限：8个工作日

第三十三条 地市/区县公司营销部(客户服务中心)负责电能计量表计的安装工作。分布式电源发电出口以及与公用电网的连接点均应安装具有电能信息采集功能的计量表，实现对分布式电源的发电量和电力用户上、下网电量的准确计量。分布式电源并网运行信息采集及传输应满足《电力二次系统安全防护规定》等相关制度标准要求。工作时限：8个工作日。

第三十四条 电能计量表安装完成、合同与协议签订完毕后，地市/区县公司负责组织分布式电源并网验收、调试工作。其中：

35千伏、10千伏接入项目，地市公司调控中心负责组织相关部门开展项目并网验收工作，出具并网验收意见(附件13)，并开展并网调试有关工作，调试通过后直接转入并网运行;380(220)伏接入项目，地市/区县公司营销部(客户服务中心)负责组织相关部门开展项目并网验收及调试，出具并网验收意见附件(13)，验收调试通过后直接转入并网运行。若验收调试不合格，提出整改方案。工作时限为10个工作日。

第八章 检查与考核

第三十五条 建立分布式电源并网服务常态稽查机制。各级营销部门要全过程督办分布式电源并网各环节工作进度，对各相关部门(单位)业务环节完成时限进行考核。

第三十六条 国网客服中心应建立分布式电源并网服务关键环节过程回访机制，开展业主回访和满意度调查，定期提出改进分布式电源并网服务工作的建议。回访率应达100%。

第三十七条 建立健全分布式电源项目并网服务责任追究制度，对分布式电源并网服务工作过程中造成重大社会影响的事件，应严格追究责任。

第九章 附则

第三十八条 各省(自治区、直辖市)电力公司根据本规则编制分布式电源并网服务实施细则和作业指导书，并参照本规则制定具体考核办法。

第三十九条 本规范由国家电网公司营销部负责解释并监督执行。

第四十条 本规范自发布之日起施行。本规则施行前已经受理的分布式电源项目，可继续执行《国家电网公司分布式电源并网服务管理规范》(国家电网营销[2013]436号)有关规定。

第五篇：分布式环保档案信息资源共享系统研究

诸云强/徐敏/朱琦/冯敏/宋佳/杜佳

2012-11-7 16:50:28 来源：《档案学通讯》(京)2011年4期

【英文标题】On Information Resource Sharing System of Distributed Environmental Archives

【作者简介】诸云强(1977-)，男，博士，中国科学院地理科学与资源研究所资源与环境信息系统国家重点实验室副研究员，主要研究方向：地学信息共享，出版专著1部，发表论文30余篇;徐敏，朱琦，环境保护部信息中心(北京 100029);冯敏，宋佳，杜佳，中国科学院地理科学与资源研究所资源与环境信息系统国家重点实验室(北京 100101)。

【内容提要】环保档案信息资源共享对于环保档案信息资源的开发利用与流动增值，服务于探索环保新道路具有重要的意义。本文在充分总结国内外环保档案信息化管理与共享研究的基础上，对环保档案信息资源共享的需求进行了详细的分析。

Environmental Protection Archival Information Resources (EPAIR) sharing is very important for developing & using EPAIR and to promote its values. It will strong support exploring new road of environmental protection enterprise. Based on summarizing the progress of EPAIR management and sharing at home and abroad, this paper analyzes in detail the requirements of EPAIR sharing which includes functional and security requirements.

【关 键 词】环保档案/信息资源共享/需求分析Environmental protection archives/Information resources sharing/Requirement analysis

1 前言

环保档案信息资源共享已经引起了环境保护行政主管部门和学术界的重视。2009年环保部专门召开环保档案专题会，强调要实现环保档案的信息化、数字化、规范化、标准化和高效利用。2010年5月，时隔16年全国环保系统档案工作会议在广东东莞召开，环保部周建副部长在讲话中指出：环保档案资源是民生资源、社会资源、政府资源和公共资源，要努力开发应用环保档案资源，拓展资源效益，搭建平台，共享信息成果等[1]。国内学者在充分认识环保档案特点(来源广泛性、内容综合性、时空特征性和应用久远性等)的基础上，指出环保档案信息资源的价值和重要作用(准确可靠的决策依据、真实有效的凭证作用、巨大的潜在性效益等)[2][3]，呼吁要更新观念、提高认识，调整服务方式、拓宽服务渠道，充分利用信息化的手段，处理好开发利用和保密的关系，大力提升环保档案信息资源利用的水平[4][5]。

为了规范数字资源长期保存系统，美国国家航空航天局(NASA)提出了开放档案信息系统(OAIS)。OAIS是一种致力于数字信息长期保存和利用的参考模型和基本框架体系，规定了数字信息长期保存系统的功能模型、信息模型、互操作模型和长久保存的管理策略[6][7]。基于OAIS，许多组织和公司开发了一系列富有特色的成果。如美国国会图书馆领导实施的“国家数字信息基础设施和保存计划(NDIIPP)”、加利福尼亚大学的数字保存仓储(DPR)、荷兰国家图书馆的长期存储和大规模电子出版物的e-Deport系统以及澳大利亚的ADRI项目等，国内北京东方飞扬软件股份有限公司的ESOAIS数字档案馆系统、国家图书馆的保存元数据方案、北京大学数字图书馆研究所等提出的中文元数据标准框架、中科院数字档案馆建设等等。欧美发达国家档案界提出并采用档案编码著录规则(Encoded Archival Description, EAD)。EAD基于SGML(Standard Generalized Markup Language)，通过DTD(Document Type Definition)定义档案文献的结构和内容，可以不经转化将文献直接在网上进行发布，以此规则编码的档案检索工具可在任何计算机平台上进行查寻、检索、显示、交换[8]。国际档案理事会提出了电子文件管理软件设计的原则和功能需求[9][10]。提出电子文件管理软件系统应该遵循的8大原则，包括：软件平台必须以标准化的元数据为核心，确保软件系统跨平台、跨域的互操作，采用开放的标准和保持技术的中立，具有利用开放格式进行大批量导入和输出的能力，必须确保信息资源的安全，尽可能自动产生元数据以及软件系统必须易于使用等。同时，规定了电子文件创建(捕获、标识、分类)、维护(控制安全、融合、保留、迁移、处置)、分发(搜索、获取、可视化)和管理四大功能模块。

上述研究主要集中在档案的长期保存、管理和访问上，即使是OAIS提出的六大功能模型(收集、存储、管理、保存规划、访问、系统管理)中缺乏对于跨单位的档案交换和共享功能的专门描述。因此，在这样的背景下，开展分布式环保档案信息资源共享系统的研究具有重要的意义。本文依托环保公益性行业科研项目：环保档案信息资源共享框架构建关键技术与示范研究，将对分布式环保档案信息资源共享系统的内涵特征、总体架构、功能体系和部署应用模式进行详细的讨论。

2 环保档案信息资源共享需求分析

信息共享是指在一定程度的开放条件下，同一信息资源为不同用户共同使用的服务方式[11]。何建邦等认为：从信息共享的表象看，共享是信息的共同使用，但从信息共享的本质特征上看，信息共享必须解决信息质量最优化，共享程度最高效等实质问题，其核心是需要对信息技术进行不断创新，对使用规则进行共同约定[12]。因此，环保档案信息资源共享不仅包括环保档案信息资源的交换、共享访问，而且还应包括为提高环保档案信息资源质量的著录管理过程。

2.1 环保档案信息资源共享功能需求

根据《环境保护档案管理办法》规定：县级以上地方各级环境保护行政主管部门对本辖区环境保护档案工作实施监督管理，并在业务上受上级环境行政主管部门和同级档案行政主管部门的监督、指导和检查。因此，环保档案信息资源共享功能需求主要体现在以下几个方面：

本单位内部员工能够按照权限进行本部门环保档案信息资源的著录、归档、管理，对本单位环保档案信息资源进行检索和按权限的访问、查阅。

环境保护行政主管上级部门需要查看到下级单位环保档案信息资源的目录及元数据信息，以便能够全面准确地了解、掌握下级单位环保档案信息资源的状况，方便对下级单位环保档案工作的监督和检查。

下级单位也希望能够实时接收到上级单位相关的环保档案信息资源，特别是文书档案。

环保系统不同行政区划的同级单位也存在相互调阅环保档案信息资源的需求，特别是开展跨区域的合作研究、发生跨区域环境污染事故时，希望能够快速调阅相关的档案信息。

其他部委的相关单位或社会公众希望能够查看对外公开的环保档案信息资源。

2.2 环保档案信息资源管理功能需求

当前，我国各省采用的环保档案管理系统并不统一，甚至于在县市层面大部分还没有对环保档案进行信息化管理，更缺乏与共享系统一体化的管理系统。因此，想要开展全国一盘棋的环保档案共享，首先要解决环保档案信息资源管理的问题。环保档案信息资源管理的功能需求主要包括：

环保档案著录归档管理权限设置。对环保档案信息资源著录、归档、管理的人员及其权限进行分配。

环保档案著录模板设置。对不同级别(文件级、卷宗级等)或不同类别(文书、科技、多媒体等)的环保档案的著录元数据项进行设置。

环保档案著录。利用计算机系统录入分类、分级的环保档案元数据信息，以及档案全文原件及其附件信息。可以单条记录录入，也可以批量导入(如自动接收电子政务平台或业务系统中已有的文书或业务文件信息)。

环保档案归档。对已著录的档案进行完整性、规范性、安全性等方面的审查，确定保管期限进行归档。

环保档案查询借阅。按权限进行环保档案的查询检索，在线浏览或离线借阅等。

环保档案统计分析。可以按照类别、、处室等对环保档案进行统计。

2.3 环保档案信息资源共享安全需求

环保档案作为对国家和社会有保存价值的各种文字、图表、声像等不同形式的历史记录，涉及国家安全和社会稳定。因此，在环保档案信息资源共享利用过程中，必须要处理好安全的问题，要做到内外有别，对未公开档案一定要把好关，严格掌握。以维护国家的根本利益[4]。根据《环境保护档案管理办法》规定：“环保部门保存的档案主要供本部门利用。其他系统或部门的工作人员查阅档案时，需持本单位介绍信，说明利用目的和范围，并经环保部门有关负责人批准后方可查阅。查阅涉及党和国家秘密的环境保护档案必须经过分管档案工作的行政领导及保密部门批准;查阅未公开的档案，必须经过有关业务部门负责人批准;摘录和复制档案，必须经过环保档案管理机构负责人批准。”因此，环保档案信息资源共享的安全需求主要包括：

本单位内部员工根据授权的用户名和密码及权限，可以查看档案目录及相应的全文及附件信息。用户名和密码仅在本单位局域网中使用，在公网上不可以使用。

环保行政主管部门上下级之间的档案信息资源交换只进行目录级、元数据的交换。根据“环保档案信息资源交换管理办法”(需要环境保护行政主管部门制定)各单位可以控制交换哪些档案目录和元数据，其他单位只能看到档案目录和元数据，而不能浏览档案全文。环保系统档案信息资源的交换基于环保政务专网进行。

对于没有到开放期限的环保档案，只公开档案的目录。合法公民和组织经系统身份验证后可查询未开放的档案目录，以及已经开放的环保档案全文信息。环保档案信息资源的公开，需要单独设置公开库，环保档案公开库与环保档案内部全集库要进行物理上的隔离，公开库放置在外网，环保档案库放置在内网或专网上。

注释：

① 环保档案信息资源共享需求，主要基于对环保部办公厅文档处，以及在全国环保系统档案工作会议上对各省市环保档案管理部门的调研整理形成。

【参考文献】

[1]蔡方，曹金庆.全国环保系统档案工作会议召开[N].中国环境报，2010(5).

[2]吴文超.环境保护档案的特点及开发利用[J].山东环境，2000(增刊)：32-33.

[3]孙青霞.合理开发环保档案信息资源为改善环境质量和经济建设服务[J].山东档案，2001(2):16-18.

[4]史海珠.环保档案的开发利用初探[J].青海环境，1992,2(4):165-167.

[5]杨玉莲，王新梅，姜桂清.环保档案信息的开发与利用[J].黑龙江环境通报，1997,21(1):66-67.

[6]钱毅.OAIS对数字档案馆系统技术路线和管理策略的启示[J].档案学研究，2009(4):46-49.

[7]CCSDS, NASA. Reference Model for an Open Archival Information System(OAIS)[R]. CCSDS 650.0-B-1 BLUE BOOK. 2002.

[8]徐维.EAD-构架档案资源网上共享的桥梁[J].中国档案，2000(9):45-47.

[9]ICA. Principles and functional requirements for records in electronic office environments MODULE 1-Overview and statement of principles. International Council on Archives. 2008[OL]. http: ///sites/default/files/ICA% 20Overview-principles%20and%20Functional%20Requirements%20Module%201.pdf.

[10]ICA. Principles and functional requirements for records in electronic office environments MODULE 2 Guidelines and functional requirements for electronic records management systems. International Council on Archives. 2008[OL]. http://www.ica. org/sites/default/files/ICA-Guidelines-principles% 20and% 20Functional%20Requirements%20Module%202.pdf.

[11]诸云强.地球系统科学数据共享关键技术研究[M].北京：科学出版社，2009.

[12]何建邦，闾国年，吴平生.地理信息共享的原理与方法[M].北京：科学出版社，2003.