浅谈通信综合营帐数据中间层设计原则与处理流程

李绿色

摘 要：文章论讨数据中间层设计原则及数据处理流程。数据中间层是计费系统对外进行统计类数据提供的桥梁，以提高数据提供的方便性、快速性和安全性。

关键词：中间层；处理流程；模式；实体

数据中间层是计费系统对外进行统计类数据提供的桥梁，系统通计费过数据加工和整理把数据映射到数据中间层的各统计要素，报表统计直接通过数据中间层进行而不对计费系统的基础数据进行操作。通过这种方法提高了数据提供的方便性、快速性和安全性。

数据中间层和计费帐务系统中其他模块的关系：数据中间层主要的功能是从计费系统中抽取数据，经过加工整理（按照其他系统要求）向外界进行数据提供，数据中间层的抽取的数据对象包括用户资料、用户的服务使用信息（用户的业务使用记录）、用户的费用信息、用户的缴费信息、用户欠费信息、调帐信息、用户的账本信息等计费系统中核心业务数据，因此数据中间层和计费系统中各功能模块都有着非常密切的关系，各模块的行为会影响数据中间层的数据源，从而影响数据中间层的行为，为了保证数据中间层的数据和计费系统的数据一致性，数据中间层模块和相关模块应有通讯接口。从减少对计费系统正常运营的影响，数据中间层生成的不宜太多频繁，一般定时处理就可以满足要求（如一月一次、一天一次、一个小时一次）。

数据中间层生成和其他系统间的关系：CRM系统（特别是采用SID模式）为数据中间层提供客户资料信息，数据中间层抽取的数据是各种接口数据源和数据提供的数据源，统计报表在数据中间层抽取的数据基础上进行简单的加工，生成最终的各种统计报表。

1 数据中间层设计原则

1.1 三种运行模式

系统运行的模式，初步设计为三种模式：实时模式、定时模式和即时模式。

实时模式主要处理话单类的统计，由于这部分数据量大，也不要求月末处理完成，考虑跟随计费的处理流程，计费每完成若干个文件的计费，系统自动组织相关的任务进行处理，一个任务包含的文件数目多少，根据业务量的大小确定，这个参数由系统参数表中的process_file_num_per_batch确定。

定时模式主要处理需要月底进行统一处理的任务和需要每天进行处理的任务。月底处理的主要是费用性质的数据抽取任务，每天处理的主要包含欠费和缴费分析的任务。

即时模式主要用于处理系统无法确定什么时候应该开始处理的情形，和用户需要随机发布的数据抽取任务，一部分在定时模式中提及的任务，有可能也需要在即时模式的框架里面进行处理，比如月底的费用性质的数据抽取任务，由于系统无法确定什么时候出帐结束，稽核完成。这个时间点需要用户确定。

1.2 系统参数控制机制

设计若干的实体，并在系统中设置一组参数，最终用户具有控制这些实体是否生成的权利，这组参数在系统参数表（system_param）中，基本的命名方式是实体名称加_is_valid组成，这组参数的具体含义将在用户操作文档进行详细的描述。这里举一个例子简单说明一下：

参数stop_user_element_is_valid 是表的是否需要生成stop_user_element（拆停机用户分析数据的参数），在是否生成之间切换，只需要执行下列语句：

Update system_param set param_val='true' where param_name = 'stop_user_element_is_valid' 就可以要求系统生成這个实体。

Update system_param set param_val='false' Where param_name

='stop_user_element_is_valid' 就可以要求系统不生成这个实体。

1.3 处理引擎

引擎是一种机制，将设计方案中所设计的实体简单的分为用户发展相关、话单类统计相关、费用统计相关，欠费相关、缴费分析相关、用户费用异常分析、调帐分析等。这样就有了用户发展处理引擎、话单统计引擎、费用处理引擎、欠费处理引擎、缴费分析引擎、费用异常分析引擎、调帐分析引擎。之所以这里引入引擎这个概念的原因在于，这几类实体需要处理的原始数据都是基本一致的。考虑到系统的扩展性和性能问题，须将在相关实体集成在一起，统一处理，至于哪些实体需要处理，哪些不需要处理，在系统参数表中有一组参数用于进行这种控制。

