適用于實時查詢的電信行業海量數據倉庫構建方法

王 銳，陳 麗

（1.中國移動通信集團公司廣東分公司 廣州510623；2.廣東交通職業技術學院計算機工程學院 廣州510650）

1 引言

隨著互聯網、移動互聯網和物聯網的發展，各種終端、信息收集器產生的數據和種類不斷增加。對于海量數據，只有合理存儲下來，經過清理、過濾和挖掘，將分析結果以各種直觀方式呈現，或者實時地提供服務，提升用戶體驗，才能體現價值，創造實際效益。

數據倉庫是目前企業比較通用的存儲數據、獲取信息的一種技術和手段，其存儲了海量的企業數據，匯總了大量有價值的信息，但數據倉庫的應用呈現方式，如KPI報表、OLAP、數據挖掘等，主要是通過對海量數據進行各種維度的不斷聚合和匯總分析，處理過程需要數小時或數天，信息獲取的實時性非常差，無法提供實時的數據查詢服務。

以通信行業為例，由于用戶數非常巨大，產生的通話記錄、上網記錄、短消息記錄數據量非常龐大，如廣東每天的數據量超過60億。一般需要經過數據采集、數據裝載、數據匯總、報表展示等多個過程，用戶才能看到數據的分析結果。但對于實時用戶行為分析、實時監控、投訴處理等應用，由于傳統數據倉庫在實時性上存在弊端，無法有效支撐。

如某用戶投訴其手機GPRS套餐流量使用完，但這個月到現在并沒有怎么上網，這時就需要查詢該用戶從月初到現在的所有上網及流量記錄。對于這種需求，傳統數據倉庫技術無法實現，或只能通過一些特殊方式（如采用盡可能小的時間粒度的分區方法、以犧牲裝載性能的在線索引方法）實現。這些方法要么只能實現準實時查詢，要么需要犧牲裝載性能，而裝載變慢會直接影響數據查詢的實時性。因此該用戶的投訴處理無法實時完成，需要等待非常長的時間。因此，對于用戶行為的第一手信息（如通話、上網、短信等）無法及時發揮其商業價值，無法及時處理用戶對網絡質量或消費的投訴。這個時間差值，現有的技術一般在數小時甚至更長時間。

為了更有效地利用數據，發掘商業價值，提高網絡質量，快速有效地處理用戶投訴，一種適用于實時查詢及分析的數據倉庫構建方法勢在必行，其核心是要解決好快速裝載和實時查詢問題。

2 現有技術方案

