电信数据稽核及处理技术方案

这篇文章主要讲解电信数据稽核处理技术方案,文中有关数据,稽核的内容,请有需要的人参考。

数据稽核及处理技术方案

 

 

 

 

 

 

 

 

编写与审核人

 

编写

审核

日期

备注

刘嘉劲、韦誉、温智勇

陶心万

2016-12-28

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

修改历史

日期

版本

作者

修改内容

更改请求号

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

注释:“更改请求号”为文档正式发布后需要变更时的编号。

 

目录

1.数据稽核 

1.1数据稽核概念 

1.2数据稽核优点 

1.3稽核策略 

1.3.1数据完整性 

1.3.2数据一致性 

1.3.3数据准确性 

1.4数据稽核流程 

2稽核方案 

2.1稽核数据 

2.2稽核规则 

2.3数据稽核方式 

2.4稽核方式比较和分析 

3数据处理与分析 

3.1技术方案 

3.1.1 Hadoop平台方案 

3.1.2 MapReduce中的ShuffleSort分析 

3.1.3 Hive处理流程 

3.1.4 Hive的服务端组件 

3.1.5 Hive的数据类型 

3.2采集数据稽核 

3.2.1数据完整性稽核 

3.2.2数据一致性稽核 

3.2.3数据准确性稽核 

3.3基站数据分析 

4结语 

 

 

1.数据稽核

1.1数据稽核概念

目前通信市场竞争激烈,资费下调,利润空间减少,应加强业务稽核,保障数据完整,是企业完善治理结构的内在需求。成本高、效率低、稽核过程繁琐、管理风险高是营收业务管理模式运行中的主要瓶颈。实际工作中,出于降低运营成本和偏重市场营销的经营思想等因素考虑,业务稽核工作是运营商管理工作中比较薄弱的环节;对电信业务进行稽核,保证受理业务合理、完整、准确也更显复杂性和必要性为适应内控需要,减少潜在风险,业务稽核将成为电信运营商日常管理工作中重要的一个环节。实行严格的业务稽核是电信企业发展的迫切需要,也是建立规范有效的内控制度的必要环节。

电信运营支撑系统中,用户数据存在以下特点:

第一业务属性维度多,包含各种订购关系、营销活动信息、产品业务属性、用户信息、客户信息、账户信息、资费信息等,各项数据分别存放于数据库中不同的表中。

第二数据量大,每项数据表都是海量的,采用原来的关联查询处理方法处理业务,几乎是不可能的。

第三数据间关系复杂,由于数据属性维度多,数据存储比较分散,表间关系已不仅仅是两两关系或主从关系,数据间大多呈现星形关系和树形关系。

第四用户数据稽核指标要求多,精度要求高,要核对每一项稽核指标,都须从海量的各项数据表中,查找相应的业务属性数据,数据稽核要求涉及交易性质,有时需要统计分析,而不仅仅是简单的查询汇总。

第五稽核指标多且变化频繁,由于各种交易操作频繁,发生差异的几率也比较高,错误可能是某数据项的偏差、也可能是数据项间的关系不对。基于以上特点,一方面,用户数据关系及业务规则复杂,发生错误的几率高;另一方面,由于数据量大且稽核事务复杂,难于及时、准确、全面的发现错误数据,以便及时修复,保障计费准确,规避相关投诉。因此,急需一种高效、精准的用户数据稽核方法或措施,在海量的用户数据及复杂的关系中,及时发现错误数据。

数据稽核是数据质量管控的一个核心内容,重点就是实现数据的完整性和一致性检查,提升数据质量,数据稽核是一个从数据采集,预处理,比对,分析,预警,通知,问题修复的完整数据质量管控链条。我在前面也谈到过,在当前的应用和架构下,企业业务系统间的数据集成模式导致了核心的主数据和跨系统共享的动态数据全部落地,由于本身数据集成的问题或者由于数据源头管理不善等原因导致了大量的数据不一致性。虽然一直在做数据清理工作,但是这种不一致性和问题将持续存在于整个应用架构体系里面。在这里简单谈下数据稽核的系统解决方面的事情。

1.2数据稽核优点

提升客户对服务的感知

1.提升跨域、跨平台以及跨系统间的数据质量.

2.提高服务的响应效率,进而提升用户的感知度.

3.有效杜绝数据的差错,减少用户投诉.

 

提供网络运行、生产效率

1.有利于提高网络资源的利用率.

2.减少企业部门间在协同处理业务时因数据质量问题而带来的沟通和协调时间,同时高效、持续的数据自动质量稽核手段有利于提高企业的生产效率.

3.可靠的数据质量保证企业网络运行的效率.

 

支撑精确化运营,提升企业生产运营水平

1.为企业的数据共享提供数据质量保证.

2.利于梳理和完善企业的数据质量管控流程.

3.为企业的精确化运营管理提供数据质量保证

 

1.3稽核策略

