[转帖]论移动计费中的话单删重技术

早已女玄马

对于计费系统来说，保证对一条话单只计一次费恐怕是最最基本的要求，但要真正做到却并不容易。前段时间浙大百名教授联合投诉中国电信，说电信计费不准确。浙大教授出示的证据中很重要的一条是：在电信局打印出的通话清单上居然有两条话单一模一样。中国电信搞了这么多年的计费，不可能不清楚重单问题，因此也肯定采取了一定的删重技术。那么，为什么到现在还有重单呢？很有可能的是：因其话单删重技术中的漏洞导致产生了少量重单。重单虽少，但对企业声誉的影响却极大。那么，对于我们公司，在服务质量就是企业生命源泉的今天，怎样才能彻底解决重单问题呢？

要解决重单问题，首先我们应该了解重单是怎么产生的以下几种情况可能产生重单：


l         交换机，GateWay，SCP，短信中心等这些计费数据源会产生重复的话单。

l         清算中心下发的省际漫游和国际漫游话单文件中可能包含重单。

l         清算中心下发2-3个月前的话单，导致计费系统中因话单时间过早而无法删除可能的重单。

l         实时采集系统在某些情况可能会重复取交换机产生的文件。

l         话单分拣和批价程序可能会对同一个文件进行多次分拣和批价，导致重单。

l         话单入库程序可能对批价后的话单文件多次入库。

l         错误处理时对某些话单进行重新处理可能会出现重单。错误处理是计费系统中最复杂，也是最容易出错的模块，因此在处理错误时可能出现重单。

现在我们不难发现：在计费的许多环节上都有可能产生重单。事实上，在这几年的计费中以上情况都出现过，有些至今还不断出现，比如交换机产生文件和清算中心下发的文件中至今还会出现重单。

为了删除重单，不同省份，不同运营商采用了许多种不同的技术，比如文件系统删重，查重表删重，和日表比对删重等。但是无论采用何种技术，都应该达到以下要求：

l         彻底。仅仅减少重单是不够的，必须保证整个系统中没有一条重单。记得有一个省曾经采用过这么一种删重技术：任何一条话单都跟其前后的几百条话单进行比较，如果没发现相同，就认为不是重单。据说，这种技术的依据是重单的分布符合某种正态分布。这样的所谓“删重”显然让人难以置信，因为这种办法最多只能删除一部分交换机产生的重单，根本不可能保证没重单，这样的“删重”显然是无法满足要求的。

l         可靠。对于删重，可靠的含义是：无论是在正常情况下，还是在某些模块出错的情况下都应该保证没有重单。因为计费系统从来都不是在一个理想的状态下运行的，经常会有意想不到的情况出现，所以只有可靠的删重方法才能彻底删重，才有实用价值。

l         实时。理想的删重是来一条话单就能判断其是否重单，如果做不到这一点，至少也要求做到在每天的汇总前删除重单。如果到了月底再去删除本计费月中的重单，可能会造成错误的高额，错误的实时扣款，甚至错误的停机。假如一个用户某天打了几个电话，银行帐号上有足够的钱，却因汇总前没删除重单，结果被告知帐号上钱不够了，说不定接着就被停机。这样即使到月底把重单删了，用户能答应吗？

l         性能高。计费系统每天要处理大量的数据，速度非常关键，因此必须保证所用的删重技术有尽可能高的效率。

l         简单。删除重单的方法越简单越好，因为简单的方法往往比较高效，而且不太容易出错，实现起来也容易。许多问题上，好的解决方法往往是简单的，就象《神雕侠侣》中独狐求败留下的玄铁重剑：“重剑无锋，大巧不工”。

l         有利于其他功能的实现。数据位于现代信息处理的中心，数据模型是稳定的，而处理是多变的。对于计费系统，数据库是一切功能的核心，因此必须从全局出发来考虑数据的设计。而话单删重技术对计费系统数据库设计有着决定性的影响，但在考虑删重的同时也要考虑系统其他功能的实现，比如汇总，高额，实时话单查询，话话单量监测，以及许多话务统计的要求。

