数据广播系统

数据广播系统（精选12篇）

数据广播系统 篇1

1 数据流系统

数据流 (data stream) 应用的出现引起了国内外专家和学者的关注, 数据流管理技术作为一种新兴的技术已经被广泛的研究, 目前通用的DSMS (data stream management system) 包括Telegraph CQ[1], Aurora[2]和STREAM[3]。

数据流的查询过程是持续的查询 (continuous query) [4], 持续查询所关心的并不是全部的数据, 而是近期最近到达的部分数据, 所以数据流中的持续查询采用滑动窗口 (moving window) 机制, 基于滑动窗口的查询。

本文基于通用流数据库[5,6], 构建一个空间数据流系统模型。在此过程中, 借鉴交通导航应用开展工作。这里的空间流数据库模型系统的主要工作仅包括增加空间数据类型、空间滑动窗口和空间谓词, 为了实现简单易懂的空间连续查询语言, 本文在设计时, 尽量和原有的空间数据库查询语言和连续查询语言做到统一。本文依据标准SQL和CQL设计空间数据类型和空间谓词, 并参考OGIS标准, 尽量不修改原有查询语言的结构, 采用通用的空间数据类型表示方法, 通过增加通用的关键词的方式, 扩展连续查询查询语言。

2 空间数据类型扩展

我们考虑交通导航LBS (Location Based Service) 应用, 在这种应用中, 需要知道移动对象前方道路的交通状况, 根据交通状况选择合适的运行路线。假定每个移动对象每隔30秒向导航服务中心报告移动对象当前的速度和位置信息。前方的交通状况由运行在前方的一定范围的移动对象数量和这些移动对象的平均速度来决定, 数量多并且平均速度小于40km/h就表示交通状况差, 否则交通状况良好。随着移动汽车位置的改变, 其维持的空间查询窗口也在不断的改变位置, 如果设计一种空间滑动窗口, 使之能够随着移动对象的改变而改变, 就可以解决这个问题。

根据例子应用的需要, 拟增加的空间数据类型有Poin和SSwin两种。Point用来表示一个移动对象, 而SSwin用来表示一个空间滑动窗口。

(1) Point[x:float, y:float], 在这里Point表示某个移动对象, 它的值为移动对象的二维空间坐标;

(2) SSwin[Point1, Point2], 表示某一空间滑动窗口, 为了简化问题, 此处的SSwin, 仅表示一个矩形的空间滑动窗口, 由两个Point标识。

3 增加空间滑动窗口查询函数

为了支持空间查询, 需要增加空间谓词和空间函数, 本文需要增加空间函数Inside, 用来判断空间移动物体是否在空间滑动窗口内。

(1) Inside (Obj, SSwin)

这里的SSwin表示空间滑动窗口, Obj表示移动对象位置, 此运算符的结果为整型, 当Obj在SSwin的内部时, 其值为0, 否则, 返回值为1。

(2) 空间滑动窗口的连续查询

通过以上增加了空间数据类型和空间谓词以后, 流数据库可以支持空间滑动窗口的连续查询。粗体字部分表示本文增加的空间谓词:

4 空间滑动窗口查询的实现

本文的空间流数据库模型的实现工作是基于STREAM流数据库管理系统, 通过修改此系统的代码, 实现空间流数据库系统。此系统是斯坦福大学开发的一个的通用的流数据管理模型。此数据库管理系统模型是开放源代码的。它能够处理对多个连续的数据流和存储关系的连续查询。它提供大量的复杂流查询, 用来处理高容量和高突发性的数据流。它提供丰富的连续查询语言, 有良好的交互操作界面。

本文的实现是要在流数据库管理系统的基础上进行扩展, 虽然仅是对原有系统的扩展, 但是需要做的工作仍然涉及到整个数据库管理设计的全过程。一个数据库管理系统的设计包括一系列的阶段, 一般遵循以下的顺序。同时以下这些步骤也是实现此空间流数据库的过程中, 主要的工作:

(1) 生成词法分析树:由抽象的查询语言生成词法分析树, 这个过程是数据流管理系统实现的最初阶段。根据上节定义的空间连续查询语法, 在本文的空间数据流系统中, 用Yacc生成查询语言的语法分析树。

(2) 语义分析:对词法分析树进行语义分析, 将词法分析树转换为系统能够识别的内部表示。这一步生成的语义表示仍然不是一个操作符树。这个过程的设计主要是将空间数据类型和空间谓词转换为系统能够识别的形式, 具体的实现类似于算术表达式的语义转换。

(3) 生成逻辑计划:将查询的内部表示转换为逻辑查询计划。逻辑查询计划由逻辑操作符组成。逻辑操作符大多是关系代数操作符 (比如选择、投影、连接等) , 当然也有一些连续查询特有的操作符 (比如滑动窗口操作符) 。逻辑操作符不需要和查询执行中的操作符有关, 它仅仅是一种关系代数的抽象表示。

(4) 生成物理计划:将逻辑查询计划转换为物理查询计划。物理查询计划中的操作符是直接和在查询执行期间执行的操作符相关的。之所以要生成一个单独的逻辑查询计划, 是因为逻辑查询计划更加容易生成, 而物理查询计划涉及到底层细节。

(5) 查询执行:组织存储空间的分配, 物理操作符的执行等。

5 实验

5.1 LBS运动模型

构造如图1所示的导航应用, 移动汽车每30秒向导航中心报告当前位置信息和行驶速度并且进行空间滑动窗口的聚集查询, 这里我们主要涉及count和avg聚集查询, 分别计算滑动窗口内汽车数量和平均速度。移动汽车根据查询结果了解前方路况, 以起到交通导航的作用。

5.2 输入设计

(1) Mov Car

Mov Car的结构如表1所示。

(2) Spa Sli Window

空间滑动窗口 (Spa Sli Window) 数据流, 该数据流包含空间滑动窗口标志信息和空间滑动窗口位置信息如表2所示。

5.3 空间滑动窗口查询设计

上一节中构造了两个输入数据流, 分别模拟移动汽车信息数据流和空间滑动窗口数据流, 下面编写空间滑动窗口查询的脚本语言, 该查询脚本基于前面分析的简单的交通导航应用以CQL (持续查询语言) 编写, 脚本文件如图2所示。

5.4 结果输出

注册了输入数据流, 并且定义了空间滑动窗口查询之后, 经过我们设计的空间流数据库模型的处理得出图3和图4所示的结果。图3所示导航查询结果, 可以看出, 在61时刻的滑动窗口3内有6辆移动汽车, 汽车平均速度为34.1667km/h, 小于40km/h, 满足查询条件, 由此汽车A得知此刻前方路段交通状况差, 可以采取积极的应对措施, 绕过此拥挤的路段。图4所示每个查询时刻对应空间滑动窗口内的汽车信息, 可以看出, 1时刻的空间滑动窗口内有移动汽车A、B、C、D、E, 31时刻的空间滑动窗口内有移动汽车A、B、C、D, 61时刻的空间滑动窗口内有移动汽车A、B、C、D、E、F, 91时刻的空间滑动窗口内有移动汽车A、B、C, 121时刻的空间滑动窗口内有移动汽车A、C。

6 小结

本文结合交通导航应用对数据流系统进行空间扩展, 扩展了空间点和空间滑动窗口, 及基于空间滑动窗口的查询操作, 并依据数据库的设计步骤, 实现了空间数据流系统。以导航应用为例, 构造了一个基于空间滑动窗口的运动模型, 通过试验分析, 输出的结果均符合我们设计的运动模型。

摘要：数据流系统以连续查询为特点, 连续查询的处理机制能够保证数据处理做到实时处理。但是现有的通用的数据流系统没有对空间数据处理的支持, 而基于位置服务显然是一种需要空间数据处理的应用。本文从支持位置服务的后台数据处理出发, 提出用基于数据流系统的流数据库来支持基于位置服务的数据处理的思想, 并结合当今数据流系统的发展和基于位置的服务的需求, 对数据流系统进行空间扩展, 提出一种空间数据流系统的模型。

关键词：数据流,空间连续查询,LBS

参考文献

[1]Sirish C, Owen C, Amol D, Michael JF, Joseph MH, Wei H, Sailesh K, Samuel RM, Fred R, Mehul AS.TelegraphCQ:Continuous dataflow processing[R].In:Alon YH, ed.Proc.of the2003ACM SIGMOD Int’l Conf.on Management of Data.New York:ACM Press, 2003.668—668.

[2]Daniel JA, Don C, Ugur C, Mitch C, Christian C, Sangdon L, Michael S, Nestime T, Stan Z.Aurora:A new model and architecture for data stream management[J].The Int’l Journal on Very Large Data Bases, 2003, 12 (2) :120—139.

[3]A.Arasu, B.Babcock, S.Babu, M.Datar, K.Ito, I.Nishizawa, J.Rosenstein, and J.Widom.STREAM:The stanford stream data manager[J].IEEE Data Engineering Bulletin, 2003, 26 (1) :19—26.

[4]Shivanath B, Jennifer W.Continuous queries over data streams[J].SIGMOD Record, 2001, 30 (3) :109—120.

[5]姜芳艽.DBMS与DSMS的比较研究.微计算机信息, 2007.2, 3:33-36.

[6]金澈清, 钱卫宁, 周傲英.流数据分析与管理综述.软件学报, 2004, 15 (8) :1172-1181.

数据广播系统 篇2

为正确、高效处臵金融统计数据集中系统数据报送环节面临的突发事件，提高应对数据报送风险的能力，保证金融统计数据采集工作顺利运行，依照人民银行总行确定的风险应对机制适用范围，根据自身情况及面临的风险特制定本方案：

一、组织机构