如图所示,DM数据稽核的大致思路是通过数据完整性、数据一致性、数据准确性三方面依次对DM层数据进行稽核,每一步都为下一步做准备,层层递进,环环相扣,以保证DM获取层、基础层、衍生层、复合指标层以及视图层的数据质量。

 

1.3.1数据完整性

数据完整性稽核主要包括,实体是否在规定的时间点提供了并加工生成了数据,实体中指标是否完整覆盖订阅指标两个方面,首先考虑实体中各账期各省份是否有数据(即判断数据是否缺失),只有在实体有数据的基础上才能做进一步的数据稽核,其次检查数据中指标是否满足需求,是否包含指标订购的指标。

1.3.2数据一致性

数据在由数据源到数据获取层,数据获取层到基础数据层,再由基础数据层到衍生数据层的传递过程中,数据能否保持一致也成为纵向实体间稽核的内容。在此基础上,检查横向实体间在相同口径下的相同指标的指标值是否一致。虽然实体间相同口径下相同的指标是建设集市极力避免出现的,但是一旦出现并使用,就要要对此进行严格的稽核管控。这种大量横纵十字交叉的方式进行一致性的检查,便形成了一种网状稽核。数据一致性网状稽核的目标便是无“漏网之鱼”。复合指标层的一致性稽核主要包括复合指标层实体内上期值、累计值等对应一致的稽核,这不仅保证了复合指标层的数据一致,而且便于数据的准确性稽核。

1.3.3数据准确性

数据在时间推移的过程中不可能一成不变,会按着一定规律波动,我们依照以往指标数据,确定不同指标的波动上限,波动下限,形成一个指标的正常波动范围。在数据保证完整一致的基础上,对当前更新的月数据作环比来表现月指标的变化状况,对当前更新的日数据作同比来表现日指标的变化状况,严格控制阀门,一旦超出指标正常波动范围,准确及时地找到异常数据。另外,我们用排名对比的方法体现复合指标层指标较上月的排名变化,把指标省内排名和全国排名变化较大的标记为异常指标。以上是本月比起上月同期值的变化情况,如果指标为异常,我们并不能确定哪个月的数据异常,因此,引出在时间序列上的指标数据展现,从而确定异常数据来源。

1.4数据稽核流程

首先说下数据稽核的整个流程,首先是数据的采集和适配,这个常见方式是通过ETL工具来完成,ETL工具采集到的数据做初步的数据清理和预处理。在这个步骤完成后根据预定义的数据稽核和校验规则,对数据进行差异分析和异常分析,对于分析的结果,一方面是实时的预警和通知,一方面是根据预先定义的报表模版生产数据稽核统计报表。以上完全可以配置为一个自动化的流程,当然对于核心的业务对象或实体,我们还可以定义稽核的时间范围,稽核的业务规则进行实时的数据比对工作。

其次,来看下数据稽核中跨系统数据比对的内容。数据比对本身是一个由粗到细的过程,首先是数据表级别的比较,但是这个往往并不需要;然后是数据表中记录层级的数据比较,A系统同步了一条数据到B系统,是否正常成功同步到,首先要比对的就是两个数据表的key值关联是否存在。行记录级别比较完成后是字段级别的数据比对工作,字段级的比对分为两个层面,一个是数据表表结构和字段结构元数据的一致性,如相同的表两边字段数量不一致,相同的字段的字段类型或长度不一致等;其次是字段内数据和内容的一致性比对。还有些数据稽核工具会提供数据参考完整性和通用性业务规则校验的功能。

 

 

2稽核方案

2.1稽核数据

此次稽核需要对采集数据进行稽核,并对3G、4G基站数据分析,由于用户数据业务属性多、属性间关联规则复杂、数据量庞大、变更频率高等原因,实现高效、精准的用户数据稽核一直是较大的难题;大数据最大的优点是针对传统手段捕捉到的数据之外的非结构化数据。这意味着不能保证输入的数据是完整的,清洗过的和没有任何的错误。因此用大数据技术稽核是非常有必要的,对于HDFS上的海量数据而言,编写Mapreduce程序代码对于类似数据仓库的需求来说总是显得相对于难以维护和重用,Hive作为一种基于Hadoop的数据仓库解决方案应运而生,并得到了广泛应用。

采集数据的稽核主要是比对采集的数据和上传到HDFS后的数据,采集的数据是通过程序上传到HDFS存储,所以采集数据的稽核要制定数据完整性、数据一致性、数据准确性稽核。基站数据的分析是整合3G4G基站数据,收集各类商圈的位置信息与基站数据结合,对基站数据打上位置标签。

2.2稽核规则

根据稽核策略,我们制定了数据完整性、数据一致性、数据准确性稽核的标准,提供数据稽核时参照的依据,也就是稽核规则,此外还对数据处理分析、实时数据分析比对。

2.3数据稽核方式

