淺談通信綜合營帳數據中間層設計原則與處理流程

李綠色

摘 要：文章論討數據中間層設計原則及數據處理流程。數據中間層是計費系統對外進行統計類數據提供的橋梁，以提高數據提供的方便性、快速性和安全性。

關鍵詞：中間層；處理流程；模式；實體

數據中間層是計費系統對外進行統計類數據提供的橋梁，系統通計費過數據加工和整理把數據映射到數據中間層的各統計要素，報表統計直接通過數據中間層進行而不對計費系統的基礎數據進行操作。通過這種方法提高了數據提供的方便性、快速性和安全性。

數據中間層和計費帳務系統中其他模塊的關系：數據中間層主要的功能是從計費系統中抽取數據，經過加工整理（按照其他系統要求）向外界進行數據提供，數據中間層的抽取的數據對象包括用戶資料、用戶的服務使用信息（用戶的業務使用記錄）、用戶的費用信息、用戶的繳費信息、用戶欠費信息、調帳信息、用戶的賬本信息等計費系統中核心業務數據，因此數據中間層和計費系統中各功能模塊都有著非常密切的關系，各模塊的行為會影響數據中間層的數據源，從而影響數據中間層的行為，為了保證數據中間層的數據和計費系統的數據一致性，數據中間層模塊和相關模塊應有通訊接口。從減少對計費系統正常運營的影響，數據中間層生成的不宜太多頻繁，一般定時處理就可以滿足要求（如一月一次、一天一次、一個小時一次）。

數據中間層生成和其他系統間的關系：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.