CN105550296A - 一种基于spark-SQL大数据处理平台的数据导入方法 - Google Patents

Abstract

本发明公开了一种基于spark-SQL大数据处理平台的数据导入方法，通过入库程序将数据导入spark-SQL大数据处理平台，所述入库程序包括分区部分、数据压缩部分、写入HDFS部分，所述分区部分、数据压缩部分、写入HDFS部分分别采用C语言编程并编译连接形成优化的目标代码入库程序。采用C语言实现分区逻辑，支持多个分区，支持用户自定义分区格式。使用本发明的数据导入方法入库速度有极大提升，通过对一般样本数据的实际测试，在普通服务器平台上做对比测试，原入库程序速度为2万条/秒，本发明所优化修改过的入库程序速度可以达到19万条/秒。这种入库速度的提高，主要原因是由于程序采用C语言改写，效率比JVM方式快很多。

Description

一种基于spark-SQL大数据处理平台的数据导入方法

技术领域

本发明涉及一种数据导入方法，尤其涉及一种基于spark-SQL大数据处理平台的数据导入方法。

背景技术

随着互联网、移动互联网和物联网的发展，我们迎来了一个海量数据的时代，对这些海量数据的分析已经成为一个非常重要且紧迫的需求。

随着技术的发展，大数据处理平台经历了最初的Hadoop，Hbase，以及后来发展起来的基于SQL的Hive、shark等。基于key-value的Hbase等处理平台也逐渐兴起。而如今SQL-on-Hadoop概念的兴起又促使Spark生态发展壮大，逐渐成为最热门，使用最多，效率最好的一种大数据处理平台。

如图1所示，不管采取哪种大数据处理平台，它们的目的都是分析和处理海量数据，从中分析和挖掘出有用数据供人们使用。从最基本的原理来看，无论是基于Map-Reduce的Hadoop，还是基于Key-Value键值对的Hbase，或者是基于RDD的Spark，它们的总体处理流程都是相同的，都是包含了数据导入→数据分析和处理→数据结果展示三个主要步骤，其中最重要的两个部分为数据导入和数据分析处理过程，数据导入的速度决定了整个系统能够实时处理的数据速度，影响到整个系统的处理性能，数据导入和分析的过程则是数据处理的核心。

本专利主要涉及数据导入部分的速度的改进和优化。

大数据处理平台无论是Hadoop、Hbase、Spark等等，都涉及到海量数据的处理，而分析和处理这些海量数据的前提就是将这些外部数据导入到大数据处理平台中去，这个导入过程在实际应用环境中对导入速度、导入数据量、导入后格式的转换等等都有较高的性能要求。

数据导入通常分为以下几个关键点：

1、导入内容

通常导入内容可以为格式化或者非格式化的文本数据；

以特定的分隔符或者特定的文件格式(XML等)分割每一条记录；

内容可以以文件形式传送，也可以以数据流形式传送；

文件大小不定。

2、导入格式

导入数据的格式可以为文本格式，也可以为了减少磁盘使用量，经过压缩后转化为二进制格式。

压缩格式可以为zip、bz2、snappy、parquet等等。

导入数据可以根据内容进行分区，用以后续加快查询速度。

例如一个包含电话呼叫记录的数据格式如表一所示：

表一

记录编号	主叫号码	被叫号码	起呼时间	终呼时间	小区编号……
						1	131000001	135000001	8:00:01	8:00:57	001
2	132000002	136000001	9:00:01	9:00:58	001
						3	133000003	138000001	9:00:01	9:01:16	001
4	131000004	186000001	11:10:01	12:08:16	001

单分区：

如果以主叫号码前三位分区，则记录1，4为分区1；记录2为分区2；记录3为分区3。

如果以一个小时为单位按起呼时间分区，则记录1为分区1；记录2、3为分区2；记录4为分区3。

多分区：

同时以主叫号码前三位和以一小时为单位的起呼时间分区，则记录1、2、3、4分别会落入分区1、2、3、4。

导入数据时压缩和分区可以同时进行。

3、导入速度

导入速度越快越好，具体的业务会根据实际情况提出导入速度不低于x条每秒或者xMB每秒。不得出现数据丢失、数据导入错误、数据积压等情况。

现有技术中，基于spark-SQL大数据处理平台的数据导入方法如下：