明确了对删重技术的要求后，我们接着来讨论一下几种典型的删重技术。目前各运营商采用的删重技术主要有几种：文件系统删重，查重表删重，日表比对删重。其中查重表删重和日表比对删重都通过数据库来删重。这几种技术各有什么特点呢？哪一种技术最适合移动实时计费呢？

（一）   文件系统删重。

顾名思义，文件系统删重就是通过文件系统，而不是通过数据库来删除重单。从理论上讲，凡是数据库系统中能做到的，也一定能够在文件系统中实现，而且由于不需要象数据库系统那样考虑到各种各样的应用需求，因此通过文件系统来删重理论上应该可以取得更高的性能。但在实际中，删重除了要考虑性能之外，更要考虑其他要求。文件系统删重不象在数据库中删重那么方便，在数据库里一条SQL语句能实现的功能要是在文件系统里实现可能需要几千行代码，而且在保证数据完整性方面也很难做到数据库系统那样的水平。

对于非实时汇总来说，比如国外的多出帐周期，文件系统删重的办法除了技术难度和开发工作量都比较大以外，基本上还是适用的。因为非实时汇总通常在到每个月出帐日时才删重单，删重后马上就进行汇总并出帐，因此不会对删重后的数据再进行修改，也就不会再引入重单。

对于目前全国各省实行的实时汇总来说，文件系统删重却不太适用。因为对于实时汇总，在文件系统删重后仍有很多环节，而其中任一环节都有可能引入重单。所以即使你在文件系统中删除了所有的重单，但是怎样避免在话单入库时的重复插入呢？怎样在出错的情况下减去原来的汇总，删除原来的话单并根据原始CDR重新计费呢？这些在文件系统里恐怕是很难做到的。

因此，对于移动实时计费来说，文件系统删重技术是不适用的。

（二）   查重表删重。

查重表删重通过数据库的索引，在话单入库时完成删重工作。

其主要思想是：

l         在数据库设计上，主要采用话单表存放话单，用查重表删重。查重表只包含删重需要的关键字段，比如IMSI号和通话时间，在这张表中保留1-2个月的话单，查重表采用数据分区技术，按话单日期进行分区。

l         当入库程序收到一条批完价的话单后，先往查重表插入，如果插入成功，那么再向话单表中插入。由于查重表相对较小，且采用了ORACLE 8中的唯一索引表（本身既是索引又是表）技术和数据分区技术，因此往查重表插入的速度应该还比较快。

l         话单按处理日期分别存放到话单表不同的分区中。为什么按处理日期存放呢？因为每个月计费时都会有上个计费月，甚至更早以前的隔月延时话单，而实际向用户收费根据的是处理日期。如果话单按话单日期分区存放，到月底为了找出在本月计费的话单，那么即使对隔月延时话单加了标志位，也要把几个月内处理的所有话单都找一遍，速度慢，麻烦，且不可靠。所以这种技术要求话单按处理日期存放。

显然，这种技术可以彻底删除在交换机生成CDR过程中和分拣批价过程中产生的重单，而且在正常情况下可以保证在入库时不引入重单，基本上可以满足实时汇总对删重的要求。仅从删重方面考虑，这种技术似乎是可行的。那么，对于实时计费来说，这种技术是不是一种好的技术呢？

我们可以结合在前面提到的对删重技术的要求来分析这种技术。对于查重表删重，应该注意的两点是：

1.         话单按处理日期存放。

2.         话单表和查重表必须保持一致。

这两点意味着什么？

由于话单按处理日期存放，势必会给根据话单日期所做的统计和处理造成不便，比如查日高额用户，统计某个地区某台交换机24小时的话单数，看看某几天符合某些特征的话单量，处理5月1日国际长途折扣错误等等，另外也会给实时话单查询带来很大的麻烦。因为话单按处理日期存放，所以为了查找某天的话单，需要把在那天及那天之后处理的所有话单找一遍，程序复杂，且性能低下，远不如话单按话单日期存放那么简单。而且在实际的计费维护中绝大多数的维护和处理都跟话单日期有关，很少根据处理日期作什么统计和处理。

