大数据分析之纳税人画像-实现和优化思路

简介: 大数据分析之纳税人画像-实现和优化思路

1.背景环境

本文章来自最近做的项目模块的思考和总结,主要讲思路不涉及过多的基础和实现细节。


需求:统计出来纳税人名称、行业、近一年业务量(办税服务厅、电子税务局、自助渠道),近一年业务量top5(办税服务厅、电子税务局、自助渠道)、近一年纳税金额、近一年申报数、近一年用票数。支持根据所属税务机关分页查询。



看上去业务不复杂,但是**数据来自多个系统,数据量很大。**来来画个示意图展示下数据来源的复杂程度:


17.png



数据涉及5个厂商,数据库采用oracle,涉及几十张表,其中纳税人信息生产环境下有380多万,更不用说其他业务表的数据量有多大了,并且还需要分组,统计,排序。此时此刻心情如下:

18.png

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. 来看下现场的执行计划


19.png


20.png



冷静分析


  • 数据库是其他厂商的,我们没有权限去建索引,只给了查询权限。
  • 大量的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个小时,居然失败了,怎么办?


21.png



冷静分析


  • 仔细看sql,去掉了不必要的关联查询。
  • 拆分物理视图,一个拆三,分而治之。

最后在3个小时左右,成功创建了5个物理视图。

又出状况、一波四折


22.png



测试库是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.结论

  • 大道至简、分而治之
  • 思路总比问题多,不抛弃不放弃。

相关文章
|
4月前
|
存储 分布式计算 大数据
基于Python大数据的的电商用户行为分析系统
本系统基于Django、Scrapy与Hadoop技术,构建电商用户行为分析平台。通过爬取与处理海量用户数据,实现行为追踪、偏好分析与个性化推荐,助力企业提升营销精准度与用户体验,推动电商智能化发展。
|
5月前
|
存储 SQL 分布式计算
终于!大数据分析不用再“又要快又要省钱”二选一了!Dataphin新功能太香了!
Dataphin推出查询加速新功能,支持用StarRocks等引擎直连MaxCompute或Hadoop查原始数据,无需同步、秒级响应。数据只存一份,省成本、提效率,权限统一管理,打破“又要快又要省”的不可能三角,助力企业实现分析自由。
264 49
|
4月前
|
机器学习/深度学习 大数据 关系型数据库
基于python大数据的台风灾害分析及预测系统
针对台风灾害预警滞后、精度不足等问题,本研究基于Python与大数据技术,构建多源数据融合的台风预测系统。利用机器学习提升路径与强度预测准确率,结合Django框架实现动态可视化与实时预警,为防灾决策提供科学支持,显著提高应急响应效率,具有重要社会经济价值。
|
4月前
|
机器学习/深度学习 大数据 关系型数据库
基于python大数据的青少年网络使用情况分析及预测系统
本研究基于Python大数据技术,构建青少年网络行为分析系统,旨在破解现有防沉迷模式下用户画像模糊、预警滞后等难题。通过整合多平台亿级数据,运用机器学习实现精准行为预测与实时干预,推动数字治理向“数据驱动”转型,为家庭、学校及政府提供科学决策支持,助力青少年健康上网。
|
5月前
|
存储 SQL 分布式计算
MaxCompute 聚簇优化推荐原理
基于历史查询智能推荐Clustered表,显著降低计算成本,提升数仓性能。
336 4
MaxCompute 聚簇优化推荐原理
|
5月前
|
数据采集 数据可视化 关系型数据库
基于python大数据的电影数据可视化分析系统
电影分析与可视化平台顺应电影产业数字化趋势,整合大数据处理、人工智能与Web技术,实现电影数据的采集、分析与可视化展示。平台支持票房、评分、观众行为等多维度分析,助力行业洞察与决策,同时提供互动界面,增强观众对电影文化的理解。技术上依托Python、MySQL、Flask、HTML等构建,融合数据采集与AI分析,提升电影行业的数据应用能力。
|
5月前
|
存储 并行计算 算法
【动态多目标优化算法】基于自适应启动策略的混合交叉动态约束多目标优化算法(MC-DCMOEA)求解CEC2023研究(Matlab代码实现)
【动态多目标优化算法】基于自适应启动策略的混合交叉动态约束多目标优化算法(MC-DCMOEA)求解CEC2023研究(Matlab代码实现)
247 4
|
4月前
|
传感器 人工智能 监控
拔俗多模态跨尺度大数据AI分析平台:让复杂数据“开口说话”的智能引擎
在数字化时代,多模态跨尺度大数据AI分析平台应运而生,打破数据孤岛,融合图像、文本、视频等多源信息,贯通微观与宏观尺度,实现智能诊断、预测与决策,广泛应用于医疗、制造、金融等领域,推动AI从“看懂”到“会思考”的跃迁。
362 0
|
5月前
|
大数据 数据挖掘 定位技术
买房不是拍脑袋:大数据教你优化房地产投资策略
买房不是拍脑袋:大数据教你优化房地产投资策略
225 2