成立数据报送风险应急工作小组，由XXX行长任组长，计划财务部、风险管理部、信息科技部、各支行主管副行长及其他涉及数据报送的部门领导为成员。办公室设在计划财务部，负责具体工作。

二、风险应对机制方案

（一）金融统计制度变更的处理机制

对于统计制度变更引起的统计指标、统计口径等方面的变化，在接到正式通知后及时传达给各支行和相关部门。

业务部门与科技部门相关人员配合，在五个工作日内完成相关指标的修改及测试。

如果发生重大变化，如人行接口程序发生变化时，要求系统开发商在2个工作日内到达，进行相关业务的开发，保证与人行系统同步，及时按新口径进行统计，确保统计数据按时报送。

（二）数据处臵程序故障的处理机制

对于统计数据处理程序故障，视情况及时应对。我行统计数据处理程序采用BS架构模式，如出现故障，可以分为三种情况：

（1）前端应用程序出现故障，导致业务人员无法登陆生 成报送打包文件时，报送数据不会丢失，科技部门可在10分钟之内重新搭建前端环境，确保不会影响到报送业务的正常处理。

（2）数据库端出现故障，导致报送数据无法生成时,科技 部门可手动执行程序生成报送数据，整个生成数据的过程所需时间在1小时之内，确保不会影响数据报送。（3）装载数据库的pc-server机器出现软件或硬件故 障，导致报送数据无法正常生成时，可启用备用设备。备用设备的软件环境与正式运行环境完全一致，可在最多1个工作日内采集完成所需所有数据，保证报送程序正常工作。出现故障的服务器视故障严重程度，最多在5个工作日内会完全恢复至原状态。

（三）人员的配臵机制

对于人员配臵方面，实施AB岗制度，确保不因人的因素影响数据报送工作。

所有统计岗位都设立AB岗模式，以A岗为主，B岗为辅，若A岗人员离岗时，会及时移交给B岗人员。系统维护上也配备两名技术人员。

如统计人员更换，要求前任统计人员做好统计资料的交接，负责新任统计人员的培训，并指导一至二个报送周期后方可离岗。

（四）报送及时性的保障机制

统计部门与其他报送数据的部门保持联系，制订明确的数据上报时间，要求各数据报送部门按时报送。

对基层机构数据报送工作纳入内控考核，出现迟报、漏报和误报现象及时纠正，视情节给予内控扣分。

（五）数据更新的保障机制

现行机制下，我行金融统计报送系统与核心系统的基础数据是同步的，当本机构下设机构、部门发生变更时，金融报送数据系统会在次日采集核心变化的基础数据进行相应更新。

统计部门人员要在发生变更的次日进行数据测试，确保数据更新的及时和完整。

（六）报文报送途径的应急机制

一旦发生我行与人行数据接收系统无法链接时，数据报送管理员可下载打包好的报送数据到存储介质人工报送至市人民银行。

（七）计算机病毒的防控机制 服务器已安装企业版杀毒软件与防火墙，杀毒软件能够实时监控自动杀毒，对病毒进行防控。

遇到无法查杀病毒，导致报送数据的机器无法使用的最坏情况，则启用备用服务器重新生成报送数据，生成数据过程所花费时间在1个工作日之内。

（八）不可抗力的应急机制

遇到重大自然灾害，将启动特殊情况处理方案，导致主服务器及备用服务器硬件设备损坏，无法产生报送数据时，科技部门会取定期异地备份的数据库数据，在5个工作日内重新搭建报送环境，确保完成报送工作。

备份系统和数据 篇3

在Windows 7中我们可以通过控制面板打开备份和还原功能，对系统和数据进行备份，而微软目前也已经在Windows 10中实现了该功能，通过“设置|更新和安全”，并选择“备份”，我们可以选择“使用文件历史备份”功能，通过将文件备份到另外的驱动器来保护文件。其次，单击下方“正在查找较旧的备份？”下的“转到备份和还原（Windows 7）”链接，我们可以打开Windows 7的备份还原工具，导入旧系统和数据备份。对于从Windows 7和Windows 8升级的用户来说，升级后一个月内可以通过“设置|更新和安全|恢复”中的“回退到Windows 8.1”（根据原系统版本不同，选项相应变化）回到原来的系统。另外，从Windows 8开始，可以在“设置|更新和安全|恢复”中单击按钮完全初始化系统，或者在不影响数据的情况下恢复系统到刚安装的状态，在Windows 10中也将让用户选择保留或删除个人数据，如果保留则在刷新系统后保持数据完好，但已安装的程序将被删除。

分散的系统备份功能

Windows 10仍然有系统恢复功能和支持文件快照的文件系统。如果需要备份单独的文件夹，则可以通过“设置|更新和安全|备份”选择“使用文件历史备份”功能，将指定的文件夹备份到USB硬盘驱动器之类的外部存储介质。该功能可以自动备份用户的个人文件夹，例如在固定的时间间隔备份文档、图片和音乐。如果用户使用微软的云存储服务，那么激活OneDrive将可以同步OneDrive文件夹。如果需要调整OneDrive文件夹的配置，则除了可以在资源管理器中右键单击OneDrive文件夹设置，也可以通过任务栏上的OneDrive图标配置和打开OneDrive文件夹以及查看同步设置。

数据广播系统 篇4

随着互联网的延伸, 无线通信技术的发展, 数据库技术的大规模应用以及硬件设备的快速更新, 一种新的应用——移动计算应运而生了。所谓的移动计算, 就是指在任何时间, 任何地点, 即使是在移动的情况下, 人们也可以通过智能终端设备, 如PDA (个人数字助理) 、掌上电脑、笔记本电脑、个人信息管理器等, 通过无线网络进行立即通信, 访问所需资源。

1 移动数据库

所谓移动数据库就是在移动环境下由固定节点和移动节点构成的分布式数据库, 移动数据库的体系结构如图1。在该结构中, 由固定网络和移动蜂窝节点构成。

注:MSS:Mobile Server Station, 移动服务站FH:Fixed Host, 固定主机DB:DataBase, 数据库MC:Mobile Client, 移动客户端/移动终端

在固定网络中, 有不带无线通信接口的固定主机 (Fixed host, 可以是数据库服务器也可以是普通固定节点, 保存有服务器数据的复本) , 还有带有无线通信接口的移动支持站 (MSS) 。一个移动支持站管理一片区域, 通常称作为一个Cell, 该区域内的所有移动节点都通过无线网络与MSS通信, MSS通过固定网络与数据库服务器进行通信。

在移动数据库的研究领域, 主要有以下几个研究方向:数据复制与缓存、数据广播、事务处理、位置相关查询。数据复制是固定节点上维持数据库服务器上数据的拷贝, 缓存是移动终端上维持数据库服务器上数据的拷贝, 主要是用来提高系统的可用性、可靠性和性能。数据广播是在移动环境下, 利用移动终端和服务器通信信道的非对称性, 服务器周期性地向终端发送数据广播, 它不依赖终端的数量, 能够很好地解决在断接情况下服务器与终端的通信。事务处理是移动数据库中最关键的问题, 主要解决用户对数据库访问时数据一致性控制。位置相关查询主要解决移动对象在移动过程中如何快速有效地对数据进行查找。

2 数据广播

在移动计算环境下, MC经常与服务器处于断接状态, 这是由于: (1) 移动用户由于无线通信费用高, 不愿长时间持续与服务器连接, 主动与服务器断开连接; (2) 由于无线信号的不稳定性或MC移动到网络信号覆盖的范围之外而与服务器断开连接。

为了满足移动计算的可用性, 通常是在移动终端上维持一个数据库, 保存有该终端所感兴趣的数据的一个复本, 当网络断接时, 用户可以直接操作本地数据, 并将更新保存在本地数据库上, 并将事务保存在日志文件中, 待重新连接到网络上时, 向数据库服务器提交事务日志, 进行冲突检测后, 在服务上执行事务, 将最终的结果写入数据库服务器中, 并采用广播的方式向其他节点广播更新数据, 维持数据的一致性。

在移动计算环境下, 服务器向终端的下行带宽要远远大于终端向服务器的上行带宽, 而终端接收数据的代价也要小于发送数据的代价。终端不用每次都向服务器发送消息, 请求更新本地数据。即使是终端在断接状态无法向服务器发送数据时也可以选择是否接收服务器发送的广播数据。因此, 服务器广播哪些数据, 在什么时刻广播是很值得研究。

3 基于冷热的数据广播

热数据:用户访问频率较高的数据称之为热数据;冷数据:用户很少访问的数据称为冷数据, 和热数据是相对的。

在数据库中构建一张冷热数据表, 它有3个字段:DataObject (数据对象标识) , AccessCount (访问次数) , BroadcastCoun (广播次数) , 如表1所示。

DataObjectn:数据对象n;

Ani:数据对象n被访问了i次;

Bj:系统广播了j次;

系统初始化时, 冷热数据表中AccessCount和BroadcastCount字段都为0, 每广播一次, 该表中所有记录的BroadsCas字段都加1, 某数据对象被访问一次, 该数据对象在冷热数据表中对应AccessCount字段加1。

用数据对象的访问次数与广播次数的比值ξ来评价数据对象是否是热数据。要给定一个介定值ρ, 当ξ≥ρ时, 该数据对象就是热数据, 否则就是冷数据。

利用冷热数据可以在数据广播时选择热数据而不用广播所有的数据, 也避免了随机选择数据进行广播时既浪费带宽资源又不能满足移动客户端的数据需求带来的问题。但是仅仅广播热数据可能会带来某些冷数据被请求而无法得到最新数据, 导致事务在本地执行后提交时回滚, 影响系统的性能。可以折衷一下, 使得每次广播时数据集中大部分是热数据, 少量是冷数据, 这个比例可以依照事务执行回滚率来动态调整。这样既能提高带宽利用率, 也可以提高本地事务向服务器提交的成功率。