处理引擎只是提供原始数据和公共服务的一种机制，它负责原始数据的读取和公共数据的收集，处理在处理引擎的机制中，但并不是它的功能，分析功能由相关实体的实现逻辑实现，在处理引擎中统一调用。

用户发展处理引擎负责读取用户资料数据，传送用户资料数据结点到用户发展处理的各个实体，由各个实体引用用户资料结点信息，结合自己的实体实现逻辑生成各自的信息结点数据包并存贮在内存Hash表中，处理引擎处理完成一批数据后调用存贮子程序存贮所有实体，存贮子程序调用各实体的存贮程序将在内存Hash中的数据保存在数据库表格中。

话单统计引擎负责话单的读取和公共数据资源的获取，传送话单数据和用户资料信息结果体给相关分析结点，由相应结点按照自己的业务逻辑进行分析处理，形成目标数据，存贮在内存中，在一个批次处理完成后，话单统计引擎会发起该批次处理结束的消息。这时个分析结点保存自己的处理结果数据到相应的数据库实体中。

欠费处理引擎是一个定时的引擎，读取欠费数据，形成欠费数据结点，依据欠费数据结点中的用户资料表示，取得用户资料并打包，将欠费数据结点和用户资料结点抛给欠费数据处理子程序处理，在一批欠费数据处理完成后欠费处理引擎将调用存贮子程序存贮数据。

其他引擎还包括：

费用处理引擎负责用户应收费用处理。

缴费处理引擎负责缴费信息的处理。

商品处理引擎负责优惠商品相关对象数据收集及分析处理。

调帐处理引擎负责调帐费用的处理。

2 处理流程

数据中间层流程从触发角度来说分自动流程和人工触发流程，从抽取的数据对象来看分正常抽取和异常的重处理，一般正常流程可以采取正常流程来实现，一般定时运行，有时因为某些原因也可以通过人工触发的方式立即抽取某些数据，异常流程一般采用人工触发的方式实现，因为异常流程是当异常发生时才需要触发，属于较少使用的流程，另外由于对异常流程的界定情况比较复杂，自动触发的风险比较大。

（1）消息控制处理流程：控制台根据事务定义的要求，把数据抽取请求和相应的参数发送给数据中间层生成模块，数据中间层生成模块启动数据抽取服务进行数据的抽取并把抽取的数据保存到事实表中。

（2）定时处理流程：数据中间层定时扫描事务定义表，检查是否有事务需要处理，如果发现有事务需要处理，触发数据抽取流程进行处理，数据抽取流程根据事务的定义和相关的信息进行抽取，并把结果保留在相应的事实表中。

2.1 程序运行方式

启动后台守护服务程序：datatrans -s

执行指定的事务命令：datatrans -p cmd_id

2.2 后台守护程序处理流程，（见图1）。

执行指定事务命令处理流程，（见图2）。

2.4 模块说明

2.4.1 事务定义

一个完整的事务包括事务定义、事务间的关系、事务的子事务定义、事务参数。

事务定义描述了事务的名称、事务的抽取方式、运行方式和运行时间，是对事务的一个总体的描述。

事务间关系：描述了多个事务间的并发关系，执行的先后，分为依赖关系和互斥关系，有些事务因为数据本事的联系，必须先执行一个事务后才能再执行另一个事务，还有一些事务因为它的运行需要很多的系统资源，为了保证事务能良好的运行，可以通过互斥关系来达到独占的系统资源的目的。

2.4.2 事务运行

数据抽取的事务有些比较简单，通过一个或几个简单的sql语句就可以实现；而有些事务则比较复杂，不仅仅是简单的数据抽取，还有很多的数据加工，如主产品实例信息，本身各类信息就是分表存放的，在抽取时需要把它们综合到一张表里来，并且需要和考察的维度建立上联系，往往这些信息需要根据模型的设计思路去逐层查找。比如产品属于哪个产品包、哪个商品，需要通过产品包明细、商品明细去找。数据抽取时需要把主产品实例相关的、统计和数据提供等模块可能需要的这些信息综合到一起来，假设主产品实例信息数据量在500万相当级别，那么话单、帐单这些表的规模级别至少时主产品信息的几十倍，如果数据完全没经过加工，对用户业务量的统计可能需要关联好多张千万级规模的表，速度可想而知。