現有技術方案都在努力提高查詢的實效性和速度，但目前大多數數據倉庫的構建過程一般采用ODS(operational data store，操作數據存儲）-DW(data warehouse)架構，其中ODS是一個面向主題的、可變的、當前的細節數據集合；DW是基于ODS構建的匯總數據層，一般采用星型、雪花型模型，實現鉆取、旋轉等多維分析。ODS是細節數據滿足實時查詢的關鍵，目前的構建方案主要有以下兩種。

方案1（數據串行裝載，索引實時維護）如圖1所示。

方案2（數據并行裝載，索引后維護）如圖2所示。

以上2種方案都具有如下缺點。

（1）實時性差

因為在海量數據倉庫中，裝載的數據量非常巨大，如果需要進行快速查詢，需要在表上建立相關索引，否則查詢根本無法快速完成。如果采用方案1，裝載效率將非常低，同時也影響查詢效率；方案2主要是將表按時間盡可能小粒度地分區，通過設置最后一個分區的索引失效保證裝載的效率，但無法對最后一個分區的數據進行高效查詢。這些技術針對最近的數據都無法提供查詢或需要處理后才可查詢，存在較大的時間差，往往在小時級甚至更長時間，數據查詢的實效性差。

（2）管理復雜

為了盡可能提升查詢的實時性，現有技術需要維護有“海量”分區的分區表，過多的分區將影響數據表維護以及數據裝載的性能。每裝載完一個分區，需要重建該分區表上的索引，海量數據表的維護管理將十分復雜。

（3）裝載過程變得復雜

因為需要將數據裝載進最近的一個分區，確保數據采集的實效性，如果采集的數據出現延時，裝載的數據將有可能進入索引已重建的分區，裝載效率將變得極為低下，裝載的調度算法將十分復雜。

圖1 現有技術方案1

圖2 現有技術方案2

（4）存在沖突的可能

方案2中，如果已裝載完成的分區在建立索引的同時，有延時數據需要裝載，因為數據庫的鎖機制，兩者將發生沖突，其中一個操作將失敗，導致應用程序的穩定性變差。

3 支持實時查詢的解決方案

海量數據實時查詢的需求就是快速從數以億計的數據中，查詢出一定時間范圍內符合特定條件的數據。目前由于信息化的不斷膨脹，數據規模越來越龐大，數據倉庫往往是以TB、PB級的數據量計算。由于企業發展需求，對海量數據的實時查詢要求也越來越高。海量數據倉庫相對于傳統數據庫具有如下特點。

·數據一般有時間刻度，隨著時間增加，數據量也在不斷增加。

·數據一般具有一個關鍵的維度，如通話話單、WAP日志的手機號碼、電子交易賬單的用戶ID等，一般查詢條件都涉及關鍵的維度。

·數據查詢一般有一定的時間范圍，如一個月或一個星期等。

·數據在各自維度上的重復率較高，如一個月內某個用戶的手機號碼會有非常多的記錄。

·數據入庫后不需要進行更新操作，數據相對靜態。

本文通過對海量數據倉庫數據特點的研究，使用索引實時有效性及數據物理聚合等多個技術，縮短從源數據加載到查詢的處理時間，壓縮相關步驟處理時間至接近0，從而實現數據入庫后的實時查詢。該方案解決了現有方案的不足，其主要特點如下。

（1）實現海量數據的實時查詢

采用外部表（平面文件映射表）裝載技術以及索引實時有效技術，避免對新入庫的數據進行處理后才提供查詢，在保證高效裝載的同時，能實現ODS層數據的實時高效查詢，使數據的查詢時間差接近0，滿足實時性要求。

（2）實現海量數據的高效裝載和查詢處理

采用文件合并裝載、多文件多并行裝載、日志最小化、數據物理聚合以及索引自動聚合等技術，不僅實現海量數據的高效裝載，最大限度地壓縮入庫時間，還能提高查詢效率。如根據海量數據倉庫實時查詢的特點，在數據裝載時將數據按時間進行分區存放，同時對同一時間范圍內的數據按類型進行聚類存放，將同一時間范圍內的同類數據盡可能存放在鄰近的物理空間，可以減少磁盤I/O量及磁盤尋道時間，大大減少數據裝載和訪問帶來的物理I/O，提高查詢效率。最終可實現查詢響應速度在秒級以內，且不受數據量及硬件資源限制。

（3）無其他關聯影響

本方案在實現海量數據高效、實時查詢的基礎上，采用以上技術，無其他關聯影響，基本實現自動化處理，無需花費大量的維護成本。

綜合以上的技術實現特點，該海量數據倉庫平臺的整體架構如圖3所示。

源數據層主要對原始文件進行采集，為后續操作做好準備。數據處理層是海量數據倉庫的關鍵，采用多種優化裝載技術，如文件合并、外部表裝載、多文件并行裝載等，不僅實現了傳統ETL（數據抽取、清洗轉換和裝載）的過程，還完成了索引建立、數據分區和入庫，同時保障索引有效，為上層支撐海量數據實時查詢打下基礎。查詢處理層主要是針對不同查詢條件，實現相關索引的自動聚合，滿足了高效查詢需求。最上層為查詢響應層，接收查詢請求，返回相應查詢結果。

4 技術實現

根據圖3的解決方案，在完成ETL的過程中，重點介紹關鍵的技術實現，如圖4所示。

4.1 對數據進行分區存放

根據海量數據倉庫的特點，數據都具有時間性，每條數據一般都有一個時間戳，如電信通話清單，每條記錄都有一個時間字段（通話發生時間）；電子交易賬單，每條記錄都有一個交易時間的字段。對于這些數據的查詢都有時間范圍的限制，如查詢最近一個月內某個用戶的通話記錄。因此可以對這些數據進行分區處理，按照查詢習慣，將數據按照一定時間粒度進行分區。以通話清單為例，可以按通話時間（即數據的時間性質）對數據進行分區，如圖5所示。

數據進行分區后，每個分區的數據量縮小很多，如一個10億條記錄的表，按保留一個月時間計，分成30個分區，每個分區的數據量只在3 000萬條左右。每個分區可以近似看成一個單獨的表，可以直接在數據所在分區進行查詢，從而大大減少查詢時需要的物理I/O資源，提高查詢速度。該步驟的具體方式如下。

圖3 支持實時查詢的系統架構

圖4 技術實現原理

圖5 數據按時間分區

·找出數據中的有效時間維度，一般是查詢中涉及的時間范圍，如通話清單中的通話時間。

·根據查詢需求，定義查詢的時間范圍，如在通話清單中大部分查詢都以一個月為范圍。

·按時間范圍對數據表進行范圍分區，在數據入庫時根據分區定義情況，自動將不同時間范圍的數據存儲到不同的分區中。

4.2 數據物理聚合

對于每個分區中的數據，根據數據的另一個性質——手機號碼，對數據進行物理聚合。

本步驟實現了對數據的分區，一般可將數據量從數十億下降到數千萬，但在海量數據倉庫中，每個分區也就是每個時間段內的數據量仍可達到數十億甚至幾十億的規模。因此，對于海量數據的實時查詢，每次查詢的數據可能將上百GB數據散落在一個分區的任何物理塊中，即使采用索引，查詢效率也非常低。

分析查詢條件進一步對數據進行物理聚合。因為一般存在必備的查詢條件，即關鍵維度，如通話清單中的手機號碼，可以將手機號碼聚合在一起，通過少量物理I/O就可讀取全部查詢數據，提高查詢速度。

數據按時間范圍分區后，再進一步對表中數據按關鍵維度進行Hash分區，在進行Hash分區的同時，數據會自動進行聚合處理，訪問的數據量也大大下降。如一個10億條記錄的表，按保留一個月時間計，分成30個分區，每個分區再分成16個Hash子分區，每個子分區的數據量只有200萬左右。分區的個數可根據數據量確定，因此，可以對海量數據按一定需求進行分隔存放，只需保證每一塊子分區的合理大小，就可以做到海量數據的無關性，不管多大的數據量，經過分區處理，都可以實現性能最優化。

因為數據裝載使用多文件并行裝載的方式，二級分區也可以用于提升裝載效率，如采用每個CPU、文件、并行進程對應一個分區，可以大大提升裝載效率。二級分區的數量計算方式為：二級分區數量=max(邏輯CPU個數×2，單次裝載的文件數量),同時二級分區的個數建議設置為2n。其技術原理如圖6所示。

該步驟的具體方式如下。

圖6 數據聚合技術原理

·找出數據中的關鍵維度，一般用于特定數據的查詢過濾條件，可根據查詢需求而定，如通話清單中的手機號碼。

·根據上面的計算公式，計算關鍵維度Hash分區數。

·在時間范圍分區的基礎上，按關鍵維度進行二級Hash分區，在數據入庫時根據分區定義情況，自動將同類數據自動聚合到相同或相近的物理位置上。

4.3 關鍵維度字段建立位圖索引

通過§4.1、§4.2，實現數據的分區及相同數據的自動聚合，大大降低查詢時的I/O量，提高了查詢性能。但索引仍然是實現海量數據實時查詢最基本的要素。

由于海量數據查詢條件一般存在關鍵維度，關鍵維度上的數據重復性非常高，如通話清單中的手機號碼、電子交易賬單中的用戶ID。相對于海量的通話記錄或交易信息，手機號碼或用戶ID的數量就較為有限。

根據這個特點，相對于傳統的BTree索引技術，可以對該字段建立位圖索引，即使用位圖的方式，無需對索引的每個鍵值數據進行維護，只需對單一的鍵值數據進行維護，索引維護的成本極低。

使用位圖索引方式，在進行大數據量裝載的時候，索引進行維護的開銷可以忽略不計。位圖索引不適合需要頻繁更新的數據，但對于靜態性的數據倉庫數據，非常適合。

位圖索引要求根據主表分區情況進行相應分區，索引類型為本地分區索引，可以確保在海量入庫的同時，在關鍵維度字段建立索引的有效性，同時無需花費巨大索引維護代價。

在海量數據裝載過程中，采用位圖索引進行索引實時維護，比采用BTree進行索引實時維護的裝載性能高出10倍以上。

4.4 外部表裝載

以上步驟為實現數量數據的實時查詢打下了堅實的基礎，但對于實現實時查詢的目標還有一定距離。對于一般數據量的處理，通過以上步驟可以實現要求，但對于海量數據，由于其數據量巨大，無法只使用單進程的方式進行數據裝載，否則裝載效率無法滿足要求。目前對于海量數據的裝載，都是通過并行裝載的方式實現，對于傳統的并行裝載方式，都需要將索引置為無效，即跳過索引的實時維護。現有技術方案在滿足裝載效率的情況下，無法保證索引的實時有效。

本文采用外部表的方式實現數據入庫，在入庫的同時完成相關實現。平面文件映射可以將多個平面文件映射成一張數據庫中的虛擬表，對虛擬表的訪問與訪問實際物理表一樣，如可以通過insert*select*的SQL方式實現數據的并行入庫，對于select集及insert集都可以使用并行的方式，該并行方式屬于數據庫內語句處理級的并行，不會造成索引的無效，可以保證索引的實時維護。

文件映射表需要在每次裝載時進行更新，使用更新文件映射表屬性的方式對裝載的文件源進行更新。

該步驟的具體實現方法如下。

（1）文件映射表建立語法

（2）確定每次裝載的平面文件大小

裝載的源數據是采集的許多小文件，存在文件數量眾多、數據量大的特點。這種特點將導致裝載過程緩慢，因此需要對文件進行合并處理，合并文件大小需要根據主機性能及存儲性能綜合測定，過大及過小都將影響裝載速度。文件大小可以通過計算式測算：單個文件大小=存儲每秒I/O吞吐量/CPU個數。

（3）確定每次裝載的文件個數

目前的主機資源一般都是多CPU，數據倉庫的特點就是最大化吞吐量，因此先考慮表的子分區個數，合并文件時，需要考慮CPU數量的影響。為了提高裝載速度，必須充分發揮多CPU的特點，每個CPU都分配盡量均等的任務。并行裝載文件的個數與CPU數量有關，經實驗測算，并行裝載文件的個數計算式為：并行裝載文件的個數=邏輯CPU個數×2。

（4）修改文件映射表對應文件屬性

修改文件映射表裝載文件屬性，確保每次裝載的都是正確的目標文件，且每次裝載的文件個數符合要求。

4.5 數據入庫及實時索引維護

完成前面步驟后，只需利用平面文件映射表作為數據源表，進行數據并行入庫即可。在并行入庫的同時，實現數據的分區存儲、同類聚合及索引實時維護。

考慮到充分利用主機資源，提高入庫效率，一般為裝載的語句設置并行度，并行度分為并行讀取與并行寫入，并行度的大小與CPU數量和并行裝載的文件數有關，計算式為：讀取并行度=max(邏輯CPU個數×2，并行裝載文件個數)；寫入并行度=max(邏輯CPU個數×2，并行裝載文件個數)

相關SQL語法示例如下：insert/*+并行提示 */into目標表select*from平面文件映射表。

4.6 實現海量數據的多條件實時查詢

采用位圖索引自動聚合技術，解決了多條件實時查詢需求。通過在幾個查詢條件的字段上建立對應的位圖索引，在進行各種不同組合的查詢時，優化器能根據查詢條件自動聚合相關字段上的位圖索引，提供與組合索引一樣的查詢效率。使用該技術可以實現多條件的快速查詢，同時避免建立過多組合索引帶來的裝載速度降低問題。

通過以上步驟，海量數據無需經過緩沖處理，數據入庫后即具備高效查詢條件，用戶可隨時進行數據查詢，無需等待數據進行額外處理，查詢后瞬間返回數據結果，實現真正的海量數據實時查詢。

5 結束語

實時查詢在通信、金融、電子商務等行業需求廣泛，可以應用于用戶行為實時分析、網絡故障快速定位、用戶交易信息的實時查詢等，最大程度體現數據的價值。

本文提出的技術解決方案實現了海量數據的近零時差、秒級響應，具備實時查詢能力。目前該技術方案已經在中國移動通信集團公司廣東分公司實施應用，在每天入庫近60億條數據，單表容量達27 TB的情況下，使用本方法構建的數據倉庫，在實時查詢方面達到快速返回數據的效果，不僅支撐了數據倉庫的多維分析，還提供了海量基礎網絡數據的實時查詢能力，查詢效率高效而穩定，支撐了網絡監控、投訴處理等眾多應用場景，豐富了海量數據的利用價值。

1 王彥龍.企業級數據倉庫（EDW）原理、設計與實踐.北京:電子工業出版社,2006

2 李穎,郝克剛,葛瑋.基于電信數據倉庫系統的ETL研究與設計.計算機應用與軟件,2009,26(1)

3 朱鵬翔,劉文煌.基于DB-ODS-DW的CRM動態數據倉庫.計算機工程與應用,2002,38(20):190～193

4 張俊,張忠能.實時數據倉庫體系架構的研究.計算機工程,2004,30(Z1):180～182