数据广播调度算法的一个性能指标是调协时间, 即一次请求数据过程中接受到的广播次数。广播过于频繁会浪费大量的带宽资源, 过于稀疏又会导致移动客户端数据不能及时获取最新值而最终导致事务回滚。在国内, 有不少学者对移动数据库中数据广播进行了深入研究, 提出了优化调协时间的算法, 但都缺乏可操作性, 不支持移动数据库系统的实现应用。

4 结束语

随着移动通信技术的发展, 移动数据库还在不断地发展, 成为当今研究的一个热点, 但大都停留在理论研究阶段, 没有比较成熟的商业应用。但网络及硬件技术的发展和应用的需求使移动数据库系统成为一个必然的趋势。数据复制与缓存、数据广播、事务处理、位置相关查询等都是移动数据库中的关键问题。本文就数据广播进行了探讨, 提出了基于冷热点的数据广播。其最大的优点是广播开销不依赖于移动节点的数量变化。借助数据广播, 可以在一定程度上解决移动节点的断接问题, 并且既能提交下行带宽利用率, 也可以提高本地事务向服务器提交的成功率。

参考文献

[1]Pietro Iglio.TrustedBox:A Kernel-Level Integrity Checker[M].IEEEPress, 1999.

[2]张鹏程, 段莉明.嵌入式移动数据库概述[J].河南广播电视大学学报, 2008 (2) .

[3]余波, 钟锡昌, 张倪.移动数据库中的事务模型[J].计算机工程, 2005 (5) .

[4]曾文英, 赵跃龙, 宋玮.移动数据库关键技术的研究[J].计算机工程与应用, 2009 (5) .

[5]龚春红, 金敏.移动数据库关键技术的研究与分析[J].科学技术与工程, 2007 (8) .

数据库审计系统 篇5

概述

近几年来随着计算机在政府审计,社会审计等外部审计工作中的逐步应用。审计组织,审计手段和审计管理等也正在发生着重大变革。特别是“政府金审工程”实施以来,已硕果累累:在审计组织方式上,从审计现场的单机审计,发展到审计现场的局域网审计,以及目前正在试点实施的远程联网审计;由对被审计单位电子数据实施分散审计发展到对电子数据实施集中审计。在审计手段上,从利用计算机检索,关联,计算等功能对电子数据进行分析,发展到利用计算机技术将审计人员的经验,技巧,方法智能化,进而利用分析性测试等先进审计方法系统分析电子数据。在审计的客体上,从单纯审计电子数据,发展到既审计电子数据,又对与财政财务收支相关或与固定资产投资建设项目相关的数据信息等的合规性,经济性实施审计监督。在计算机运用的范围上,实现了从利用计算机实施审计到运用计算机管理审计项目的跨越。

数据库审计子系统的网络审计功能通过对数据包中数据操作语法的分析，可以知道对数据库中的某个表、某个字段进行了什么操作，并可对违规的操作产生报警事件。

数据库审计系统功能

数据库审计系统采用网络传感器组件，对特定的连接数据包（数据库远程连接）进行分析，从数据库访问操作入手，对抓到的数据包进行语法分析，从而审计对数据库中的哪些数据进行操作，可以对特定的数据操作制定规则，产生报警事件。

由于数据库系统的种类比较多，所以数据库审计从网络方面入手，监控数据库的操作。可以审计所有的远程数据库操作，通过旁路技术实现审计。如下图所示：

问题与挑战

在E系统和S系统中,业务数据存储的审计是。所以,我们在分析了审计管理项目的要求之后,建议。

1,数据的分级管理审计管理,主要由数据文档构成,其间的计算部分非常少。把数据根据不同的类别,不同的需要,不同的时间分别管理好,就是本系统的主要目的。

2,数据的输入,查询,修改

我们知道,一个系统的使用方便与否,直接关系到系统的质量及使用价值。因此,在考虑系统的使用方便性方面,本系统也作了很大的努力。

第二,所有标准的名称,代码都预先输入,设置等,这即可以减少输入的困难,也避免了出错。

第三,外部文件输入时,采用选择与直接拖入两种方式,选择方式,主要针对单个文件进行处理,而直接拖入方式,则可以对一组文件进行处理,一次可以处理多达数十个文件。而且,这两种方式,都不需要用户输入文件名,而是直接从外部文件的系统名称直接获取。这样,不仅快速,也更准确,安全。

第四,CS与BS的工作方式。利用传统的CS计算机程序语言,在CS模式下,完成本系统的主要工作,特别是对于内部人员来说,这种方式具有安全与快速的特性,同时也便于各种基本数据的输入与修改,对数据的追加,修改置于防火墙的保护之内。但CS方式的缺点,也是明显的,不可忽视的:就是,它需要对相关的计算机安装必要的程序及控件。为了便于查询,特别是相关领导,他们只需要看数据,报表,或仅仅对数据作极为少量的修改,如确认等,我们对这样的用户,提供了BS格式的访问方式,也即标准的互联网访问方式。这样,即可以不安装相关控件,也可以不受地域的限制,显得十分的方便与快捷。

建议

数据采集系统的设计 篇6

张连华

摘要：单片机作为微型计算机的一个分支。其应用系统的设计方法与一般的微型计算机应用系统的设计在许多方面是一致的。但由于单片机系统通常作为系统的最前端。设计时更应注意应用现场的工程实际问题，使系统的可靠性能够满足应用的要求。数据采集是单片机应用系统中最为重要和普遍的应用要求。数据采集的对象可以是温度、压力、流量等各种物理量。数据采集系统可以是复杂控制系统的一部分。也可以是配备显示(或打印)输出的独立系统(或仪表)。

关键词：单片机；温度；设计

中图分类号：TP274+.2文献标识码：A文章編号：1000-8136(2009)35-0164-02

1模拟通道的组成

模拟通道的一般构成见图1。

1.1传感器

传感器把被测的物理量(如温度、压力等)作为输入参数，转换为电量(电流、电压、电阻等)输出。物理量性质和测量范围的不同。传感器的工作机理和结构就不同。通常传感器输出的电信号是模拟信号(已有许多新型传感器采用数字量输出)。当信号的数值符合MD转换器的输入等级时，可以不用放大器放大；当信号的数值不符合A／D转换器的输入等级时。就需要放大器的放大。

1.2多路开关

多路开关的作用是可以利用一个A／D转换器进行多路模拟量的转换。利用多路开关轮流切换各被测回路与A／D转换器间的通路，以达分时享用A／D转换器的目的。常用的多路开关有CD4051／CD4052和AD7501／AD7502等。

1.3放大器

放大器通常采用集成运算放大器，常用的集成运算放大器有OP-07，5G7650等。在环境条件较差时，可以采用数据放大器(也称为精密测量放大器)或传感器接口专用模块。

1.4取样保持器

取样保持器具有取样和保持两个状态。在取样状态时，电路的输出跟随输入模拟信号变化；在保持状态时，电路的输出保持着前一次取样结束前瞬间的模拟量值。使用取样保持器的目的是使A／D转换器转换期间输入的模拟量数值不变，从而提高A／D转换的精度。常用的取样保持芯片有LF398，AD582等。

当前输入的信号变化与MD转换器的转换时间慢的多时，可以不用取样保持器。

1.5A／D转换器

A／D转换器的主要指标是分辨率，A／D转换器的位数与其分辨率有直接的关系。8位的A／D转换器可以满量程的1／256进行分辨。A／D转换器的另一重要指标是转换时间．选择A／D转换器时必须满足采样分辨率和速度的要求。

2数据采集系统的设计

2.1设计要求

设计一个温度数据采集系统，被测温度范围是0-500度，被测点为4个。要求测量的温度分辨率为0.5度。每2s测量一次。

2.2器件选择

传感器选用镍铬一镍硅热电偶，分度号为K(旧分度号为EU-2)。当温度为500度时，热电势为20.64 mV。

满量程为500度。对于0.5℃的分辨率要求，A／D转换器要具有0.5／500=111000的分辨能力。8位的A／D转换器的分辨能力为1／256。10位的A／D转换器的分辨能力为1／1024。5G14433具有1／2048的分辨率。

每2s对4点进行一次巡回检查时，每点取样时间为2s/4=0.5s，即1s取样2次。对于5G14433．当外接电阻Rc为300 kn时，时钟频率为147 Hz,每秒转换约9次。

另外，还需要将热电偶输出的20.64 mV的信号放大到5G14433的输入电压为2V，放大器的增益为2000／20.64=96.9。为了提高放大器的抑制共模干扰的能力，多路开关选用差动多路转换器CD4052。

由于温度信号变化缓慢，可不用取样保持器。

2.3硬件电路

数据采集系统的模拟输入通道电路见图2。

图2中未画出显示及输出部分电路，数据放大器可以选用单片高性能数据放大器芯片，也可以采用普通运算放大器组合而成。

2.4软件流程

关系数据库管理系统数据字典研究 篇7

1 数据字典物理存储

1.1 数据字典的定义

数据字典的一个重要作用就是提供最终用户数据库所有的信息, 在物理存储上就采用跟其他用户表一样的实现, 提供统一的接口。而数据字典的主要作用还是提供给DBMS自身使用, 在实现上还跟整个数据库的结构功能相关。

1.2 数据字典的逻辑功能

具体来说, 关系数据库中的所有数据信息与关联都与数据字典有着十分紧密的联系。数据字典具有着对关系数据库中的所有对象进行定义的逻辑功能, 除此之外, 数据字典还可以对关系数据库中的序列值进行默认、对数据库中的各种信息进行约束、对数据库中的用户信息进行存储和统计、对数据库中的用户权限进行分辨, 并且还可以对数据库中的各种信息的定义以及它们之间的关联进行操作与辨别。