数据稽核使用实时流处理打破了传统的数据分析和处理的模式,即数据最终积累和落地后再针对海量数据进行拆分处理,然后进行分析统计,传统的模式很难真正达到实时性和速度要求。而实时流处理模型的重点正是既有类似HadoopMapReducePIG一样的数据处理和调度引擎,由解决了直接通过输入适配接驳到流的入口,流实时达到实时处理,实时进行分组汇聚等增量操作。在这种模式下一个重点就是前面谈到过的对于数据稽核规则需要进行拆分,形成多个可以并行处理的PE任务,对实时达到的数据流进行处理,形成某种结果信息后再向后续节点推送,最终实时的监控和查询数据比对结果。

 

在建立数据仓库时,ETL通常都采用批处理的方式,一般来说是每天的夜间进行跑批。

随着数据仓库技术的逐步成熟,企业对数据仓库的时间延迟有了更高的要求,也就出现了目前常说的实时ETLReal-Time ETL)。实时ETL是数据仓库领域里比较新的一部分内容。微批处理的方式和我们通常的ETL处理方式很相似,但是处理的时间间隔要短,例如间隔一个小时处理一次。数据稽核处理方式有以下几种方式。

1.触发器方式

是普遍采取的一种增量抽取机制。该方式是根据抽取要求,在要被抽取的源表上建立插入、修改、删除3个触发器,每当源表中的数据发生变化,就被相应的触发器将变化的数据写入一个增量日志表,ETL的增量抽取则是从增量日志表中而不是直接在源表中抽取数据,同时增量日志表中抽取过的数据要及时被标记或删除。为了简单起见,增量日志表一般不存储增量数据的所有字段信息,而只是存储源表名称、更新的关键字值和更新操作类型(knsenupdatedelete)ETL增量抽取进程首先根据源表名称和更新的关键字值,从源表中提取对应的完整记录,再根据更新操作类型,对目标表进行相应的处理。

2.时间戳方式

时间戳方式是指增量抽取时,抽取进程通过比较系统时间与抽取源表的时间戳字段的值来决定抽取哪些数据。这种方式需要在源表上增加一个时间戳字段,系统中更新修改表数据的时候,同时修改时间戳字段的值。有的数据库(例如Sql Server)的时间戳支持自动更新,即表的其它字段的数据发生改变时,时间戳字段的值会被自动更新为记录改变的时刻。在这种情下,进行ETL实施时就只需要在源表加上时间戳字段就可以了。对于不支持时间戳自动更新的数据库,这就要求业务系统在更新业务数据时,通过编程的方式手工更新时间戳字段。使用时间戳方式可以正常捕获源表的插入和更新操作,但对于删除操作则无能为力,需要结合其它机制才能完成。

3.全表删除插入方式

全表删除插入方式是指每次抽取前先删除目标表数据,抽取时全新加载数据。该方式实际上将增量抽取等同于全量抽取。对于数据量不大,全量抽取的时间代价小于执行增量抽取的算法和条件代价时,可以采用该方式。

4.全表比对方式                                                                

全表比对即在增量抽取时,ETL进程逐条比较源表和目标表的记录,将新增和修改的记录读取出来。优化之后的全部比对方式是采用MD5校验码,需要事先为要抽取的表建立一个结构类似的MD5临时表,该临时表记录源表的主键值以及根据源表所有字段的数据计算出来的MD5校验码,每次进行数据抽取时,对源表和MD5临时表进行MD5校验码的比对,如有不同,进行update操作:如目标表没有存在该主键值,表示该记录还没有,则进行insert操作。然后还需要对在源表中已不存在而目标表仍保留的主键值,执行delete操作。

5.日志表方式

对于建立了业务系统的生产数据库,可以在数据库中创建业务日志表,当特定需要监控的业务数据发生变化时,由相应的业务系统程序模块来更新维护日志表内容。增量抽取时,

通过读日志表数据决定加载哪些数据及如何加载。日志表的维护需要由业务系统程序用代码来完成。

6.系统日志分析方式

该方式通过分析数据库自身的日志来判断变化的数据。关系犁数据库系统都会将所有的DML操作存储在日志文件中,以实现数据库的备份和还原功能。ETL增晕抽取进程通过对数据库的日志进行分析,提取对相关源表在特定时间后发生的DML操作信息,就可以得知自上次抽取时刻以来该表的数据变化情况,从而指导增量抽取动作。有些数据库系统提供了访问日志的专用的程序包例如OracleLogMinder),使数据库日志的分析工作得到大大简化。

2.4稽核方式比较和分析

