規則引擎處理海量資料實現工作日誌(一）

一，為什麼我們要使用規則引擎

 

 在電信行業中，我們做的最多的工作是在比較資料，話單的海量資料處理，無非就是將資料比較，去重，入庫，匯總。為了在有限時間內實現數千萬話單的邏輯，我們一遍一遍的用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自動轉化為高效的演算法。

2， 為什麼資料庫能用有限的記憶體處理無限外存資料，資料庫怎麼處理記憶體與外存的交換關係。

3， Page是什麼東西，B-tree與Page是怎麼聯絡起來的。

4， Index是什麼東西，它是怎麼添加上去的，為什麼加上它sql就查的特別快。