由于关系数据库之中的各个对象之间存在着较强的关联性, 当用户对某一对象进行删除操作时, 往往会由于该对象与其它对象之间的关联程度与类型不同而产生一定的影响。例如数据库用户在PRLMARY KEY上建立起一个unique index文件, 而这个unique index文件的主要功能就是帮助PRLMARY KEY实现其自身的功能任务。而由于PRLMARY KEY是依附在一个数据表中的, 当删除表或是表中的相关信息有所变动时, 依附于这个表存在的PRLMARY KEY中的unique index里的信息也会相应的被删除或有所变动。而数据字典负责的功能就是将关系数据库中发生的这些关联信息与操作完整的记录和保存下来。通常来说, 关系数据库中的所有这些关联对数据库的用户都是公开透明的, 而另一种情况就是数据库用户为了方便自己的操作或是其它因素, 在对数据库中的对象进行删除操作时需要加上由用户自己设定的关系语句才能实现删除操作, 当此删除操作实现时, 与该对象有着密切关联的其它信息也会一并被删除。

1.3 物理记录的存储格式

关系数据库中的数据字典与用户数据都是以表的形式被记录保存在关系数据库的物理文件中的, 并且关系数据库管理系统中有着多种物理存储格式, 每一种物理存储格式都有着各自不同的特点, 相互之间具有较大的差别, 而这都是由于关系数据库管理系统中并发模式类型的不同造成的。现阶段, 我国的数据库管理系统将加锁模型与多版本模型作为最为主要的两种并发模型。其中加锁式并发模型的特点是记录格式简单、无需版本信息就能实现, 如SQL Server并发模型。而多版本并发模型主要有Oracle数据块并发模型。该种并发模型不仅需要用到物理记录来对数据库中的版本信息进行记录, 而且还需要物理格式的帮助来实现对数据库系统的并发控制及相关的事务处理, 比较复杂。

2 数据字典内存表示

2.1 CACHE作用

关系数据库管理系统能够通过对数据字典中的信息数据进行读取来获得数据用户以及数据库中的对象与存储信息, 当数据库用户需要对某些数据进行查询和相关的操作时都需要利用其所发出的SQL语句来对数据字典中的信息进行查询, 查询频率非常高。现阶段, 我国的数据库管理系统主要由两部分组成, 即CACHE与RELCACHE。其中CACHE主要负责的是对数据库管理系统中的表进行存放。在该部分中, 一个系统表能够利用ID查询、NAME查询与主键查询中的任意一种方式进行查询, 除此之外, 用户也可以通过部分键对该系统表进行查询。当查询操作完成后, 关系数据库系统会根据数据字典的分析最终弹出用户需要寻找的表格。

而RELCACHE部分的每一项都是一个RELATION结构, 该结构对此结构中的所有数据信息与关联进行了记录与保存。并且此结构能够将关系数据库系统中的所有与需要查询事件相关联的描述信息进行联合构造, 以更好的满足数据库用户的需求, 提高关系数据库管理的质量与水平。

2.2 数据库的启动与CACHE的初始化

使关系数据库能够启动并发挥其应有的作用, 操作人员至少要做好以下三个步骤, 即将一个实例启动, 之后对数据库系统进行装配操作, 第三, 将数据库系统打开。使数据库的CACHE系统得以初始化的方式有两种:第一种, 在数据库系统建立时进行CACHE的初始化, 主要负责对数据库系统的内存进行分配;第二种, 数据库系统已经建立完成后在启动时进行初始化操作, 此时, 内存已经分配完毕, 用户只要正常进行启动操作就可以完成CACHE的初始化。

3 结束语

本文主要对关系数据库管理系统的数据字典程序进行了分析介绍与研究, 希望能够进一步推动我国关系数据库系统的管理质量, 促进关系数据库系统的进步。

参考文献

[1]程阳.关系数据库管理系统的一种简易的数据存储与查询模块的设计与实现[D].华中科技大学 (硕士学位论文) , 2012.

[2]冯玉才, 李东, 王元珍, 曹忠升.一种移动数据库管理系统的体系结构[J].计算机研究与发展, 2011, 38 (5) :620-625.

数据广播系统 篇8

随着社会科技的不断发展与进步,互联网得到了飞速发展,计算机技术也得到了广泛的应用,但另一方面信息的安全问题却日益突出,信息安全技术应运而生并得到了极大的发展。信息安全技术的核心是数据加密技术,它不仅能够加解密数据,而且还能够鉴别、认证数字签名等,从而使在网络上传输的数据的完整性、确认性及机密性得到了切实的保证。本文将DES算法和RSA算法的优点结合起来,将一个数据加密系统设计了出来,同时将Java安全软件包充分利用起来,实现了数字签名。

1 数据加密技术

1.1 私钥加密体制

私钥加密体制指在加密和解密时所使用的密钥是相同的,由两种类型,分别是分组密码和序列密码。分组密码对明文进行分组的依据是其固定的长度,用同一个密钥加密每一个分组,从而促进等长的密文分组的产生。序列密码又称流密码,因为它将明文数据一次加密一个字节或比特。和序列密码相比,分组密码使用于软件实现,并且具有较快的加密速度,因此在人们的日常工作和生活中得到了极为广泛的运用。

1.2 公钥加密体制

1976年,W.Diffie和Hellman最早提出了公钥体制,利用两个不同的密钥分开加密和解密的能力是该体制最大的特点。公开密钥在加密信息中得到了应用,而使人密钥则在解密信息中得到了应用。通信双方可以直接进行保密通信,而不需要事先交换密钥。同时,在计算机上也不能实现从公开的公钥或密文中将明文或密钥分析出来。

2 数据库“敏感”数据安全加密系统设计

2.1 数据库“敏感”数据安全加密系统的体系结构

该加密系统是在目前较为成熟的仿真网络体系结构HLA的基础上发展起来的,由两部分组成,分别是CA服务器端和客户端。在联邦成员中嵌入加密客户端,可以对各联邦成员之间的“敏感”数据进行加密,CA服务器则可以生成、分发及管理密钥。联邦成员和CA服务器之间及各个联邦成员之间进行通讯的途径是HLA-RTI接口。加密系统体系结构如图1所示。

2.2 数据库“敏感”数据安全加密系统的功能模块

CA服务器端与加密客户端组成了加密系统的功能模块。其中,CA服务器端的主要功能是认证客户端的身份、生成、存储并分发RSA密钥等。密钥是在用户口令字和大数分解理论的基础上生成的,每次有一对密钥(公钥和私钥)产生,用于对会话密钥进行加密和数字签名,也就是对称加密算法AES或DES、3DES算法的密钥;将生成的密钥对和申请者的用户名联系起来,促进一个关联目录的生成,以方便客户端查找即是密钥的存储;依据客户端的请求信息,在关联目录中将与之相匹配的信息查找出来,如果找到的话,就把密钥向请求的客户端发送即是密钥的分发。

加密客户端的主要功能是完成对文件的加密和解密、传输实时数据的加密和解密密文、管理和传输对称加密算法的密钥及和CA服务器交互等。其中,对称加密算法AES或DES、3DES及混沌序列加密算法的密钥均在密钥生成模块生成;密钥的加密传输模块主要是使会话密钥的安全得到切实的保障,也就是说,用公钥密码算法RSA的公钥对会话密钥进行加密,然后一起传输加密后的密钥和密文,在解密端,为了得到会话密钥,可以使用TSA的私钥来进行解密;实时数据的加密和解密模块的基础是混沌特性,在加密或解密实时数据时利用混沌序列密码算法。加密系统的功能模块划分如图2所示。

2.3 数据加密模块的设计与实现

混合加密体制是数据加密系统所使用的,它将对称密码算法具有的较快的贾母速度、较高的加密强度、较高效的加解密大量数据等能力进行了充分的运用;公钥密码算法具有较高的加密强度,密钥便于管理。为了弥补传统密码算法中不便于传递密钥的缺点,可以加密明文的密钥。将二者结合起来,可以实现数据传输的安全性。

2.3.1 3DES算法的设计与实现

目前,虽然DES具有较为广泛的应用范围,并且人们可以很方便地从公开渠道获取,但是因为DES只有56位的密钥长度,易于攻击,其加密强度已经远远不能满足现代安全的需要,因此可以将两个56位的密钥混合起来使用来完成加解密,这样密钥就达到了112位的长度,从而大大增强了加密强度,这就是3DES。3DES的算法原理如图3所示。

图3中密钥K1、K2是随机产生的。

三重DES算法的实现主要包括DES类和THREE类两个类。其中DES类的主要函数是public static byte[]encrypt(byte[]oword64,int[][]i Sub Keys)//加密;public static byte[]decrypt(byte[]b Cipher-text,int[][]Sub Keys)//解密。THREE类的主要函数是public static byte[]encrypt(byte[]oword,int[][]Sub Keys1,int[][]Sub Keys2)//解密;public static byte[]decrypt(byte[]sword,int[][]Sub Keys1,int[][]Sub Keys2)//加密,返回明文。

2.3.2 RSA算法的设计与实现

大数分解是RSA的安全性赖以存在的基础。公钥和私钥都是两个大素数的函数。RSA算法的实现主要包括三个部分,即生成密钥、加密数据和解密数据。在变量的定义方面,在对p、q、n、e、d、t进行定义时,利用Java中的大数Big Interger();在密钥的生成方面,利用publi boolean generate PQNTED(Stringe);在加密数据方面,利用public String Encrypt(String msg、Big Integer pbkey、Big Intiger n),在加密的过程中,在对所要加密的字节数组进行分组时,可以利用转换函数copy Bytes();在解密数据的过程中,利用之前产生的公钥n与私钥d。把所要解密的数据与公钥n与私钥d作为参数向加密函数public String Decrypt(String msg,Big Integer prikey Big Integer n)传递。