ETL在进行增量抽取操作时,有以上各种机制可以选择。现从兼容性、完备性、性能和侵入性3个方面对这些机制的优劣进行比较分析。数据抽取需要面对的源系统,并不一定都是关系型数据库系统。某个ETL过程需要从若干年前的遗留系统中抽取Excel或者CSV文本数据的情形是经常发牛的。这时,所有基于关系型数据库产品的增量机制都无法工作,时间戳方式和全表比对方式可能有一定的利用价值,在最坏的情况下,只有放弃增量抽取的思路,转而采用全表删除插入方式。完备性方面,时间戳方式不能捕获delete操作,需要结合其它方式一起使用。增量抽取的性能因素表现在两个方面,一是抽取进程本身的性能,二是对源系统性能的负面影响。触发器方式、日志表方式以及系统日志分析方式由于不需要在抽取过程中执行比对步骤,所以增量抽取的性能较佳。全表比对方式需要经过复杂的比对过程才能识别出更改的记录,抽取性能最差。在对源系统的性能影响方面,触发器方式由于是直接在源系统业务表上建立触发器,同时写临时表,对于频繁操作的业务系统可能会有一定的性能损失,尤其是当业务表上执行批量操作时,行级触发器将会对性能产生严重的影响;同步CDC方式内部采用触发器的方式实现,也同样存在性能影响的问题;全表比对方式和日志表方式对数据源系统数据库的性能没有任何影响,只是它们需要业务系统进行额外的运算和数据库操作,会有少许的时间损耗;时间戳方式、系统日志分析方式以及基于系统日志分析的方式异步CDC和闪回查询对数据库性能的影响也是非常小的。对数据源系统的侵入性是指业务系统是否要为实现增抽取机制做功能修改和额外操作,在这一点上,时间戳方式值得特别关注该方式除了要修改数据源系统表结构外,对于不支持时间戳字段自动更新的关系型数据库产品,还必须要修改业务系统的功能,让它在源表t执行每次操作时都要显式的更新表的时间戳字段,这在ETL实施过程中必须得到数据源系统高度的配合才能达到,并且在多数情况下这种要求在数据源系统看来是比较“过分”的,这也是时间戳方式无法得到广泛运用的主要原因。另外,触发器方式需要在源表上建立触发器,这种在某些场合中也遭到拒绝。还有一些需要建立临时表的方式,例如全表比对和日志表方式。可能因为开放给ETL进程的数据库权限的限制而无法实施。同样的情况也可能发生在基于系统日志分析的方式上,因为大多数的数据库产品只允许特定组的用户甚至只有DBA才能执行日志分析。闪回杏询在侵入性方面的影响是最小的。

 

3数据处理与分析

针对不同数据类型与应用的大数据处理系统是支持大数据科学研究的基础平台,对于规模巨大、结构复杂、价值稀疏的大数据,其处理亦面临计算复杂度高、任务周期长、实时性要求强等难题,大数据及其处理的这些难点不仅对大数据处理系统的系统架构、计算框架、处理方法提出了新的挑战,更对大数据处理系统的运行效率及单位能耗提出了苛刻要求,要求大数据处理系统必须具有高效能的特点,对于以高效能为目标的大数据处理系统的系统架构设计、计算框架设计、处理方法设计和测试基准设计研究,其基础是大数据处理系统的效能评价与优化问题研究,这些问题的解决可奠定大数据处理系统设计、实现、测试与优化的基本准则,是构建能效优化的分布式存储和处理的硬件及软件系统架构的重要依据和基础,因此是大数据分析处理所必须解决的关键问题。

3.1技术方案

大数据,首先你要能存的下大数据,HDFSHadoop Distributed FileSystem)的设计本质上是为了大量的数据能横跨成百上千台机器,但是你看到的是一个文件系统而不是很多文件系统。存的下数据之后,我们就得对这些数据进行处理,此次数据稽核中使用了hadoop+hive的大数据处理技术,hiveHadoop的一个组件,作为数据厂库,hive的数据是存储在Hadoop的文件系统中的,hiveHadoop提供SQL语句,是Hadoop可以通过SQL语句操作文件系统中的数据,hive是依赖Hadoop而存在的。Hive是基于Hadoop的数据仓库平台,由Facebook贡献,其支持类似SQL的结构化查询功能。Facebook设计开发Hive的初衷就是让那些熟悉SQL编程方式的人也可以更好的利用hadoophive可以让数据分析人员只关注于具体业务模型,而不需要深入了解Map/Reduce的编程细节,但是这并不意味着使用hive不需要了解和学习Map/Reduce编程模型和Hadoop,复杂的业务需求和模型总是存在的,对于Hive分析人员来说,深入了解HadoopHive的原理和Mapreduce模型,对于优化查询总有益处。

hive把海量数据存储于 hadoop 文件系统,而不是数据库,但提供了一套类数据库的数据存储和处理机制,并采用 HQL (类 SQL )语言对这些数据进行自动化管理和处理。我们可以把 hive 中海量结构化数据看成一个个的表,而实际上这些数据是分布式存储在 HDFS 中的。 Hive 经过对语句进行解析和转换,最终生成一系列基于 Hadoop map/reduce 任务,通过执行这些任务完成数据处理。