1、如图2所示，根据外部文件格式，写出Spark-SQL语句或者HDFS的load语句，将外部数据导入临时表。外部数据位于外部系统的磁盘上，临时表位于Spark大数据系统的HDFS存储上。这一步相当于将调用HDFS的文件接口，将外部文件直接拷贝到HDFS上。

其内部实现为，Spark-SQL语句最终转化为HDFS文件导入接口程序调用，同时将待导入的文件按特定大小拆分，然后分配给不同的任务进程，通过接口程序同步导入HDFS存储。这一步位于HDFS上的文件成为临时表文件。

2、如图3和图4所示，将导入的文本文件按指定分区格式、压缩格式进行二次处理。

指定分区格式、压缩格式通过Spark-SQL语句来进行指定。

Spark首先将上述临时表文件中的数据根据配置分为RDD数据块，每个RDD数据块分配给特定任务进行并行处理，通过Spark-SQL内部转化机制，将SQL语句中的分区转化为针对RDD数据块的特定操作方法，从而基于RDD数据块上对数据进行分区，将分区后的数据调用第三方库进行压缩，最终再次将分区和压缩后的数据写入HDFS文件系统。

对于Spark来说，一种分区就是一层目录，可以有一级或者多级。

以上面的呼叫记录来说，单以主叫前三位分区方式，目录结构如图3所示。

如果以主叫前三位和一小时间隔的起呼时间两个分区进行分区，目录结构如图4所示。

3、如图5所示，上述Spark-SQL语句转化为对RDD块的操作(包括所有分区、压缩操作)，都是由Scala语言实现，最终都转化为Java字节码，在JVM虚拟机内部执行，从编程语言角度来说，是一种解释型语言。

因此，Spark所有程序运行于JVM虚拟机内，受制于JVM虚拟机的性能、资源等因素。基于Spark-SQL的数据导入技术方案(外部数据为文本文件模式)如图5所示。

以基于Spark的大数据处理平台为例，官方发布的Spark平台版本对数据导入优化不够，对导入数据量、导入速度、和导入后的分区支持都不好，例如存在速度慢，不支持大数据量，分区数限制、程序内存溢出等等问题。

现有技术中的问题有：

1、现有技术基于hive或者spark-SQL的数据导入程序，采用Scala语言编写，运行在JVM(JavaVirtualMachine，Java虚拟机，下同)上，存在效率低、速度慢等问题。Scala是一种纯粹的面向对象编程语言，它用Scalac这个编译器把源文件编译成Java的class文件(即在JVM上运行的字节码)，所以是解释型语言。就执行同样操作的程序而言，用解释型语言编写的程序比用编译型语言编写的程序慢很多。

Spark是一种大数据框架，开发之初为了快速实现这种框架，采用了较为高级的scala语言，目的是加快程序开发进度，而对程序的执行效率并没有那么重视。这在通常的应用情况下不会有什么问题。

但是在生产环境中会有一些对程序的执行效率有特殊需求的地方，例如对入库速度有较高要求，在这种情形下，spark原生的入库程序不能满足要求，必须采用新的手段来实现更快的入库执行速度。

另外，采用C语言需要运用C和Java混合编程技术，例如JNI(JavaNativeInterface)的调用方式，相对单一编程语言来说，编码的复杂程度提高；而且C语言是一种比较低级的语言，在换取执行效率的同时，其开发效率大大降低，会导致开发周期加长。因此，对于本领域普通技术人员来说编程难度极大，必须付出创造性的劳动。

2、由于JVM虚拟机本身的机理，无法一次处理超过1GB的多分区(2个及以上spark数据分区)的数据。如果导入程序一次性设置2个以上分区并处理1GB以上的大文件，大数据处理平台的内部处理机制会很容易引起JVM虚拟机栈内存或者堆内存的耗尽，致使JVM虚拟机的崩溃，从而导致整个平台的不可用。

3、现有技术与大数据处理平台本身融合在一起，不可分割，占用了平台资源，在数据导入和数据查询并行处理的时候造成了两者性能上的相互制约；

如图6所示，现有技术中，Spark大数据处理平台一般部署为一个集群，集群由若干台机器组成。在集群运行过程中，通常外部数据的导入和对数据的实时查询同步进行，因此，集群中机器的资源将同时分配给数据导入程序和数据查询程序，在IO冲突、CPU时间争抢以及内存的申请方面，两者必将有或多或少的冲突，严重时两者性能将大打折扣。