RSA只有在大数运算的基础上才能实现,只有这样才能执行大量的大数加减乘除和模逆、模幂运算。这就导致相对于其他特别是对称密钥算法来说,RSA的实现效率十分低下。本文设计的系统中生成的DES密钥用RSA替代的原因也就是这种速度上的差异。

本文设计的数据库“敏感”数据安全加密系统,将数据的加密技术和签名技术综合了起来,一方面解决了密钥的管理问题,另一方面也使数据的不可否认性及完整性得到了切实的保障,同时也将该系统网络通信的程序设计和界面设计方法提供了出来。本系统将集中主要的加密算法进行了具体的分类,使代码的高效性、可扩展性等得到了有效地增强,有利于以后的再次开发。

摘要：本文首先简要阐述了数据加密技术,然后从数据库“敏感”数据安全加密系统的体系结构、功能模块及数据加密模块的设计与实现三个方面,对数据库“敏感”数据安全加密系统设计进行了相关的研究。

关键词：数据库,敏感数据,安全加密系统,设计

参考文献

[1]胡向东,魏琴芳.应用密码学[M].北京:电子工业出版社.2006.

[2]贺雪晨,陈林玲,赵琰.信息对抗与网络安全[M].北京:清华大学出版社.2006.

[3]褚雄,王子敬,王勇.一种基于FPGA的DES加密算法实现[J].江南大学学报(自然科学版),2006,15(6):661—664.

[4]朱作付,徐超,葛红美.基于DES和RSA算法的数据加密传输系统设计[J].通信技术,2010,43(4).

[5]Compag,HewIett-Packard,InteI,Lucent,Microsoft,NEC,PhiIips.UniversaI Bus Specification(Revision2.0)[M].InteI,2000.

生产指挥系统实时数据采集系统 篇9

天然气分公司实时数据采集系统通过覆盖全公司范围的网络, 提取生产装置的运行数据、安全数据、电数据、水数据、仪表风、原料数据、质量数据等原始信息, 建立一个包含全公司范围内的生产管理信息的采集平台, 对生产过程进行实时监控和有效指挥。采集软件采用紫金桥®Realinfo监控组态软件进行开发, 目前共设置数采前置机43台, 人工录入及32台, 囊括分公司九个油气生产单位、两个储运单位、一个销售中心的43个油气生产站队24套装置, 57套控制系统和26个计量系统, 实现了8922个生产数据自动采集、组态, 969幅流程图和25幅装置区三维鸟瞰图的传输与发布。

数据采集系统逻辑结构图如图1所示。

二、生产指挥系统实时数据采集系统的组建

2.1天然气分公司计算机网络建设。通过对局域网和广域网的改造, 分公司机关及所属大队局域网全部利用光纤接入油田公司主干网。大队下属所有小队包括偏远站队、计量间和变电所接入全部利用光纤接入本大队局域网或油田公司主干网。

2.2架设系统硬件设备

架设中心服务器。在信息中心机房架设故障转移集群服务器。计算机通过网线物理连接并通过集群软件实现程序上的连接, 可以使计算机实现单机无法实现的容错和负载均衡。群集的优点是两台服务器工作时都将历史记录、事件记录、报警记录存储到相同的地方, 两台机器不需要频繁同步。集群服务器双机热备过程如图2所示。

在每个装置设立前置机, 负责采集生产装置中控制系统的数据, 将数据传送给中心服务器。同时设置人工录入机, 负责录入不能自动采集的数据, 并将录入数据传送到前置机。

在前置机的设立中采用了断点续传技术。

断点续传技术用于数据库之间以级联方式进行通讯时, 当前置机与服务器间通讯中断, 前置机每隔一定周期, 向服务器发出传输数据指令, 超过超时时间后仍不应答, 将自动保存数据, 在规定时间内如果通讯故障排除, 那么这段时间内的历史会自动从子数据库中恢复到主数据库上。

2.3实施数据采集。通过在数采前置机和工控机间做数据采集的接口, 以工控机做服务器, 以数采前置机做客户端, 把工控机中数据写入实时数据库。生产装置中前置机和工控机的接口主要有以下几种:OPC (FOXBORO、ME) 、DDE (813、BENTLY、燃机) 、DB PLC (PLC) 、力控, 其中数量最多的是OPC和DDE两种技术。

2.3.1OPC接口技术。OPC (OLE for Process Control——用于过程控制的OLE) 定义了应用Microsoft操作系统在基于PC的客户机之间交换自动化实时数据的方法。OPC技术基于COM/DCOM, COM透过一组一组的接口提供服务, 所有COM组件的使用者必须透过这些接口来访问组件提供的功能。

OPC客户和OPC服务器进行数据交互可以采取同步方式或异步方式。

同步方式每一次读数据时读取该组中的所有项, 得到返回的数据后在采集周期内再次发出读取申请, 得不到数据就不结束此进程;异步通讯方式中, 客户端把关心的数据点通知Server, 并且提供一个回调函数, 只有关心的数据发生变化时, OPC服务器才调用其回调函数, 通知客户端做相应的处理。

在前期实时数据采集中, 大部分通讯方式采用异步方式, 在后期的测试中发现几个站队数据采集不上的现象。分析原因后发现, 工控机的OPC Server版本比较低, 同时, 数采通讯的优先级别要远远低于工控机本身数据处理的优先级, 在有大量的系统运算时, 就会出现服务缓慢或中断的现象。南一、一大队杏V-I原稳、杏三浅冷、六大队深冷都出现了这种现象, 如果改成同步通讯方式, 不断地发出读取申请, 又会增加工控机和数采机的负荷, 针对此问题, 研发了单组同步通讯方式, 它是同步通讯方式中的一个特例, 这种方式把原数据组中数据项重新分成若干组, 采取少量多次的方式采集, 以牺牲部分采集效率为前提, 既保证数据采集不中断, 又极大的减小了工控机和前置机的负荷。

2.3.2 D D E接口技术。D D E是一种动态数据交换机制 (Dynamic Data Exchange, DDE) 。使用DDE通讯需要两个Windows应用程序, 其中一个作为服务器处理信息, 另外一个作为客户机从服务器获得信息。客户机应用程序向当前所激活的服务器应用程序发送一条消息请求信息, 服务器应用程序根据该信息作出应答, 使用共享的内存在应用程序之间进行数据交换。

数采前置机将通过以上几种接口方式从工控机 (Server端) 采集到数据写入实时数据库, 形成基础数据, 创建生产信息数据仓库, 再通过数据整合, 形成可供各层面人需要的生产信息。

2.4web发布。采集的各种数据被分门别类的存储到数据库中, 通过将各个装置的流程、重要装置、关键参数控制点、重要数据进行合理布局, 做成高仿真的工艺流程图, 并将流程图中的数据与实时数据库中的数据源相关联, 每隔固定周期刷新一次, 使得生产人员可以在网络中的多个终端实时监测生产过程。

目前, 我们公司范围内的任何单位的终端, 为了防止公司的生产数据泄密, 我们给不同单位加了一定的访问权限。

三、存在问题及运行效果

目前, 生产指挥系统的实时数据采集系统还存在一定问题:

工控机对外通讯服务版本低。在前置机和工控机的通讯服务方式中, DDE是微软早期开发支持的一种通讯技术, 由于现在微软转而支持OPC接口技术, 而使DDE处于一个停滞不前的发展状态, 导致目前DDE通讯速度要明显低于OPC。D D E的服务机制也比较脆弱, 在生产指挥系统中8 1 3、BENTLY等系统都使用DDE服务, 导致在这部分的数据采集中更容易出现问题;在实施力控系统数据采集的时候, 由于技术人员很了解力控软件的开发过程, 将力控的系统服务进行了升级改动, 使对外通讯能力达到数采的基本要求, 才保障通讯的正常进行, 所以, 技术相对落后的力控系统对数据采集以及以后的采集能力的升级也是一种制约;目前OPC技术比较成熟, 但我们装置中工控机的控制系统大都是90年代左右的产品, OPC Sever的技术也已经大大落后, 我们不得不采用一些小的技术措施, 在不影响工控机本身的数据处理速度的前提下, 降低它系统资源的需求量, 以满足数采需求。

鉴于以上几种情况, 建议将生产装置中的控制系统进行升级或改造, 保证系统对大量系统运算处理更迅速, 对异常事件反应更及时。

人工录入部分数据量大。系统中有人工录入机32台, 人工数据录入点1202个, 要求每小时录入的数据是854个, 每八小时和二十四小时录入的是348个, 从一定程度上加重了岗位人员的劳动强度, 建议在检修改造中将这些点进行改造, 加装能够远传的二次表, 实现自动采集, 以减少劳动强度, 避免人工录入误差。

从总体上来说, 实时数据采集系统在生产中发挥的作用还是有目共睹的。

数据广播系统 篇10

近年来,随着综合治税工作的深入开展,涉税信息目录及采集范围不断扩大,税收征管、行政许可、建设项目、注册登记等各类涉税信息数据规模快速增长,特别是综合治税信息系统在省市县三级的推广与应用,为综合治税数据分析与决策支持提供了规模庞大的数据资源。研究如何基于这些海量数据开展数据分析,从中获取与综合治税相关的信息与价值,为各级税务部门加强税源控管、堵塞税收漏洞、实现信息管税提供支撑,具有重要的理论和现实意义。

数据仓库是一个面向主题的、集成的、非易失且随时间变化的数据集合,用来支持管理决策[1],是实现数据整合和分析利用的最佳解决方案。目前,综合治税信息系统所使用的数据库,是按照联机事务处理(OLTP)的要求进行设计的,其数据结构、内容用法与数据仓库有很大不同,无法满足复杂查询和数据挖掘的需要。例如,复杂查询所涉及的多表链接、汇总排序等操作,会很大程度上影响系统相应速度[2]。因此,构建综合治税数据仓库,以数据仓库为基础开发综合治税数据分析系统,是充分利用综合治税数据资源,提升涉税信息利用水平的有效手段。

