终于找到问题所在了,原来不是程序问题,而是数据质量问题

原创 2006年06月09日 03:07:00

本篇仅仅是本人工作中的感想,非做本行业软件人员看不明白的

我写的服务程序,任务有如下:

1、接受通讯服务器得自车辆的消息

2、分析消息,并按消息类别保存

3、自动划分班次,即车辆来的消息,是线性的,服务要根据线路各个站点的拓扑关系,将线性发上来的消息,按段分割,使其分属不同的班次

      当掉头,并且掉头后报上来的站点多于一个站点,则理解为掉头,原来班次结束,新班次开始;

      当到达终点站后,再报上来始发站消息,则将首次报始发站前的消息,归结为前一班次,后面的为新班次。

4、对于停车消息:

      a> 须整理上下车、留车人数

      b> 须将每次停车,归属于某个班次

5、实时统计技术指标

      断面按小时统计平均需用时间

      断面按小时统计留车人数

      断面按小时统计通过次数

      站点按小时统计上下车人数

。。。

      原来,断面车距与通过班次 的报表,显示的各个站点按时间段的通过差别很大,这肯定是有问题,因为,在一天内,除去中途掉头的特殊情况外,各个站点通过的班次,应该是一样的,而不同时间段即便有差别,也不会太大,并且应该是按照站点顺序线性分布的,可报表显示,各个班次无规律差别很大。

      本周的工作,就是修改服务,以解决此问题,幸亏服务有消息录放机,可以快速(约半小时可以播放并处理一天的数据)地模拟出一天的车辆消息,即便如此,也是修改了n次,模拟了n次,检查了n次报表,还是无果。

      终于,在今天半夜,找到了问题症结:数据源----车辆发来的消息有问题,在一个班次中间,会多次错报反方向站点的信息。

       虽然找到问题来源,但要解决,还是很困难,或者修改车辆终端的程序,或者试着修改兴趣点,或者上层服务来通过算法屏蔽这种情况。

      修改底层程序,需要时间可能会很长;

      检查是否兴趣点设置不合适,或许是最容易解决的方法;

      修改服务屏蔽这种错报,也比较麻烦,因为,这样的话,就不能实时分析统计了。如怀疑某个消息错误,则必须在其后续报上来的多个消息,最多要等到下个站点的消息上来后才能确定是真的掉头还是错报,这样的话,就必须也要阻塞本车辆后续消息的分析、怀疑错报站点的其他车辆报该站点的消息的分析。

      明天将问题提交,再由领导确定如何解决吧。

相关文章推荐

大型软件系统数据质量问题研究

  • 2011年08月30日 19:22
  • 102KB
  • 下载

关于数据仓库数据质量问题探讨

数据仓库的数据来自于多个数据源,所以数据的一致性很难得到保证,既然没有绝对的准确,那么就需要制定一个标准 字串1一、 数据质量和清洗字串4   ETL是数据仓库的最重要的基础,良好的ETL从业务系统中...

解决数据质量问题是大数据应用的关键

研究称,整个人类文明所获得的全部数据量,有90%是最近两年内产生的。随着移动互联大潮的席卷,预计通过网路产生的数据量还将呈几何级增长。庞大的数据资源蕴藏着无限的宝藏,过去的一年无论是企业、政府还是媒体...

质量问题跟踪表

  • 2012年05月23日 01:56
  • 32KB
  • 下载

中国式危机公关9加1策略(第十章 质量问题4步走策略)

第十章 质量问题4步走策略 第一节 质量问题4步走策略的应用背景 质量,对于消费者来说,永远是最能吸引他们的话题,也永远是他们作出选择的最重要决定因素;对于企业来说,追求产品质量,也永远是他们持久...
  • tiewen
  • tiewen
  • 2012年02月22日 10:13
  • 7563

App 创业者的福音,应用质量问题将完美解决

很多的App创业者过这样的痛苦经历:好不容易开发出来了App,上线之后被反馈应用体验不佳、业务流程有缺陷,更严重的是各种闪退。应用质量问题使得App恶评不断,来自不易的种子用户迅速流失,创业团队陷入困...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:终于找到问题所在了,原来不是程序问题,而是数据质量问题
举报原因:
原因补充:

(最多只允许输入30个字)