从图6中可以看出，现有技术在执行入库和查询时，都是从集群申请资源，是一种争抢形式执行的，而集群整个资源有限，争抢必然一方面导致某些逻辑无法执行，而争抢行为本身也会消耗资源，造成资源浪费。

发明内容

本发明要解决的技术问题是提供一种基于spark-SQL大数据处理平台的数据导入方法，该数据导入方法可以提高Spark大数据处理平台的数据导入速度，无论采用外部记录条数或者外部文件大小来计算导入速度，都有极大提升。

为了解决上述技术问题，本发明提供一种基于spark-SQL大数据处理平台的数据导入方法，通过入库程序将数据导入spark-SQL大数据处理平台，所述入库程序包括分区部分、数据压缩部分、写入HDFS部分，所述分区部分、数据压缩部分、写入HDFS部分分别采用C语言编程并编译连接形成优化的目标代码入库程序。

采用C语言实现分区逻辑，支持多个分区，支持用户自定义分区格式。

所述入库程序采用主程序加动态库的方式，主程序负责整个入库流程的控制和实现，其中动态库主要实现用户定义分区格式，即用户自己编写针对数据的分区程序，将其通过动态库技术嵌入到主程序中，随主程序一起运行。

分离入库程序和大数据处理平台，将入库程序所需要的资源和其它资源分离。

入库程序独立出来后，脱离整个平台独立运行，或者，若干入库程序组成单独的入库服务器集群。

通过配置，指定和入库程序相配合运行的大数据处理平台。

本发明基于spark-SQL大数据处理平台的数据导入方法与现有技术相比具有以下有益效果。

1、入库速度有极大提升，通过对一般样本数据的实际测试，在普通服务器平台上做对比测试，原入库程序速度为2万条/秒，本发明所优化修改过的入库程序速度可以达到19万条/秒。这种入库速度的提高，主要原因是由于程序采用C语言改写，效率比JVM方式快很多。

2、支持多分区和压缩。原入库程序在2分区情况下运行极不稳定，出现内存溢出问题，也就是说原入库程序稳定支持最多1个分区。而本发明所优化修改后的入库程序，采用C语言动态库技术，让用户自由定义分区规则，可以支持10个以上的入库分区，并且由于C语言的语言特性，其内存占用量大大小于JVM方式，因此不会出现内存溢出等内存不够的情况，能够确保程序稳定运行。

3、重写后的入库模块，可以独立入库程序组成单独集群，提供更高的入库速度。因为独立后的入库模块，可以由单独的物理机器组成集群，不占用集群资源。以上面提到的数据样本为例，由本发明所修改后的6个节点所组成的入库集群速度可达100万条/秒。

4、采用动态库技术可以做到可以灵活、单独修改分区程序，而不影响其它流程。

5、平台导入数据的同时，可以支持多个Spark数据分区，可以灵活自定义分区规则，而不仅仅限于只能由Spark内置函数来实现分区规则；并且同时支持多种Spark数据压缩格式。现有技术，经过实际测试，实际运用环境中最多支持2个分区，多于2个分区的情况，极易导致内存不足，从而引起整个流程执行失败。其归根到底的原因在于Scala这种高级语言的面向对象特性和其实现原理，在进行分区的同时，会为每条数据记录生成若干对象结构体，需要占用一定的内存，分区越多，原数据越多，占用的内存也越多，而且这种占用随着分区数量增多几乎呈几何级数增长。因此多于2个的分区规则，不适合实际生产环境使用。另外，现有技术的分区基于内置函数实现，例如对日期格式的转换，对某字段进行截取等。如果要实现类似于“对某字段截取，并计算哈希值，由此作为分区依据”这种需求，就无法用内置函数来实现，而上述需求可以很容易通过C语言编程来实现。

6、分离大数据平台的数据导入和数据查询功能，两者相互独立，互不影响，形成各自的集群，并且数据导入速度能够随着增加数据导入节点而线性增加。现有技术无法实现导入和查询分离。现有技术的导入和查询功能都基于spark本身提供的接口，它们都属于集群内部，因此他们的运行都会占用和消耗集群资源，在总集群规模不变，集群总资源数一定的情况下，提高导入速度必然影响查询速度，所以他们是相互影响，相互制约的关系。而将入库模块独立出集群后，就不会出现上述问题。

附图说明

图1是现有技术中Spark大数据处理平台的总体框架图。

图2是现有技术中将外部数据导入临时表的流程图。

图3是现有技术中一层目录结构示意图。

图4是现有技术中两个分区目录结构示意图。

