[發明專利]一種數據處理方法及系統

有效

• 申請號: 201210571950.0
• 申請日: 2012-12-25
• 公開（公告）號: CN103902544B
• 公開（公告）日: 2017-11-21
• 發明（設計）人: 錢嶺;郭磊濤;張寶海
• 申請（專利權）人: 中國移動通信集團公司
• 主分類號: G06F17/30
• 分類號: G06F17/30
• 代理公司: 北京鑫媛睿博知識產權代理有限公司11297
• 代理人: 龔家驊

技術領域

本發明涉及通信領域，尤其涉及一種數據處理方法及系統。

背景技術

為了優化數據查詢和掃描速度，在磁盤數據庫中對數據表進行分區是一種常見方法，目的是減少處理查詢時掃描的數據規模。這是因為在多數查詢的總體時間中，磁盤數據的掃描占據了至少50%以上的時間。通過分區技術可以將數據表分開保存到不同的實體（邏輯實體或者物理服務器）中，通過在處理查詢時僅掃描相關的分區來減少查詢時間。

目前有多種數據分區技術，按照類型可以分為：

（1）范圍分區（Range）：按照選定列的數值范圍分區，如大于20000的數據保存在分區1中，小等于20000的數據保存到分區2中。其中這個選定的列被稱為分區鍵（Partition Key，PK）。

（2）列表分區（List）：按照分區鍵的離散取值來確定分區，如“中國”、“日本”、“韓國”均可以放置到“東亞”這個分區中。

（3）哈希分區（Hash）：哈希分區根據hash函數確定應該將數據保存到哪個分區中。哈希函數是事先確定的計算函數，可以將輸入的數據，按照實現確定的規則放置到適當的分區中，一種簡單的哈希函數是取余數。

列式數據庫，如SybaseIQ、Vertica、InfoBright等，在存儲方式方面將數據按照列存儲為一個實體（如文件），然后按照范圍來分區存儲。這種方式減少了數據掃描時處理的數據量，但是當需要掃描很多列時，會遇到性能下降的情況，主要是因為將列連接成行、以及掃描文件數量較多造成的。

NoSQL數據庫也采用了相似的分區技術，如HBase采用了動態范圍分區技術，而Cassandra采用了哈希分區技術。在此類系統中，為了減少數據掃描的數量，還將相關列當做列族（Column Family）存儲，以便進一步減少數據掃描數量。

圖1示出了針對同一數據表中的數據，采用上述幾種分區方式時的差異。圖1（a）示出了不分區的情況；圖1（b）示出了按照范圍分區的情況，其中，c0列為分區鍵PK，根據PK的取值，數據表被劃分為3個范圍分區；圖1（c）示出了采用列式范圍分區的情況，其中，在進行劃分列的同時，以c0列作為分區鍵PK，進一步對每列進行區域劃分；圖1（d）示出了采用列族范圍分區的情況，與圖1（c）的區別是，將多個列合并為一列族。

在NMS（Network Management System，網絡管理系統）信令監測、BI（Business Intelligence，商務智能）等大數據應用中，針對時間序列數據，有一種常見的復雜查詢業務，具有如下特征：（1）查詢條件組合靈活，即使針對一個數據表，也會遇到很多種條件維度的查詢；（2）查詢結果組合靈活，且包含很多列。

發明人在實現本發明的過程中，發現針對大數據應用，現有的數據處理技術至少存在以下缺陷：

（1）全表掃描方式：掃描數據量大時，性能存在嚴重問題；

（2）按照時間維度分區：可以減少掃描數據規模，但是由于同一時間發生對應了大量的網絡消息，依然需要掃描大量數據，性能同樣受到影響；

（3）列式和列族方式：在輸出列數量較多，如超過30，則性能下降較多。

由此可見，目前亟需一種性能高的數據處理方案。

發明內容

本發明實施例提供了一種數據處理方法及系統，用以提高數據處理性能。

本發明實施例提供的數據處理方法，該方法包括：

根據至少2個不同級別的分區鍵，創建元數據模型，元數據模型中定義的每個數據分區至少包含除分區鍵所在的數據列以外的所有數據列；

接收到原始數據后，根據所述元數據模型對所述原始數據進行分區處理。

本發明實施例提供的數據處理系統，包括：

控制模塊，用于根據至少2個不同級別的分區鍵，創建元數據模型，并將創建的元數據模型存儲到元數據管理模塊；所述元數據模型中定義的每個數據分區至少包含除分區鍵所在的數據列以外的所有數據列；

元數據管理模塊，用于存儲和維護元數據模型；

數據處理模塊，用于在接收到原始數據后，根據所述元數據管理模塊中的元數據模型，對所述原始數據進行分區處理。

本發明的上述實施例中，由于在進行數據分區時，根據多個分區鍵（不少于2個），按照各分區鍵的級別對所述原始數據進行分區處理，從而得到多維度的數據分區，并且每個數據分區至少包含除分區鍵所在的數據列以外的所有數據列，從而在數據查詢時獲得更好的查詢效率。

附圖說明