有人认为话单按处理日期存放，可以方便错误处理，理由是根据处理日期只要找出可以很方便地找出开始出错那天开始的话单。那么，是不是如此呢？假设某个错误是在计费月开始时出现，到计费月快结束时才发现，难到把所有这段时间的话单都重新处理一遍？这意味着对当月的话单全部重新计费，这样做在性能上恐怕无法忍受。事实上在做错误处理时基本上都是根据错单特征来处理，因为一般来说错单数量是不多的，但可能分布在每个地区。根据错单特征来处理比根据处理日期来处理性能高得多。所以，话单按处理日期不可能方便错误处理，而且在处理跟话单日期相关的错误时，反而麻烦。

另外，这种技术要求话单表和查重表必须保持一致。如果不一致，会有什么后果呢？如果话单表中有的话单在查重表中没有，那么就可能产生重单；如果查重表中有的话单在话单表中没有，那么可能把一些正常的话单当作重单删除掉。而且，一旦出现不一致，该怎么办？恐怕只能将错就错，因为你很难找出到底是哪些话单数据不一致，也很难使这两个表重新同步。因为再保持同步的唯一办法是清空查重表，然后把话单表中的数据重新往查重表插一遍，但这样做一遍可能要插入十几亿条记录，需要十天八天时间，这段时间里正常的计费必须停下来。

当然，如果应用这种技术时查重表和话单表不一致的概率是零的外，那以上的担心纯粹是杞人忧天。那么，到底有没有可能出现不一致呢？

首先，我们分析一下入库时是否可能造成话单表和查重表不一致。在正常情况下，话单被一条一条地插入，向查重表插入和向话单表插入在同一事务中，通过数据库的事务机制保证事务完整性。如果程序正确，应该不会造成不一致。但是，假设出帐前几天因网络故障或计费主机故障造成计费停了几天，积压了大量的数据，怎么办？还这样一条一条地插入么？这样做效率是非常低的。如果采用类似与SQL *LOADER这样批量导入工具，用DIRECT PATH方式导入，性能可以提高十几倍。但是，在这种情况下怎样来保证向两边插入的数据是一致的呢？因为这种批量导入的办法无法通过数据库的事务机制来保证向两边插入的数据是一致的，在这过程中可能会造成话单表和查重表的不一致。这样的外，遇到这种情况时只能象原来那样，一条条地插入，否则就可能造成话单表和查重表的不一致。

另外，我们看一下在出错处理时会不会引入重单。不管你信不信，对计费系统来说，经常会出现这样或那样的错，其中很大一部分不是因为计费程序出错，而是因为交换机维护，路由更改，资料不正确等原因。出错时怎么办？典型的出错处理过程是：根据出错情况归纳出错单特征à根据错单特征在话单表中找出错单à调用错误处理过程在所有汇总中减去错单的汇总à根据错误特征在话单表中删除错单à根据找出的错单的关键字删除查重表中的错单à找出原始的CDRà重新分拣批价à重新入库à重新汇总。由此可见错误处理是个非常复杂的过程，而且由于错误情况千变万化，具体的处理更复杂。为了保持话单表和查重表的一致，这意味着任何对话单表的插入和删除操作应该同时也对查重表执行。这样，不仅增加了错误处理的工作量，而且由于错误处理通常是临时过程，万一在这过程中出点错，造成话单表中删掉了，而查重表中没删掉，那该怎么办？ 因此，在错误处理过程中也极有可能造成话单表和查重表的不一致。

总之，查重表删重尽管能在一定程度上删除重单，但是却会给日常维护和统计，实时话单查询等带来很大不便，而且在出错情况下错误处理比较麻烦，容易造成话单表与查重表的不一致，影响计费准确性。因此，查重表删重不是一种理想的删重技术。

（三）   日表比对删重

在讨论这种技术之前，我想先解释几个概念。实时计费系统每天都会对前一天的话单进行删重和累计汇总。如果一条话单日汇总之后才到，这条话单被称为延时话单。根据延时话单日期的不同，又可以将延时话单分为当月延时话单和隔月延时话单，话单日期在当前计费月时间范围内的被称为当月延时话单，在当前计费月开始日期之前的话单被称为隔月延时话单。