借助于HadoopHDFS的大数据存储能力,数据仍然存储于HadoopHDFS中,Hive提供了一种类SQL的查询语言:HiveQLHQL),对数据进行管理和分析。Hive 构建在基于静态批处理的Hadoop 之上,Hadoop 通常都有较高的延迟并且在作业提交和调度的时候需要大量的开销。因此,Hive 并不能够在大规模数据集上实现低延迟快速的查询,例如,Hive 在几百MB 的数据集上执行查询一般有分钟级的时间延迟。

Hive 并不适合那些需要低延迟的应用,例如,联机事务处理(OLTP)。Hive 查询操作过程严格遵守Hadoop MapReduce 的作业执行模型,Hive 将用户的HiveQL 语句通过解释器转换为MapReduce 作业提交到Hadoop 集群上,Hadoop 监控作业执行过程,然后返回作业执行结果给用户。

Hive的执行入口是Driver,执行的SQL语句首先提交到Drive驱动,然后调用compiler解释驱动,最终解释成MapReduce任务去执行。

 

3.1.1 Hadoop平台方案

Hadoop是一个由Apache基金会所开发的分布式系统基础架构。用户可以在不了解分布式底层细节的情况下,开发分布式程序。充分利用集群的威力进行高速运算和存储。

Hadoop实现了一个分布式文件系统(Hadoop Distributed File System),简称HDFSHDFS有高容错性的特点,并且设计用来部署在低廉的(low-cost)硬件上,而且它提供高吞吐量(high throughput)来访问应用程序的数据,适合那些有着超大数据集(large data set)的应用程序。HDFS放宽了(relaxPOSIX的要求,可以以流的形式访问(streaming access)文件系统中的数据。

Hadoop的框架最核心的设计就是:HDFSMapReduceHDFS为海量的数据提供了存储,则MapReduce为海量的数据提供了计算。

 

MapReduce是一个软件框架,基于该框架能够容易地编写应用程序,这些应用程序能够运行在由上千个商用机器组成的大集群上,并以一种可靠的,具有容错能力的方式并行地处理上TB级别的海量数据集。这个定义里面有着这些关键词,一是软件框架,二是并行处理,三是可靠且容错,四是大规模集群,五是海量数据集。因此,对于MapReduce,可以简洁地认为,它是一个软件框架。MapReduce擅长处理大数据,它为什么具有这种能力呢?这可由MapReduce的设计思想发觉。MapReduce的思想就是“分而治之”。Mapper负责“分”,即把复杂的任务分解为若干个“简单的任务”来处理。“简单的任务”包含三层含义:一是数据或计算的规模相对原任务要大大缩小;二是就近计算原则,即任务会分配到存放着所需数据的节点上进行计算;三是这些小任务可以并行计算,彼此间几乎没有依赖关系。Reducer负责对map阶段的结果进行汇总。至于需要多少个Reducer,用户可以根据具体问题,通过在mapred-site.xml配置文件里设置参数mapred.reduce.tasks的值,缺省值为1

 

3.1.2 MapReduce中的ShuffleSort分析

MapReduce是现今一个非常流行的分布式计算框架,它被设计用于并行计算海量数据。第一个提出该技术框架的是Google公司,而Google的灵感则来自于函数式编程语言,如LISPSchemeML等。MapReduce框架的核心步骤主要分两部分:MapReduce。当你向MapReduce框架提交一个计算作业时,它会首先把计算作业拆分成若干个Map 任务,然后分配到不同的节点上去执行,每一个Map任务处理输入数据中的一部分,当Map任务完成后,它会生成一些中间文件,这些中间文件将会作为Reduce 任务的输入数据。Reduce任务的主要目标就是把前面若干个Map的输出汇总到一起并输出。从高层抽象来看,MapReduce的数据流图如图 所示:

 

Shuffle是指从Map产生输出开始,包括系统执行排序以及传送Map输出到Reducer作为输入的过程。在这里我们将去探究Shuffle是如何工作的,因为对基础的理解有助于对MapReduce程序进行调优。

首先从Map端开始分析,当Map开始产生输出的时候,他并不是简单的把数据写到磁盘,因为频繁的操作会导致性能严重下降,他的处理更加复杂,数据首先是写到内存中的一个缓冲区,并作一些预排序,以提升效率,如图:

 

每个Map任务都有一个用来写入输出数据的循环内存缓冲区,这个缓冲区默认大小是100M,可以通过io.sort.mb属性来设置具体的大小,当缓冲区中的数据量达到一个特定的阀值(io.sort.mb * io.sort.spill.percent,其中io.sort.spill.percent 默认是0.80)时,系统将会启动一个后台线程把缓冲区中的内容spill 到磁盘。在spill过程中,Map的输出将会继续写入到缓冲区,但如果缓冲区已经满了,Map就会被阻塞直道spill完成。spill线程在把缓冲区的数据写到磁盘前,会对他进行一个二次排序,首先根据数据所属的partition排序,然后每个partition中再按Key排序。输出包括一个索引文件和数据文件,如果设定了Combiner,将在排序输出的基础上进行。Combiner就是一个Mini Reducer,它在执行Map任务的节点本身运行,先对Map的输出作一次简单的Reduce,使得Map的输出更紧凑,更少的数据会被写入磁盘和传送到ReducerSpill文件保存在由mapred.local.dir指定的目录中,Map任务结束后删除。

每当内存中的数据达到spill阀值的时候,都会产生一个新的spill文件,所以在Map任务写完他的最后一个输出记录的时候,可能会有多个spill文件,在Map任务完成前,所有的spill文件将会被归并排序为一个索引文件和数据文件。如图3 所示。这是一个多路归并过程,最大归并路数由io.sort.factor 控制默认是10)。如果设定了Combiner,并且spil文件的数量至少是3(由min.num.spills.for.combine 属性控制),那么Combiner将在输出文件被写入磁盘前运行以压缩数据。

 

 