图5是现有技术中基于Spark-SQL的数据导入技术方案的原理图。

图6是现有技术中申请系统资源流程图。

图7是本发明的导入数据流程图。

图8是本发明动态库流程图。

具体实施方式

实施例一：

如图7和图8所示，本实施方式提供一种基于spark-SQL大数据处理平台的数据导入方法，通过入库程序将数据导入spark-SQL大数据处理平台，所述入库程序包括分区部分、数据压缩部分、写入HDFS部分，所述分区部分、数据压缩部分、写入HDFS部分分别采用C语言编程并编译连接形成优化的目标代码入库程序。

采用C语言实现分区逻辑，支持多个分区，支持用户自定义分区格式。

所述入库程序采用主程序加动态库的方式，主程序负责整个入库流程的控制和实现，其中动态库主要实现用户定义分区格式，即用户自己编写针对数据的分区程序，将其通过动态库技术嵌入到主程序中，随主程序一起运行。

分离入库程序和大数据处理平台，将入库程序所需要的资源和其它资源分离。

入库程序独立出来后，脱离整个平台独立运行，或者，若干入库程序组成单独的入库服务器集群。

通过配置，指定和入库程序相配合运行的大数据处理平台。

实施例二：

1、如图7所示，采用C语言编写入库程序，实现文件读取，文件处理(每条记录按照分区规则进行分区)，将分区后的文件进行压缩(包含多种压缩格式，例如gzip,orc,snappy,parquet等)，然后通过HDFS文件接口上传到HDFS文件系统。

这部分内容主要包括，文件的读取和解析。文件读取采用C标准文件接口，直接从本地文件系统读取文件内容，按照行解析，即读入文件的每一行。

读取完成后，对一行文件进行分区解析。即根据分区规则，对某字段解析和计算，计算结果即分区依据。然后将所有的行解析完后，按照分区将行分类，每一个分区的所有行分别存放在内存中不同区域，至此，分区步骤完成。这一步调用动态库接口，通过动态库内的函数实现。

然后对分区后的文件进行压缩，压缩过程调用对应压缩格式的API接口，例如zip文件调用zip文件lib库中的函数，snappy调用snappy官方提供的C语言标准接口即可，函数调用完成后，内存中的文件即已经是压缩过的格式。

压缩完成后，将压缩后的文件存放到HDFS上去。这里存放按照分区规则存放，也就是相应分区的文件写入相应HDFS的目录中，例如某文件按分区规则属于分区1和分区2，那么按照目录存放规则，则放入HDFS相应存储目录的子目录1下面的子目录2中即可。

2、如图8所示，动态库流程图。

动态库实现针对每条数据按自定义规则进行分区。动态库由用户自行编写，使用C语言开发，可以实现任意个数，任意规则的分区规则。

使用动态库的好处就是可以将其脱离主程序开发，动态库的更改不影响主程序，只需要保持调用接口一致即可。

动态库接口函数实例(C代码)：

GetDataPartInfo(void*data,stringpartinfo)；

data为输入数据，partinfo为输出分区信息。

例如，输入数据为：

11310000011350000018:00:018:00:57001

输出数据为：

第一分区：13；第二分区：8。

具体分区做法为：将号码段按第一，第二个字节截取，组成第一分区，这里为将131000001截取13，作为第一个分区；然后将8：00：01按时间段分为第二个分区，这里为8点，则第二分区为8。

动态库在收到上述数据时，就输出第一分区13和第二分区8。以此类推，读取下一条数据，不断循环。

动态库程序的编写与一般动态库相同，遵循Windows或者Linux系统下动态库编写规则。本例中主要就是入口函数功能的实现。即通过调用入口函数，同时以一行记录作为输入参数，即可返回该记录属于哪个分区，该函数内部对记录进行解析，解析过程由用户自定义，因此使用时仅需要调用此函数。

3、如图7所示，分离入库程序和大数据处理平台，组成单独集群并配置。

首先停用原入库程序，不再通过spark原接口进行数据入库(不包括建数据库表过程，数据库表的建立依然采用原流程)。

然后将本发明中的入库程序和编译后的代码放置到一台或者多台物理节点上，配置好相应的配置文件，启动入库程序。如果有多个节点，则在多个节点上启动本程序。

分离后的入库程序单独部署在一台物理节点上，也可以部署在多台物理节点上组成入库集群。

如果是组成入库集群，则需要在每个节点上配置HDFS所在节点信息即可。