事务运行方式主要分两种方式：消息触发、定时触发。需要抽取数据的事务很多，并且一般数据抽取都是夜里进行，如果每次数据抽取都要人为干预会很麻烦。定时触发就是为了解决这个问题，在事务定义时可以定义事务抽取的时间间隔，触发事务的时间点等信息。消息触发的方式是定时触发的一种补充，在自动流程中加入了一个人工干预的过程，使服务能够处理一些特殊情况或异常情况。消息的发送来源于控制台，消息触发方式主要是为了能够灵活控制数据抽取事务。

2.5 数据抽取

数据抽取就是根据事务的定义，把数据源的数据按照目标數据的要求，进行转换整理，存储到目的表或文件的过程。

数据抽取从触发方式可以分为定时自动触发和人工触发两种，自动触发又分为每天定时触发和按照一定时间间隔（每小时、每月等）触发两种。从抽取的数据集角度数据抽取可以分为增量抽取的方式和全量抽取的方式。数据抽取从实现的角度可以采取sql语句、存储过程、写C/C++程序、shell脚本四种方式来抽取，sql语句抽取可以适用于数据量不大，数据转换不很复杂的事务的抽取，它的数据源和目的数据一般都是数据表，但也可以是数据库支持的文件格式，这种方法灵活简单，新需求的解决只有配置sql语句不用新的开；C/C++程序用来解决前面两种方法不能解决的事务的抽取，这种方法处理的事务一般数据量非常大，更多是处于性能方面的考虑。

2.6 数据源

数据源分两种：数据表和文件。数据源可能是计费系统的数据也可能是计费系统外围的数据，当给计费系统以外的系统提供数据时，称为数据提供，反之为数据接收。

数据中间层大部分事务都是从数据库表中进行数据抽取，如系统的很多参数资料（商品、电信管理区域、组织等）、客户档案资料、帐单信息、欠费数据、缴费数据等。

从文件抽取主要是话单、清单数据，这部分数据规模大，从文件中抽取可以数据库操作，减小对计费的影响。关于话单、清单是从文件中抽取还是从数据库中抽取，以及对计费流程的影响需要根据对数据中间层实时性要求来确定，对于一般按天抽取来说，从清单表、话单表中抽取应该是个可行的方案，省去分析各种清单、话单的文件格式，减少开发难度和工作量。

所同步数据的范围，可通过参数（trans_cmd.param_list）配置：例如基表表名、帐期、本地网、日期等。程序通过这些参数组合出源数据表名。

源数据表名可配置取映射的备份表。例如：在某个时间点对ACCT_ITEM_1100有备份表为BAK_ACCT_ITEM_1100，程序可以通过表名映射配置从BAK_ACCT_ITEM_1100表中取数。如果没有配置，则默认为原始表ACCT_ITEM_1100。同时读取备份表时，需要注意可能存在跨库访问的情况，例如将BAK_ACCT_ITEM_1100备份在META库中，此时需要程序通过配置就可以正常读取到BAK_ACCT_ITEM_1100表。

2.7 目的数据

目的数据分两种：数据表和文件。

目前数据中间层从计费系统抽取的数据都是需要入库的，因为数据中间层从计费系统中抽取的这些数据都是一些比较重要的核心业务数据，至少统计分析是需要这些数据的。计费系统其自身的专业性就决定了它需要更多地考虑计费的性能，从而尽量减少数据的冗余，减少数据的读写等，而统计分析角度各种各样，为了减少统计的复杂度，必须增加冗余字段，提高统计效率。从这一点上来讲统计分析和计费是矛盾的。数据中间层作为计费系统的一个扩展，在计费系统中相对独立，其模块功能（数据抽取和提供）也决定了它需要更多从统计角度去组织数据，减少以前直接从计费系统统计数据的复杂度。

目的数据为文件：以文件方式存储更方便系统间进行数据交换，它没有数据库那么多要求，并且从计费系统的安全方面考虑的话，用文件更好些。数据中间层的一个重要功能就是数据提供，可能的数据接口会比较多，用文件进行交互将是一个重要的方式。