对写入到磁盘的数据进行压缩(这种压缩同Combiner 的压缩不一样)通常是一个很好的方法,因为这样做使得数据写入磁盘的速度更快,节省磁盘空间,并减少需要传送到Reducer 的数据量。默认输出是不被压缩的,但可以很简单的设置mapred.compress.map.outputtrue启用该功能。压缩所使用的库由mapred.map.output.compression.codec来设定spill文件归并完毕后,Map将删除所有的临时spill 文件,并告知TaskTracker 任务已完成。Reducers 通过HTTP 来获取对应的数据。用来传输partitions数据的工作线程个数由tasktracker.http.threads控制,这个设定是针对每一个TaskTracker的,并不是单个Map,默认值为40,在运行大作业的大集群上可以增大以提升数据传输速率。

现在让我们转到ShuffleReduce部分。Map的输出文件放置在运行Map任务的TaskTracker的本地磁盘上(注意:Map输出总是写到本地磁盘,但是Reduce输出不是,一般是写到HDFS),它是运行Reduce任务的TaskTracker所需要的输入数据。Reduce任务的输入数据分布在集群内的多个Map任务的输出中,Map任务可能会在不同的时间内完成,只要有其中一个Map任务完成,Reduce任务就开始拷贝他的输出。这个阶段称为拷贝阶段,Reduce任务拥有多个拷贝线程,可以并行的获取Map输出。可以通过设定mapred.reduce.parallel.copies来改变线程数。

Reduce是怎么知道从哪些TaskTrackers中获取Map的输出呢?当Map任务完成之后,会通知他们的父TaskTracker,告知状态更新,然后TaskTracker再转告JobTracker,这些通知信息是通过心跳通信机制传输的,因此针对以一个特定的作业,jobtracker知道Map输出与tasktrackers的映射关系。Reducer中有一个线程会间歇的向JobTracker询问Map输出的地址,直到把所有的数据都取到。在Reducer取走了Map输出之后,TaskTracker不会立即删除这些数据,因为Reducer可能会失败,他们会在整个作业完成之后,JobTracker告知他们要删除的时候才去删除。

如果Map输出足够小,他们会被拷贝到Reduce TaskTracker的内存中(缓冲区的大小由mapred.job.shuffle.input.buffer.percnet控制),或者达到了Map输出的阀值的大小mapred.inmem.merge.threshold控制,缓冲区中的数据将会被归并然后spill到磁盘。

拷贝来的数据叠加在磁盘上,有一个后台线程会将它们归并为更大的排序文件,这样做节省了后期归并的时间。对于经过压缩的Map 输出,系统会自动把它们解压到内存方便对其执行归并。

当所有的Map输出都被拷贝后,Reduce任务进入排序阶段(更恰当的说应该是归并阶段,因为排序在Map端就已经完成),这个阶段会对所有的Map输出进行归并排序,这个工作会重复多次才能完成。

假设这里有50Map输出(可能有保存在内存中的),并且归并因子是10(由io.sort.factor控制,就像Map端的merge一样),那最终需要5次归并。每次归并会把10个文件归并为一个,最终生成5个中间文件。在这一步之后,系统不再把5个中间文件归并成一个,而是排序后直接“喂”给Reduce 函数,省去向磁盘写数据这一步。最终归并的数据可以是混合数据,既有内存上的也有磁盘上的。由于归并的目的是归并最少的文件数目,使得在最后一次归并时总文件个数达到归并因子的数目,所以每次操作所涉及的文件个数在实际中会更微妙些。譬如,如果有40个文件,并不是每次都归并10个最终得到4个文件,相反第一次只归并4个文件,然后再实现三次归并,每次10个,最终得到4个归并好的文件和6 个未归并的文件。要注意,这种做法并没有改变归并的次数,只是最小化写入磁盘的数据优化措施,因为最后一次归并的数据总是直接送到Reduce 函数那里。在Reduce阶段,Reduce函数会作用在排序输出的每一个key上。这个阶段的输出被直接写到输出文件系统,一般是HDFS。在HDFS中,因为TaskTracker节点也运行着一个DataNode进程,所以第一个块备份会直接写到本地磁盘。到此,MapReduceShuffleSort分析完毕。

