非结构化问题

2024-05-04

非结构化问题(精选九篇)

非结构化问题 篇1

由于变后掠翼可以更好地解决高、低速性能要求的矛盾, 是现代飞机设计的一个重要途径, 所以选此作为研究对象, 进行初步探索性研究。

机翼变后掠流场的求解包含运动边界的非定常复杂流场, 是计算流体力学中的难点。非结构动网格技术 (DUT) 是在非结构网格框架下求解此类问题的关键。目前国内外发展的可靠性较高的网格变形方法主要有弹簧近似方法[1]和弹性体方法[2], 弹性体方法的网格变形能力强且网格质量较高, 但计算工作量大;弹簧近似方法则比较简单、高效, 但网格变形能力不如弹性体方法。

通过对弹簧近似方法的改进, 使弹簧近似方法在保持原有计算效率的前提下, 网格变形能力和网格质量得到大大的提高。最后, 将发展后的非结构动网格生成方法与ALE形式的流场解算器耦合起来, 求解了包含运动边界的、模拟上述机翼运动状态下的亚, 跨音速绕流, 并对结果进行了分析。

1 弹簧近似方法

根据Blom[3]的定义, 弹簧近似方法有两种描述方法, 一种是弹簧的平衡长度为零, 称为顶点弹簧 (Vertex springs) ;另一种是弹簧的平衡长度等于边界未运动和变形前边的原长, 称为棱边弹簧 (Segment springs) 。

传统的顶点弹簧近似方法一般用于网格优化, 弹簧倔强系数取为常数, 网格点移动后的新位置坐标相当于周围点坐标的平均。现对这一经典方法进行了修改, 使其更适于实现网格变形运动。下面给出修改后的顶点弹簧近似方法。对于顶点弹簧, 节点i, j间的弹簧张力可以写为:

Fij=Κij (rj-ri) (1)

(1) 式中Kij为连接节点i, j的弹簧的倔强系数;ri, rj分别为节点i, j的位置矢量。对任意的一个节点i, 它的合力方程为

Fi=j=1ΝiΚij (rj-ri) (2)

(2) 式中Ni为计算区域内所有与节点i相连的非结构网格的节点总数。不同于网格优化的情况, 修改后的顶点弹簧方法, 令计算区域内所用网格节点的受力都为边界没有发生运动和变形时所受的合力。对计算区域内所有的m个非结构网格的节点, 列上述合力方程, 得到初始状态下的该线性系统的矩阵表达式

[-j=1ΝiΚ1jΚ1jΚ1ΝΚi1-j=1ΝiΚijΚiΝΚm1Κmj-j=1ΝiΚmj]×[r1rirΝ]=[F1FiFm] (3)

(3) 式中Ni为包括边界点的网格节点数。当边界运动或变形后, 通过改变边界的位置矢量和适当的整理, (3) 式就得到一个m阶的线性方程组。由于该线性方程组的刚度矩阵对称正定, 则求解的Gauss-Seidel迭代法关于任意初始向量均收敛。其相应的分量迭代格式为:

ri (k+1) =1Κii[Fi-j=1i-1Κijrj (k+1) -j=i+1mΚijrj (k) ] (i=1, 2, , m;k=0, 1, 2, ) (4)

当边界变形或运动到n+1时刻, 利用 (4) 式经过数次迭代, 便可以达到需要的精度, 得到n+1时刻的网格点的位置。

2 弹簧倔强系数的选择

2.1 标准方法

标准的弹簧近似方法大都选取网格边的边长为参考量来确定弹簧的倔强系数, 大量数值试验表明, 对于二维或三维网格, 弹簧倔强系数按 (3) 式取, 能较好地保持网格的疏密特征。

Κspringij=1lij2 (5)

(3) 式中lij为网格边的边长。于是当lij→0时, Kspringij→∞。这样便很好地保证了任意的网格节点i, j不会碰撞。

2.2 方法改进

标准的弹簧近似方法仅仅考虑了弹簧在直线方向的伸缩作用, 在二维或三维时, 并不能保证避免网格边的互相交叉。而且, 在用标准的弹簧近似方法处理相对大一些的边界运动和变形时, 就会产生体积为负的“无效”网格单元。为了防止产生这种“无效”网格单元, 就必须在弹簧倔强系数中引入单元几何形状的变量。因此, 在实际计算中对 (5) 式稍作改变, 成为 (6) 式。

Κspringij=1Vminlij2 (6)

(6) 式中Vmin为拥有网格边ij的所有单元中, 体积最小的单元。当Vmin→0时, Kspringij→∞。这样就保证了与网格边ij相对的所有单元中体积最小的单元不会成为体积为负的“无效”网格单元。

为了防止挤压, 已有的四面体单元及四面体中的三角形面元, 必须考虑挤压弹簧倔强系数。挤压弹簧倔强系数计算的具体公式为

Κsquashij=1sin2θ (7)

(7) 式中θ为网格边ij所对应的三角形内角, 以及网格边ij所对应的四面体单元所夹内角, 如图1所示。当θ→0或θπ时, Ksquashij→∞。这样就避免了挤压已有四面体及三角形面元。

此外, 一些文献把采用弹簧近似方法调整网格点位置的方法, 与椭圆型结构网格生成方法比较。认为, 此种方法也具有椭圆型方法的性质, 即局部的扰动只在局部产生影响。计算也证明了这一点, 最早出现网格变形失败的单元, 就是在运动边界附近。为减小这一性质的影响就必须使弹簧的倔强系数沿内边界到外边界的径向方向合理分布。因此, 我们引进弹簧倔强系数的径向分布系数Kd, 称之为边界修正。

经过上述的改进和修正, 最后得到总的弹簧系数为:

Κij=Κd (Κspringij+Κsquashij) (8)

(8) 式中Kd=1/d, d为计算区域内的点到物面的最小距离。改进后的方法与标准方法的对比结果如图2所示, 图2 (a) 是标准方法的结果, NACA0012翼型绕1/4弦点偏转35度, 尾部已经出现失败。图2 (b) 是对同一问题使用改进后的方法, 此时翼型偏转到50度, 网格质量仍然较好。

3 动网格方法的应用

3.1 控制方程

ALE (Arbitrary Lagrangian-Eulerian ) 有限体积描述下的三维可压缩Euler方程可表示为如下的积分形式:

tΩQdV+ΩF (Q) ndS=0

Ω是控制体, ∂Ω是控制体边界, n为控制体边界外法向单位向量, 守恒项和对流项分别为

Q=[ρρuρvρwe]ΤF (Q) n= (Un) [ρρuρvρwρe+p]Τ+p[0nxnynzat]Τ

其中U为流体相对于网格的速度, at为网格运动的法向速度, nx, ny, nz是n的3个分量。

xt, yt, zt分别是网格运动速度的3个分量。空间离散采用格心格式的有限体积法, 时间离散采用Jameson[4]提出的双时间方法, 几何守恒律及刚体动力学模型可参考文献[5,6]。

3.2 算例

3.2.1 简谐振动NACA64A010的跨音速绕流

所计算的机翼剖面形状为NACA64A010, 转动轴定在50%的弦长位置处, 马赫数Ma=0.796, 瞬间迎角α (t) 的运动方程为:α (t) =α0+αmsin (wt) , 式中平均攻角α0=0.0°, 最大振幅攻角αm=1.01°, 减缩角频率K=0.202。为了得到稳定的周期解, 计算了6个周期。

3.2.2 M6机翼变后掠的跨音速绕流

采用的模型是一种以M6机翼为原型的理想的不产生扭转变形可任意拉伸的柔性机翼, 其运动方式是攻角和翼根固定, 翼稍截面向后平移, 机翼自由拉伸, 其展长与弦长不变, 机翼面积也不变。选机翼前缘后掠角为起始角, 在此基础上向后偏转20度, 马赫数Ma=0.80, 总时间T=2.0秒, 攻角a=3.00°。

3.3 结果分析

图3, 图4分别给出了NACA64A010瞬间总升力系数CL和瞬间总力矩系数Cm (力矩作用点为50%弦长处) 随瞬间迎角变化的曲线, 图5给出了在第6周期内8个均分点处的瞬间压力系数分布。图6给出机翼起始和后掠20度后的状态, 图7给出了M6机翼总升力系数随后掠角变化曲线, 图8给出了总力矩系数随后掠角变化曲线。

计算的结果与实验结果吻合良好, 所发展的按弹簧近似的非结构动网格技术与有限体积格式流场解算器相结合, 是一种求包含象机翼变后掠这样的运动边界的三维非定常复杂流场的有效方法。

4 小 结

二维机翼谐和振动结果表明, 本文所发展的弹簧近似方法, 在不降低计算效率的同时, 可以大大提高网格的变形能力和网格质量, 很好地解决了非结构动网格技术中关键的网格变形问题。研究结果表明, 本文所发展的非结构动网格技术及适用于动网格的非定常有限体积解算器具有很高的精度和很强的适用性, 适用于模拟流体与结构耦合等复杂非定常流动问题。

参考文献

[1] Batina J T.Implicit flux-split Euler schemes for unsteady aerodynam-ic analysis involving unstructured dynamic meshes.N91-10918, 1990

[2] Teaduyar T E, Behr M, Liou J.A new strategy for finite elementcomputations involving moving boundaries and interfaces—The defor-ming-spatial-domain/space-time procedure:I.The concept and thepreliminary numerical tests.Computer Methods in Applied Mechacicsand Engineering, 1992;94:339—351

[3] Blom F J.Considerations on the spring analogy.Journal of Aircraft, 2000;32:647—668

[4] Jameson A.Time dependent calculation using multigrid with applica-tions to unsteady flows past airfoils and wings.AIAA paper 1991;91—1596

[5] Hwang C J, Yang S Y.Locally implicit total variation diminishingschemes on mixed quadrilateral-triangular meshes.AIAA Journal, 1993;31 (11) :2008—2015

非结构化问题 篇2

1 非结构构件的定义与分类

所谓非结构构件,是指一般不属于构件的主要结构,包括施工中非结构构件和建筑附属机电设备两大类。非结构构件的构造分为三类,第一类是结构组件(例如,女儿墙、雨篷、跨级密封墙),第二类装饰品(如,贴面、顶棚、悬吊重物等)、第三种类型非结构墙体(例如,内隔墙、挡土墙、框架填充墙)。

