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】