[發明專利]處理報表數據的方法和裝置

有效

• 申請號: 201710398736.2
• 申請日: 2017-05-31
• 公開（公告）號: CN107229718B
• 公開（公告）日: 2020-06-05
• 發明（設計）人: 李銘浩;朱錕煒;沈俊杰
• 申請（專利權）人: 北京京東尚科信息技術有限公司;北京京東世紀貿易有限公司
• 主分類號: G06F16/22
• 分類號: G06F16/22;G06F16/242;G06F16/2455
• 代理公司: 中原信達知識產權代理有限責任公司 11219
• 代理人: 姜勁;金潔

本發明實施例提供一種處理報表數據的方法和裝置，有助于在支持多種數據查詢方式的情況下有更高的處理速度。該方法包括：對于從數據源中選擇的多個數據列，分別標明該數據列的類型，數據列的類型包括鍵名列和鍵值列；保存當前報表并且保存行索引字典；對于獲取的數據源中的當前行數據的多個鍵名列使用所述預設的計算方式計算出一個對應值，判斷若該對應值是行索引字典中的一個已有鍵名，則將當前報表中序號是該已有鍵名對應的鍵值的一行的數據與當前行數據采用當前報表中的各個鍵值列對應的聚合函數進行數據合并。

技術領域

本發明涉及計算機及軟件技術領域，特別地涉及一種處理報表數據的方法和裝置。

背景技術

在數字化時代，越來越多的信息以數據報表的形式提供給人們，例如商品的信息，或者廣告投放效果的信息……等等。以廣告為例，對于投放了廣告的廣告主而言，他們在廣告投放之后都會頻繁的查看廣告的投放效果，投放效果基本都以報表的形式展示給廣告主，由于報表所涉及的數據量大、數據條目多、邏輯計算復雜，僅僅的優化SQL查詢語句來提升查詢效率是遠遠不夠的。在大數據的查詢場景下，需要設計一種基于報表存儲和計算的數據結構，來支持對時間延遲敏感的查詢，并且具有良好的可伸縮性，可以隨著數據規模和查詢總量的增長，保持原有的計算速度。目前相關的技術例如RDBMS視圖和HBase存儲結構。

RDBMS視圖是指關系數據庫的視圖，目前業務層主要使用Mysql。當某個查詢結果非常頻繁，而且會被當做子查詢用于別的查詢中時，視圖就可以作為一張臨時的虛擬表，存儲這些數據。視圖的數據模型和它所使用的數據庫一致，仍然有著相同的存儲結構。

由于視圖所使用的數據結構仍然和數據庫的一致，數據庫帶來的限制也仍然存在。當結果集比較大而且需要對結果集進行計算、查找或排序時，如果沒有索引，仍然效率很低。索引的創建又非常依賴場景，很不靈活。

HBase是一個分布式列存儲數據庫，提供了可靠的存儲和高性能的計算，其海量數據操作的時效性也要優于其他RDBMS數據庫。HBase的存儲模型是基于列存儲模，每一行數據都會有一個Rowkey，數據按Rowkey有序存儲，這樣的數據結構會使查詢時可以快速定位數據。同時HBase的存儲模型支持動態的增加列，列的存儲值為空也不會增加存儲空間，使得使用起來更靈活，免去了RDBMS需要修改存儲結構的問題。同時HBase對于報表系統的場景有著比較明顯的劣勢，HBase條件查詢性能不高，而報表系統會使用大量的條件查詢。

目前眾多的系統對報表的查詢是使用單一類型的數據庫語句例如SQL語句直接查詢數據庫，獲取報表數據，使用數據庫是MySQL，所以對應的技術方案主要是以優化SQL語句、優化MySQL的配置、增加硬件配置、分庫分表等方式來優化查詢速度，對于每一張報表都需要根據其場景設計技術方案。

現有技術主要存在以下不足之處：

1.完全依賴于采用單一數據庫的語句進行查詢時的存儲結構，查詢性能較低，當處理千萬級數據時不能達到毫秒級的響應速度。

2.如果數據庫發生變動，所有的優化方案需要重新設計，針對每個場景都需要設計存儲格式，兼容性和擴展性都不好。

3.只能基于當前采用的數據庫本身去優化改善，如果該數據庫版本更新，需要將設計再次重新與新版本合并，造成不必要的工作量。

發明內容

有鑒于此，本發明實施例提供一種處理報表數據的方法和裝置，有助于在支持多種數據查詢方式的情況下有更高的處理速度。本發明的其他有益效果和優點以及非常規的可選實現方式將結合具體實施方式加以說明。

為實現上述目的，根據本發明實施例的一個方面，提供了一種處理報表數據的方法。