1 功能需求分析

根据综合治税数据整合与应用需求,数据分析系统建设应以信息管税为目标,按照“覆盖广泛、详实可靠、开放共享、安全高效”的原则,依托数据仓库技术,逐步将税收征管、行政许可、建设项目、注册登记等各类涉税信息接入系统,构建集信息采集交换、审核校验、统计汇总、分析预测、应用发布为一体的综合治税数据仓库,实现第三方涉税信息整合分析与深度应用,包括以下主要功能:

(1)涉税信息采集交换。按照综合治税信息共享目录的要求,依托现有综合治税信息系统,通过人工报送和自动交换两种方式采集原始涉税信息,形成综合治税数据仓库初始数据。此外,系统应提供异构数据源支持,支持半结构化和非结构化数据采集导入功能。

(2)建立综合治税数据仓库。按照数据仓库设计、建设要求,按照统一编码体系,对原始涉税信息进行抽取、转换、装载(即ETL过程)。此外,系统应能根据数据仓库的数据处理流程,按照数据质量控制标准对数据进行校验和审核,保证数据正确性。

(3)涉税信息报表和查询。根据综合治税工作需要,按照规范的数据统计口径,建立综合治税数据统计报表体系,定期生成各类统计报表。同时,系统应提供直观的查询功能,能够对报表数据进行钻取操作,实现从汇总数据到明细数据的分层下钻和逐级浏览。

(4)税收风险评估。以第三方涉税信息整合应用为出发点,建立风险评估模型,通过模型将各类涉税信息与税务部门的征管信息进行比对分析,及时发现税收管理的薄弱环节,查找定位税收风险点,堵塞税收征管漏洞,为提高税收征管水平提供数据支撑。

(5)重点税源监控。依托涉税部门提供的企业生产经营信息以及税务部门的税收征管信息,建立重点税源监测指标,对重点纳税人的经营与纳税情况进行监控,并以图形、表格等形式进行展现,直观地反映微观经济主体的运行状态,为制定税收优惠政策、促进企业发展提供参考。

(6)税收收入预测预警。基于综合治税数据仓库所整合的历年度税收数据,建立数据挖掘模型,将税收收入与相关宏观经济指标进行关联分析,对二者的相关性进行深入挖掘。此外,借助计量经济学模型,对税收收入未来走势和波动幅度进行科学预测,为税收政策的制定和领导决策提供依据。

2 系统架构设计

系统整体架构如图1所示,分为4个层次:数据采集层、数据服务层、应用分析层、信息展现层。

图1 系统整体架构

(1)数据采集层。数据采集层是整个系统中涉税信息的统一入口,该层能够屏蔽异构数据源的差异,使系统中后续数据处理基于统一的数据接口,降低技术复杂性。系统采集的各类涉税信息,首先在这一层中进行保存,既能减少对数据源性能产生影响,又能在数据ETL失败时再次加载,从而提高系统效率。

(2)数据存储层。数据存储层根据分析主题的要求,采用星型结构对业务数据进行建模,形成数据仓库逻辑模型和实体模型。在数据处理方面,数据存储层先通过ETL处理从数据采集层获取原始数据,再按照数据模型结构对原始数据进行整合,形成一系列事实表和维表。此外,部门数据分析所需数据集市也在该层进行设计和实现。

(3)应用分析层。应用分析层基于数据存储层中的模型数据,对信息展现层提供不同类型的数据分析服务。其中,即席查询服务通过语义层映射机制,可以为涉税信息自定义查询提供支持;报表服务通过定义报表模板,提供可扩展报表生成和查询服务;OLAP通过建立多维数据结构,为复杂数据分析操作提供快速响应服务;数据挖掘服务通过封装特定算法,对综合治税数据进行关联分析,为风险评估、预测预警等系统功能提供支撑。

(4)信息展现层。信息展现层按照数据分析需求,将数据仓库中的数据以及应用分析结果,通过数据展现工具以图形、报表、文字等形式呈现到用户面前。此外,还提供管理维护界面,完成包括用户管理、权限分配等系统管理功能。

3 关键技术实现

3.1 数据自动交换

涉税信息采集是进行数据分析的前提和基础,信息采集的质量直接对数据分析结果产生影响。因此,对于信息化程度高、业务数据集中存储的涉税部门,应当建立数据自动交换平台,实现涉税信息的自动采集,提高数据的完整性、准确性和及时性。

数据自动交换技术的实现模式主要有两种:一是数据库复制模式,其优点是交换双方数据库结构相同,交换数据的内容能够保证较好的一致性和实时性,缺点是扩展性和适应性不足,对异构数据交换的支持较差;二是前置机模式,其优点是支持数据库、文件、接口服务等多种接入方式,有较好的适应性和扩展性,数据交换流程可配置、管理和监控,缺点是数据较难实时同步,交换服务程序对硬件要求较高。本系统采用前置机模式,在各涉税部门部署数据交换前置服务器及软件工具,利用XML文件对异构数据格式进行转换,在保持数据库相对独立和自治的基础上,实现涉税信息的自动提取、整理、传输和保存[3]。

3.2 ETL

ETL是建设数据仓库的重要步骤。在完成不同部门、不同类型涉税信息采集后,涉税信息需要经过抽取、转换、加载进入数据仓库,形成一系列维表和事实表,为后续数据分析与挖掘提供数据基础。在数据抽取环节,系统采用触发器的方式,在数据采集层保存涉税信息的同时,启动对应的数据抽取处理,实现数据采集与ETL的有效衔接,确保采集的涉税信息及时进入数据仓库;在数据转换环节,要对涉税信息的有效性进行检查,然后对照税收收入、纳税人登记信息等事实表,以及区划、行业、税种等维表,经过数据变换、清理、集成、聚集和概括等处理,形成格式一致的事实表和维表数据[4];在数据加载环节,要将转换完成的事实表与维表,批量存储到综合治税数据仓库中。

3.3 数据建模

在数据仓库数据建模中,星型模式能够提高查询性能,降低维表复杂度,因而得到广泛应用[5]。在此模型中,根据数据分析的主题构造事实表,用于存储分析数据的度量值和维度值;根据数据分析的角度构造维度表,用于存储分析数据的维度值(包括历史版本)。事实表和维表以主外键的形式进行关联,形成主题分析所需的星型模型[6]。例如,分产业税收分析主题所对应的数据模型如图2所示。

3.4 联机分析处理

联机分析处理(OLAP)是数据仓库的主要应用,专门设计用于支持复杂的分析操作,侧重对决策人员和高层管理人员的决策支持。在应用分析层,OLAP服务利用数据仓库的模型数据,根据主题分析需求建立多维分析模型(CUBE多维立方体),并以ROLAP方式进行存储,可从不同层次、阶段共享、存取和分析涉税数据[7]。在信息展现层,系统采用Cognos组件,按照用户的分析需求,以报表、图形、记分卡、仪表盘等多种形式,把CUBE的数据和分析结果展现给最终用户。

4 结语

建设综合治税数据仓库,并以此为基础构建综合治税数据分析系统,是充分利用综合治税数据资源、提升综合治税信息价值的有效手段。本文从应用角度,阐述了综合治税数据仓库及数据分析系统的功能、架构和关键技术。综合治税数据的深层次数据挖掘功能及其实现等问题,还有待进一步研究。

图2 税收收入分析主题数据模型

摘要：为提高综合治税涉税信息利用水平,实现对各类综合治税数据的整合分析与关联比对,为数据分析提供应用支撑,在分析系统业务需求的基础上,设计了基于数据仓库的综合治税数据分析系统,探讨数据自动交换、ETL、数据建模、联机分析处理等关键技术。

关键词：综合治税,数据仓库,决策支持

参考文献

[1][美]荫蒙(Inmon,W.H).数据仓库[M].王志海,译.北京:机械工业出版社,2006.

[2]林建明,琚春华,李军.基于数据仓库的财政综合信息分析系统研究与设计[J].计算机时代,2008(9):24-26.

[3]张丽华.基于XML的异构数据交换技术研究[J].苏州科技学院学报:工程技术版,2010(6):77-79.

[4]黄容,党齐民,陈宝树.财政数据仓库的设计开发[J].计算机工程与应用,2003(32):190-193.

[5]陈荣保,何伟华,戚维田.基于数据仓库的财政收支多维分析系统设计[J].常州信息职业技术学院学报,2008(1):13-15.

[6]张军占,陈光伟.基于数据仓库和OLAP的城市财税分析系统的构建[J].计算机与现代化,2008(9):126-128.

数据广播系统 篇11

【关键词】 数据仓库 数据挖掘 关联规则

【中图分类号】 R-3【文献标识码】 B【文章编号】 1007-8231（2011） 08-0655-03

在计算机技术飞速发展的今天，传统的数据库技术已经不能满足大数据量的分析要求。医院信息系统在多年的建设和发展中，积累了大量的原始数据。如何使这些陈旧的信息进行再开发和利用，从中提取出有用的信息，为临床和管理服务，是我们建立数据仓库，进行数据挖掘的目标和意义。

我们通常的数据处理分为两类，一类是对这些数据只是进行传统的操作型处理，第二类是分析型处理。操作型处理也叫事务处理，通常是对一个或一组记录的查询和修改。要求的是响应时间，数据的安全性和完整性。分析型处理也叫信息型处理，用于决策分析。想进行深入的DSS、多维分析等就要访问大量的历史数据，而这样的分析应用就会影响传统数据处理的响应时间。所以我们有必要引入数据仓库概念。数据仓库技术为历史数据的分析和处理提供良好的基础，数据挖掘使这些海量数据真正成为有用的信息。