例如现在有IP地址为192.168.0.1,192.168.0.2,192.168.0.3的三个入库节点，HDFS的namenode所在节点IP地址为192.168.10.1，则三个入库节点的配置文件存在下列配置项：

[HDFS接口IP]:192.168.10.1(指明入库节点将数据解析完毕后，发送到这个HDFS文件服务器上)。

[入库文件接收目录]:/home/Hadoop/(这个目录指明每个入库节点各自从何处取得需要处理的文件)。

采用C语言改写spark原来的入库程序，入库程序可以脱离JVM虚拟机独立存在。

详见流程图中C代码方框。

采用C语言改写spark入库程序的分区规则，更加灵活，可以支持任意分区规则，任意分区个数。

本发明采用动态库技术，提供统一调用接口，用户自定义程序实现动态库接口，即可实现灵活的分区规则和分区个数。

采用C语言动态库技术，支持用户自定义分区规则。

规则同上所述。

采用C语言改写spark入库程序，设置各种数据压缩格式，包括parquet，snappy，orc，gzip等等。

压缩格式的不同只需要调用不同的压缩接口即可，这在C编码中很容易实现，流程图中本发明中最后分区完成后即为压缩过程，这个过程可以调用各种压缩接口，不仅仅限于说明中的几种，只要相应压缩格式提供C接口，都可以实现。

4、如图7所示，分离入库程序和大数据处理平台，入库程序可以独立于大数据处理平台。

本发明中的入库程序可以单独部署或者部署在多台机器上，于spark平台没有相关性，它仅仅对平台提供分区并压缩好的文件，通过HDFS文件接口上传到平台上，所以除了HDFS文件接口，入库程序与大数据平台没有其它相关连的地方，所以本入库程序可以独立于大数据平台存在，互不影响互不干扰。

本实施方式的优点如下。

1、系统的入库处理能力更高，比原生spark入库程序速度快10倍。采用C语言编码后，代码执行效率要高于JVM方式，因此入库速度有很大提高。

2、采用C动态库技术，支持用户自己编写分区规则，所以能够支持更多的分区格式，采用C语言编码，占用内存小，能够支持更多的分区数，程序更稳定，更灵活。

3、用户可以用C语言调用各种压缩接口，对分区后的数据进行压缩，因此支持各种数据压缩格式。

4、采用C语言改写后，原入库程序可以不依赖于原spark平台存在，分离入库程序和大数据处理平台，使两者互不影响，提高各自处理能力，

需要说明的是，以上参照附图所描述的各个实施例仅用以说明本发明而非限制本发明的范围，本领域的普通技术人员应当理解，在不脱离本发明的精神和范围的前提下对本发明进行的修改或者等同替换，均应涵盖在本发明的范围之内。此外，除上下文另有所指外，以单数形式出现的词包括复数形式，反之亦然。另外，除非特别说明，那么任何实施例的全部或一部分可结合任何其它实施例的全部或一部分来使用。

Claims (6)

1.一种基于spark-SQL大数据处理平台的数据导入方法，通过入库程序将数据导入spark-SQL大数据处理平台，所述入库程序包括分区部分、数据压缩部分、写入HDFS部分，其特征在于：所述分区部分、数据压缩部分、写入HDFS部分分别采用C语言编程并编译连接形成优化的目标代码入库程序。

2.根据权利要求1所述基于spark-SQL大数据处理平台的数据导入方法，其特征在于：采用C语言实现分区逻辑，支持多个分区，支持用户自定义分区格式。

3.根据权利要求1所述基于spark-SQL大数据处理平台的数据导入方法，其特征在于：所述入库程序采用主程序加动态库的方式，主程序负责整个入库流程的控制和实现，其中动态库主要实现用户定义分区格式，即用户自己编写针对数据的分区程序，将其通过动态库技术嵌入到主程序中，随主程序一起运行。

4.根据权利要求1所述基于spark-SQL大数据处理平台的数据导入方法，其特征在于：分离入库程序和大数据处理平台，将入库程序所需要的资源和其它资源分离。

5.根据权利要求4所述基于spark-SQL大数据处理平台的数据导入方法，其特征在于：入库程序独立出来后，脱离整个平台独立运行，或者，若干入库程序组成单独的入库服务器集群。

6.根据权利要求5所述基于spark-SQL大数据处理平台的数据导入方法，其特征在于：通过配置，指定和入库程序相配合运行的大数据处理平台。