3.1.3 Hive处理流程

 

流程大致步骤为:

1. 用户提交查询等任务给Driver

2. 编译器获得该用户的任务Plan

3. 编译器Compiler根据用户任务去MetaStore中获取需要的Hive的元数据信息。

4. 编译器Compiler得到元数据信息,对任务进行编译,先将HiveQL转换为抽象语法树,然后将抽象语法树转换成查询块,将查询块转化为逻辑的查询计划,重写逻辑查询计划,将逻辑计划转化为物理的计划(MapReduce, 最后选择最佳的策略。

5. 将最终的计划提交给Driver

6. Driver将计划Plan转交给ExecutionEngine去执行,获取元数据信息,提交给JobTracker或者SourceManager执行该任务,任务会直接读取HDFS中文件进行相应的操作。

7. 获取执行的结果。

8. 取得并返回执行结果。

创建表时:

解析用户提交的Hive语句-->对其进行解析-->分解为表、字段、分区等Hive对象。根据解析到的信息构建对应的表、字段、分区等对象,从SEQUENCE_TABLE中获取构建对象的最新的ID,与构建对象信息(名称、类型等等)一同通过DAO方法写入元数据库的表中,成功后将SEQUENCE_TABLE中对应的最新ID+5.实际上常见的RDBMS都是通过这种方法进行组织的,其系统表中和Hive元数据一样显示了这些ID信息。通过这些元数据可以很容易的读取到数据。

Hive编译过程

基本流程为:将HiveQL转化为抽象语法树再转为查询块然后转为逻辑查询计划再转为物理查询计划最终选择最佳决策的过程。

优化器的主要功能:

1. 将多Multiple join 合并为一个Muti-way join

2. joingroup-by和自定义的MapReduce操作重新进行划分。

3. 消减不必要的列。

4. 在表的扫描操作中推行使用断言。

5. 对于已分区的表,消减不必要的分区。

6. 在抽样查询中,消减不必要的桶。

7. 优化器还增加了局部聚合操作用于处理大分组聚合和增加再分区操作用于处理不对称的分组聚合。

 

3.1.4 Hive的服务端组件

1. Driver组件:该组件包括:CompilerOptimizerExecutor,它可以将Hive的编译、解析、优化转化为MapReduce任务提交给Hadoop1中的JobTracker或者是Hadoop2中的SourceManager来进行实际的执行相应的任务。

2. MetaStore组件:存储着hive的元数据信息,将自己的元数据存储到了关系型数据库当中,支持的数据库主要有:MysqlDerby、支持把metastore独立出来放在远程的集群上面,使得hive更加健壮。元数据主要包括了表的名称、表的列、分区和属性、表的属性(是不是外部表等等)、表的数据所在的目录。

3. 用户接口:CLICommand Line Interface)(常用的接口:命令行模式)、Client:Hive的客户端用户连接至Hive Server ,在启动Client的时候,需要制定Hive Server所在的节点,并且在该节点上启动Hive ServerWUI:通过浏览器的方式访问Hive

3.1.5 Hive的数据类型

Hive支持原子和复杂数据类型,原子数据类型包括:数据值、布尔类型、字符串类型等,复杂的类型包括:ArrayMapStruct。其中ArrayMapjava中的ArrayMap是相似的,StructC语言中的Struct相似。

例如:

 

 

注意:

1. 原子数据类型是可以进行隐式的转换的,例如tinyInt类型会自动转为Int类型但是不能由int自动转为tinyInt类型。

2. 所有的整数类型、FloatString类型都可以转换为Double类型。

3. TinyIntSmallIntInt都可以转为Float类型。

4. Boolean 类型不可以转换为其他的任何类型。

5. 可以通过使用Cast操作显示的进行数据转换,例如Cast('1' as int);将字符串转为整型,如果强制转换失败如:Cast('X' as int);表达式返回的是NULL;

 

3.2采集数据稽核

3.2.1数据完整性稽核

数据是否缺失稽核

检查采集到的数据和通过程序上传到HDFS存储的数据,查看文件数是否一致,相同则数据完整。

3.2.2数据一致性稽核

数据横向对比稽核

数据横向稽核又分为数据获取层间指标值的对比稽核及数据获取层内指标值的对比稽核,数据获取层表间指标值的对比稽核:通过对横向基础在相同数据,相同省份,相同业务口径下的各共有指标值作差。若差值为零,则数据正常;否则数据有误,而且若接口层数据传递无误,则表明数据有误;

复合指标表内一致性稽核

复合指标一致性稽核是检查数据除本期值以外的其他值的一致性,主要针对复合指标层的月复合指标表和日复合指标表,其中月复合指标表中的上期指标值、本年累计指标值、去年同期指标值、去年同期累计指标值,日复合指标表中的昨日指标值、上月同期值、本月同期累计值、上月同期累计值、去年同期值、去年同期月累计。

 