2 非结构构件地震破坏的原因

非结构构件在地震时遭受破坏的主要原因有两个,即惯性力作用和结构系统变形.地震时,房屋的各个部分均受到惯性力的作用.非结构构件的滑移或倾斜程度以及所承受地震侧力的大小,均影响其使用或安全.因此在设计时必然要考虑到这种惯性力的作用.另外,当结构系统受到地震作用后,发生变形,改变原来的几何形状.强烈的地震时,建筑顶层侧移很大,窗户、填充墙等嵌在结构构件内的非结构构件,可能因不适应整体结构的变形,发生破碎、掉落,出现裂缝,甚至倒塌.由此可见,除了考虑非结构构件所受到的惯性力外,还须考虑结构系统在地震时的变形对其可能的影响。

3 非结构构件地震反应分析方法

规范给出了非结构构件的水平地震作用的计算方法有等效侧力法及楼面反应谱法,二者的计算公式如下:

等效侧力法水平地震作用计算公式:F=yηζ1ζ2amaxG

楼面反应谱法水平地震作用计算公式:F=yηβsG

在这两个公式当中,F表示的是沿最不利方向施加于非结构构件重心处的水平地震作用标准值;Y表示的是非结构构件功能系数;η表示的是非结构构件类别系数;G表示是非结构构件的重力;ζ1表示的是状态系数;ζ2表示的是为位置系数;amax表示的是地震影响系数最大值;βs表示的`是非结构构件的楼面反应谱值。

等效侧力法对只在一个楼层有支点的附属系统,称为单支点系统,为简化计算通过对大量建筑不同楼层上的不同周期的附属系统反应的计算结果进行统计,直接给出附属系统的地震作用简化公式。楼板反应谱是在结构设计中的地面反应谱,这反映了非承重结构构件的动力特性本身,非结构构件的楼层位置,以及结构和非结构阻尼特性的地震地面运动放大。当楼层反应谱法进行时,非结构部件通常采用单点模型。两个计算公式的区别在于地震动力大小的估算,当弹性的或弹性连接的附属系统的重力超过所在楼层的1%,或与建筑物刚接的刚性附属系统的重力超过所在楼层的10%时,不宜使用等效侧力法,而宜采用楼面谱程序计算附属系统的地震力。所以我们通常采用楼面反应谱法进行计算。而规范地给出楼层反应谱,不包含主系统的辅助系统,作为输入和要求有不同的自然周期振动的单自由度系统的响应频谱,其优点是解耦,避免了主要解决系统的运动方程。但由于它没有考虑子系统与主系统之间的相互作用等四个因素,造成的地板谱有较大的误差,在某些情况下,误差可以是多次的。 这四个影响因素包括了:

质量比。当附属系统与主系统楼层的质量比大于0.001时,附属系统对主系统相应楼层的反应有明显影响。

谐振。当子系统的自振周期与主系统自振周期相等或接近时,系统会发生强相互作用,“减振器效应”,则附属系统出现强烈的振动,而主系统反应,大大减弱,也主要系统的自振周期将发生转变。

非经典阻尼。当系统与主系统的阻尼特性不一致时,组合系统具有非经典阻尼特性。在共振的情况下,它的影响是不容忽视的。在这个时候,阻尼矩阵不是对角矩阵,形成一个阻尼耦合运动方程,不能用基于杜哈妹积分叠加法求解。

多支座激励。当附属系统在主系统不同楼层有支点时,不同支点间的相互运动还会引起附属系统中的附加内力,即‘伪静力效应。

为克服规范中所述的楼面反应谱法的缺点,应在基于求解由主系统和安装在不同楼层上的单自由度附属系统组成的组合系统中附属系统的地震反应,这样就综合考虑了上述四个因素的影响。从而得到更可靠的楼面反应谱计算结果。为建立楼面反应谱,把自振周期设在0~6s范围内的附属系统的地震反应,用时程积分法求解,对不同的地震记录,不同周期的附属系统,积分求解组合这包含极大的工作量。采用滤波白噪声表示地面运动,用随机振动法通过峰值系数直接得到楼面反应谱。 研究楼面反应谱的目的是为附属系统的抗震设计提供反应谱。有了楼面反应谱,只要知道附属系统本身的自振周期、质量和阻尼,就可查出其地震力,而不需要分析主系统。应当说明,文章所述的非结构构件抗震设计仅限于验算设备的支架、连接件或锚固件的抗震能力,不包括设备自身的抗震能力。

4 各类非结构构件在抗震设计中要注意的主要问题和应采取的措施

我们对非结构构件的抗震问题要有充分的认识,对特定类型的非结构构件,采取针对具体设计,采取措施加强非结构构件的安全性,进一步加强非结构构件节点的细部设计与改进。第一类是附属会员,如女儿墙、雨篷、低交叉密封墙和其他组件。主要的地震问题是防止倒塌,措施是加强结构的整体性,并使之与主体结构可靠锚固连接。第二类为装饰物,如贴面、顶棚、悬吊重物等。主要的地震问题是防止破坏和装饰的主要措施。重要的单板和装饰,也可以用在灵活的连接上,即使主体结构在地震中有较大的变形,也不能损坏和装饰单板。第三类非结构墙体,如内墙、墙、框架墙等。根据材料的不同和主体结构的连接情况,对其主要结构有不同的影响,如:主结构的横向刚度发生改变,结构构件的地震作用内力分布发生变化。主体结构的破坏会导致主体结构的破坏,如局部高度的墙,形成短柱,柱的脆性破坏。第四类是辅助机械和电气设备等,它与建筑物连接,通过支撑、固定,设备应具有足够的刚度和强度,并应与建筑物连接,使该设备能在地震后迅速恢复受地震强度的影响。当然,在机电设备的建设中,应适当的设计,以防止系统的施工和共振现象的发生。

5 结语

非结构构件虽然不是主要结构,但在设计中容易被忽视。但作为工程技术人员,应是非结构构件与主体结构的同等程度的重要程度来提高其重视程度。只要我们继续加强业务学习,提高设计水平,严格按照设计和施工的相关规范,对非结构构件的地震造成的破坏可以减少和避免。

参考文献

[1] 孙俊,刘铮,刘永芳.工程结构基于性能的抗震设计方法研究[J].四川建筑科学研究,2005(03).

[2] 沈章春,王全凤.基于性能抗震设计理论与实用方法[J].四川建筑科学研究,2008(03).

浅析非结构化电子文件 篇3

关键词:非结构化电子文件,电子文件,文件,元数据

众所周知,电子文件是有别于纸质文件的新型文件。从形式上看,有文本文件、图形文件、音频文件、数据库文件等多种类型。然而,在以往的电子文件管理研究中,却忽视了一种重要的电子文件类型———非结构化电子文件。长期以来,非结构化电子文件在电子文件管理中未能给予应有的重视。作为国家标准《电子文件归档与管理规范》起草者之一的邱晓威先生也曾坦言:“《电子文件归档与管理规范》中所指的电子文件主要是公务活动中产生的电子文件,即公文类电子文件。”[1]56很显然,在各业务信息系统中生成的非结构化电子文件不包括在内,管理上存在标准规范的缺失。在一些基层档案部门甚至没有将非结构化电子文件纳入电子文件管理范畴,更多的是将其视为一种电子数据,任其放任自流。为此,十分有必要进一步深化对非结构化电子文件的认识。

一、文件、电子文件与非结构化电子文件

国际档案理事会1984年出版的《档案术语词典》这样定义文件:一是由机关、团体、组织或个人,在履行其法定职责或处理事务中所形成、收到并保存的记录下的信息(文献),其形式和载体不论。二是指自动数据处理中,构成文件基本单元的数据单位,它本身又由若干相关数据字段所组成[2]83。国内的文件定义与国外相比,在本质上是基本一致的。如陈兆祦教授在为《中国大百科全书》条目撰写的释文稿就将其定义为:“文件(record,document)组织或个人为处理事务而制作的记录有信息的材料,是人类记录、固定、传递和储存信息的一种工具。”[3]72上述定义并未对文件的形式和载体做出限制,实质上不论是何种形式、何种载体均可视为文件。不过,这一时期主要是以纸质文件为主体,电子文件并未普及。

1997年国际档案理事会电子文件委员会在《电子文件管理指南》中关于文件定义的表述是:文件是由机构或个人在其活动的开始、进行和结束过程中所产生或接收的记录信息,该记录信息由足以为其活动提供凭证的内容、背景信息和结构所构成,而不管其形式或载体如何[4]51。此后,国内广泛认同文件是由内容、背景和结构三要素组成之说,也就是所谓的文件组成“三要素说”[5]32。当然,这里所说的文件主要是指电子文件。由于电子文件不再具有纸质文件般的实体形态,所以人们逐渐改变以往认识纸张等有形物质载体文件的惯性思维,转向从文件的组成要素揭示这一新型文件的属性。

随着计算机和网络技术的不断发展,电子文件及其结构随之也发生了很大变化,非结构化电子文件的产生正是这种变化的结果。早期在计算机环境下生成的文件是线性的文本组织模式,传统意义上的“份”、“件”概念依然可以沿用,比如在办公系统中形成的公文类电子文件。然而,随着超文本等文件形式的出现,非线性的文本组织模式大大改变了我们早已形成认识习惯的文件结构。例如,非结构化电子文件,一个数据库由若干记录组成,一个记录由若干字段(数据项)组成;既有单个关系数据库的信息,又有来自多个系统平台的有关数据。在薪资管理系统的工资报表、证券交易所的股市行情表等文件都属于该类型。这种复合型文件可能随来源数据的变化而不断变化,已经失去了传统意义上文件实体的概念,而只是一系列动态信息集合[4]51。认识这种相对复杂的文件,已经不能沿用传统的思维和方法。

假如说,从版式固定的公文类电子文件上还可以找到传统文件的身影(或者说形式),那么到非结构化电子文件已经很难发现传统文件的痕迹了。从纸质文件到一般的电子文件再到非结构化电子文件,其形式和载体已经发生了很大变化,很难再从形式和载体来判定或者认识一种新的文件类型。从文件类型的发展历程来看,变的是其外在形式,不变的是其内在本质。虽然非结构化电子文件比较抽象,而且文件结构复杂,多少令人产生一种难以认知的感觉,但是,我们可以通过文件组成三要素来进一步揭示其属性。

二、非结构化电子文件的组成三要素

一般认为,文件是由内容、背景和结构三个要素构成,这可以从国际档案理事会电子文件委员会给文件下的定义中看出。也有学者将元数据纳入文件的组成要素,笔者认为电子文件与元数据之间不是整体与部分的关系,而是一种映射关系。元数据只是对电子文件的一种描述,所以没有将其归入文件的组成要素。

1.内容信息。内容信息是文件之所以成为文件的必要条件。文件的形成必定承载和传递着特定的内容信息,否则它将失去存在的价值。伍振华教授将单份普通公文等(包括简单的电子文件和非电子文件,但不是数据库形态的文件)文件的内容分为:外延最窄的内容(正文所表达的信息)、外延最宽的内容(文件原文信息)和外延居中的内容(文件定稿所表达的信息)三种类型[5]33。一份完整的行政机关公文文件一般都会包含有发文机关标识、发文字号、签发人、标题、主送机关、公文正文、成文日期、抄送机关、印发机关等18项要素。普通公文中反映正文内容的核心信息和其他辅助性信息一目了然,很好辨别。而非结构化电子文件不同于普通公文,首先,传统意义上“份”和“件”的概念已经被淡化,甚至不复存在;再则,其内容的呈现形式已大不同于版式固定、格式统一的公文类电子文件。比如,作为典型的非结构化电子文件———数据库文件是一个动态信息集合,其内容信息的表现方式也相对灵活。所以,我们很难再区分什么是正文信息,什么是定稿信息。实质上,数据库文件中能够完整呈现的所有的动态信息集合体都应该是其内容信息,这也是构建数据库管理数据、文件的应有之意。

2.背景信息。背景信息也是电子文件不可或缺的重要组成部分,是维护电子文件真实性、完整性和有效性的重要保障。国家标准GB/T18894-2002《电子文件归档与管理规范》这样定义背景信息:“描述生成电子文件的职能活动、电子文件的作用、办理过程、结果、上下文关系以及对其产生影响的历史环境等信息。”对于内容和载体固化为一体的纸质文件而言,其本身就已经包含着背景信息。例如,通过纸张等载体信息就很容易判定文件材料形成时间、所反映的文化背景、是否被修改等背景信息。而包括非结构化电子文件在内的电子文件的背景信息,其外延比较繁杂,主要有责任者、形成时间、形成地点、接收者、抄送者、传递日期、接收日期、形成的软硬件条件、系统数据等等[6]52。为了保证背景信息的完整性及其功能的正常发挥,需要特意从文件的制作形成、接收、存储到使用的整个文件生命周期中采集并保存。采集公文类电子文件的背景信息,对功能完善的电子文件管理系统来说是可以实现的。但是,如果处理的对象是结构相对复杂的非结构化电子文件,对其背景信息的采集是有一定难度的。除了要解决异构数据库系统之间的衔接问题之外,还得理顺档案部门与业务部门之间的协作关系,毕竟绝大多数的非结构化电子文件来自于业务部门的业务信息系统,其系统独立性较强。如何更科学地确定电子文件背景信息的内容要素,如何根据不同电子文件的类型划定更具针对性的背景信息,如何将电子文件的背景信息推向标准化,这些都是今后亟待解决的问题。

3.结构信息。“结构信息是指文件内容信息的组成表达方式”[7]5,包括物理结构和逻辑结构两种结构形式。物理结构的具体表现形式为:一是指电子文件线性文本信息在物理存储介质中的组织方式,二是指电子文件非线性文本的各个信息组成部分的不同物理位置[4]50。前者主要是一般性的、简单的电子文件的物理结构,如普通公文类电子文件;后者主要是指结构相对复杂的电子文件的物理结构,如非结构化电子文件等。通常情况下,我们不会太关注电子文件的物理存储位置,尤其是各个信息组成部分分散存储的非结构化电子文件,其物理排列方式、存储位置对用户来说是不透明的,其实也没必要知道。相较于物理结构,我们更关注的是逻辑结构。逻辑结构即用户能够直接看到的文件信息的自身结构,这是最直观的。非结构化电子文件的形成过程实际上是一种将分散的文件要素进行逻辑组合的过程,非结构化电子文件的内容即数据,以数据文件的形式生成、保存,而数据结构的出生地和存储地点是数据字典,文件属性中的常规信息(如文件的创建时间、修改时间和存取时间)均由操作系统负责记录、生成和维护[8]42。可见,非结构化电子文件背后需要一个庞大的逻辑结构作支撑,才能完整地呈现其所表达的内容信息,否则所有的数据都处于无序状态。

三、非结构化电子文件的管理难题

1.元数据管理研究比较滞后。元数据是保证电子文件真实性、完整性、有效性和维系文件间有机联系性的重要工具。人们可以借助元数据来帮助记录电子文件形成时的背景信息和相关的软硬件系统参数,记录文件管理业务活动的有关信息(如文件的起草、修改、定稿、分发)以及相对应的日期时间等等。然而,面对数据库系统中的非结构化电子文件,却很难进行有效的元数据采集和存储。虽然,有关国家标准对文件管理元数据划定了一个总体结构,规定了文件管理实体类元数据的类型和文件管理实体类元数据间的关系,但是,这毕竟是一个顶层的总体结构,无法直接用于非结构化电子文件元数据管理。而且,现有的文件管理元数据研究成果大多是针对普通公文类电子文件,非结构化电子文件元数据管理研究是相对滞后的。国家标准《文件管理元数据原则》将文件管理元数据定义为结构化信息与半结构化信息,其意义实际上就是为了更好地处理文件管理元数据在原则性与灵活性、普遍性与特殊性、通用性与专业性上的辩证关系[9]32。然而在实际当中,我们并没有处理好这种关系。国家标准给了一个总体的固定结构———元数据的结构化信息,是所有文件类型都需要遵循的;但我们却忽视了非结构化信息建设,无法满足不同电子文件类型进行各自具体描述的个性化需求。今后需要加大对非结构化电子文件等不同电子文件类型元数据的管理研究,以实现元数据的标准化。

2.对系统的依赖性更高。电子文件从生成、运转、处理、储存、检索、到传输和利用的各个环节都必须依赖于计算机的软硬件系统。正是电子文件对系统的依赖性,加大了对其的管理难度。文件对系统的依赖性越高,其管理难度也越大。有些非结构化电子文件的内容信息具有高集成性的特点,其多元信息的集成性使得文件的各个部分可以取自并存放在不同的数据库里,多次调用、反复组合,每一次新的集成都是不同的结果、生成不同的逻辑组合产品[8]41。部分非结构化电子文件之所以能够实现内容信息的高集成性,是因为背后有一个强大的系统在支撑,这也使得它对系统的依赖性更高,必须依附于专业的数据库系统才能完整地实现其功能。对普通公文类电子文件的管理,一般在系统设计之初就预先嵌入档案管理的功能模块,以便在电子文件管理系统中更好地实现前端控制和全程管理。而对非结构化电子文件管理来说,目前还是个难题。其中一个很重要的原因就是,非结构化电子文件对专业系统的依赖性很高,无法在通用系统中自由流通。也正因为如此,在对非结构化电子文件进行物理归档、脱机保存时,需要将专用软件系统一并收集归档。

3.难以进行“双套制”管理。对电子文件进行“双套制”管理,将计算机生成的文件转换成纸质文件,更多的是反映了人们对电子文件生存环境的一种担忧,也是一种无奈的最佳选择。不然,在追求效率的文件管理领域,人们没有必要多此一举,采取“双套制”。需要强调的是,实行“双套制”的主要对象是普通公文类电子文件或者一些结构简单的电子文件,其他专业、专用电子文件一般不适用于“双套制”,也无法进行“双套制”。假如说“双套制”能使普通公文类电子文件很好地避开自身在技术上所遇到的,诸如无法长久有效保持档案属性等一系列难题,那么当面对结构复杂、系统依赖性高的非结构化电子文件时,就很难将其完整地转换成另一套———纸质文件。上文也提及过,组成非结构化电子文件内容信息的各个部分是分散储存的,它通过系统强大的逻辑组合功能,可以多次调用、反复组合文件各部分要素,然后集成输出,而且每一次新的集成都可以输出不同的内容。显然,想要将非结构化电子文件中的所有内容信息完整地输出到纸张上并与其数字显示一致是不太现实的。由此可见,“双套制”并不是一把万能钥匙,当遇到复杂的非结构化电子文件时就显得无能为力。

尽管业务信息系统能够处理与其业务相关的信息,但其主要功能并不是对这些信息进行管控。许多业务信息系统设计的目的仅是为了支持和满足当前业务活动对于信息的需求,其功能有限,并不具备对文件进行有效管理的能力,至多能够保存与它们所执行业务交流活动有关的当前文件[10]168。再加上这些非结构化电子文件大多来自于专业性较强的行业或部门,涉及的内容广泛而专业,且相对比较重要。因此,必须加强对非结构化电子文件的管控。

参考文献

[1]邱晓威.关于《电子文件归档与规范》的若干说明——兼与“对《电子文件归档与管理规范》中术语定义的几点建议”作者商榷[J].档案学研究,2004(4).

[2]弗兰克·B·埃文斯,弗朗索瓦·J·安利,彼得·沃尔内·英汉法荷德意俄西档案术语词典[M].丁文进,何嘉荪,方新德,等.编译.北京:档案出版社,1988.

[3]陈兆祦.档案学基础知识[J].档案学通讯,1991(4).

[4]于英香.略论电子文件结构[J].档案学通讯,2005(5).

[5]伍振华.文件组成“三要素说”献疑[J].档案学通讯,2006(3).

[6]唐小燕.背景信息——电子文件管理不可或缺的元素[J].档案学研究,2001(5).

[7]刘家真.电子文件管理理论与实践[M].北京:科学出版社,2003.

[8]王健.对电子文件形成特点的再思考——兼议电子文件前段控制战略的实现[J].中国档案,2002(11).

[9]张正强.国家标准《文件管理元数据原则》中文件管理元数据的结构化信息与半结构化信息的理解[J].档案学研究,2011(6).

结构化、半结构化和非结构化数据 篇4

结构化数据: 能够用数据或统一的结构加以表示,我们称之为结构化数据,如数字、符号,传统的关系数据模型、行数据,存储于数据库,可用二维表结构表示,

半结构化数据: 所谓半结构化数据,就是介于完全结构化数据(如关系型数据库、面向对象数据库中的数据)和完全无结构的数据(如声音、图像文件等)之间的数据,XML、HTML文档就属于半结构化数据。它一般是自描述的,数据的结构和内容混在一起,没有明显的区分。

谈基建非结构化档案数据的管理 篇5

关键词:非结构化,基建,档案管理,Hadoop,生命周期管理

1 背景与现状

随着社会信息技术的发展, 信息化已深入到社会经济的各个领域, 而大数据已作为信息化产业的助推器, 其正在深刻改变我们的生活、工作和思维方式。大数据技术的发展与应用, 不仅催生了许多新的商业模式和新兴行业, 同时也促进了基建等传统行业发生着巨大的变革。

近年来, 我国正在大力发展基础设施的建设, 包括公路、铁路、航路、学校及大量城镇综合体等。2013年9月和10月由中国国家主席习近平分别提出建设“新丝绸之路经济带”和“21世纪海上丝绸之路”的战略构想, 我国正在协助沿线国家开展大量基础设施建设工作。随着国家在建重大基建项目陆续完工和新项目不断开标, 基建档案呈指数型增长, 建设单位、施工单位和监理单位在工程施工过程中产生了数量巨大、内容丰富、形式多样工程档案, 大量图片、视频、语音记录等包含着大量非结构化档案数据, 像一座未开采的金矿, 静静地等待着开拓者去挖掘。然而, 传统的结构化数据库对其处理效率低下, 并且不能有效地快速扩展, 且成本昂贵;非结构化电子档案在各业务系统的版本不一致, 导致“一数多源”, 无法实现同源化管理;且非结构化档案数据的管理起步较晚, 规范不健全, 缺乏统一的管理。

随着处理非结构化数据的大数据技术得到长足的发展, 建立一个统一的非结构化档案数据管理平台已成为当务之急。其不仅能够对非结构化数据进行统一管理, 杜绝分散存储造成的空间浪费和版本管理紊乱问题, 也使得企业的信息架构得到进一步治理, 实现企业信息架构的SOA化。本文拟对基建非结构化档案数据信息化管理平台的建设进行论述。

2 基建档案管理发展历程

总体来看, 我国的基建档案管理主要经历了三个主要的发展阶段。目前我国的基建档案管理信息化水平仍处于初步信息化管理阶段, 正在向基于大数据技术的信息化管理发展。

第一阶段, 实物存档阶段。在许多基建工程中, 大部分的重要工程档案仍以纸质、光盘等实物形式存在并进行存储, 资料存在分散、损坏、丢失等情况, 使得后续的维护工作难以进行;档案主要以纸质为载体, 难以对大量档案进行检索并快速定位, 无法为后续的扩建工程提供参考, 降低了工作效率;以实物形式存储档案, 占用了大量空间及人力物力, 带来巨大的开销, 不利于企业业务的可持续发展;风险方面, 面临着众多安全挑战, 需要考虑档案偷盗、防火、台风、洪水等不确定风险。

第二阶段, 初步实现信息化管理阶段。面对传统档案管理方法暴露出的诸多问题, 许多大型企业开始着手建设档案信息化系统。该阶段, 企业将档案调用、修改等业务以流程形式嵌入信息系统, 并开始使用信息化系统进行档案的整理、分类、保存、查找工作。企业档案管理逐步向规范化、标准化演进。然而目前, 基建档案信息化管理也逐渐暴露出一些问题:由于大量档案以图片、视频等非结构化形式存储, 信息化系统面临着存储容量小, 查询速度慢、扩容困难等问题;海量历史档案资料蕴含着巨大的价值, 但由于各企业的档案存储分散, 存储容量有限, 无法有效对大量基建档案进行有效的分析挖掘。

第三阶段, 基于大数据技术的基建档案信息化管理。在现代化基建档案管理中, 非结构化档案数据的比例达到总量的80%以上, 面临着难以存储, 难以分析等问题。大数据技术的出现, 解决了档案信息化管理系统的大量数据存储及检索问题, 为基建档案的信息化提供了可持续发展。企业可使用大数据技术建设档案管理信息化系统, 可在海量历史档案数据中快速定位查找历史档案资料。基于云计算资源搭建的大数据集群, 存储成本廉价, 数据容量大, 数据采用分布式架构进行存储, 并支持数据自动备份;大数据分析引擎, 支持海量历史数据分析, 探索海量历史档案中蕴含的问题及规律, 并依此改进基建档案管理工作, 指引企业管理流程及技术不断优化;随着档案资料管理不断趋于规范化, 基建档案资料跨企业、跨行业共享及融合, 形成档案大数据, 可分析基建行业存在的主要问题及客观规律, 提升行业规范程度, 促进基建管理和技术水平不断提升。

3 非结构化档案数据管理建设方案

3.1 基建非结构化档案数据管理面临的问题

基建档案大数据具有4V的特点, 数据容量大 (Volume) 、类型繁多 (Variety) 、高价值 (Value) 、处理要求高 (Velocity) 。而非结构化数据作为基建档案大数据的主要组成部分, 其管理面临着以下挑战。首先, 非结构化基建档案资料缺少统一的规划管理, 分布在多套系统中, 存储方式多样, 且大量应归档的非结构化档案由于存储空间限制, 未纳入归档范围;其次, 非结构化档案数据的利用非常不充分;另外, 各机构的非结构化档案的标准建设体系不一致。

因此, 制定统一的规范, 建立企业级非结构化档案数据管理平台, 对非结构化数据进行统一管理势在必行。平台需实现非结构化档案的自动归档管理和存储, 支持版本管理、信息检索及加工分析, 实现信息共享, 并支撑创新应用。

3.2 基建非结构化档案数据管理的关键技术

3.2.1 基于元数据的档案管理体系

建立基于元数据的基建档案管理体系, 是实现档案大数据汇聚及共享的基础。元数据是描述数据的数据, 非结构化数据的存储管理必须支持归类或者检索。伴随基建档案信息化的普及, 音频、图像、视频等多媒体档案呈爆发式增长, 其多为非结构化数据, 元数据相关标准是实现存储以及共享的关键。基建行业需依据国家统一的元数据管理规范, 建立档案管理体系, 使其支持精确的检索。

3.2.2 海量数据的存储机制

可采用Hadoop技术处理非结构化档案数据。作为非结构化数据存储媒介, Hadoop分布式文件存储具有分布式, 弹性扩容等特点, 采用该技术处理大数据存储具有扩容成本低, 弹性扩展的优点, 使系统具有可用性、可集成性、可扩展性和可伸缩性的特性。

3.2.3 建立版本管理等生命周期管理体系

对声图等非结构化档案资源进行版本管理, 从非结构化数据的申请开始进行把关, 通过申请后, 非结构化数据纳入管理范畴, 如进行编辑, 则记录编辑的修改属性, 以及编辑后的非结构化数据版本, 当该非结构化数据的调用频率小于一定概率时, 可将该非结构化数据进行归档操作。

3.2.4 实现图形图像及语音识别, 加强非结构化数据应用

通过集成图像图形识别技术, 对特定档案信息的特定位置非结构化数据进行识别, 并作为关键字自动录入信息, 作为该图形的关键特征信息, 使图像具有可查询并重复应用的特征, 加强非结构化数据的应用;通过语音识别技术, 将语音中的关键信息进行标识, 使之能够支持智能匹配, 以便为查询或决策提供支持。

3.3 基建非结构化档案数据管理平台

平台采用大数据技术 (Hadoop) 体系搭建, 以电子档案数据的元数据管理和档案数据生命周期管理为支撑, 支持企业海量档案的存储和查询应用、档案中非结构化信息的分析挖掘、及档案调用更改的监管。

平台架构主要由以下内容构成:

应用服务层。主要支持技术人员及档案管理人员对档案进行查询和共享等应用, 最大限度提高基建档案利用价值;另一方面, 支持业务人员对历史档案进行分析、挖掘潜在规律、预测发展趋势, 支持监管人员对档案调用及更改的规范性进行实时监管, 辅助管理者进行重大决策。

基建非结构化档案数据管理平台架构示意图

能力支撑层。该层主要构建大数据混合计算处理子系统, 其中, 构建大数据实时查询模块, 以支持海量电子档案资料的查询;构建大数据分析模块, 以支持海量档案数据的分析。此外, 该层还负责非结构化档案数据的元数据管理、生命周期管理、业务流程管理, 以支撑应用层的大数据应用。

数据服务层。该层采用大数据技术体系中的分布式文件系统作为非结构化档案的存储介质, 并构建档案数据库、元数据库、日志数据库等数据库进行数据存储。

基础设施服务层。基建企业或行业构建非结构化档案数据管理平台时, 可利用企业云或公有云资源, 使系统具备弹性扩容的能力, 承载不断增加的档案数据资料。

3.4 基建非结构化档案数据管理平台的建设步骤

大型企业建设基建档案大数据管理平台可参照三个步骤逐步实现。此外, 行业主管部门可建立基建行业级非结构化档案数据管理平台, 对行业动态进行实时监控、挖掘分析, 并依据数据分析结果指导基建企业改进业务流程。

首先, 制定统一标准, 确定数据使用范围, 构建服务框架, 实现相关系统非结构化数据的迁移和接入工作, 使所有系统都通过该平台进行集中存储、管理以及应用非结构化档案数据的目标。

而后, 通过全面管理档案数据, 特别注重深挖非结构化档案价值。主要通过梳理资源, 实现其生命周期管理和综合利用。

最后, 利用平台实现创新应用, 实现深度业务融合、支持智能分析决策。主要包括深化研究和高级应用开发, 充分发挥档案数据, 尤其是发挥非结构化档案数据的价值, 使基建档案管理趋于规范化、自动化、流程化, 以提高企业效率, 为智能分析和决策提供支撑依据。

4 基建非结构化档案管理发展面临的挑战

基于大数据技术的基建档案信息化管理, 面临着标准制定、技能培养、资源整合等方面的挑战。

4.1 数据标准有待规范

统一的数据标准, 使企业从不同平台或渠道获取非结构化档案数据, 进而为统一分析提供了可能。如企业各部门存储记录数据的标准存在巨大差异, 则很难支持大数据的建模和分析。

4.2 探索档案管理及共享机制

实现企业数据的同源化管理及共享机制, 解决统一档案在多个系统中的版本不一致问题。基于非结构化档案管理平台, 对基建非结构化档案数据实现统一管理, 统一以向相关业务平台提供非结构化档案数据的查询和修改等功能。平台支持建立各种维度的精确索引, 能够自动分类, 提高查询效率, 并支持多种接口以及跨平台访问方式。

4.3 人员技能有待提升

提高档案管理领域教育信息化水平, 除了基建业务知识外, 需要通过培训, 建设高素质的信息化工作人员队伍, 培养高级的数据分析人才, 对基建企业的非结构化档案数据进行分析挖掘, 发掘规律及问题, 指导并提升企业管理水平。

5 总结

在基建档案管理的实践中, 非结构化档案数据管理起着举足轻重的作用。企业及行业主管部门可应用大数据技术, 建立非结构化档案管理平台, 对海量基建档案进行管理和共享, 挖掘海量档案大数据蕴含的巨大潜在价值, 实现档案数据实现同源化管理和应用。基建企业及行业主管部门应深入、广泛地开发利用基建档案资源, 最大限度地提高基建档案利用价值;并提升基建档案管理的基础性作用和地位, 充分发挥基建非结构化档案信息在工程建设方面带给决策者的辅助决策作用。

参考文献

[1]王浩春.数字化档案是档案管理工作的发展趋势[J].城建档案, 2014 (10) .

[2]苏昕仪.浅析促进档案信息化发展的措施[J].科技创新与应用, 2015, (8) .

[3]郎波, 张博宇.面向大数据的非结构化数据管理平台关键技术[J].信息技术与标准化, 2013 (10) .

非结构化海量网络数据处理技术研究 篇6

飞行试验数据处理[1]是飞行试验工程中非常重要的一个环节,是对各类试飞数据信息进行细致、充分和全面的分析与处理,数据处理结果是飞行试验鉴定结论的核心依据。随着计算机网络技术在飞行试验测试领域的深入应用,网络化测试技术[2]逐渐成为飞行试验测试技术发展的另一个核心。同时随着现代飞机设计技术的发展,飞机系统越来越复杂,飞行试验科目、测试参数、测试数据种类以及测试数据总量越来越多。对飞行试验数据处理从质量、速度以及数据安全性、可靠性等方面提出了更高的要求。机载网络化测试系统架构技术[3]应用于最新的飞机测试系统上,该系统采集记录的网络数据记录了飞机一个飞行试验起落的各类测试数据信息,新一代飞机测试参数总量激增,数据总量达到上百个GB。为缩短单架次飞行试验周期,如何高效快捷地对这些非结构化的海量网络数据包进行同步分析处理,方便科研人员的应用,就成为必须解决的实际问题。

1 网络化机载测试系统飞行试验数据的特点

在网络化机载测试系统Kam4000中,网络数据包从采集器通过二级交换机到记录器。第一级交换机可以有多个,二级交换机作为系统的时钟接入点、遥测数据和记录器的接入点、系统配置文件的加载点,结构如图1所示。网络数据包被记录器完整的记录下来,在此需要分析的是记录器记录的完整的网络数据。该网络数据是有一个个网络数据包组成,每个网络数据包的格式根据采集器的不同可以是不同的。

1.1 与Kam500采集系统的差别

现在大量应用于飞行试验的Kam500[4]机载测试系统,采集记录的飞行试验数据格式为标准的PCM数据[5]。PCM数据由重复出现的长帧组成,每个长帧的长度是固定的,每个长帧包含若干个短帧。网络化机载测试系统Kam4000中,采集记录的飞行试验数据为网络数据包格式。每个网络数据包的大小都可以不同,并且每个网络数据包中的参数个数也可以不同。

1.2 海量网络数据包的格式

网络化测试系统采用ARCA公司的最新采集器,采集记录的数据格式根据采集器的不同可以是IENA,或XNET/INET[6]网络数据包格式。采用BCU105(IENA Ethernet Controller)支持的是IENA包结构。 而采用BCU140(XNET Ethernet Controller)支持XNET/INET的同时,也支持IENA。 在网络化测试系统中IENA和XNET/INET网络数据包以Ethernet Ⅱ协议广播。根据记录器的不同,记录的网络数据包结构可以是PCAP格式 或者 IRIG106-10格式记录。

PCAP基本格式:

文件头 数据包头 数据包 数据包头 数据包…

IRIG106-10基本格式:

文件头 特殊字头 数据包 特殊字头 数据包…

根据飞行试验的测试特性,参照以往的模拟量在飞行实验中记录数据的大小,如果参数量为5 000个,一定的飞行时间内记录的飞行试验数据为12 GB左右。随着飞机系统的复杂性的增加,应用于飞行实验的网络化测试系统需测试的飞行试验参数也越来越多,单架次的飞行试验记录的模拟量数据将是现在的4倍、5倍甚至更多。

1.3 网络数据包个数多

为提高发包效率,使发包延迟时间尽可能小,将数据包在采集后快速的发送出去,ARCA公司的采集器规定每个数据包的大小在设计上不允许超过1 500 B。同时,现在的测试参数都是高采样率,在这样的测试系统条件下,一个网络数据包可记录的参数量非常有限,必然会产生惟一标示的单个网络数据包的个数激增。

1.4 网络数据包非结构化

网络数据包具有典型的非结构化。在采集器端,按照测试系统的配置采集参数,并形成网络数据包。对于交换机而言,单个网络数据包的到来和发送没有完整的规则。在记录器上记录的原始网络数据包数据,在数据包的排列顺序上是无序的,数据包的周期是不确定的。不能准确预测到下一个网络数据包到来的顺序和时间。

2 网络数据处理方法

针对以上网络数据包的特点:最新的网络数据包格式和记录格式,海量的原始数据,数目庞大的测试参数,典型的非结构化,以及上千万、上亿的单个网络数据包。根据飞行试验的特点,必须在尽可能短的时间内给出飞行试验的数据分析结果,以便试飞工程师安排接下来的飞行试验。

2.1 内存映射文件

内存映射文件[7],是由一个文件到一块内存的映射。WIN32提供了允许应用程序把文件映射到一个进程的函数 (CreateFileMapping)。使用内存映射文件处理存储于磁盘上的文件时,将不必再对文件执行I/O操作,使得内存映射文件在处理大数据量的文件时能起到相当重要的作用。在处理飞行试验海量网络数据时,需不断地提取数据的,进行判断、跳过等文件操作。如果按照以往的文件指针模式去提取网络数据,在数据处理效率上有可能不能满足飞行试验海量网络数据处理的需求。针对快速读取海量原始网络数据,内存映射文件模式提供了解决方法。

2.2 时间矩阵同步分析算法

针对飞行试验原始网络数据,每个单独的网络数据包总是有时间标识的。这些时间标识在整个原始文件中又是无序存放的。飞行试验的科目所需要的数据往往存在于多个网络数据包中,这些网络数据包中的数据往往不会是同一时刻采集的,也就是说网络数据包的时间标识不会是同时刻的。针对网络数据包的这些特性,为快速进行网络数据包的时统分析,设计了时间矩阵同步分析算法。

如图2网络数据包时间顺序所示,原始网络数据包的时间在顺序上是无序的。

时间矩阵同步分析算法是一种高效的同步分析算法,是最快最逼近真实数据的一种的算法。将原始数据时间以1 s为单位,以实际需要的每秒采样率PerCyc为等分值,即将时间轴分PerCyc等分,如图3所示。

假设PerCyc为6,则在1 s内,平均提取6个时间点。以第二个时间点10为例,从图中可以看到,某个实际的网络数据包时间在10附近有08 s,09 s,12 s三点,那么在提取该网络数据包的时候,比较后选择09 s点数值为同步分析的结果数值。以此类推,对需要提取的网络数据包在10 s点的数值都可以比较逼近获得。

2.3 分布式应用中间件网络数据处理

以中间件形式[8](Active控件等)将网络数据包接口软件发布在分布式网络数据处理系统中。该系统在数据管理、海量数据并发处理和数据分发等方面满足海量飞行试验数据处理需求,通过基于Web的飞行试验数据处理子系统实现对所需数据信息的访问。如图4所示。

(1) 客户端ActiveX根据调度服务器列表中的IP及端口号循环尝试建立Socket通信[9],发出计算请求;

(2) 客户端ActiveX与调度服务器建立连接后,调度服务器经过负载均衡计算,返回给客户端ActiveX一个计算服务器的IP及端口号;

(3) 客户端ActiveX与计算服务器建立Socket连接;

(4) 客户端ActiveX发出执行计算命令;

(5) 计算服务器接收到计算命令后,启动确定的分布式中间件执行分布式计算任务,并将状态信息输出到控制台,计算服务器中的状态监控程序用管道技术[10]将分布式中间件的输出作为自己的输入,并通过Socket方式返回给客户端ActiveX;

(6) 客户端ActiveX接收任务执行的状态信息,显示给用户;

(7) 当分布式中间件执行完毕,计算服务器中的状态监控程序将最后的结果文件通过Socket传给客户端ActiveX;

(8) 客户端ActiveX控件将文件保存至客户端,分布式计算结束。

3 结 语

本文由面及点地对网络化测试系统中采集记录的网络数据进行了深层次的理解和多视角的剖析。同时为实现对非结构化海量网络数据进行快速分析处理,对数据处理算法和数据处理软件集成进行了研究,从接口软件关键算法设计到数据系统集成提出了解决方法。并且这些方法已经在飞行试验海量网络数据处理软件的设计过程中应用,通过对飞行试验中采集的网络数据进行分析处理,使用这些算法的飞行试验海量网络数据处理软件的处理效率满足飞行试验海量网络数据处理需求,解决了在飞行试验中的非结构海量网络数据快速分析处理问题,为新一代机载网络化测试系统应用于飞行试验提供了技术保障。国外许多航空公司已经在飞行试验中应用网络化测试系统,对非结构海量网络数据分析处理技术也在进行研究[11]。

摘要:为实现网络化测试系统下非结构化海量网络数据的快速分析处理,在关键的算法和系统化集成处理方面提出解决方法。采用内存映射文件方式快速读取海量数据,并设计了时间矩阵算法,用以快速进行同步分析处理;应用分布式中间件方式实现海量数据的并发处理和数据分发,对飞行试验采集的网络数据进行了分析处理,使用这些算法的数据处理软件,可以使处理效率满足飞行试验海量网络数据处理的需求。这些都为新一代机载采集系统应用于飞行试验提供了技术保障。

非结构化问题 篇7

当今最流行的的搜索引擎分别是使用目录分类技术的搜索引擎和基于全文检索的搜索的搜索引擎。使用目录分类技术的搜索引擎是最早出现的搜索引擎,但是目前普遍使用的是基于全文检索的搜索引擎,因为目录分类技术的搜索引擎需要大量的人力对网站信息进行人工编目与分类,因此存在着成本高,对网站内部细节描述过于简单,描述能力差的缺陷。用户无法通过这种搜索引擎搜到位于网站内部的有用信息,造成信息丢失。全文检索技术是目前发展比较成熟应用的最广泛的,目前的绝大多数搜索引擎都基于此技术。基于全文检索技术的搜索引擎一般分为3个阶段:网页搜集,预处理,查询服务。网页搜集通过网络爬虫抓取互联网上的页面,有批量搜集和增量搜集。预处理对海量的原始网页集合进行关键字提取,重复或转载网页的消除。链接分析,网页重要程度的计算分析等。查询服务主要是对用户提供方便快捷的界面包括查询方式和匹配,结果排序,文档摘要。与分类目录相比,全文检索能够处理网站深处的信息,但是带来的问题也显而易见。通过全文检索得到的检索结果往往是巨大的并且用户很难快速定位他的目标数据。企业级信息检索[1]主要目的是在企业信息资源中利用信息检索技术快速查找到需要的信息内容。而且由于信息的保密性,所以他与传统的Web检索有很大的区别.

企业非结构化数据的管理和检索的生命周期包括非结构化原信息的获取,包括从数据库,主机,文件等。然后是原信息的处理包括划分片段,标注等,第三步是建立索引,最后是用户检索,相互关系如图1所示。

1 UIMA简介

Unstructured Information Management Architecture(UIMA)是IBM开源的非结构化信息管理的一个体系架构。UIMA是非结构化信息管理体系结构在字处理文档、电子邮件、视频和其他非结构化信息中搜索特定的文本甚至概念。从而发现、组织和传送有用的知识给客户。在分析非结构化的信息的过程中,应用的算法有统计的方法、基于规则的自然语言处理(NLP)、信息修复(IR)、机器学习(Machine Learning)和本体论(Ontologies)等。IBM的UIMA就是一种Framework,该Frmaework便于开发者实现、描述、组合、布署UIMA的组件和应用[2]。

1.1 分析引擎、注释器和Common Analysis Structure

分析引擎[3]是UIMA中的中央构建块。分析引擎包含一个或多个注释器或其他分析引擎。每个注释器实现一个特定的文本分析功能。这种递归式打包允许您通过简单的分析引擎构建复杂的分析引擎。每个注释器将其结果储存在具有类型的特征结构中,该结构仅是包含类型和一组属性/值对的数据结构。

注释是一种特殊的特征结构,它被附加到需要分析的工件的某个区域。例如,注释可能被附加到文档中的一段文本上。对于这种情况,注释在文档中包含一个特定的开始和结束位置。这意味着可以方便地使用注释指定信息提取结果。所有特征结构(包括注释)都用UIMA Common Analysis Structure(CAS)表示,CAS是中央数据结构,所有UIMA组件都通过它进行通信。

图2显示一个包含用于已命名实体识别、语法分析和关系探测的注释器的分析引擎。注意,Relationship Annotator通过分析在CAS中预先存在的概念和语法注释探测关系,而不需要查看实际的文档文本。

1.2 UIMA类型系统

一个类型系统的描述是用来定义一个将要被分析的文件类型,以便区分与别的文件类型,UIMA利用这个描述文件对符合描述要求的源文件进行分析和加索引,最后进行搜索。

UIMA类型系统定义能够在文档中找到并且能够被分析引擎提取的各种对象的类型。例如,Person就是一个类型。类型包括特征。例如Age和Occupation可能被定义为Person类型的特征。类型的例子还有Organization、Company、Money、Product或NounPhrase。

类型系统特定于领域和特定于应用程序。您可以将类型并入到不同的类中。例如Company可以定义为Organization的子类型,或NounPhrase可以定义为ParseNode的子类型。

在文本分析中,用于派生其他类型的概括性的通用类型被称为Annotation类型,它由UIMA框架提供。您可以使用Annotation类型在文档中标记区域。Annotation类型包含Begin和End特征,这些特征的值将确定一个跨段。例如,在以下文本字符串(与图2分析的字符串一样)中,注释Person从位置0开始在位置10结束。

开发注释器的第一步是定义需要使用的CAS Feature Structure类型。这在一个称为Type System Descriptor的XML文件中完成。UIMA定义内置类型TOP(它是类型系统的根,类似于Java中的Object)和以上描述的Annotation等。UIMA还为Boolean、Integer和Double等特征定义基础范围类型,并为执行原始类型定义数组。

1.3 UIMA Processing Engine ARchives(PEAR)文件

开发并成功测试了分析引擎之后,您可以打包它并将其作为预配置(文本)分析组件部署到另一个应用程序中。在UIMA中,一种注释器打包格式称为PEAR,它是Processing Engine ARchive的缩写。PEAR格式包含运行打包注释器组件所需的所有信息。

2 OEE介绍

OEE(OmniFind Enterprise Edition)是IBM企业信息搜索平台的核心产品,可以支持企业中多种数据源的检索查询,这些数据源包括文件系统、数据库、邮件系统、企业内容管理系系统,并且通过UIMA可以集成第三方的分析工具,同时可以满足企业信息搜索的高安全性、高可用性、高性能以及可扩展性等要求,提供多种部署方式可以灵活的满足多样化的企业搜索需求。

3 利用UIMA和OEE定制企业搜索引擎服务

3.1 抽取文本有用信息

利用正则表达式抽取出源文件中需要标注的信息,如图3所示。

然后利用一xml文件配置定制规则,这个文件包含了一组规则,这些规则定义了注释器应该处理的字符数字序列的类型以及处理方式。

3.2 定义type system

Type system是UIMA中cas的一种对象模式,为UIMA可以被分析的一种数据类型,一旦定义完相应的类型系统,UIMA就知道该怎么样对什么样的文件进行定性的信息抽取。Type system定义如图4所示。

3.3 创建相应的注释器

Annotators是是UIMA的核心,针对不同关键字的语义搜索,通常需要定制不同的注释器。图5是语言模块快的注释器片段。

3.4 注释结果

利用UIMA生成相应的class文件,然后进行注释,图6是注释完的结果。

最后把注释完的文件,通过ominifind建立注释索引和全文关键字索引,以支持片段搜索和特定领域的搜索以及全文搜索。

参考文献

[1]Laurent Proulx.Enterprise search as a producitivity tool.http://www.nstein.com,2007,8.

[2]中国开源社区http://www.oschina.net/p/uimajava.

[3]开发和集成定制的UIMA文本分析引擎[DB/OL].http://www.ibm.com/developerworks/cn/data/library/techartdes/dm-0908text-analysis3/.

[4]Browning P,Lowndes M.JISC TechWatch Report:Content Manage-ment System[DB/OL].http://www.jisc.ac.uk,2008.1.

[5]Nicholas Chase."Create a UIMA component Web services"[DB/OL].http://www.ibm.com/developerworks/edu/w-dw-wa-uima.html,2005.

[6]杜小勇.第三代搜索引擎初探:智能化、个性化[J].中国传媒科技[DB/OL].http://tag.csdn.net/Article/acecc958-9747-4ec0-b013-e6656ede991d.html,2006.

[7]刘升平.XML的模型论语义及其应用[D].北京:北京大学,2005.

[8][DB/OL].http://www.shopbottools.com.

非结构化问题 篇8

随着信息技术的普及与发展,纸质病历早已不能适应现代医学的需求,电子病历开始在医院管理和医疗工作中出现[1]。

初期,由于缺乏临床信息系统支持,我国电子病历首先是从病程记录编辑器开始的,期间经历了Word、半结构化或结构化等编辑器的过程演变。近年来,随着检查、检验、心电、手术麻醉等各类临床信息系统的大力应用,完整的临床数据集成、展现及智能化应用已成为电子病历发展的方向[2]。

可以看出,电子病历系统已从当初作为HIS的一个模块存在,逐步发展成为一个系统集成平台,在提高医生工作效率的同时,也大大提升了电子病历的质量。不过,在医院的医疗科研实践中我们发现,医生在进行医学研究[3]或遇到疑难杂症需要查阅以往特殊患者病历的时候[1],往往只能依据受限的查询条件(如:患者的基本信息、医生创建的结构化元素等)来获取患者的病历,而在系统中没有事先定义好的信息将无法作为查询条件进行检索。如果有一种查询检索机制,它能够独立于电子病历系统之外,并采用全文检索的方式,那么它就可以充分满足医生和患者的任意查询需求,而用Lucene引擎构建非结构化电子病历检索系统就能够做到这一点。

1 Lucene全文检索引擎

1.1 Lucene简介

Lucene是一款以JAVA实现的成熟、自由、开源的软件项目,也是Apache软件基金(apache software foundation)中的一个项目,并且基于Apache软件许可协议授权。它是一类强大的Java搜索库,是一类高性能的、可扩展的信息检索(IR)工具,目的是为软件开发人员提供简单易用的索引和搜索API,使之很方便地为应用程序添加搜索功能[4]。

Lucene专注于文本索引和搜索,它并不关心数据来源、格式,甚至不关心数据的语种,只要能把它转换为文本格式即可。也就是说,它可以索引和搜索存储在文件中的如下数据:远程Web服务器上的网页、本地文件系统中的文档、简单的文本文件、Word文档、XML文档、HTML文档及PDF文档,或者其他能够从中提取文本信息的数据格式。同样,也可以利用Lucene来索引存储在数据库中的数据,以提供一些其他数据库所不具备的全文搜索等功能[4]。

1.2 Lucene全文检索的实现机制

Lucene类似一个支持全文检索的数据库系统。Lucene的结构设计类似于数据库的表、记录、字段,如图1所示[5]。这样做的结果是设计思路非常清晰,同时保证数据检索高效性,绝大部分的数据都可以方便地映射到Lucene的存储结构接口中[6]。

虽然Lucene的结构设计与数据库的设计极为相似,但Lucene的索引与数据库索引又有着极大的不同。数据库的索引和Lucene的索引的建立都是为了提高查询速度,但数据库的索引建立的设计仅针对少数的字段信息建立索引,并非为全文检索设计,因此利用数据库的索引仅能根据已建索引的字段进行检索,无法实现全文索引,我们可以把它称之为结构化的查询;而Lucene的索引建立却是以全文检索为基础,不受“字段”的局限,可根据需要任意检索,我们也可以称它为非结构化的查询,因为只要能够转化为文本格式的数据源,Lucene就可以对它进行索引和检索。

2 非结构电子病历检索系统的设计与实现

2.1 设计原则

(1)平台无关性。系统应能够独立于业务系统之外,它只需要关心电子病历文件存储的路径。

(2)安全性,稳定性。系统应保障对现有电子病历系统不产生任何影响。同时,由于电子病历涉及个人隐私,因此,应该控制好查询访问的权限等级。

(3)可管理性。可以通过完善统一的控制界面来管理和维护,以满足内容不断更新的需求。

2.2 设计目标

(1)实现全文检索。

(2)操作简单,具有一定的统计功能。

(3)查准率(precision)和查全率(recall)高。查全率是用来衡量搜索系统查找相关文档的能力;而查准率是用来衡量搜索系统过滤非相关文档的能力。

2.3 设计方案

2.3.1 系统架构

用Lucene引擎构建非结构化电子病历检索系统的总体架构图[5],如图2所示。

2.3.2 模块功能说明

(1)索引模块。查找电子病历文件(存放在内部构建的FTP服务器上),以获取电子病历内容,并将其转化为文本格式信息,然后利用Lucene内嵌的分析器将文本分割成一系列被称之为语汇单元的独立的原子元素,也就是前面所讲的“字段”,最后把文档加入到索引列表,形成索引文件。

(2)搜索模块。根据用户提交的查询请求,利用Lucene提供的查询解析器(query parser)将其转化为查询对象,最后查询检索索引并返回与查询语句相匹配的电子病历文件。

(3)管理模块。启动和停止搜索服务、权限等级分配、索引更新、搜索日志。

(4)分析模块。根据搜索日志记录的信息,分析用户的查询请求,以提供简单的统计报表。

2.4 系统实现

2.4.1 开发环境

本系统搭建在Windows Server 2003 SP2操作平台上,采用Java、Jsp编写,开发工具为Eclipase3.2,集成了全文检索Java包Lucene core 2.3.1,Web应用服务器Apache Tomcat 4.1。

2.4.2 代码设计

索引与检索是系统的核心,其部分源代码设计如下:

(1)创建索引[8]

*索引创建函数,生成Index Writer创建索引,调用子目录索引函数,并优化

*存储本地磁盘索引

(2)检索

*检索关键字列出对应电子病历的数量

3 讨论

系统在设计与实现的过程中仍存在着许多值得探讨的问题:(1)电子病历内容的特殊性,使其更新频率非常高,索引的创建与更新时机就显得尤为重要。(2)门诊系统与住院电子病历属于不同公司开发,电子病历的存放路径及文档格式转化也是一个大问题。(3)对于亚洲语种而言,Lucene内置的分析器并不能完全满足检索的需要,因此,针对中文语言的切分规则,有必要设计一些好的算法,以符合其自身的语言习惯。(4)检索结果的排序优化及安全机制都需要在长期的应用中不断改进。(5)无论是结构化还是非结构化的电子病历文档,如果能够构建统一的转换平台,将其转化为Lucene能够识别的文本格式,相信它的适用范围会更加广阔。

4 结语

本系统虽然只是实现了比较简单的全文检索功能,但是对非结构化电子病历的检索而言却有着较为重要的意义,因为它可以不用局限于电子病历的开发公司,不用局限于电子病历的应用平台,再加之Lucene引擎的灵活开放,如果其功能能够如讨论中的那样有所加强,相信它的应用前景会非常令人期待。

摘要:目的:构建非结构化电子病历检索系统。方法:以Lucene为搜索引擎,通过前期对电子病历文件的索引处理,实现电子病历的全文检索。结果:该技术强调对非结构电子病历的处理,使其不依赖于电子病历系统本身,更加灵活,易于扩展。结论:使用非结构化电子病历检索系统,可以有效地改善检索条件的局限,提高电子病历的利用率。

关键词:Lucene,搜索引擎,全文检索,非结构化,电子病历

参考文献

[1]王晓,罗二平,张健.基于语义的电子病历智能全文检索[J].医疗卫生装备,2008,29(4):45-46.

[2]陈金雄.电子病历建设与发展[J].中国数字医学,2011,6(5):53-55.

[3]夏洪斌,蔡剑飞,陈金雄,等.结构化电子病历系统应用与体会[J].医疗卫生装备,2009,30(5):46-47.

[4]Michael McCandless,Erik Hatcher,Otis Gospodnetic.Lucene实战[M].2版.北京:人民邮电出版社,2011:6-7.

[5]孙西全,马瑞芳,李燕灵.基于Lucene的信息检索的研究与应用[J].情报理论与实践,2006,29(1):125-128.

[6]王利云,王华,陈刚,等.基于Lucene的全文检索系统的设计与实现[J].计算机工程与设计,2007,28(24):59-61.

非结构化问题 篇9

关键词:非结构化对等网络,资源搜索,拓扑调整,“搭便车”,历史查询

近年来,对等网络发展迅猛,被广泛应用到诸如文件共享、实时消息、协同工作等多个领域。对等网络的成功在于它消除了传统C/S模式下以服务器为中心带来的性能瓶颈问题,具有更好的容错性、可靠性及可扩展性。但与此同时,作为一种分布式自组织网络,对等网络还具有大规模,高动态的特点,这使得在对等网络中高效地进行资源搜索成为一个突出的问题。

目前对等网络大致分为:结构化对等网络和非结构化对等网络。前者利用分布式hash表(DHT),将节点组织成严格的拓扑结构,并将数据映射到特定的节点,在资源搜索时采取相应的定位方法,搜索能在确定跳数内完成,效率较高。然而,对等网络的高动态性使得维护结构化的拓扑开销巨大。在非结构化对等网络中,节点关系松散,资源分布随机,这类网络容错性强,能很好地适应网络的动态特性,目前广泛流行的P2P应用软件主要采用这一组织方式(如Gnutella,KaZaA等),但是这类网络资源搜索通信开销大,效率不够高。

对等网络的可用性有赖于网络中各个节点贡献资源,然而文献[1]显示,在Gnutella中有70%的用户节点从网络中获取资源,但他们对网络贡献的资源却几乎为零,这种被称为“搭便车”的现象普遍存在于P2P网络当中,阻碍了网络的高效运行。

本文针对非结构化对等网络,提出一种通过历史反馈信息,动态调整网络拓扑结构,使兴趣相关节点聚集的方法,提高非结构化网络的搜索性能,同时对网络当中“搭便车”的现象也有遏制的作用。

1 相关工作

资源搜索一直是对等网络相关研究的一个关键问题。最为典型的非结构化对等网络Gnutella采用泛洪的方法,这种方法简单健壮,适应力强,然而泛洪带来的巨大通信开销,直接影响到网络的可用性和可扩展性。为改善搜索性能,后续研究提出了多种改进方法,可大致可以分为两类:一类是保持现有拓扑结构,改变搜索的路由方式[2,3,4,5]。这类方法能有效减少网络的通信开销,但是会对搜索成功率和响应时间带来一定负面影响。另一类则采取某种简单的路由方法(泛洪或者随机游走),而着眼于改变网络的拓扑结构。这类方法因为能对网络的拓扑结构进行改变,具有很强的灵活性,能给网络的性能带来更大的优化空间,也更具有研究价值。这类方法的核心问题是,如何发现和衡量有价值的节点并维护高效的连接。

捷径法[6]以兴趣局部性为依据,即对于一个节点而言,如果某节点能满足它的某次查询,则它的后续查询也很可能在这一节点得到响应。在上述的节点之间新建立起的有向连接就称之为捷径。网络当中每个节点维护一定数量的捷径表,在搜索的时候,先搜索捷径连接的节点,不能满足的情况下,再启动底层覆盖网中的泛洪查找。捷径法通过捎带更新(Piggybacking)的方式,记录查询的相应情况,并据此发现捷径。该法原理简单,性能良好。但并未考虑忽略了节点负载能力限制也未考虑网络的公平问题。

APT[7]采取了不同的思路,每个节点维护一个本地信任向量,记录从网络当中其它节点成功下载文件的情况。节点通过对历史信息学习与具有较高本地信任值得节点建立连接。APT将这一过程抽象为一个最优化问题,即目标是使整个网络具有最大的信任值,以节点的负载上限为约束条件。各个节点采用贪婪算法,调整连接使自己拥有的连接信任值最大。APT方法通过改变覆盖网络的结构,使网络具有更高的信任度,提高了网络的可用性,同时将恶意节点以及“搭便车”的节点逐步边缘化。

文献[8]与上一方法的思想相似,都是通过调整网络拓扑优化网络性能。文献[8]以查询过程当中平均每一跳能返回的结果数量作为衡量节点价值的标准。某一节点将与它相关的节点分为直接节点和间接节点,直接节点相当于邻居,间接节点则是返回查询消息的非邻居节点,通过定期的统计,计算直接邻居和间接邻居的每跳返回结果数量,不断用高指标的间接节点替换低指标的直接节点。

以上方法都是通过对历史查询情况的学习来调整网络的拓扑结构,还有方法通过语义描述来确定节点兴趣,使兴趣相似的节点聚集如SON、GES等,这些方法有效但兴趣粒度大小的确定面临网络性能和维护代价的两难问题。

本文提出的方法基于对历史查询情况的学习,保留捷径法的简单实用,同时考虑连接建立的双向性,引入逆向选择机制,在提高网络效能的同时,能有效遏制“搭便车”的现象。

2 主要思想

本文提出的方法基于以下三点假设:(1)文献[6]提出的兴趣局部性,即某节点能满足当前查询则很可能满足后续查询;(2)从节点自身利益出发,节点会与最有可能返回查询结果的节点建立连接;(3)具有相似兴趣的节点,有较大可能满足彼此之间的查询。

本文提出的方法借鉴文献[6]的方式建立捷径,但对捷径发现的方法做了改进,能更快速地在网络当中发现捷径。由于捷径建立过程的单向性,使得捷径的发起方成为受益者,而加重被连接一方节点的负载,考虑到节点负载方面的限制以及节点对自身利益的关注,本文引入逆向选择的机制,让捷径的被连接方依据自身的情况作出接受或拒绝的决定。通过上述方式建立的捷径具有双向性,而能够达到互惠的目的,同时“搭便车”的节点因为不能给其他节点提供资源而被淘汰到网络边缘。由于捷径的逐步建立完善,使得因具有相似兴趣而能相互提供资源的节点相对聚集,查询大多数时候能被捷径所满足,初始网络中的连接作用不大,然而维护这些连接需要额外的通信开销,我们进一步用高效的捷径代替低效的初始连接,一方面以减少维护它们的额外开销,另一方面适应网络的动态变化,进一步提高网络的性能。

在本文论述的方法当中,网络中的每个节点维护三个表:(1)节点的邻居表(Neighbor List),存储节点的邻居信息,这是所有对等网络路由的基础;(2)捷径表(Short-cut List),存储返回查询结果的节点信息如(地址,端口等),同时记录节点返回查询结果的情况,并据此进行排名,位于前k位(k值由系统或者用户设定)的节点为有效项,被确定为捷径;(3)被连接表(Linked List),存储连接到本地的捷径发起节点的信息。

2.1 捷径的发现以及消息的路由方法

同文献[6]相似捷径的发现是启发式的,为避免通信开销,采取消息捎带的策略。节点加入网络之初,对其他节点的兴趣并无了解,因此在查询是只能在Gnutella覆盖网络上泛洪查找,返回结果的节点被加入捷径表,它们都是潜在的捷径连接点,从中选取m个节点(m<=k)作为捷径。在下一次查询时,先逐一查找捷径,若有结果返回则停止。过程如下:

(1)查询发送至第一个捷径节点,若捷径节点返回结果则结束;否则转发至与与其相关的捷径节点,即捷径节点的被连接表中的节点和捷径表中的有效捷径(表内前k项)。若有返回结果则停止,修改A本地捷径表中对应捷径节点以及返回结果节点的命中数量,若不能满足,转入下一步;

(2)则继续转发至捷径节点的被连接表中的节点和捷径表中的有效捷径(表内前k项),(3)对下一捷径节点重复以上步骤,若不能满足,转入下一步;

(3)在初始的网络中泛洪搜索。

这里与文献[6]不同之处在于,文献[6]在上述过程中,只对捷径节点逐一搜索,遇能返回结果则停止,在此我们将搜索扩大到与捷径有捷径关系的节点,这样做基于前提假设(3)中提到的如果具有相似兴趣(本文中指有能相互满足大量查询)的节点,有较大可能满足彼此之间的查询,这一方面能减少在底层网络盲目泛洪的机会,另一方面扩大发现捷径的范围,增加发现高效捷径的机会,使得具有相似兴趣的节点更快的聚集。

图中带箭头的连接为捷径,其他连接为初始网络中的连接。

以图1种A为例,说明查询时的消息路由方式。设H点比E在A中捷径表中排名靠前。A的查询消息先发送至H,H有两条捷径:它自身连向D的捷径和G连向它的捷径,若H能满足查询,则停止;否则H将消息转发D、G,若搜索命中,则停止,不然A将查询发送给下一捷径E,若仍未命中则A在初始网络中泛洪查找。

2.2 捷径的选择

如前所述捷径表中存储的节点为候选的捷径节点,位于降序排列排名前k位的节点才是有效捷径。对众多的候选者进行排序就涉及到对节点价值的衡量。节点返回结果的数量、时延、带宽、负载等都可以作为参考的因素,系统和用户可以根据具体情况,选取其中之一或者综合几个因素的绩效函数来对候选节点进行排序。为简单以及便于对比起见,我们采用文献[6]的指标,以查询成功率作为绩效函数。查询成功率被定义为捷径成功返回结果的数量与向其发起查询的次数之比。

每个节点的计算能力和带宽等资源是有限的,因此节点的负载能力会受到限制。而在网络中捷径的建立,无疑会增加节点的负荷。从前面的描述中不难看出网络捷径是基于单向利益建立的,即只对捷径的发起方有利,这很可能导致“搭便车”的情况:某些节点通过捷径使自己获取了很多资源,却没有给捷径另一端的节点作任何贡献。考虑到前提假设第(2)点,节点会基于自身利益作决定,我们引入逆向选择机制,即节点会对连接到自身的捷径进行取舍。由于每个节点都存储有捷径表和被连接表,逆向选择机制可以通过对比两个表中项目的情况来达成。本文采取的方法如下:

(1)每个节点设定一个最大负载值L,与节点的相关的捷径(被连接表和捷径表中的有效项)、节点在初始网络中的邻居都视为负载,其和为Ls;

(2)若Ls

(3)节点以捷径表中排序为参照调整被连接表,按照捷径表中先后顺序,排序被连接表中的节点,剔除在捷径表中不存在的节点;

(4)在Ls=L,而又有新的捷径连接请求时,若捷径发起节点比当前被连接表中排在最后的节点在捷径表中排名靠前,则接受新的请求,将新节点加入被连接表,剔除排名最后的节点;

上述过程,一方面使节点不会过载,另一方面,通过步骤(3)、(4)实现逆向选择机制,使对节点贡献更大的节点有更大的建立捷径的机会,逐步避免没有贡献及贡献小的节点,使捷径的效率更高,同时避免了“搭便车”的节点。

参图2,以一实例说明上述过程。设A的负载最大值L为6,A当前的捷径表和被连接表如表1,表2。

A当前负载为最大,因而它会拒绝其他节点向它发出的捷径连接请求。在进行捷径逆向选择过程当中,A通过对比表1和表2会发现其与H有着相似兴趣,彼此能为对方提供大量资源,因此保留H,而表2中D因为未能向A提供资源而会被剔除。A此时允许新的捷径连接到自身。

2.3 网络拓扑调整

捷径的存在使得节点避免在每次查找的时候都在初始的网络当中进行盲目地泛洪,随着捷径的不断增多和完善,节点的多数查询都能通过捷径得到满足,这样使得节点在初始网络当中的连接作用逐渐减小,而节点维护初始网络当中的邻居表也需要通信开销。由于前一节采用的逆向选择机制,使得捷径具有双向性,这就使得捷径可以替代初始网络中的邻居连接。通过将同时将双向捷径替换邻居表中低效邻居节点,我们可以对网络拓扑进行调整,使得兴趣相似得节点在网络当中相对聚集,使搜索性能得到提高。与此同时,去除初始网络当中得低效邻居节点,改善了节点的负载状况,使节点能够引入新的捷径。如图2情形,节点A可能断开与C的连接而与H的捷径变为邻居连接。

3 模拟实验

本文选择PeerSim为实验平台,对本文提出的方法进行了模拟,并将实验结果与Gnutella的泛洪搜索以及文献[6]中的捷径法进行了对比。我们选取以下指标衡量搜索性能:

查询成功率:节点搜到成功返回消息的查询数量与节点总共发起的查询数量之比。

平均搜索路径长度:查询发起节点到成功返回消息的节点之间的平均跳数。

实验结果如图。从图3可以看到因为捷径的引入使得捷径法和本文的方法在查询成功率方面较泛洪查找有大幅提高,而本文的方法在捷径建立机制上的改进以及对初始网络拓扑的优化又使得在相同的轮次下,本文的方法比捷径法获得更高的效率。图4展示了三种方法在搜索路径长度上的变化,可以看到泛洪方法的搜索路径长度,随机地在5跳左右浮动,而捷径法和本文的方法则因为利用了历史查询的情况,随着历史查询的积累,步长逐渐减小,趋近于某一数值。而同样地因为本文更充分地使用了历史信息,使得兴趣相近的节点更快地聚集,从而更快更大幅度地减小了搜索路径。

通过在实验网络中设定一定数量的“搭便车”节点,对比平均特征路径长度来衡量本文方法对“搭便车”现象的影响。节点的平均特征路径长度定义为网络中其他节点到某一节点的最短路径的平均值。图5将随机选择的10个普通节点与实验中设定的“搭便车”节点的平均特征路径长度作了对比,从图中可以看到“搭便车”节点的路径长度均值高于普通节点,这说明通过本文的反向选择机制,“搭便车”节点总体在向网络边缘移动,少数“搭便车”节点因为不能提供资源,甚至从网络当中脱离出来。

4 总结

本文着眼于提高非结构化对等网络的搜索性能,提出了一种新的优化方法。本文部分借鉴捷径法,引入逆向选择机制,并动态改变节点连接,通过改变网络拓扑结构的方式,更大限度地优化搜索性能。实验结果显示,本文提出的方法不仅在有效提高了网络的搜索性能,而且能抑制网络中的“搭便车”现象。

参考文献

[1]ADAR E,HUBRTMA B A.Free-riding on gnutella.[J]First Monday,2000,5(10):1-22.

[2]KALOGERAKI V,GUNOLULOS D,ZEINALIPOUR-YAZTI D.A local searchmechanism for peer-to-peer networks[C]//Proceedings of the 11th ACM Conferenceon Information and Knowledge Management.New York:ACM,2002:300-307.

[3]YANG B,GARCIA-MOLINA H.Improving search in peer-to-peer networks[C].//Proceedings of the 22nd international Conference on Distributed Computing.Picat-away:IEEE,2002:5-10.

[4]GKANTSIDIS C,MIHAIL M,SABERI A.Random walks in peer-to-peer networks[C].//Proceedings of IEEE INFOCOM'o4.Picataway:IEEE,2004:120-130.

[5]TSOUMAKOS D,ROUSSOPOULOS N.Adaptive Probabilistic search for peer-to-peer networks[C].//Proceedings of the 3rd international conference on peer-to-peercomputing.Picataway:IEEE,2003:102-109.

[6]SRIPANIDKULCHAI K,MAGGS B M,ZHANG Hui.Efficient content location usinginterest-based locality in peer-to-peer systems[C].//Proceedings of the INFOCOM2003.San Francisco:IEEE,2003:2166-2176.

[7]CONDIE T E,KAMVAR S D,GARCIA-MOLINA H.Adaptive peer-to-peer topolo-gies[C].//The 4th International Conference on Peer-to-Peer Computing.Zuich:IEEE,2004:53-62.

上一篇:现代艺术运动下一篇:时尚语文