规则引擎处理海量数据实现工作日志(一）

一， 为什么我们要使用规则引擎

 

 在电信行业中，我们做的最多的工作是在比较数据，话单的海量数据处理，无非就是将数据比较，去重，入库，汇总。为了在有限时间内实现数千万话单的逻辑，我们一遍一遍的用 C实现简单教科书重复了一遍一遍的算法， list， tree， hash，几乎一个业务就衍生出一个独立程序。

 所以我们看到我们的业务支撑上的服务器上，基本就是进程管理器，加一堆杂乱无章的独立程序，构成我们的系统。

 

 我们在想，我们能不能用数据库，内存数据库，文件数据库，把话单变成能用 Sql解析的数据，我们只用动态 sql，去处理任意的数据形式，去重，汇总，比对，完成所有 c程序要完成的工作。

 

1，  我们应该怎么使用数据库来实现，我们能不能用 Oracle生产库，能不能用 TimesTen。

 

不能，使用 Oracle,TimesTen会加大我们项目的预算，使我们的项目用很赚钱，变成赚一点钱的项目，要在我们所有业务支撑系统中推广，每一个实例 30W$东西我们坚决不用，所以数据库的机制由我们自己实现，那么必须是开源的，可改造的。

 

2，  我们自己实现的数据库，有什么技术需求，他与普通的数据库用什么区别。

*我们在计费，账务过分的依赖于共享内存，它必须小心的使用，因为你如果将未知大小销账列表都装进内存，当系统迅速吃光所有服务器的内存时，我们只好等着工程人员骂着娘帮我们重启机器。

用了数据库来运行就不一样了，当我们设定一个地市的 pagecache是 5G是，那么 20个地市就是 100G，消耗资源的大小是我们心中有数的。

 

*我们需要将千万级以上的数据快速的转换成 B-tree的数据结构，我们不能忍受我们入库 Oracle是每秒几千条入库效率，由话单文件，生成数十G 数据库文件必须在二十分钟以内。

 

*转换后的文件形式不能过分的膨胀， XX省移动的话单在 300G左右，我们不能再转换后将其变成几个 T的容量，那样会使到我们又必须拉下面子求客户买机器。

 

*数据库索引的建立必须是快速的，自发的，能够依照我们 sql里的条件，自动的创建需要的索引，由于他不是在线数据库，那么我们不用当心建立索引后，数据操作过慢的问题。我们是在所有数据转换成 B-tree后，根据 sql批量的建立我们需要的索引。

 

*业务对应的逻辑的实体，我们称之为规则 RULE。

 

*规则可以拆分成可重用的逻辑粒度，我们称之为规则细项 RULEITEM

 

*多个 sql处理逻辑的过程我们称之为处理逻辑 handle

 

*以上这些特征，我们称之为规则引擎。

 

*最后一点是，我们不需要再养一大批 c算法高手了，业务人员根据业务的需要制定对应的 SQL，我们的规则引擎自动帮我们处理数以亿万级的数据。

 

目前该方案已经在支撑系统的一个子系统中慢慢成形，数据量在千万级以上，并用于日常生产环境中，极大的降低开发成本，想与各位行业内外探讨下方案，

 

该方案是否与数据挖掘和数据仓库学科有共通的地方，这个可以请 BI或 NCR的朋友看看？

除了电信，金融以外行业，海量数据处理对于游戏，网站等其他行业有无相关需求？

 

再来是介绍我们实现这个方案的技术背景。

一， 我们要先弄懂我们怎么去写这样一个规则引擎数据库。

我们先通过一个个问题来探讨什么是数据库，他是怎么实现的。有人说软件科学最精美方向有 3个方向，操作系统，数据库，编译器。我们现在朝着其中一个去探究，看看前边有什么绮丽的风景。

我在这里先简单介绍下我所理解的数据内核，

1，  数据库是怎么读懂 Sql，为什么数据库能将 Sql自动转化为高效的算法。（parse代码生成，VM虚拟机）

2，  为什么数据库能用有限的内存处理无限外存数据，数据库怎么处理内存与外存的交换关系。（pagecache缓存管理）

3，  Page是什么东西， B-tree与 Page是怎么联系起来的。（B-tree,Page)

4，  Index是什么东西，它是怎么添加上去的，为什么加上它 sql就查的特别快。