目前医院已经有了各种信息子系统，有收费子系统，出入院管理子系统，门诊管理子系统，财务系统，病案统计子系统等等，所有子系统都同时使用一个大型的数据库，虽然硬件的配置能使系统处理数据能力较高，但是同时进行深入分析和统计时还是会降低数据处理能力，管理人员分析经营成果也没有方便有效的途径和方法。要提高分析和决策的效率，必须把分析型数据从事务处理环境中提取出来，按照分析的需要进行重新组织，使用软件工具来多方面多层次分析数据，建立数据仓库，应用数据挖掘正好可以满足这些要求。

首先在数据处理方面，传统数据库必须要将每年的数据分开统计，以提高实时的数据查询处理能力。历史的数据连查询都要分别统计，更不用说做深入的分析和应用了，而且提供的分析统计功能基本只能提供简单的查询和统计，需要专业人员设置好报表，才可以对数据进行统计。这样的数据库技术已经慢慢跟不上医院的飞速发展了。引入数据仓库技术以后，可以为提升速度，从而对数据进拆分。例如可对当月数据，直接以当前的HIS数据库为数据源，只做前台数据处理和查询使用，对隔一段时期的历史数据，定时导入到数据仓库中，数据仓库数据库在物理上与在线处理系统分离，这样做大数据量分析的时候就不会影响到在线处理系统的运行，从而造成死机，服务器瘫痪等情况，它相当于一个数据病案室。将当前数据源的数据在相隔一个期间以后，提交到数据仓库，用来提供管理分析。并且分析数据时不需要专业人员事先设定好报表，由原来被动的、固定的报表模式，到现在各级领导可跟据自已的想法，从现有的模型中主动挖掘出自已想要数据，能够充分挖掘医院信息系统的信息资源，提高医院信息系统的的应用分析水平。

其次在分析应用方面

1可以对医院医疗收入状况进行分析，以了解相关因素对医疗收入的影响

例如：以“门诊”为主题建立挖掘模型，从门诊的挂号人数，就诊时间，化验检查次数、时间、金额，取药次数、金额等方面对门诊病人就诊效率进行分析，在就诊时间上、手续上分析，发现影响就诊效率的根本所在，从而提高效率，增加门诊收入。例如采用统计分析方法对门诊病人就诊效率进行分析。如图

表1星期情况分布表

表2号种情况分布表

表3月份情况分布表

通过这些数据分析出影响就诊时间的原因，以改进医疗服务的质量。

2可以对药品采购，储存，出售，浪费情况进行分析

以“药库”为主题建立挖掘模型。从出库趋势、库存量、库存单位盈利和厂商盈利等四方面进行数据挖掘和分析。数据分析的结果为医院管理者提供管理和经营方面的决策支持，从而避免出现药品积压、药品无计划采购和药品浪费等问题

例如采用关联规则对药品的购买进行分析：（所谓关联规则，是指数据对象之间的相互依赖关系，而发现规则的任务就是从数据库发现那些确信变和支持度都大于给定值的强壮规则。）例如：将医院2010年10月—2011年九月的药房发药的数据作为源数据转换后载入数据仓库，给定最小支持度为25%和最小可信度60%对其进行关联分析得出药品的关联度如

Rule1:浓鱼肝油--->枸椽酸钙surport=0.4542Confidence=0.7323

Rule2:枸椽酸钙--->浓鱼肝油 surport=0.3041 Confidence=0.5937

Rule3:美托洛尔--->替米沙坦surport=0.3298confidence=0.5892

Rule4:替米沙坦--->美托洛尔Surport=0.4838 Confidence=0.7230

从上述规则可得出结论，浓鱼肝油多半会跟枸椽酸钙配合使用，而枸椽酸钙却不需要同时配合浓鱼肝油，同样的，替米沙坦对美托洛尔的依赖成度也较高。因此在药品采购时可以根据得出的关联规则来考虑药品配合使用的问题，调整药品的库存及采购数量。还可以根据此规则把相关的药品放在相近的药品架上，提高药房的发药效率。

数据仓库和挖掘应用是一个不断深入、不断完善的过程，完成了一个主题，一个应用，又会提出更多的应用需求。还可以对病人信息分析，医疗信息分析、绩效评估，疾病的治疗方式和成果等方面进行更深入的研究和实践。从而及时发现潜在的病因，疾病的耐药性和治疗周期等等，不仅仅为医院，甚至可能为整个医疗事业带来令人兴奋的成果。

参考文献

[1]陈京民.数据仓库与数据挖掘技术.北京:电子工业出版社,2002,95-96.

[2]康晓东．基于数据仓库的数据挖掘技术[M]．北京：机械工业出版社，2004．

数据广播系统 篇12

由于传统存储设备容量、传输带宽有限,而且设备节点扩展难、使用难、数据管理难,不足以应付不断增长数据的存储要求,对于需要面向不同地域分布的用户进行服务更是无力应对。随着信息化基础设施的不断完善、大数据技术突飞猛进的发展,使得构建一种支持大数据架构存储的集群式数据管理系统成为可能。

1 关键技术点

1.1 集群技术

集群是将一组独立的计算机系统通过网络有机连接,主要解决高可用性、高性能计算、扩展性等问题。

集群的模式主要包括两种模式,负载均衡和冗余模式模式。

对于负载均衡,目前比较常用的负载均衡技术主要有基于DNS的负载均衡[2]、反向代理负载均衡和基于NAT(Net Address Translation)的负载均衡。

基于DNS负载均衡是通过DNS服务中的域名解析来实现负载均衡,在DNS服务器中,可以为多个不同的地址配置同一个名字,而最终查询这个名字的客户机将在解析这个名字时得到其中一个地址。因此,对于同一个名字,不同的客户机会得到不同的地址,他们也就访问不同地址上的WEB服务器,从而达到负载均衡的目的。

反向代理负载均衡使用代理服务器可以按照某种算法将会话连接均匀地转发给多台内部服务器,从而达到负载均衡的目的。

基于NAT的负载均衡技术使用内部地址和外部地址之间进行转换,以便具备内部地址的计算机能访问外部网络,而当外部网络中的计算机访问地址网关拥有的某一外部地址时,地址转换网关能将其转发到一个映射的内部地址上。这样,地址转换网关能将每个链接均匀转换为不同的内部服务器地址,从而达到负载分担的目的。

对于冗余模式,主要分为全冗余备份、互为冗余备份、中央备份服务器三种模式。

全冗余模式:集群中的每台服务器都会备份其它服务器的Session,当一台服务器发生故障,可以失败转移到其它任意一台服务器上。

互为冗余备份:A会有B的数据,B会有C的数据,C会有A的数据,如果A出错,就会由C接替A的工作。

中央备份服务器:N+1模式,一个中央Server存放所有Session,如果一台Server宕机,接管的Server就从中央服务器恢复相关Session数据。

1.2 分布式存储计算平台

Hadoop是Apache软件基金会所研发的开放源码项目,它是一个分布式存储计算平台,可以在其上开发和运行处理海量数据。让用户通过跨集群的计算机完成大型数据集的分布式处理任务。用户可以利用该框架在大量廉价计算机上构建一个具有高可靠和良好扩展性的分布式处理系统[3]。

它的两大核心内容为[4]:分布式文件系统(Hadoop distributed file system,HDFS),是分布式计算中数据存储管理的基础,具有高吞吐量数据访问能力、高容错性、高可靠性和高扩展性等提点,可用于存储海量级别的数据(Tbyte甚至Pbyte);Map Reduce(Google Map Reduce的开源实现)算法模型,是一种编程规范,2004年Google研究员通过对网页存储和并行分析处理研究后,在文献[5]提出该模型,并在ACM等多个期刊上转载[6,7],Map Reduce用于处理大规模数据集的计算模型,它可以将一个应用程序分解为多个并行计算指令,依靠大量的计算节点完成数据集的分布式计算,用户通过编写Map和Reduce两个函数来完成对应的逻辑功能,实现分布式处理的模型和算法,原理如图1所示[8]。

HDFS文件系统使用副本存储策略来实现高可靠性。系统的冗余因子一般为3,分别位于3个Data Node上,其中一个位于不同集群上,当一个Data Node出现故障后,其保存的数据仍然可以通过其他Data Node上保存的数据进行读取网络断开会造成一组Data Node和Data Node失去联系,Name Node根据缺失的心跳信息判断故障情况。当一个在Data Node出现故障,这时Name Node就再复制该Data Node的副本并存储到其他Data Node上,以此来保证系统的高可靠性。当用户需要访问文件系统中的文件时,都需要向Name Node提交请求,获得相应的权限后,再对Data Node进行读或写[2]。系统原理如图2所示[10]。

2 系统方案

2.1 需求分析

现有的数据文件管理系统大都基于FTP客户端和本地磁盘阵列完成的简单数据管理系统,不具备分布式扩展能力,而且客户端使用不方便、与客户业务结合不紧密,不支持多客户并行使用及海量数据文件的管理。

本方案建立一套在大数据集群架构层面的利用WEB技术进行管理的数据管理系统,提供统一的门户网站,支持接口一致的数据获取和下载访问,支持对数据权限的细粒度分配,包括组织架构设置、任务设置、审批流程的设置等。

基于大数据集群架构的数据文件管理系统应具备以下特点。

(1)统一的门户:提供用户管理、文件管理、任务管理、组织架构设置、审批流程控制等全面的控制能力。

(2)随时接入与访问数据:能够在任何终端、平台登录系统,接入和访问数据。

(3)高扩展性:能够通过堆叠硬件,零配置增加存储能力且用户访问能力不降低的系统性能。

(4)高可靠:系统具有冗余能力,在单点损坏的情况下能够报警并自动启用冗余节点。