日表比对删重的主要特点是：当天的话单在插入日表时由日表主关键字来防止重单，延时话单通过跟日表中的话单进行比对来删重。

下面以短消息计费为例，详细介绍以下日表比对删重的主要思想：

l         话单表分成三类，分别是日表，待处理延时话单表和隔月延时话单表。日表一天一张，存放每天的话单，比如：7月7日的话单就入到表CDR_SM_07_07表中。待处理延时话单表只有一张，无论是当月的还是隔月的延时话单都先入到这张表中，这张表名为CDR_SM_00_00。隔月延时话单表一个月一张，存放处理后的隔月延时话单。这样对于任何一个计费月，这个计费月的日表中的话单加上这个月的隔月延时话单表中的话单就是在这个月计费的话单。

l         入库前，话单按话单日期分成不同文件。入库时，当天的话单入当天的表，不用作任何判断。对于非当日的话单，要先查询数据库中的标志判断那一天的话单是否已经汇总。若未汇总，那么入日表，否则就入到待处理延时话单表中。

l         日表有主键，因此正常情况下对于当日话单不需要作任何的删重操作。在特殊情况下，如计费主机因故障停了几天的情况下，采用先用SQL *LOADER的DIRECT PATH方式快速导入，然后重建索引的方式来删除重单。

l         每天在做完日表汇总后处理待处理延时话单表CDR_SM_00_00，删除延时话单中可能的重单并汇总。处理时，将话单日期分类并作批量处理。对于当月延时话单，只需要跟相应日表去比较，看看是否有重单，有重则删之。对于隔月延时话单，除跟日表比对外，还要跟隔月延时话单表去比对，因为同样的延时话单可能今天来明天接着出现。删完重后将将当月延时话单插入相应日表，将隔月延时话单插入隔月延时话单表中。这样就可以删除延时话单中的重单。

显然，日表比对方式能删除所有可能的重单。那么这种方式与前面的查重表删重方式相比，到底有哪些优点呢？

l         彻底。不仅能删除交换机生成CDR时，分拣批价时的产生的重单，而且可以删除入库时重复插入的话单。即使入库程序重复插入，也能保证最后没有重单。

l         可靠。查重表删重容易在出错情况下造成话单表和查重表的不一致，而日表比对删重没这个问题。

l         效率高。在计费系统里，98%的话单是当天的话单，当月延时话单不到总量的2%，而隔月延时话单更少。虽然日表比对方式在删延时话单时速度相对较慢，但由于延时话单量很少，因此对系统性能影响很少。而且由于对占总话单数98%的当日话单删重操作速度非常快，所以系统总体性能比较高。而查重表删重对所有的话单都向查重表中插一遍以查重，因此速度比较慢。

l         抓住了删重的关键。就象解决大多数的问题一样，删重也要抓住关键。既然在原始CDR生成时，采集时，话单分拣和批价时，入库时都可能产生重单，因此在这之前删重没有任何意义。而汇总时要求数据库中没有重单，因此删重的关键环节应该在话单入库后，在每日汇总前。日表比对技术抓住了删重的关键环节。

l         简单。日表比对删重是一种比较简单的删重方式。因为这种技术很关键的一条是任何一条话单最后只在一张表中存在，所以不存在几张表中保持一致的问题。在错误处理时，不需要同时对话单表和查重表操作，因此也不必为保持这两者的同步而费脑筋。

因此，日表比对删重不仅能彻底删除重单，而且可靠、高效、技术简单，实现起来也容易。

总之，对于移动计费来说，保证没有重单是最基本的要求。由于在计费的许多环节上都可能产生重单，因此删重时必须全面考虑，处理时要抓住关键。在几种删重技术中，文件删重对于实时计费来说不太适用，查重表删重不是很可靠，而且会给其他功能的实现和日常维护带来不便。只有日表比对删重不仅能彻底删除重单，而且可靠，高效，简单，实现起来容易，错误处理和日常维护也比较方便，所以说日表比对删重是一种比较实用的删重技术。

作者：葛长伟