大數據分析之納稅人畫像-實現和優化思路

1.背景環境

本文章來自最近作的項目模塊的思考和總結，主要講思路不涉及過多的基礎和實現細節。

需求：統計出來納稅人名稱、行業、近一年業務量（辦稅服務廳、電子稅務局、自助渠道），近一年業務量top5(辦稅服務廳、電子稅務局、自助渠道)、近一年納稅金額、近一年申報數、近一年用票數。支持根據所屬稅務機關分頁查詢。

看上去業務不復雜，可是數據來自多個系統，數據量很大。來來畫個示意圖展現下數據來源的複雜程度：

數據涉及5個廠商，數據庫採用oracle，涉及幾十張表，其中納稅人信息生產環境下有380多萬，更不用說其餘業務表的數據量有多大了，而且還須要分組，統計，排序。此時此刻心情以下：

2.實現方案

2.1 視圖（失敗的方案）

因爲項目時間關係，想法很簡單先採用視圖，先實現再說。（其實在作的時候就有不詳的預感，感受這種方案不行）。因而開幹，在實現的過程當中我用到的
關鍵技術點有：
oracle wm_concat(column)函數實現查詢相同id字段，內容以逗號分隔

select id, wmsys.wm_concat(字段名)字段別名  from table group by id

Oracle分組查詢取每組排序後的前N條記錄

SELECT *   
FROM  (
        SELECT 分組的字段名, ROW_NUMBER() OVER(PARTITION BY 分組的字段名 
        ORDER BY 排序的字段名) AS RN FROM 表名
) 
WHERE RN <= 10   獲得分組後,數據的前幾條

count、sum、group by 、join、dblink等等
生產環境下驗證結果
測試環境還好，生產環境打開視圖很久查不出來數據，臨時表空間暴增30g. 來看下現場的執行計劃


冷靜分析

• 數據庫是其餘廠商的，咱們沒有權限去建索引，只給了查詢權限。
• 大量的hash join，這些操做都在內存中，內存不足會把臨時計算結果放到磁盤致使臨時表空間暴增。
• 分組、排序類的特別耗時。
• 問題的本質也就是相似於數據結構的：時間複雜度和空間複雜度。 通俗點說你願意拿空間換時間仍是時間換空間？
• 大道至簡、分而治之。當人類面臨負責問題和巨大工程的時候，都喜歡切成一小塊一小塊的去處理，問題就迎刃而解。
  

2.2 定時任務彙總（備選方案1）

接着上文，其實咱們能夠提早把數據加工好，插入彙總表，不用每次用戶查詢的時候去計算就行了。
技術實現關鍵點：

• 能夠用spring +quarter 定時任務
• oracle中定時任務

以上在彙總的過程當中必須注意一次拉取小批量數據加工。
因爲時間緊急，定時任務須要開發代碼，數據量大，數據批次須要處理等缺點放棄了

2.3 物理視圖（選用方案2）

由於有比較多的查詢彙總，考慮到速度，最後選擇了物理視圖方案。下面簡單介紹下物理視圖。
物化視圖也是種視圖。Oracle的物化視圖是包括一個查詢結果的數據庫對像，它是遠程數據的的本地副本，或者用來生成基於數據表求和的彙總表。物化視圖存儲基於遠程表的數據，也能夠稱爲快照。
物化視圖能夠查詢表，視圖和其它的物化視圖。
特色：
(1) 物化視圖在某種意義上說就是一個物理表(並且不只僅是一個物理表)，這經過其能夠被user_tables查詢出來，而獲得確認；
(2) 物化視圖也是一種段(segment)，因此其有本身的物理存儲屬性；
(3) 物化視圖會佔用數據庫磁盤空間，這點從user_segment的查詢結果，能夠獲得佐證；
建立語句：create materialized view mv_name as select * from table_name
建立過程一波三折
把方案一種的視圖sql改稱物理視圖，到生產環境下建立。尼瑪又出情況了

一個sql執行了8個小時，竟然失敗了，怎麼辦？
冷靜分析

• 仔細看sql，去掉了沒必要要的關聯查詢。
• 拆分物理視圖，一個拆三，分而治之。

最後在3個小時左右，成功建立了5個物理視圖。
又出情況、一波四折
**
測試庫是11.2.0.1.0的，WMSYS.WM_CONCAT( )函數返回的是varchar類型，而正式庫是11.2.0.4.0的，返回的是CLOB類型的。爲了兼容，因此解決辦法是：TO_CHAR(WMSYS.WM_CONCAT(param )); 只要用to_char()函數轉換一下就能夠了。。。
好吧，從新來過，最後在3個小時左右，成功建立了5個物理視圖。

2.4 hadoop（作夢的方案，殺雞蔫用牛刀）

聽說PB級別的數據，才上hadoop。爲了賣弄一下我也懂點大數據技術（畢竟也讀過幾本書），簡單的列一下實現思路：
0.搭建hadoop平臺
1.sqoop導入數據到hive
2.利用hive進行分析
3.sqoop把分析結果導入Oracle彙總表
4.持續運維
爲何不採用的緣由：
1.數據量遠遠不夠
2.客戶是否給你那麼多機器來組集羣。
3.公司缺少相關技術的開發和運維，成本代價高。

3.結論

• 大道至簡、分而治之
• 思路總比問題多，不拋棄不放棄。

總結不易歡迎在看或轉發，更多精彩關注微信公衆號【lovepythoncn】