【摘要】
近年来，在应用需求的强大驱动下，我国通信业有了长足的进步。现有通信行业中的许多企业单位，如电信公司或移动集团，其信息系统的主要特征之一是对线路的实时监控要求很高，数据量庞大，如何将实时控制与信息系统集成在一起便成为系统实施的一个关键部分。
在参与了某个通信公司的一套网管系统以及决策支持系统的设计后，我们分析了两者的集成与应用工作，深切地感受到有一个良好的设计策略以及重视所选用的工具是一个关键。这个项目主要是对下属各分站的子网以及有关链路的连通情况进行实时监控、实现报警、路由控制和授权等功能，其关键在于提供一个实时显示情况的地图界面，井将数据汇总和组织，建立起数据仓库以及进一步实施数据挖掘分析，从而能支持企业的决策分析。我作为设计人员之一，着重在本文中讨论控制系统与信息系统集成时的策略。
【正文】
众所周知，通信行业需要有一整套监控通信网络的手段，其工作特点是涉及到的各分站与基站的在地理位置L的分布性，更加需要有在更高一级提供检测不同分站链接情况的手段。一般来讲，由于数据都是海量的，所以，如何将整个网络系统所得的数据及时处理，以便和决策部门的分析相结合，也成为迫切需要解决的重要课题。简言之，分布性、实时性以及数据海量性是解决整个系统设计和集成的核心问题。
首先，让我们来讨论一下“网管监控系统”。由于我参与设计与开发的这个系统并不是位于基层的分站，其定位在将下属各分站的主机通信数据（包括数据流量、链路负荷、通往其他结点即主机的连通情况等）加以收集，所以对于具体通信事务的底层操作要求并不很高。
考虑到上述原因，我们采用了一个地理信息系统开发平台Mapinfo并采用Delphi编程，后台用SQL Server数据库（这是由于考虑到决策所需要用到的是Microsoft公司的OLAP Service）。在分析和计划之前，我们先对ITU801标准做了详细的探讨，这只是一个有关子网和链路定义以及分层等描述的标准，在听取了许多分站人员的建议后，将MAPINFO公司提供的一个相关的MAP X的Active X控件嵌入到Delphi程序中，利用MAP X中提供的丰富的类以及操作，比如Object、Layer等实现网管界面，井且加入了子网和链路的概念，对属下的分站可以随意地组合成为不同子网，而且实现了放大与缩小的功能，大致可以将整个地区的分站集中在一张地图中，能显示在屏幕上，这时，只是显示出各个分站的概要，小到可以显示出某台主机的机柜、机柜直到插件板（因为这些都要实时监控）。我们采用了分层的方法来实现以上缩放。对于一些静态的数据，如分站，主机的位置等则先用Mapinfo公司提供的一套编制地理信息的工具（MAP X是其提供给编程工具的一个Active X控件）做成静态的层次图放置于数据库中。
我们新做成的这套系统通过与各分站的专用线路加以连接，能实时地得到数据，显示于地图上，反映出各站、各子网、各链路的实时状态，并能将控制命令传回分站（如强制链路中断、路由转换等）。
现在，让我们来讨论其中最为关键的问题，即是要将实时控制系统与企业信息系统加以集成，我们的设想和体系结构大体上可以用一张简图表示（此处暂略）。
在这个体系结构中，由各分站保留着详细的数据，网管系统则在一定时间间隔内将汇总到的数据作少量统计，抽取其中需要保存的内容放入数据库，如每分钟流量，某分站与其他分站每分钟通信流量，在该分站中某个链路的负荷（这些链路有可能是动态分配的，也可能是固定分站之间的通信链路）。尽管如此，数据仍然是海量的，因此，如果要把这些数据都直接送到各个决策部门，比如送给市场部门是不现实的。所以，我们在数据库的基础上建立了数据仓库，确定了客户、时间、通信量、计费和故障等几个数据仓库的主题，每隔一定时间对数据库中的原始数据进行清理与抽取等预处理工作，建立好数据仓库。这里的预处理包括了许多方面的内容，比如有建立计算时间，但是无计费的（计费值为零）的数据，应视为建立失败的无效数据，需要予以剔除；某些企业租用的是专用线路按月计费，中间的通信因此无计费的一些有关记录也应剔除等。
在预处理之后，再利用OLAP Service的分析将数据融合与汇总。按照决策部门的需要提供相应数据（比如：市场部门需要每一分站的收益，客户分布情况以及客户费用等）。这些都可以由OLAP Service对数据作预先处理，此时处理完的数据在逻辑上是以立方体（CUBE）形式存在的，其占用的存储空间便能显著地降低，如1999年8月有2000万条通讯记录，即使形成作为备份的文本都需要4G空间，经过OLAP Service处理后仅需200M左右空间，因此，经处理后的数据主要存放于另外的相关部门的机器中，而不能与主服务器放在一起。
最后，再来讨论由决策人员所使用的系统。由于这些部门并不分散，我们就没有采用OLAP Servce的Web发布方案。采用Delphi编制了访问OLAP Service的客户端软件，用了OLAP Service提供的、Cube Browser控件，用相似于网页的界面提供了数据立方体的各种操作，如上钻（观察角度从月转到季度甚至年），切片，旋转等操作。为了便于输出打印数据，还内嵌了Microsoft的Excel数据透视表，可以将在Cube Browser上所看到的数据转化为Excel的表格形式，或者转换成饼形图、柱形图和曲线图等，比如可以观察每天24小时通信流量的分布曲线图，可以发现在夜间12点以后明显通信流量减少，而决策部门便可制定某些优惠或减价措施吸引更多客户在12点之后使用网络。
另外，在采用OLAP Service中的数据挖掘功能时，其中提供的两类算法分别是基于决策树的分类和基于决策树的聚类，市场部门的聚类算法将客户根据费用情况加以聚集，以期发现处于同一消费水平的客户的共同特征，便于制定政策，吸引客户。这方面的努力我们将会进一步持续进行，以保证有足够的海量数据而发现其中的规律。
整个系统运行后，其数据采集，数据处理等一系列工作都由程序定期地自动进行，该系统应用已有一段时间，受到了不少好评。当然，也发现了其中有不少问题，比如；主服务器数据库的容量问题，主站与分站的通信效率问题，还有在网管系统中，网络故障的确定还不够细致，需要由分站再具体化加以确定，决策系统与网管系统之间还缺少直接通信手段等，这些都有待于进一步的解决与改进。
实时控制系统与企业信息系统集成化是推动从事生产制造、测量与监控等业务的企事业单位真正迈向信息化，提高工作效率的一个重要动力。如果是大型企业，更需要有一整套的系统，支持Web发布，智能查询，自动识别如用于故障预测和数据挖掘等技术，从而能够将底层的实时监控与高层的决策更好地集成在一起。展望其前景，无疑是十分美好的，但是我们认为相应的工作量很大，在技术上仍然需要有所提高和有所突破。
评注：能紧扣集成的主题，结合实际作了较有深度的论述。所讨论的数据库和数据仓库技术符合企业信息化的方向。对遇到的问题的举例剖析还不够，实时控制方面的论述也可更细化一些说明。（本文主要参考了广东林嘉宜等人的论文）
近年来，在应用需求的强大驱动下，我国通信业有了长足的进步。现有通信行业中的许多企业单位，如电信公司或移动集团，其信息系统的主要特征之一是对线路的实时监控要求很高，数据量庞大，如何将实时控制与信息系统集成在一起便成为系统实施的一个关键部分。
在参与了某个通信公司的一套网管系统以及决策支持系统的设计后，我们分析了两者的集成与应用工作，深切地感受到有一个良好的设计策略以及重视所选用的工具是一个关键。这个项目主要是对下属各分站的子网以及有关链路的连通情况进行实时监控、实现报警、路由控制和授权等功能，其关键在于提供一个实时显示情况的地图界面，井将数据汇总和组织，建立起数据仓库以及进一步实施数据挖掘分析，从而能支持企业的决策分析。我作为设计人员之一，着重在本文中讨论控制系统与信息系统集成时的策略。
【正文】
众所周知，通信行业需要有一整套监控通信网络的手段，其工作特点是涉及到的各分站与基站的在地理位置L的分布性，更加需要有在更高一级提供检测不同分站链接情况的手段。一般来讲，由于数据都是海量的，所以，如何将整个网络系统所得的数据及时处理，以便和决策部门的分析相结合，也成为迫切需要解决的重要课题。简言之，分布性、实时性以及数据海量性是解决整个系统设计和集成的核心问题。
首先，让我们来讨论一下“网管监控系统”。由于我参与设计与开发的这个系统并不是位于基层的分站，其定位在将下属各分站的主机通信数据（包括数据流量、链路负荷、通往其他结点即主机的连通情况等）加以收集，所以对于具体通信事务的底层操作要求并不很高。
考虑到上述原因，我们采用了一个地理信息系统开发平台Mapinfo并采用Delphi编程，后台用SQL Server数据库（这是由于考虑到决策所需要用到的是Microsoft公司的OLAP Service）。在分析和计划之前，我们先对ITU801标准做了详细的探讨，这只是一个有关子网和链路定义以及分层等描述的标准，在听取了许多分站人员的建议后，将MAPINFO公司提供的一个相关的MAP X的Active X控件嵌入到Delphi程序中，利用MAP X中提供的丰富的类以及操作，比如Object、Layer等实现网管界面，井且加入了子网和链路的概念，对属下的分站可以随意地组合成为不同子网，而且实现了放大与缩小的功能，大致可以将整个地区的分站集中在一张地图中，能显示在屏幕上，这时，只是显示出各个分站的概要，小到可以显示出某台主机的机柜、机柜直到插件板（因为这些都要实时监控）。我们采用了分层的方法来实现以上缩放。对于一些静态的数据，如分站，主机的位置等则先用Mapinfo公司提供的一套编制地理信息的工具（MAP X是其提供给编程工具的一个Active X控件）做成静态的层次图放置于数据库中。
我们新做成的这套系统通过与各分站的专用线路加以连接，能实时地得到数据，显示于地图上，反映出各站、各子网、各链路的实时状态，并能将控制命令传回分站（如强制链路中断、路由转换等）。
现在，让我们来讨论其中最为关键的问题，即是要将实时控制系统与企业信息系统加以集成，我们的设想和体系结构大体上可以用一张简图表示（此处暂略）。
在这个体系结构中，由各分站保留着详细的数据，网管系统则在一定时间间隔内将汇总到的数据作少量统计，抽取其中需要保存的内容放入数据库，如每分钟流量，某分站与其他分站每分钟通信流量，在该分站中某个链路的负荷（这些链路有可能是动态分配的，也可能是固定分站之间的通信链路）。尽管如此，数据仍然是海量的，因此，如果要把这些数据都直接送到各个决策部门，比如送给市场部门是不现实的。所以，我们在数据库的基础上建立了数据仓库，确定了客户、时间、通信量、计费和故障等几个数据仓库的主题，每隔一定时间对数据库中的原始数据进行清理与抽取等预处理工作，建立好数据仓库。这里的预处理包括了许多方面的内容，比如有建立计算时间，但是无计费的（计费值为零）的数据，应视为建立失败的无效数据，需要予以剔除；某些企业租用的是专用线路按月计费，中间的通信因此无计费的一些有关记录也应剔除等。
在预处理之后，再利用OLAP Service的分析将数据融合与汇总。按照决策部门的需要提供相应数据（比如：市场部门需要每一分站的收益，客户分布情况以及客户费用等）。这些都可以由OLAP Service对数据作预先处理，此时处理完的数据在逻辑上是以立方体（CUBE）形式存在的，其占用的存储空间便能显著地降低，如1999年8月有2000万条通讯记录，即使形成作为备份的文本都需要4G空间，经过OLAP Service处理后仅需200M左右空间，因此，经处理后的数据主要存放于另外的相关部门的机器中，而不能与主服务器放在一起。
最后，再来讨论由决策人员所使用的系统。由于这些部门并不分散，我们就没有采用OLAP Servce的Web发布方案。采用Delphi编制了访问OLAP Service的客户端软件，用了OLAP Service提供的、Cube Browser控件，用相似于网页的界面提供了数据立方体的各种操作，如上钻（观察角度从月转到季度甚至年），切片，旋转等操作。为了便于输出打印数据，还内嵌了Microsoft的Excel数据透视表，可以将在Cube Browser上所看到的数据转化为Excel的表格形式，或者转换成饼形图、柱形图和曲线图等，比如可以观察每天24小时通信流量的分布曲线图，可以发现在夜间12点以后明显通信流量减少，而决策部门便可制定某些优惠或减价措施吸引更多客户在12点之后使用网络。
另外，在采用OLAP Service中的数据挖掘功能时，其中提供的两类算法分别是基于决策树的分类和基于决策树的聚类，市场部门的聚类算法将客户根据费用情况加以聚集，以期发现处于同一消费水平的客户的共同特征，便于制定政策，吸引客户。这方面的努力我们将会进一步持续进行，以保证有足够的海量数据而发现其中的规律。
整个系统运行后，其数据采集，数据处理等一系列工作都由程序定期地自动进行，该系统应用已有一段时间，受到了不少好评。当然，也发现了其中有不少问题，比如；主服务器数据库的容量问题，主站与分站的通信效率问题，还有在网管系统中，网络故障的确定还不够细致，需要由分站再具体化加以确定，决策系统与网管系统之间还缺少直接通信手段等，这些都有待于进一步的解决与改进。
实时控制系统与企业信息系统集成化是推动从事生产制造、测量与监控等业务的企事业单位真正迈向信息化，提高工作效率的一个重要动力。如果是大型企业，更需要有一整套的系统，支持Web发布，智能查询，自动识别如用于故障预测和数据挖掘等技术，从而能够将底层的实时监控与高层的决策更好地集成在一起。展望其前景，无疑是十分美好的，但是我们认为相应的工作量很大，在技术上仍然需要有所提高和有所突破。
评注：能紧扣集成的主题，结合实际作了较有深度的论述。所讨论的数据库和数据仓库技术符合企业信息化的方向。对遇到的问题的举例剖析还不够，实时控制方面的论述也可更细化一些说明。（本文主要参考了广东林嘉宜等人的论文）
1762
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