3.2.3数据准确性稽核

月数据环比预警稽核

参考以往合理月数据指标的环比变化,确定该指标变化的波峰,波谷,由此形成其正常变化范围。通过对当月数据值与上月数据值对环比对照,若该数据在正常变化范围内,则说明该指标数据正常;若偏离正常变化范围之外,则说明该指标数据异常。

日数据同比预警稽核

参考以往合理日数据指标的同比变化,确定该指标其波峰,波谷,由此形成其正常变化范围。通过对当日值与上月同日值对同比对照,若该数据在正常变化范围内,则说明该指标数据正常;若偏离正常变化范围之外,则说明该指标数据异常。通过稽核发现数据异常可通过邮件发送通知。

3.3基站数据分析

大数据中的一个重要组成部分就是位置大数据(location big data,LBD),位置大数据已经成为当前用来感知人类社群活动规律,分析地理国情和构建智慧城市的重要战略资源。实现智慧城市的关键之一是建立一种泛在的城市计算(urban computing)体制,其中涉及到泛在测绘、位置大数据分析和服务提供三个重要层面。因此位置大数据的分析处理和辅助决策已成为智慧城市实现与城市地理国情分析中的关键问题。通过对位置大数据的分析应用,主要可形成智慧城市三个方面的服务支持:为城市运行服务,包括城市规划、疾病控制、智能交通、节能减排、环境保护、应急响应等;为个人生活服务,包括社会交流、个性化信息推送、驾驶安全、智能驾驶等;为企业经济服务,包括企业的调度、门店选址、广告推送、位置营销等。在大数据科学研究中,一些与数据本身来源和主体看似无关的对象,在经过数据价值提取和协同挖掘后往往会表现出密切关联性。同样地,位置大数据的应用分析,不只是被用来进行交通问题的分析,还能够提升我们对更为广泛的人类社会经济活动和自然环境的认知,从而体现其内在价值。从目前的研究和应用来看,位置大数据在社会感知、群体智能系统建设、地理国情分析等方面的应用效果显著。

基站数据的分析是整合3G4G基站数据,收集各类商圈的位置信息与基站数据结合,对基站数据打上位置标签。首先是根据基站经纬度在地图上定位,根据基站附近的商圈给基站给定标签,如广州范围内的商场、公园、火车站、机场、客运站,基站给定标签之后可以为后续的服务提供数据。

基站静态数据的自动化查新使用了大数据技术hadoophive自动化更新基站商圈特征,根据基站经纬度在地图上搜索附近出的商圈使用爬虫把附近指定商圈信息爬取下来,之后通过hive自定义函数写入表中更新当前基站标签,自动化更新的周期可以在UTS系统上自定义时间对基站标签更新。

 

位置服务已从单纯的定位服务转变为具有社会化、本地化和移动性特征的新型业态。用户的服务需求已经从获取位置扩展为获取位置背后更为丰富的社会信息与群体智能,从位置搜索、路径规划等普遍化需求扩展为符合自身社会属性的个性化、智能化需求。通过位置大数据的社会感知,可以更好地认识“人的世界”。在不同城市和不同人群中,位置数据特征上的差异就可以直接映射到人们在休闲/娱乐方式、群体性格、情感分布、生活压力、城市宜居性等方面上去。再者,通过大规模位置轨迹的分布学习,可以为社群移动行为进行指导,从而参与诸如疾控预防、防灾减灾等工作。位置大数据已经成为当前用来感知人类社群活动规律、分析地理国情和构建智慧城市的重要战略资源,提升了大众对更为广泛的人类社会经济活动和自然环境的认识,充分体现了位置数据的价值。

4结语

通过数据稽核保证了数据的完整性、一致性和准确性减少了企业部门间在协同处理业务时因数据质量问题而带来的沟通和协调时间,同时高效、持续的数据自动质量稽核手段有利于提高企业的生产效率,为企业的精确化运营管理提供数据质量保证。将hadoophive和流处理,消息中间件,规则引擎等技术应用到数据稽核绝对不是大材小用,而是大数据技术能够更好的服务于传统业务系统,解决业务系统问题的重要尝试。即并不是我们的业务系统必须到了海量数据存储后才谈得上用大数据技术,而是在业务需求本身在实时性,效率,架构可扩展性等多个方面都可以采用大数据技术来解决真实业务场景下的业务问题。使用大数据稽核降低了人力物力消耗,减少了数据稽核成本。

大数据,其影响除了经济方面的,它同时也能在政治、文化等方面产生深远的影响,大数据可以帮助人们开启循“数”管理的模式,也是我们当下“大社会”的集中体现,三分技术,七分数据,得数据者得天下。

 

以上关于电信数据稽核及处理技术方案的文章就到此为止,希望对大家有所帮助。

您可以选择一种方式赞助本站

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: