李綠色

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

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

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

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

數(shù)據(jù)中間層生成和其他系統(tǒng)間的關系：CRM系統(tǒng)（特別是采用SID模式）為數(shù)據(jù)中間層提供客戶資料信息，數(shù)據(jù)中間層抽取的數(shù)據(jù)是各種接口數(shù)據(jù)源和數(shù)據(jù)提供的數(shù)據(jù)源，統(tǒng)計報表在數(shù)據(jù)中間層抽取的數(shù)據(jù)基礎上進行簡單的加工，生成最終的各種統(tǒng)計報表。

1 數(shù)據(jù)中間層設計原則

1.1 三種運行模式

系統(tǒng)運行的模式，初步設計為三種模式：實時模式、定時模式和即時模式。

實時模式主要處理話單類的統(tǒng)計，由于這部分數(shù)據(jù)量大，也不要求月末處理完成，考慮跟隨計費的處理流程，計費每完成若干個文件的計費，系統(tǒng)自動組織相關的任務進行處理，一個任務包含的文件數(shù)目多少，根據(jù)業(yè)務量的大小確定，這個參數(shù)由系統(tǒng)參數(shù)表中的process_file_num_per_batch確定。

定時模式主要處理需要月底進行統(tǒng)一處理的任務和需要每天進行處理的任務。月底處理的主要是費用性質(zhì)的數(shù)據(jù)抽取任務，每天處理的主要包含欠費和繳費分析的任務。

即時模式主要用于處理系統(tǒng)無法確定什么時候應該開始處理的情形，和用戶需要隨機發(fā)布的數(shù)據(jù)抽取任務，一部分在定時模式中提及的任務，有可能也需要在即時模式的框架里面進行處理，比如月底的費用性質(zhì)的數(shù)據(jù)抽取任務，由于系統(tǒng)無法確定什么時候出帳結(jié)束，稽核完成。這個時間點需要用戶確定。

1.2 系統(tǒng)參數(shù)控制機制

設計若干的實體，并在系統(tǒng)中設置一組參數(shù)，最終用戶具有控制這些實體是否生成的權(quán)利，這組參數(shù)在系統(tǒng)參數(shù)表（system_param）中，基本的命名方式是實體名稱加_is_valid組成，這組參數(shù)的具體含義將在用戶操作文檔進行詳細的描述。這里舉一個例子簡單說明一下：

參數(shù)stop_user_element_is_valid 是表的是否需要生成stop_user_element（拆停機用戶分析數(shù)據(jù)的參數(shù)），在是否生成之間切換，只需要執(zhí)行下列語句：

Update system_param set param_val='true' where param_name = 'stop_user_element_is_valid' 就可以要求系統(tǒng)生成這個實體。

Update system_param set param_val='false' Where param_name

='stop_user_element_is_valid' 就可以要求系統(tǒng)不生成這個實體。

1.3 處理引擎

引擎是一種機制，將設計方案中所設計的實體簡單的分為用戶發(fā)展相關、話單類統(tǒng)計相關、費用統(tǒng)計相關，欠費相關、繳費分析相關、用戶費用異常分析、調(diào)帳分析等。這樣就有了用戶發(fā)展處理引擎、話單統(tǒng)計引擎、費用處理引擎、欠費處理引擎、繳費分析引擎、費用異常分析引擎、調(diào)帳分析引擎。之所以這里引入引擎這個概念的原因在于，這幾類實體需要處理的原始數(shù)據(jù)都是基本一致的。考慮到系統(tǒng)的擴展性和性能問題，須將在相關實體集成在一起，統(tǒng)一處理，至于哪些實體需要處理，哪些不需要處理，在系統(tǒng)參數(shù)表中有一組參數(shù)用于進行這種控制。

處理引擎只是提供原始數(shù)據(jù)和公共服務的一種機制，它負責原始數(shù)據(jù)的讀取和公共數(shù)據(jù)的收集，處理在處理引擎的機制中，但并不是它的功能，分析功能由相關實體的實現(xiàn)邏輯實現(xiàn)，在處理引擎中統(tǒng)一調(diào)用。

用戶發(fā)展處理引擎負責讀取用戶資料數(shù)據(jù)，傳送用戶資料數(shù)據(jù)結(jié)點到用戶發(fā)展處理的各個實體，由各個實體引用用戶資料結(jié)點信息，結(jié)合自己的實體實現(xiàn)邏輯生成各自的信息結(jié)點數(shù)據(jù)包并存貯在內(nèi)存Hash表中，處理引擎處理完成一批數(shù)據(jù)后調(diào)用存貯子程序存貯所有實體，存貯子程序調(diào)用各實體的存貯程序?qū)⒃趦?nèi)存Hash中的數(shù)據(jù)保存在數(shù)據(jù)庫表格中。

話單統(tǒng)計引擎負責話單的讀取和公共數(shù)據(jù)資源的獲取，傳送話單數(shù)據(jù)和用戶資料信息結(jié)果體給相關分析結(jié)點，由相應結(jié)點按照自己的業(yè)務邏輯進行分析處理，形成目標數(shù)據(jù)，存貯在內(nèi)存中，在一個批次處理完成后，話單統(tǒng)計引擎會發(fā)起該批次處理結(jié)束的消息。這時個分析結(jié)點保存自己的處理結(jié)果數(shù)據(jù)到相應的數(shù)據(jù)庫實體中。

欠費處理引擎是一個定時的引擎，讀取欠費數(shù)據(jù)，形成欠費數(shù)據(jù)結(jié)點，依據(jù)欠費數(shù)據(jù)結(jié)點中的用戶資料表示，取得用戶資料并打包，將欠費數(shù)據(jù)結(jié)點和用戶資料結(jié)點拋給欠費數(shù)據(jù)處理子程序處理，在一批欠費數(shù)據(jù)處理完成后欠費處理引擎將調(diào)用存貯子程序存貯數(shù)據(jù)。

其他引擎還包括：

費用處理引擎負責用戶應收費用處理。

繳費處理引擎負責繳費信息的處理。

商品處理引擎負責優(yōu)惠商品相關對象數(shù)據(jù)收集及分析處理。

調(diào)帳處理引擎負責調(diào)帳費用的處理。

2 處理流程

數(shù)據(jù)中間層流程從觸發(fā)角度來說分自動流程和人工觸發(fā)流程，從抽取的數(shù)據(jù)對象來看分正常抽取和異常的重處理，一般正常流程可以采取正常流程來實現(xiàn)，一般定時運行，有時因為某些原因也可以通過人工觸發(fā)的方式立即抽取某些數(shù)據(jù)，異常流程一般采用人工觸發(fā)的方式實現(xiàn)，因為異常流程是當異常發(fā)生時才需要觸發(fā)，屬于較少使用的流程，另外由于對異常流程的界定情況比較復雜，自動觸發(fā)的風險比較大。

（1）消息控制處理流程：控制臺根據(jù)事務定義的要求，把數(shù)據(jù)抽取請求和相應的參數(shù)發(fā)送給數(shù)據(jù)中間層生成模塊，數(shù)據(jù)中間層生成模塊啟動數(shù)據(jù)抽取服務進行數(shù)據(jù)的抽取并把抽取的數(shù)據(jù)保存到事實表中。

（2）定時處理流程：數(shù)據(jù)中間層定時掃描事務定義表，檢查是否有事務需要處理，如果發(fā)現(xiàn)有事務需要處理，觸發(fā)數(shù)據(jù)抽取流程進行處理，數(shù)據(jù)抽取流程根據(jù)事務的定義和相關的信息進行抽取，并把結(jié)果保留在相應的事實表中。

2.1 程序運行方式

啟動后臺守護服務程序：datatrans -s

執(zhí)行指定的事務命令：datatrans -p cmd_id

2.2 后臺守護程序處理流程，（見圖1）。

執(zhí)行指定事務命令處理流程，（見圖2）。

2.4 模塊說明

2.4.1 事務定義

一個完整的事務包括事務定義、事務間的關系、事務的子事務定義、事務參數(shù)。

事務定義描述了事務的名稱、事務的抽取方式、運行方式和運行時間，是對事務的一個總體的描述。

事務間關系：描述了多個事務間的并發(fā)關系，執(zhí)行的先后，分為依賴關系和互斥關系，有些事務因為數(shù)據(jù)本事的聯(lián)系，必須先執(zhí)行一個事務后才能再執(zhí)行另一個事務，還有一些事務因為它的運行需要很多的系統(tǒng)資源，為了保證事務能良好的運行，可以通過互斥關系來達到獨占的系統(tǒng)資源的目的。

2.4.2 事務運行

數(shù)據(jù)抽取的事務有些比較簡單，通過一個或幾個簡單的sql語句就可以實現(xiàn)；而有些事務則比較復雜，不僅僅是簡單的數(shù)據(jù)抽取，還有很多的數(shù)據(jù)加工，如主產(chǎn)品實例信息，本身各類信息就是分表存放的，在抽取時需要把它們綜合到一張表里來，并且需要和考察的維度建立上聯(lián)系，往往這些信息需要根據(jù)模型的設計思路去逐層查找。比如產(chǎn)品屬于哪個產(chǎn)品包、哪個商品，需要通過產(chǎn)品包明細、商品明細去找。數(shù)據(jù)抽取時需要把主產(chǎn)品實例相關的、統(tǒng)計和數(shù)據(jù)提供等模塊可能需要的這些信息綜合到一起來，假設主產(chǎn)品實例信息數(shù)據(jù)量在500萬相當級別，那么話單、帳單這些表的規(guī)模級別至少時主產(chǎn)品信息的幾十倍，如果數(shù)據(jù)完全沒經(jīng)過加工，對用戶業(yè)務量的統(tǒng)計可能需要關聯(lián)好多張千萬級規(guī)模的表，速度可想而知。

事務運行方式主要分兩種方式：消息觸發(fā)、定時觸發(fā)。需要抽取數(shù)據(jù)的事務很多，并且一般數(shù)據(jù)抽取都是夜里進行，如果每次數(shù)據(jù)抽取都要人為干預會很麻煩。定時觸發(fā)就是為了解決這個問題，在事務定義時可以定義事務抽取的時間間隔，觸發(fā)事務的時間點等信息。消息觸發(fā)的方式是定時觸發(fā)的一種補充，在自動流程中加入了一個人工干預的過程，使服務能夠處理一些特殊情況或異常情況。消息的發(fā)送來源于控制臺，消息觸發(fā)方式主要是為了能夠靈活控制數(shù)據(jù)抽取事務。

2.5 數(shù)據(jù)抽取

數(shù)據(jù)抽取就是根據(jù)事務的定義，把數(shù)據(jù)源的數(shù)據(jù)按照目標數(shù)據(jù)的要求，進行轉(zhuǎn)換整理，存儲到目的表或文件的過程。

數(shù)據(jù)抽取從觸發(fā)方式可以分為定時自動觸發(fā)和人工觸發(fā)兩種，自動觸發(fā)又分為每天定時觸發(fā)和按照一定時間間隔（每小時、每月等）觸發(fā)兩種。從抽取的數(shù)據(jù)集角度數(shù)據(jù)抽取可以分為增量抽取的方式和全量抽取的方式。數(shù)據(jù)抽取從實現(xiàn)的角度可以采取sql語句、存儲過程、寫C/C++程序、shell腳本四種方式來抽取，sql語句抽取可以適用于數(shù)據(jù)量不大，數(shù)據(jù)轉(zhuǎn)換不很復雜的事務的抽取，它的數(shù)據(jù)源和目的數(shù)據(jù)一般都是數(shù)據(jù)表，但也可以是數(shù)據(jù)庫支持的文件格式，這種方法靈活簡單，新需求的解決只有配置sql語句不用新的開；C/C++程序用來解決前面兩種方法不能解決的事務的抽取，這種方法處理的事務一般數(shù)據(jù)量非常大，更多是處于性能方面的考慮。

2.6 數(shù)據(jù)源

數(shù)據(jù)源分兩種：數(shù)據(jù)表和文件。數(shù)據(jù)源可能是計費系統(tǒng)的數(shù)據(jù)也可能是計費系統(tǒng)外圍的數(shù)據(jù)，當給計費系統(tǒng)以外的系統(tǒng)提供數(shù)據(jù)時，稱為數(shù)據(jù)提供，反之為數(shù)據(jù)接收。

數(shù)據(jù)中間層大部分事務都是從數(shù)據(jù)庫表中進行數(shù)據(jù)抽取，如系統(tǒng)的很多參數(shù)資料（商品、電信管理區(qū)域、組織等）、客戶檔案資料、帳單信息、欠費數(shù)據(jù)、繳費數(shù)據(jù)等。

從文件抽取主要是話單、清單數(shù)據(jù)，這部分數(shù)據(jù)規(guī)模大，從文件中抽取可以數(shù)據(jù)庫操作，減小對計費的影響。關于話單、清單是從文件中抽取還是從數(shù)據(jù)庫中抽取，以及對計費流程的影響需要根據(jù)對數(shù)據(jù)中間層實時性要求來確定，對于一般按天抽取來說，從清單表、話單表中抽取應該是個可行的方案，省去分析各種清單、話單的文件格式，減少開發(fā)難度和工作量。

所同步數(shù)據(jù)的范圍，可通過參數(shù)（trans_cmd.param_list）配置：例如基表表名、帳期、本地網(wǎng)、日期等。程序通過這些參數(shù)組合出源數(shù)據(jù)表名。

源數(shù)據(jù)表名可配置取映射的備份表。例如：在某個時間點對ACCT_ITEM_1100有備份表為BAK_ACCT_ITEM_1100，程序可以通過表名映射配置從BAK_ACCT_ITEM_1100表中取數(shù)。如果沒有配置，則默認為原始表ACCT_ITEM_1100。同時讀取備份表時，需要注意可能存在跨庫訪問的情況，例如將BAK_ACCT_ITEM_1100備份在META庫中，此時需要程序通過配置就可以正常讀取到BAK_ACCT_ITEM_1100表。

2.7 目的數(shù)據(jù)

目的數(shù)據(jù)分兩種：數(shù)據(jù)表和文件。

目前數(shù)據(jù)中間層從計費系統(tǒng)抽取的數(shù)據(jù)都是需要入庫的，因為數(shù)據(jù)中間層從計費系統(tǒng)中抽取的這些數(shù)據(jù)都是一些比較重要的核心業(yè)務數(shù)據(jù)，至少統(tǒng)計分析是需要這些數(shù)據(jù)的。計費系統(tǒng)其自身的專業(yè)性就決定了它需要更多地考慮計費的性能，從而盡量減少數(shù)據(jù)的冗余，減少數(shù)據(jù)的讀寫等，而統(tǒng)計分析角度各種各樣，為了減少統(tǒng)計的復雜度，必須增加冗余字段，提高統(tǒng)計效率。從這一點上來講統(tǒng)計分析和計費是矛盾的。數(shù)據(jù)中間層作為計費系統(tǒng)的一個擴展，在計費系統(tǒng)中相對獨立，其模塊功能（數(shù)據(jù)抽取和提供）也決定了它需要更多從統(tǒng)計角度去組織數(shù)據(jù)，減少以前直接從計費系統(tǒng)統(tǒng)計數(shù)據(jù)的復雜度。

目的數(shù)據(jù)為文件：以文件方式存儲更方便系統(tǒng)間進行數(shù)據(jù)交換，它沒有數(shù)據(jù)庫那么多要求，并且從計費系統(tǒng)的安全方面考慮的話，用文件更好些。數(shù)據(jù)中間層的一個重要功能就是數(shù)據(jù)提供，可能的數(shù)據(jù)接口會比較多，用文件進行交互將是一個重要的方式。

2.8 消息和定時事務控制

不管是簡單的事務還是是復雜的事務，都需要支持定時和消息兩種觸發(fā)數(shù)據(jù)抽取模式。

先說消息觸發(fā)模式的處理。從數(shù)據(jù)中間層控制臺選取想要處理的事務，點“運行”或“重處理”按鈕發(fā)送命令到數(shù)據(jù)中間層后臺服務，可以同時傳入若干個參數(shù)（如果有參數(shù)會彈出界面要求輸入），根據(jù)事先定義好的消息接口，后臺服務接受到命令后解析命令行，并按要求執(zhí)行。

定時觸發(fā)模式：系統(tǒng)啟一個守候進程，用來輪循事務定義表，根據(jù)事務定義的開始運行時間和時間間隔判斷，如果事務處理的時間到了，啟動事務進行數(shù)據(jù)抽取并記錄處理日志。

事務控制模塊主要需要解決的問題是事務如何運行、何時運行的問題，需要參照事務之間的并發(fā)關系、事務處理的日志信息（當前有哪些事務在運行、同一事務上次運行信息等）。

控制流程需要注意的幾個地方：

事務的優(yōu)先級：保證事務按照優(yōu)先級別運行。

事務間關系：保證互相沖突的事務不會同時運行。

當前運行事務：保證數(shù)據(jù)不重復抽取，不并發(fā)沖突。

事務運行的歷史信息：保證系統(tǒng)數(shù)據(jù)完整性和正確性，不重復抽取，不遺漏。

每次事務抽取都需要記錄事務處理日志，日志主要用來進行事務處理的查詢和事務的回退和異常處理時使用。事務在開始運行時先寫日志記錄，狀態(tài)為正在處理的狀態(tài)，事務處理結(jié)束時根據(jù)事務處理的結(jié)果成功或者失敗更新日志中的狀態(tài)，事務處理失敗記錄失敗原因提供查詢。日志主要包含下列信息：

（1）記錄每次事務數(shù)據(jù)抽取的開始時間、結(jié)束時間

（2）記錄每次事務抽取的數(shù)據(jù)的起始時間、截至時間

（3）記錄事務抽取的狀態(tài)及結(jié)果

2.9 審核/異常處理

審核：可行性審核。根據(jù)事務之間的關系，事務的處理日志，判斷事務是否啟動。事務之間的關系有依賴關系、互斥關系，事務內(nèi)部（如果分成幾個子事務的話）有先后，執(zhí)行某個事務前它所依賴的事務必須已經(jīng)執(zhí)行，子事務也是一樣。參數(shù)有效性審核。為了保證抽取的數(shù)據(jù)不重復不遺漏，必須參照事務的處理日志獲取上次該事務運行的結(jié)果，抽取的數(shù)據(jù)對象的范圍（如時間范圍等）。

重處理：數(shù)據(jù)清理首先就是確定對哪些數(shù)據(jù)進行清理，一般都是通過時間來進行過濾。數(shù)據(jù)清理有兩種方式，一種是自動清理，如上面提到的每次對抽取前要進行數(shù)據(jù)有效性審核，這時可能會自動觸發(fā)數(shù)據(jù)清理，這種情況下時間信息是根據(jù)日志中記錄的歷史處理情況確定的。還有一種比如統(tǒng)計發(fā)現(xiàn)數(shù)據(jù)不對了，可能人為觸發(fā)數(shù)據(jù)重新抽取，這時往往會提供時間信息，指明重新抽取哪個時間內(nèi)的數(shù)據(jù)，這時就不能按照默認的處理方式來處理，要按照指定的時間進行數(shù)據(jù)清理，（按指定時間信息）再進行數(shù)據(jù)抽取。

數(shù)據(jù)清理分全量抽取和增量抽取兩種方式。如果數(shù)據(jù)量?。o態(tài)表）可以把表里的數(shù)據(jù)全部刪除，如果數(shù)據(jù)量大，刪除數(shù)據(jù)要浪費很多系統(tǒng)資源和時間，可以把表drop后重建。

增量抽取方式：增量抽取只能采取刪除的方式，大數(shù)據(jù)量處理時需要注意有限的系統(tǒng)資源使用情況，如事務太大可能造成數(shù)據(jù)庫回滾端不夠用的情況。另外，可以考慮利用數(shù)據(jù)庫的原理采用分區(qū)等方式來加速數(shù)據(jù)的清理。

抽取數(shù)據(jù)時間的說明：

事務抽取哪個時間的數(shù)據(jù)由下面四種時間共同決定：

消息包中指定時間；

事務參數(shù)配置中定制時間；

根據(jù)處理歷史和系統(tǒng)時間默認獲?。?/p>

系統(tǒng)當前時間。

手工觸發(fā)的方式：根據(jù)消息中的時間和系統(tǒng)當前時間確定抽取的時間跨度。

自動觸發(fā)的方式：根據(jù)事務的配置時間參照事務的處理日志中事務上次處理的處理結(jié)果。

和起止時間決定本次自動處理的開始時間和結(jié)束時間。

參考文獻

[1]張耀華.基于MYSQL的分布式數(shù)據(jù)中間層[D].復旦大學，2013.

[2]楊敏.對象關系型實時數(shù)據(jù)中間層[D].浙江大學，2007.

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