(5)高安全性:系统具有统一认证的权限控制能力,防止非法用户访问未授权数据。

2.2 系统架构

大数据集群架构的数据管理系统是以数据管理和存储为核心的计算平台,它的内涵主要是在分布式存储平台基础上,通过集群应用、网络技术和分布式文件系统等技术,将网路中大量不同类型的存储设备集合起来协同工作,共同对外提供数据存储和业务访问功能,并能够保证数据的安全性并节约存储空间。实现了存储介质的互联和数据的统一管理、共享、冲突解决、透明存储、容错容灾、一致性及数据迁移等功能,传统存储设备主要是指简单的硬件,例如:阵列、光纤存储等,而大数据集群架构的组成则是存储设备、网络设备、应用软件、服务器、访问接口等多部分的高效组合。基于大数据集群架构的数据管理系统主要由3层组成,它是一种典型的层次结构。

存储层的设备主要是指最底层设备,包括:Nas、FC、i SCSI等,统一由上一层的虚拟化管理设备进行集中管理,对底层设备进行状态监视和审计维护等。考虑到就近服务的要求,以提高当地用户的体验,并增加抗毁性,可以把存储集群分布在不同的区域,各个区域间的集群通过网络互联形成逻辑上对用户透明的存储设备。

基础管理层是核心层,通过利用集群技术、分布式文件系统技术、数据压缩、加密技术实现不同区域间多个存储设备的协同工作,一体化对外提供服务。为了保证数据安全性,采用了数据加密技术,同时为了提高数据可靠性,采用数据容灾备份技术。

应用层主要提供了基本的用户权限认证、权限管理、部门组织架构、审批流程控制、数据驾驶舱管理、任务管理等业务层面的控制和应用,为用户提供业务层面的统一界面。

本系统前端采用WEB架构进行部署,后端采用Hadoop的HDFS分布式存储系统,前端软件利用负载均衡模式进行集群化部署,后端Hadoop系统自身具备了冗余模式的集群管理方式。

应用服务器集群采用Tomcat组成集群,使用分组集群架构,利用Tomcat自身的全冗余session备份模式,集群中的每台服务器都会备份其它服务器的Session,当一台服务器发生故障,可以失败转移到其它任意一台服务器上。

2.3 软件架构

大数据集群架构的数据文件管理系统前端采用HTML5进行人机交互设计,后端架构采用B/S架构设计,基于Spring MVC框架,实现模型、视图、控制器的分离,利于系统功能模块升级;权限管理采用Apache Shiro、界面显示框架采用Bootstrap、JQuery等Web应用主流框架/组件,降低开发风险和成本,缩短开发周期,提高整个系统安全性、稳定性、可扩展性。数据底层采用Hadoop HDFS文件系统结合My SQL数据库完成管理数据和数据文件的管理。

软件架构层次划分为分布式文件层、数据层、业务层和应用层四层。软件架构如图4所示。

分布式数据文件层有Hadoop的hdfs文件系统进行服务,直接对外提供数据文件的分布式访问。

数据层安装在独立的Mysql数据库内,保存数据文件的属性信息、用户信息、权限信息、组织架构信息以及任务信息等应用系统的基础信息。

业务层包含了用户、权限、工作流、任务控制、组织架构等信息的添加、删除、变更等基础管理服务,以及数据缓存机制,文件操作服务包括新建目录、删除目录、复制、合并、重命名基本文件操作。其中数据合并功能,可以将My Sql数据文件合并备份到分布式数据文件层,保证管理信息的可靠性,也提高了整个系统的可靠性。

应用层提供了相关业务层的人机交互界面,为用户提供统一的视图信息。

软件底层的核心主要是对Hadoop hdfs文件系统的操作。Hadoop有一个抽象的文件系统,HDFS只是其中一个实现,Java抽象类org.apache.hadoop.fs.File System定义了Hadoop的文件系统接口。Hadoop是通过Java编写的,通过org.apache.hadoop.fs.File System的具体实现类Distributed File System,可以调用所有的Hadoop hdfs文件系统交互操作。

综合利用Distributed File System和Hadoop提供的IOutils类完成数据文件的读写、查询等操作,实现业务层的文件操作功能。

分布式文件数据API操作的主要步骤是[9]:

(1)调用get函数得到文件系统实例,其中需要输入服务器的配置信息;

(2)调用open函数获取文件的输入流;

(3)调用create函数,制定Path对象,返回输出流;

(4)该过程可以使用Progressable重载方法跟踪执行进行;

(5)调用IOutils.copy Bytes方法完成数据的操作。

3 部署方式

3.1 原则

(1)可扩展性:服务器需具有横向扩展能力,因为随着应用和企业的不断壮大,用户增多,服务器应具备一定的可扩展空间;

(2)高可用性:为了保障服务的连续性,通常要求服务器不间断地工作,持续为用户提供连续服务,对于关键应用需要任何时间都可用,并且能保证响应速度。因此就要求服务器集群具有强大的处理能力,不能有单点故障,保证系统的高可用。

3.2 方案

通过对关键技术的对比分析,部署方案采用基于DNS负载均衡、反向代理均衡以及Tomcat全冗余session冗余备份的解决方案,DNS负载均衡作为全局负载器,通过分析客户在网络上地址,以及反向代理服务器的负载情况,将反向代理均衡服务器发布向客户,反向代理均衡器通过审视内部应用服务器的负载情况,将任务提交到空闲的服务器执行,并统一对外提供服务,而Tomcat自身的session全冗余备份模式,保证了服务的不间断和连续一致性。部署方案如图DNS全局负载均衡采用具有负载均衡功能的4层交换设备,反向代理服务器采用安装了ngix软件服务器,内部应用服务器利用tomcat部署小型集群。

通过以上部署,可以实现在广域网上不同地域服务器间的流量调配,保证终端使用最佳的服务,确保服务质量。

4 优势分析

(1)以WEB架构组建的数据管理应用,让用户有独享的数据管理界面,可以随时、随地接入,对数据进行管理、获取和分享。

(2)采用分布式集群架构,增强了多用户服务能力,只需通过简单的增加应用服务器,就可以从容的应对来自不同地域用户的激增。

(3)存储采用HDFS大数据分布式文件系统,较传统存储阵列带来了以下优点:

高性能,阵列主控一般链接速率6Gbps、10Gbps,总是有上限的服务能力,很难满足用户激增或数据吞吐量激增的情况,而随着用户、用户数据不断的增多,传统阵列架构将很难满足,而本系统数据分布在不同的Data Node节点上,每个Data Node节点都可以10Gbps为应用服务器提供数据,多台Data Node节点组合在一起,理想的吞吐率将达到10Gbps×N,远远超过传统阵列。

易扩充,该架构只需要通过简单扩展Data Node节点,就可以自动增加存储容量,传统阵列需要经过备份数据、重做阵列来扩充数据容量。

高可靠,一般默认配置下,该架构有3份的冗余存储,并可以通过策略来改变冗余的存储地域,保证了在不同地域、不同存储机柜都有备份。

经济性,可以利用廉价商用设备作为扩充节点,减少投入。

5 结束语

本文介绍了一种基于大数据集群架构的据管理系统方案,可以应用于需要在不同地域进行数据管理的场景,实现透明化数据管理与共享。通过利用HDFS分布式文件系统作为底层存储,上层利用Ngix反向代理的方式管理集群负载,解决了数据管理系统要求的高效性、高可用性和高可扩展性,以该架构搭建的系统能够解决在用户不断增多的情况下,较容易的通过增加硬件就完成系统的扩容,并具备异地就近服务、异地互备的能力。另外,前端搭建了WEB架构的数据管理应用系统,用户可以随时、随地的接入网路对数据进行管理和分享。

该架构为大数据架构的最基础平台,后期通过部署分布式计算框架或利用Map Reduce模型,将现有数据节点变为计算节点,可以方便的为用户提供并行计算服务。

摘要：由于传统存储设备容量、传输带宽有限,而且设备节点扩展难、使用难、数据管理难,不足以应付不断增长的用户及数据存储要求。针对这种情况,通过对现有大数据底层支撑技术的梳理,搭建了一种基于大数据集群架构的数据管理系统,该系统为满足支持不同地域海量数据服务的需求,考虑了高性能、易用性、易扩展和可靠性等方面的因素,解决了在用户激增的情况下,较容易的通过增加硬件就完成系统的扩容,并具备异地就近服务、异地互备的能力。

关键词：数据管理,大数据,集群,Hadoop Hdfs

参考文献

[1]沈志荣,易乐天,舒继武.大规模数据中心的数据存储可靠性[J].中国计算机学会通讯,2012,8(10):8-16.

[2]崔晶.基于DNS的Web服务集群负载平衡算法[J].中国科技信息,2007(5):118-120.

[3]陆嘉恒,文继荣,毛新生,等.分布式系统及云计算概论[M].北京:清华大学出版社,2011.

[4]蔡斌,陈湘萍.Hadoop技术内幕:深入解析Hadoop Common和HDFS架构设计与实现原理[M].北京:机械工业出版社,2013.

[5]Dean J,Ghemawat S.Map Reduce:Simplified Data Processing on Large Clusters[C].//Proc of 6th OSDI.San Francisco:USENIX Association,2004:137-150.

[6]Dean J,Ghemawat S.Experiences with Map Reduce:an abstraction for large scale compultation[C].//Proc 15th Inter-Conf on PACT.Washington DC,2006:1-2.

[7]Dean J,Ghemawat S Map Reduce:a flexible data processing tool[J].Communications of the ACM,2010,53:72-77.

[8]Apache Haoop[EB/OL].(2014-06-30)..http://hadoop.apache.org.

[9]李振举,李学军,杨晟.HDFS可视化管理系统设计与实现[J].微型机与应用,2015,34(8):80-82.