一种紧耦合可扩展的大数据交互方法
【专利摘要】本发明提供一种紧耦合可扩展的大数据交互方法，通过构建分布式紧耦合的客户端驱动层，在保证一致性的基础上，能够避免客户端或服务端的单点失效，并减少了客户端之间的通信开销，使系统在以元数据查询类为主的场景下具有接近线性的可扩展性，满足大数据的在线高并发交互分析需求。上述方法可以保证数据的读写一致性，虽然单纯读操作会出现延迟现象，但可以保证读取版本的顺序一致。在需要读取最新版本情况下，可以主动执行一次数据同步过程。此外，该方法具备很好的容错性，只要失效节点数小于半数，其他节点读写数据不受影响，当节点回复后，只需一次读写操作通过步骤即可同步。
【专利说明】一种紧耦合可扩展的大数据交互方法
【技术领域】
[0001]本发明涉及大数据【技术领域】，具体地说是一种紧耦合可扩展的大数据交互方法。
【背景技术】
[0002]随着大数据时代的到来，针对行业大数据业务应用需求，面向数据密集型应用的计算模型和系统不断出现，如离线批处理系统MapReduce，海量数据高并发处理系统HBase,内存计算框架Spark和流式处理框架Storm,以及传统的高性能计算框架MPI等。在这些大数据处理模式中，由于都引入了新的编程模型，学习成本较大，因此，基于各类大数据处理系统构建与传统数据库应用为相似的交互分析模式和效果需求最为广泛。在交互分析中，数据以表的形式存储，以SQL语句作为编程接口，支持检索、统计、关联、排序等操作，达到高并发、低延迟的处理效果。当前出现的基于MapReduce的Hive,基于Spark的Shark都属于这一类交互分析引擎。
[0003]然而，现有的交互分析引擎，虽然支持表结构和SQL语句的模式，并且底层的数据系统采用分布式架构，但在实际应用中的交互分析效果依然很差。如Hive采用MapReduce引擎采用在各个处理阶段严格同步、步步物化的模式，处理延迟较大，Shark虽然基于内存计算引擎，通过流水化和中间结果缓存优化了处理性能，但由于其采用传统的Clinet/Sever模式，并且进行SQL解析、路径规划和元数据处理Server端仅支持单点部署，但制约了高并发的交互处理效果。因此，需要一种新型驱动架构，满足大数据的在线高并发交互分析需求。
【发明内容】
[0004]本发明的目的是提供一种紧耦合可扩展的大数据交互方法。
[0005]本发明的目的是按以下方式实现的，通过构建分布式紧耦合的客户端驱动层，在保证一致性的基础上，能够避免客户端或服务端的单点失效，并减少了客户端之间的通信开销，使系统在以元数据查询类为主的场景下具有接近线性的可扩展性，满足大数据的在线高并发交互分析需求，具体步骤如下:
1)在应用服务器中部署多个应用实例，各应用实例间进行负载均衡；
2)在每个实例的进程空间中动态链接客户端驱动，客户端接受应用发送的交互请求，完成Sql解析、执行路径优化、任务调度、发送操作请求和结果汇聚；
3)应用实例得到返回结果并在业务逻辑层处理，避免客户端或服务端的单点失效，并减少了客户端之间的通信开销，由于上述架构的客户端驱动只需要保存少量系统的元数据状态，并且元数据是以读取和查询类操作为主，因此能够有效扩展、支持高并发，当发生元数据写操作时，存在着元数据同步问题，因此需要通过节点间交互保障读写一致性；
4)读写同步过程为每次读写时，先从本节点读到当前版本；进行数据更新后，版本号加1，向所有个节点发送写数据更新请求；节点收到新版本更新后，若之前没有同意更高的版本，则赞成返回，否则通知发送方最新的版本号； 5)当未收到半数以上同意票后，取各节点返回的最大的版本号，若最大版本号与自己发出的相同，表明更新冲突，等待最新版本数据同步，否则从半数以上个节点读取最新版本数据，当收到最新版本数据后，重新设置当前版本继续进行更新；
6)当收到半数个节点以上个同意票后，向所有节点提交结果；收到半数个节点的确认后，读与操作完成；
在以元数据读操作为主的类场景下具有很好的可扩展性，但发生元数据写操作时，存在着元数据同步问题，因此需要通过节点间交互保障读写一致性，多节点紧耦合系统的读写同步过程如下:
(1)每次读写时，先从本节点读到当前版本4；
(2)进行数据更新后，版本号#1，向所有/7个节点发送写请求?/ν+1；
(3)节点Z7i收到dv+1后，若之前没有同意更高的版本，即^〈r+1则赞成返回，否则通知发送方最新的版本号K ；
(4)当未收到半数以上同意票后，取各节点返回的最大的版本号匕；
4.1)当Km= v+l,表明更新冲突，等待最新版本Km同步；
4.2)否则，向/?/2+1个节点读取最新版本Km ；
4.3)当收到最大版本号后，设置当前版本^ Kffl继续执行步骤(2)；
(5)否则，当收到半数/7/2+1个节点以上个同意票后，向所有节点提交结果；
(6)收到/7/2+1个节点的确认后，读写操作完成；
(7)单纯读操作受步骤(6)影响，会出现延迟现象，但能保证读取版本的顺序一致，在需要读取最新版本情况下，主动执行一次步骤4.1)以同步数据；
(8)只要失效节点数小于n/2+l，其他节点读写数据不受影响，当节点回复后，只需一次读写操作，通过步骤4.2)、4.3)即可同步。
[0006]本发明的目的有益效果是:上述方法可以保证数据的读写一致性，虽然单纯读操作会出现延迟现象，但可以保证读取版本的顺序一致。在需要读取最新版本情况下，可以主动执行一次数据同步过程。此外，该方法具备很好的容错性，只要失效节点数小于半数，其他节点读写数据不受影响，当节点回复后，只需一次读写操作通过步骤即可同步。
【专利附图】
【附图说明】
[0007]图1是单客户端、单服务器系统架构图；
图2是单客户端、多服务端系统架构图；
图3是多客户端、多服务端分离系统架构图；
图4是多节点紧耦合系统架构图；
图5是多节点驱动架构的读写同步过程图。
【具体实施方式】
[0008]以下将结合附图及实施例来详细说明本发明的实施方式，借此对本发明如何应用技术手段来解决技术问题，并达成技术效果的实现过程能充分理解并据以实施。需要说明的是，如果不冲突，本发明实施例以及实施例中的各个特征的相互均在本发明的保护范围之内。
[0009]在传统的客户机服务器模式中，图1所示的单客户端、单服务器系统在服务端存在单点失效和性能瓶颈，图2所示单客户端、多服务端系统在服务端建立了集群，但在客户端存在单点失效和性能瓶颈，图3所示多客户端、多服务端分离系统在客户端和服务端分别建立集群，能够在两端分别进行负载均衡，虽然能够避免单点失效，提高并发性能，但若客户端和服务端采用物理隔离的部署方式则节点资源需求量太大，即便是采用物理集中的部署模式相互之间仍是多对多的复杂拓扑结构，各种路由消息、收发数据所产占用的系统和通信开销随着节点数目增加呈幂指数增长，在网络带宽受限的环境下严重影响了大数据系统的性能。
[0010]多节点紧耦合系统如图4所示:
(1)在应用服务器中部署个应用实例，各应用实例间进行负载均衡；
(2)在每个实例的进程空间中动态链接客户端驱动；
(3)客户端驱动接受应用发送的交互请求，完成Sql解析、执行操作编译和路径优化、向分布式大数据处理系统发送操作请求；
(4)大数据处理系统在各处理节点上进行处理，并将结果返回给客户端驱动汇总处理；
(5)应用实例得到返回结果并在业务逻辑层处理；
上述架构能够避免客户端或服务端的单点失效，并减少了客户端之间的通信开销，由于上述架构的客户端驱动只需要保存少量系统的元数据状态，并且元数据是以读取和查询类操作为主，因此能够有效扩展、支持高并发。
[0011]多节点紧耦合系统读写同步方法
上述在以元数据读操作为主的类场景下具有很好的可扩展性，但发生元数据写操作时，存在着元数据同步问题，因此需要通过节点间交互保障读写一致性。多节点紧耦合系统的读写同步过程如图5所示:
(1)每次读写时，先从本节点读到当前版本;
(2)进行数据更新后，版本号#1，向所有/7个节点发送写请求?/ν+1；
(3)节点Z7i收到dv+1后，若之前没有同意更高的版本，即^〈r+1则赞成返回，否则通知发送方最新的版本号^
(4)当未收到半数以上同意票后，取各节点返回的最大的版本号匕，
4.1)当Km= v+l,表明更新冲突，等待最新版本Km同步；
4.2)否则，向/?/2+1个节点读取最新版本tv
4.3)当收到最大版本号后，设置当前版本^匕继续进行(2)
(5)否则，当收到半数/7/2+1个节点以上个同意票后，向所有节点提交结果；
(6)收到/7/2+1个节点的确认后，读写操作完成。
[0012]上述方法可以保证数据的读写一致性，虽然单纯读操作受步骤(6)影响，会出现延迟现象，但可以保证读取版本的顺序一致。在需要读取最新版本情况下，可以主动执行一次步骤4.1)同步数据。此外，该方法具备很好的容错性，只要失效节点数小于n/2+l，其他节点读写数据不受影响，当节点回复后，只需一次读写操作，通过步骤4.2)、4.3)即可同步。
[0013]本发明提出的面向大数据交互处理的驱动架构及同步方法，可以应用到MapReduce>Spark>HBase等大数据处理系统上,通过在构建客户端驱动层，能够在保证一致性的基础上，使客户驱动层在在以元数据查询类为主的场景下具有接近线性的可扩展性，满足大数据的在线高并发交互分析需求。以构建于MapReduce的驱动架构为例，在原先Hive的单点方式仅支持100个并发的情况下，使用5节点紧耦合驱动架构能使并发量达到500 个。
[0014]除说明书所述的技术特征外，均为本专业技术人员的已知技术。
【权利要求】
1.一种紧耦合可扩展的大数据交互方法，其特征在于通过构建分布式紧耦合的客户端驱动层，在保证一致性的基础上，能够避免客户端或服务端的单点失效，并减少了客户端之间的通信开销，使系统在以元数据查询类为主的场景下具有接近线性的可扩展性，满足大数据的在线高并发交互分析需求，具体步骤如下: .1)在应用服务器中部署多个应用实例，各应用实例间进行负载均衡； .2)在每个实例的进程空间中动态链接客户端驱动，客户端接受应用发送的交互请求，完成Sql解析、执行路径优化、任务调度、发送操作请求和结果汇聚； .3)应用实例得到返回结果并在业务逻辑层处理，避免客户端或服务端的单点失效，并减少了客户端之间的通信开销，由于上述架构的客户端驱动只需要保存少量系统的元数据状态，并且元数据是以读取和查询类操作为主，因此能够有效扩展、支持高并发，当发生元数据写操作时，存在着元数据同步问题，因此需要通过节点间交互保障读写一致性； .4)读写同步过程为每次读写时，先从本节点读到当前版本；进行数据更新后，版本号加1，向所有个节点发送写数据更新请求；节点收到新版本更新后，若之前没有同意更高的版本，则赞成返回，否则通知发送方最新的版本号； .5)当未收到半数以上同意票后，取各节点返回的最大的版本号，若最大版本号与自己发出的相同，表明更新冲突，等待最新版本数据同步，否则从半数以上个节点读取最新版本数据，当收到最新版本数据后，重新设置当前版本继续进行更新； .6)当收到半数个节点以上个同意票后，向所有节点提交结果；收到半数个节点的确认后，读与操作完成； 根据权利要求1所述的一种分布式多节点紧耦合大数据交互方法，其特征在于，在以元数据读操作为主的类场景下具有很好的可扩展性，但发生元数据写操作时，存在着元数据同步问题，因此需要通过节点间交互保障读写一致性，多节点紧耦合系统的读写同步过程如下: (1)每次读写时，先从本节点读到当前版本4； (2)进行数据更新后，版本号#1，向所有/7个节点发送写请求?/ν+1； (3)节点Z7i收到dv+1后，若之前没有同意更高的版本，即^〈r+1则赞成返回，否则通知发送方最新的版本号K ； (4)当未收到半数以上同意票后，取各节点返回的最大的版本号匕； .4.1)当Km= v+l,表明更新冲突，等待最新版本Km同步； .4.2)否则，向/?/2+1个节点读取最新版本Km ； .4.3)当收到最大版本号后，设置当前版本^ Kffl继续执行步骤(2)； (5)否则，当收到半数/7/2+1个节点以上个同意票后，向所有节点提交结果； (6)收到/7/2+1个节点的确认后，读写操作完成； (7)单纯读操作受步骤(6)影响，会出现延迟现象，但能保证读取版本的顺序一致，在需要读取最新版本情况下，主动执行一次步骤4.1)以同步数据； (8)只要失效节点数小于n/2+l，其他节点读写数据不受影响，当节点回复后，只需一次读写操作，通过步骤4.2)、4.3)即可同步。
【文档编号】H04L29/08GK104348913SQ201410585403
【公开日】2015年2月11日 申请日期:2014年10月28日 优先权日:2014年10月28日
【发明者】王恩东, 张东, 亓开元, 刘成平, 辛国茂, 杨勇, 卢俊佐 申请人:浪潮电子信息产业股份有限公司