2.8 消息和定时事务控制

不管是简单的事务还是是复杂的事务，都需要支持定时和消息两种触发数据抽取模式。

先说消息触发模式的处理。从数据中间层控制台选取想要处理的事务，点“运行”或“重处理”按钮发送命令到数据中间层后台服务，可以同时传入若干个参数（如果有参数会弹出界面要求输入），根据事先定义好的消息接口，后台服务接受到命令后解析命令行，并按要求执行。

定时触发模式：系统启一个守候进程，用来轮循事务定义表，根据事务定义的开始运行时间和时间间隔判断，如果事务处理的时间到了，启动事务进行数据抽取并记录处理日志。

事务控制模块主要需要解决的问题是事务如何运行、何时运行的问题，需要参照事务之间的并发关系、事务处理的日志信息（当前有哪些事务在运行、同一事务上次运行信息等）。

控制流程需要注意的几个地方：

事务的优先级：保证事务按照优先级别运行。

事务间关系：保证互相冲突的事务不会同时运行。

当前运行事务：保证数据不重复抽取，不并发冲突。

事务运行的历史信息：保证系统数据完整性和正确性，不重复抽取，不遗漏。

每次事务抽取都需要记录事务处理日志，日志主要用来进行事务处理的查询和事务的回退和异常处理时使用。事务在开始运行时先写日志记录，状态为正在处理的状态，事务处理结束时根据事务处理的结果成功或者失败更新日志中的状态，事务处理失败记录失败原因提供查询。日志主要包含下列信息：

（1）记录每次事务数据抽取的开始时间、结束时间

（2）记录每次事务抽取的数据的起始时间、截至时间

（3）记录事务抽取的状态及结果

2.9 审核/异常处理

审核：可行性审核。根据事务之间的关系，事务的处理日志，判断事务是否启动。事务之间的关系有依赖关系、互斥关系，事务内部（如果分成几个子事务的话）有先后，执行某个事务前它所依赖的事务必须已经执行，子事务也是一样。参数有效性审核。为了保证抽取的数据不重复不遗漏，必须参照事务的处理日志获取上次该事务运行的结果，抽取的数据对象的范围（如時间范围等）。

重处理：数据清理首先就是确定对哪些数据进行清理，一般都是通过时间来进行过滤。数据清理有两种方式，一种是自动清理，如上面提到的每次对抽取前要进行数据有效性审核，这时可能会自动触发数据清理，这种情况下时间信息是根据日志中记录的历史处理情况确定的。还有一种比如统计发现数据不对了，可能人为触发数据重新抽取，这时往往会提供时间信息，指明重新抽取哪个时间内的数据，这时就不能按照默认的处理方式来处理，要按照指定的时间进行数据清理，（按指定时间信息）再进行数据抽取。

数据清理分全量抽取和增量抽取两种方式。如果数据量小（静态表）可以把表里的数据全部删除，如果数据量大，删除数据要浪费很多系统资源和时间，可以把表drop后重建。

增量抽取方式：增量抽取只能采取删除的方式，大数据量处理时需要注意有限的系统资源使用情况，如事务太大可能造成数据库回滚端不够用的情况。另外，可以考虑利用数据库的原理采用分区等方式来加速数据的清理。

抽取数据时间的说明：

事务抽取哪个时间的数据由下面四种时间共同决定：

消息包中指定时间；

事务参数配置中定制时间；

根据处理历史和系统时间默认获取；

系统当前时间。

手工触发的方式：根据消息中的时间和系统当前时间确定抽取的时间跨度。

自动触发的方式：根据事务的配置时间参照事务的处理日志中事务上次处理的处理结果。

和起止时间决定本次自动处理的开始时间和结束时间。

参考文献

[1]张耀华.基于MYSQL的分布式数据中间层[D].复旦大学，2013.

[2]杨敏.对象关系型实时数据中间层[D].浙江大学，2007.

[3]S.Greaves，Y. Kanai，H. Muraoka.Shingled recording for 2-3 Tbit/in2. IEEE Transactions on Magnetics ，2009.