CN108614820A - 实现流式源数据解析的方法和装置 - Google Patents

Abstract

本公开揭示了一种实现流式源数据解析的方法和装置。所述方法包括：拉取流式源数据并缓存；调用与缓存的流式源数据相匹配的数据解析插件；通过调用的所述数据解析插件处理缓存的流式源数据得到目标数据；向指定目的地分发目标数据，目标数据通过所述分发进行数据落地。在此实现过程中，将流式源数据处理插件化，只要按照拉取的流式源数据调用数据解析插件即可支持此流式源数据的数据格式，完成其所对应的实时解析和落地存储过程，而并不需要重新进行相应的业务开发，也将使得所实现的数据汇集能够支持各种数据格式，甚至于新的数据格式，所需的工作量也只是编码对应的数据解析插件，全面支持各种数据源的流式源数据解析。

Description

实现流式源数据解析的方法和装置

技术领域

本公开涉及数据处理技术领域，特别涉及一种实现流式源数据解析的方法和装置。

背景技术

随着互联网应用的迅猛发展，为用户提供服务的多种业务，在其运营中会源源不断的产生大量数据，例如，用户在实现此业务的服务中不断上报的数据等。因此，可使得各业务方都作为一数据源，进行一个或者多个数据源中数据的汇集。

在所进行的数据汇集中，数据被流式地上报至数据源，由此，将涉及到流式源数据的实时解析和落地存储过程。

在此过程中，首先需要按照落地存储的需求，而进行流式源数据的解析。然而，现有数据解析的实现仅能够支持较少的数据源格式，可扩展性较为欠缺，对于与其所支持的数据源格式不相符的业务而言，则不得不重新进行业务开发。

发明内容

为了解决相关技术中流式源数据的实时解析和落地存储可扩展性欠缺的技术问题，本公开提供了一种实现流式源数据解析的方法和装置。

一种实现流式源数据解析的方法，所述方法包括：

拉取流式源数据，并缓存，所述流式源数据是流式地上报至数据源的数据；

调用与缓存的所述流式源数据相匹配的数据解析插件，所述数据解析插件是预先配置的；

通过调用的所述数据解析插件处理所述缓存的流式源数据得到目标数据；

向指定目的地分发所述目标数据，所述目标数据通过所述分发进行数据落地。

一种实现流式源数据解析的装置，所述装置包括：

数据拉取模块，用于拉取流式源数据，并缓存，所述流式源数据是流式地上报至数据源的数据；

插件调用模块，用于调用与缓存的所述流式源数据相匹配的数据解析插件，所述数据解析插件是预先配置的；

数据处理模块，用于通过调用的所述数据解析插件处理所述缓存的流式源数据得到目标数据；

分发模块，用于向指定目的地分发所述目标数据，所述目标数据通过所述分发进行数据落地。

本公开的实施例提供的技术方案可以包括以下有益效果：

进行数据源中流式源数据的拉取和缓存，流式源数据即为流式地上报至数据源的数据，调用与缓存的流式源数据相匹配的数据解析插件，数据解析插件是预先配置的，通过调用的数据解析插件处理缓存的流式源数据得到目标数据，并最终向指定目的地分发目标数据，目标数据通过分发进行数据落地，在此实现过程中，将流式源数据处理插件化，只要按照拉取的流式源数据调用数据解析插件即可支持此流式源数据的数据格式，完成其所对应的实时解析和落地存储过程，而并不需要重新进行相应的业务开发，也将使得所实现的数据汇集能够支持各种数据格式，甚至于新的数据格式，所需的工作量也只是编码对应的数据解析插件，全面支持各种数据源的流式源数据解析。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并于说明书一起用于解释本发明的原理。

图1是根据本公开所涉及的实施环境的示意图；

图2是根据一示例性实施例示出的一种装置的框图；

图3是根据一示例性实施例示出的一种实现流式源数据解析的方法的流程图；

图4是根据另一示例性实施例示出的一种实现流式源数据解析的方法的流程图；

图5是根据图3对应实施例示出的对向指定的目的地分发目标数据步骤的细节进行描述的流程图；

图6是根据图5对应实施例示出的对向指定目的地分发消息文件，通过消息文件的分发使消息文件中组装置的目标数据被分发至指定目的地步骤的细节进行描述的流程图；

图7是根据一示例性实施例示出的一种实现流式源数据解析的方法的流程图；

图8是根据一示例性实施例示出的Spout结构的示意图；

图9是根据一示例性实施例示出的Bolt结构的示意图；

图10是根据一示例性实施例示出的一种实现流式源数据解析的装置的框图；

图11是根据另一示例性实施例示出的一种实现流式源数据解析的装置的框图；

图12是根据图10对应实施例示出的对分发模块的细节进行描述的框图；

图13是根据另一示例性实施例示出的一种实现流式源数据解析的装置的框图；

图14是根据另一示例性实施例示出的一种实现流式源数据解析的装置的框图。

具体实施方式

这里将详细地对示例性实施例执行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

图1是根据本公开的实施环境的示意图。该实施环境包括数据解析***110和存储***130。

其中，数据解析***110用于实现一个或者多个业务平台的流式源数据拉取，并处理，以得到目标数据；相对应的，存储***130对此目标数据进行存储。通过数据解析***110和存储***130的配合，能够实现一个或者多个业务平台的大数据拉取和导入。

图2是根据一示例性实施例示出的一种装置的框图。例如，装置200可以是图1所示实施环境中，数据解析***110的任意一台机器，和/或，存储***130中的任意一台机器。

参照图2，根据一示例性实施例示出的一种装置的框图。例如，装置200可以是图1所示实施环境中数据解析***110和存储***130包含的机器，比如服务器。

参照图2，该装置200可因配置或性能不同而产生比较大的差异，可以包括一个或一个以***处理器(central processing units，CPU)222(例如，一个或一个以上处理器)和存储器232，一个或一个以上存储应用程序242或数据244的存储介质230(例如一个或一个以上海量存储设备)。其中，存储器232和存储介质230可以是短暂存储或持久存储。存储在存储介质230的程序可以包括一个或一个以上模块(图示未示出)，每个模块可以包括对服务器中的一系列指令操作。更进一步地，中央处理器222可以设置为与存储介质230通信，在装置200上执行存储介质230中的一系列指令操作。装置200还可以包括一个或一个以上电源226，一个或一个以上有线或无线网络接口250，一个或一个以上输入输出接口258，和/或，一个或一个以上操作***241，例如Windows ServerTM，Mac OS XTM，UnixTM，LinuxTM，FreeBSDTM等等。下述图3、图4、图5、图6和图7所示实施例中所述的由服务器所执行的步骤可以基于该图2所示的装置结构。

图3是根据一示例性实施例示出的一种实现流式源数据解析的方法的流程图。该实现流式源数据解析的方法适用于图1所示实施环境。如图3所示，该实现流式源数据解析的方法，可以包括以下步骤。

在步骤310中，拉取流式源数据，并缓存，流式源数据是流式地上报至数据源的数据。

其中，各种业务的实现中，源数据在产生之后，都会上报到业务平台，以通过业务平台对源数据的处理而实现业务所设定的功能和服务。因此，业务平台中存在着源源不断上报的源数据，数据量巨大，且数据重要不可丢失。

此业务平台内的源数据，由于是流式地上报至业务平台内，因此，可将数据平台作为数据源，从此数据源拉取得到流式源数据。

在所实现的数据汇集中，从一业务方或者多个业务方所提供的数据源拉取流式源数据，并缓存。在一个示例性实施例的具体实现中，流式源数据的拉取和缓存，是通过配置的Receiver线程实现的，以主动从业务方拉取数据。

通过专门配置的线程，如Receiver线程，来进行流式源数据的拉取和缓存，然后再往后端发送，以此即可保证最大的效率，不会让前端的数据拉取速度成为整个***的瓶颈。

在步骤330中，调用与缓存的流式源数据相匹配的数据解析插件，数据解析插件是预先配置的。

其中，预先根据数据处理的需求编写插件，以便于在此过程中直接调用。缓存的流式源数据中，使用了一定的标识来进行标记，因此，可以根据流式源数据中的标识来调用与之相匹配的数据解析插件。

进一步的，对于步骤330，在一个示例性实施例的具体实现中，具体过程包括：从缓存的流式源数据中提取插件标识，按照所述插件标识从预先配置的数据解析插件中调用与缓存的流式源数据相匹配的数据解析插件。

在步骤350中，通过调用的数据解析插件处理缓存的流式源数据得到目标数据。

其中，通过调用的与流式源数据相匹配的数据解析插件，来实现缓存的流式源数据的处理，以此来实现流式源数据的处理，并且能够使得流式源数据的处理适配于其所在的业务和后续所需要进行的存储，进而在数据解析插件的作用下能够支持各种数据格式的流式源数据，例如，不再仅限于文本格式、二进制格式等少数的数据格式，还可以支持诸如文本文件、Mysql Binlog、DB全量读取和TCP/UDP消息等数据格式。

数据处理的插件化实现，能够按照前后端预定的数据格式进行数据解析和分拣，并且随时可以根据需要构建新的数据格式，所需的工作量也仅仅是编码对应插件的工作量，在减少开发者工作量的同时增加了扩展性能。

在步骤370中，向指定的目的地分发目标数据，目标数据通过分发进行数据落地。

其中，在通过数据解析插件得到目标数据之后，即可进行数据分发，以便于使得目标数据能够落地到对应的存储***，进行而完成整个流式源数据的解析和分拣过程。

通过对流式源数据解析而得到的目标数据，均有为其所指定的目的地，此目的地指示了目标数据写入的存储***，进而在此存储***中实现目标数据的存储。

可以理解的，可以根据目标数据所对应的流式源数据来确定指定的目的地，按照指定的目的地来分发目标数据。

在一个示例性实施例的具体实现中，目标数据的分发，可以通过Sender线程实现。通过Sender线程往后端数据源发送目标数据，在此过程中，将有多重情况。一方面，可将目标数据发送给下一个处理环节，如进行数据汇聚，以减少小文件对存储***，例如，HDFS文件***(Hadoop Distributed File System，分布式文件***)的冲击；另一方面，也可直接发送至目的地所对应的存储***，进而最终实现数据在存储***中的落地存储。

通过如上所述的过程，可配置多种数据解析插件，在多种数据解析插件的作用下使得流式源数据解析的实现能够适配多种数据格式，进而能够根据运营需要随意实现多种业务的流式源数据汇集，在提高可扩展性能的同时，也将使得后端存储***的实现具备多样性。

图4是根据另一示例性实施例示出的一种实现流式源数据解析的方法的流程图。该实现流式源数据解析的方法，如图4所示，在步骤350之后，还可以包括以下步骤。

在步骤410中，根据目标数据对应的流式源数据，得到目标数据所属数据单元的标识信息。

其中，通过图3对应实施例中调用的数据解析插件获得流式源数据所对应的目标数据，此目标数据是唯一对应于流式源数据的，因此，将使用流式源数据的目标信息实现目标数据的标识。

对应于相同标识信息的目标数据，将形成一数据单元。也就是说，在通过数据解析插件获得流式源数据对应的目标数据之后，便按照对应的标识信息写入目标数据，随着目标数据的不断写入而形成承载了一定数据量的目标数据的数据单元。

此数据单元，由于承载了相同标识信息的目标数据，因此，其标识信息即为目标数据对应于流式源数据的标识信息。

由此可知，在通过调用的数据解析插件得到流式源数据对应的目标数据之后，需要首先根据对应的流式源数据而获得目标数据所属数据单元的标识信息，以便于执行后续目标数据向数据单元的写入过程。

在一个示例性实施例中，目标信息可以包括业务标识、接口标识和数据时间三个维度，通过此目标数据来为目标数据确定其所属的数据单元。

具体的，业务标识和接口标识对应于存储数据中的一个数据表，而数据时间则指示了此数据表中的数据分区，因此，在后续所进行的数据分发中，也将根据标识信息确定目标数据落地的存储***，并以此来控制目标数据在存储***中的存储。

数据时间，是对数据生成时间归一化所得到的。通过数据时间来标记在一时间段所生成的流式源数据，以及此流式源数据对应的目标数据。

通过数据时间，可以获知在一时间段内前端所生成的目标数据条数，以及后端所接收目标数据条数，进而是比对查错。

因此，数据时间将作为检查校验的粒度，如果数据出错，对只需要在相应时间段内进行目标数据的补录或者其它方式的处理即可，简便快捷。

在步骤430中，按照标识信息将目标数据写入数据单元。

其中，根据标识信息定位数据单元，进而将目标数据写入此数据单元，在此数据单元中，包含了相同标识信息对应的多条目标数据。

在步骤450中，将数据单元中的目标数据组装成消息文件，并建立消息文件与标识信息之间的映射关系，消息文件用于进行目标数据的发送。

其中，随着数据单元中不断进行的目标数据写入，将进行数据单元中目标数据的组装，得到相对应的消息文件。由于数据单元是对应于一标识信息的，将得到的消息文件映射于此标识信息，构建消息文件与此标识信息之间的映射关系。

由此可知，消息文件将使为对应于一标识信息的多条目标数据的载体，通过此消息文件实现多条目标数据的有序封装，有利于实现目标数据的分发。

所组装形成的消息文件，与标识信息形成映射关系的数据，以等待分发至相应的目的地。

由上可知，进程与线程之间的通信将是通过消息队列实现的，例如，消息文件与标识信息形成映射关系的数据的存在，实现简单，却减少了一些锁的开销，充分平衡了网络等各种资源，并且***性能能够随着机器数目的增加，性能线性增加。

在一个示例性实施例中，将数据单元中的目标数据组装成消息文件，包括以下步骤。

通过配置的数据大小和超时时间控制数据单元中目标数据的组装置，如果数据单元中目标数据达到配置的数据大小或超时，则将数据单元中的目标数据组装成消息文件。

其中，数据单元中，配置了数据大小和超时时间。数据大小，用于指示控制数据单元中执行目标数据组装时目标数据的数据量。超时时间，用于指示控制数据单元中最终执行目标数据组装置的时间限值。在一个示例性实施例的具体实现中，可在数据单元中配置计时器，以通过计时器确认数据单元中进行的目标数据写入是否超时。

数据单元进行着目标数据的写入，在写入的目标数据达到配置的数据大小时，即可对数据单元中的目标数据打包，以组装在一起形成一消息。

但是，随着时间的推移，如果数据单元中写入的目标数据仍未达到配置的数据大小，则在时间上达到配置的超时时间时，即便数据单元中目标数据的数据量很小，仍然执行数据单元中的目标数据打包，以继续向后端发送目标数据，提高效率。

通过所进行的目标数据组装置，将使得拉取的多条目标数据组装置成一个个消息文件进发送，以此来提高网络发送的效率。

图5是根据图3对应实施例示出的对步骤370的细节进行描述的流程图。该步骤370，如图5所示，可以包括以下步骤。

在步骤371中，根据消息文件映射的标识信息得到指定目的地。

其中，如前所述的，由标识信息可以确定消息文件所落地的存储***，此存储***即为消息文件进行落地存储的目的地。因此，通过消息文件映射的标识信息即可得到指定目的地。

在步骤373中，向指定目的地分发消息文件，通过消息文件的分发使消息文件中组装的目标数据被分发至指定目的地。

通过此过程，为目标数据的分发提供了具体实现，即以消息文件为载体实现目标数据的分发，由此，将提高提升了数据传输的吞吐能力。

图6是根据图5对应实施例示出的对步骤373的细节进行描述的流程图。该步骤373，如图6所示，可以包括以下步骤。

在步骤3731中，在消息文件被确认分发至目的地之后剔除消息文件，未被确认的消息文件则被积压等待重传。

其中，与标识信息形成映射关系而存在的消息文件，其所进行的消息文件分发是一个数据的可靠性传输过程，因此，在消息文件被确认分发至目的地之后便剔除消息文件，而未获得确认的消息文件，则积压等待重传。

具体而言，后端将为其所进行的每一消息文件接收回传确认消息，以告之消息文件被成功分发。在接收到后端为此消息文件回传的确认消息之后，即可剔除此消息文件。

如果消息文件被分发后一直未接收到此消息文件的确认消息，则此消息文件将被积压，以等待重传，进而是通过此可靠性传输过程，避免出现目标数据丢失和重复传输的情况。

在步骤3733中，根据积压的消息文件限制流式源数据的拉取，直至被积压的消息文件在数量上低于阈值之后消除限制。

其中，在积压的消息文件数量过多时，例如，在数量上超出给定的阈值，则会通过实现流式源数据拉取的线程，例如，前述Receiver线程暂停工作，进入休眠状态。

另一方面，后端在感知自身处于繁忙状态时，可以主动通知前端，以降低Receiver线程中拉取流式源数据的速度，并且如果频繁接收到后端的反馈，则直接暂停Receiver线程。

也就是说，在后端的配合下，实现过载保护的负反馈机制。在后端的处理出现高负载情况或者接近过载的临界值时，给前端一个反馈，使得前端减少或者停止对后端所进行的数据分发，当后端出现空载的时候，前端应当取消对后端的限制，由此，便实现了背压机制，进而通过背压机制精准实现流量控制。

此流量控制，将是通过给定的阈值实现的，如前所述的，积压的消息文件数量，超出给定的阈值，则限制其拉取。反之，如果积压的消息文件在数量上低于阈值，则消除此限制，正常进行消息文件的拉取。

在一个示例性实施例中，对于后端对数据的处理失败，也将主动地向前端快速发送失败确认消息，以通知前端重新发送目标数据。

在此基础上，前端即可准确知道哪些承载了目标数据的消息文件被确认成功传输，哪些消息文件被确认在后端的处理失败需要重新传输，根据此即可判断后端的处理速度。

如果在一定时间内出现大量的失败确认消息，则可判断后端处理速度比较慢，在一设定时间内降低流式源数据的拉取速度，以此实现背压机制。

在一个示例性实施例的具体实现中，可以通过运行的Actor线程来实现如上所述的过程，以获知后端对于消息文件处理的情况。

通过如上所述的过程，便实现了良好的流控制机制，进而能够稳定的承载海量的数据处理业务，极大的提高了可靠性和稳定性。

图7是根据一示例性实施例示出的一种实现流式源数据解析的方法的流程图。该实现流式源数据解析的方法，如图7所示，在步骤370之后，还可以包括以下步骤。

在步骤510中，目标数据的后端处理中，接收通过消息文件分发的目标数据。

其中，首先需要说明的是，图3至图6对应实施例实现了流式源数据解析的前端，即运行在实时计算拓扑中流式源数据解析应用的Spout结构，而图7对应实现实施例则用于实现与此前端相对应的后端，即实现流式源数据解析应用的Bolt结构。

前端将通过消息文件的形式，将承载的目标数据分发至后端进行处理直到落地至相应的存储***。

在一个示例性实施例中，接收前端分发的消息文件，从消息文件中解析出目标数据。例如，此过程，可以通过运行的Processor线程实现。

在步骤530中，根据目标数据所属数据单元的标识信息，将目标数据写入数据单元进行缓存。

其中，在通过前述步骤接收到通过消息文件传输的目标数据，如前所述的，目标数据对应于一标识信息，此标识信息也将是目标数据所属数据单元的标识信息。

根据目标数据对应的标识信息，定位所属的数据单元，并将目标数据写入数据单元进缓存。

在步骤550中，打包数据单元中的目标数据得到承载目标数据的本地文件。

其中，随着数据单元中，对应于相同标识信息的目标数据的不断写入，将由打包数据单元中的目标数据，以便于实现目标数据的上传入库。

与前端实现相类似的，数据单元中，配置了数据大小限值和超时时间限值，如果数据单元中目标数据的数据量达到数据大小限值，或者在时间上达到超时时间限值，则执行数据单元中目标数据的打包。

由此，即可避免数据量小时，存储***长期接收不到数据，以为前端没有数据生成，但是前端确实发送了部分数据的情况。

在步骤570中，将本地文件加入上传队列，将本地文件上传至所属数据单元对应的存储***。

其中，通过上传队列控制本地文件的上传过程，以便于使得承载的目标数据最终被存储到对应的存储***。

在一个示例性实施例中，进行数据单元中目标数据打包所得到的本地文件，将构成本地文件队列，并压缩加入上传队列，以等待上传。

对于此过程所进行的本地文件上传，其所上传至的存储***是HDFS文件***，进而在HDFS文件***的作用下将本地文件存入最终落地的其它存储***。

在一个示例性实施例中，该实现流式源数据解析的方法，还可以包括以下步骤。

根据应用程序协调服务通知的配置文件更新，从应用程序协调服务获取更新的配置文件，通过此配置文件执行线上更新过程。

其中，应用程序协调服务，即Zookeeper会监控实现流式源数据解析的集群状态，并且其配置文件是被上传至其上存储的。

因此，在配置文件发生变化时，应用程序协调服务对此进行通知，以使得集群中的各节点回调代码获取应用程序协调服务上更新的配置文件，进行线上更新，而不需要重启来进行配置更新，由此实现了流式源数据解析的灵活管理。

通过此过程，便实现了业务配置同步和管理通知。在一个示例性实施例的具体实现中，前端所进行的业务配置同步和管理通知，可以分别通过一配置的客户端程序实现，此客户端定期与应用程序协调服务定期通信而到对应的目录找到更新的配置文件，之后根据配置文件来运行线上更新过程。

以将数据分拣到HDFS文件***为例，结合具体应用场景，描述该实现流式源数据解析的方法。

该实现流式源数据解析的方法对应于一运行于实时计算拓扑中的流式源数据解析应用。在此流式源数据解析应用中，包括两大结构，一是Spout结构，另一则是Bolt结构。

通过Spout结构实现流式源数据的拉取和解析，即完成前端的数据处理过程，得到向后端分发的目标数据；通过Bolt结构实现后端的数据处理，进而将得到的目标数据上传至HDFS文件***，并最终入库。

图8是根据一示例性实施例示出的Spout结构的示意图。在图8所示的Spout结构中，通过configManager(610)和onlineconfig(620)所实现的客户端来进行Spout中的业务配置同步和管理通知。

例如，在配置的数据解析插件，即Parse Plugin(630)发生变化时，便通过configManager(610)和onlineconfig(620)实现Spout中与之相关的业务配置同步和管理通知，进而可以根据需要而随时配置新的数据解析插件。

通过Receiver进程(640)拉取流式源数据并缓存，在缓存的流式源数据中，将调用与之相匹配的Parse Plugin(630)进行解析得到目标数据，并按照标识信息写入相应的数据单元650。

在数据单元650达到配置的数据大小或超时时，便在此数据单元650中进行目标数据的打包，得到消息文件，即Inner Msg，多个不同数据单元650所形成的消息文件形成队列660。

在目标数据写数据单元650的过程中，还将通过NullMsg Sender(670)生成空对账文件，以用于后端将目标数据写入HDFS文件***时的检查校验，由此，对于一消息文件，即Inner Msg，其所承载的数据，包括目标数据，以及与此目标数据对应的空对账文件。

队列660中，通过Sender进程680分别发送消息文件。

此外，也将通过Actor线程690获得后端的处理情况，进而相应调整所进行的流式源数据拉取过程。

图9是根据一示例性实施例示出的Bolt结构的示意图。在图9所示的Bolt结构中，通过Receiver(710)接收消息文件，并存入至缓冲队列720中。

Processor进程，将从缓冲队列中的消息文件解析出目标数据，并相应标识信息对应的数据单元，并在此数据单元中配置计时器，以控制数据单元中目标数据的打包。

随着数据单元中进行的目标数据打包而将目标数据写入本地文件，进而多个本地文件形成本地文件队列730。

本地文件队列730中的本地文件，使用LZO格式进行压缩后加入上传队列，等待上传。

至此，Uploader进程740便从上传队列中逐一取出本地文件，并上传。

在此需要补充说明的是，上传的执行，将首先基于标识信息中的数据时间和空对账文件进行检查校验，并在通过之后执行上传。

通过如上所述的实现，能够对流式源数据实时的进行数据清洗，将其导入到对应的数据存储区，供后续的再次分析和使用。

下述为本公开装置实施例，可以用于执行本公开上述实现流式源数据解析的方法实施例。对于本公开装置实施例中未披露的细节，请参照本公开的实现流式源数据解析的方法实施例。

图10是根据一示例性实施例示出的一种实现流式源数据解析的装置的框图。该实现流式源数据解析的装置，如图10所示，包括但不限于：数据拉取模块810、插件调用模块830、数据处理模块850和分发模块870。

数据拉取模块810，用于拉取流式源数据，并缓存，流式源数据是流式地上报至数据源的数据。

插件调用模块830，用于调用与缓存的流式源数据相匹配的数据解析插件，数据解析插件是预先配置的。

数据处理模块850，用于通过调用的数据解析插件处理缓存的流式源数据得到目标数据。

分发模块870，用于向指定目的地分发目标数据，目标数据通过分发进行数据落地。

图11是根据另一示例性实施例示出的一种实现流式源数据解析的装置的框图。该实现流式源数据解析的装置，如图11所示，包括但不限于：标识获得模块910、数据写入模块930和消息文件组装模块950。

标识获得模块910，用于根据目标数据对应的流式源数据，得到目标数据所属数据单元的标识信息。

数据写入模块930，用于按照标识信息将目标数据写入数据单元。

消息文件组装模块950，用于将数据单元中的目标数据组装成消息文件，并建立消息文件与标识信息之间的映射关系，消息文件用于进行目标数据的分发。

图12是根据图10对应实施例示出的对分发模块的细节进行描述的框图。该分发模块870，如图12所示，可以包括但不限于：目的地获得单元871和文件分发单元873。

目的地获得单元871，用于根据消息文件映射的标识信息得到指定目的地。

文件分发单元873，用于向指定目的地分发消息文件，通过消息文件的分发使消息文件中组装的目标数据被分发至指定目的地。

图13是根据另一示例性实施例示出的一种实现流式源数据解析的装置的框图。该实现流式源数据解析的装置，如图13所示，可以包括但不限于：文件分发确认模块1010和拉取限制模块1030。

文件分发确认模块1010，用于在消息文件被确认分发至目的地之后剔除消息文件，未被确认的消息文件则被积压等待重传；

拉取限制模块1030，用于根据积压的消息文件限制流式源数据的拉取，直至被积压的消息文件在数量上低于阈值之后消除限制。

在一个示例性实施例中，消息文件组装模块950进一步用于通过配置的数据大小和超时时间控制数据单元中目标数据的组装，如果数据单元中目标数据达到配置的数据大小或超时，则将数据单元中的目标数据组装成消息文件。

图14是根据另一示例性实施例示出的一种实现流式源数据解析的装置的框图。该实现流式源数据解析的装置，如图14所示，可以包括但不限于：数据接收模块1110、数据缓存模块1130、打包模块1150和上传模块1170。

数据接收模块1110，用于目标数据的后端处理中，接收通过消息文件分发的目标数据。

数据缓存模块1130，用于根据目标数据所属数据单元的标识信息，将目标数据写入数据单元进行缓存。

打包模块1150，用于打包数据单元中的目标数据得到承载目标数据的本地文件。

上传模块1170，用于将本地文件加入上传队列，将本地文件上传至所属数据单元对应的存储***。

可选的，本公开还提供一种服务器，该服务器可以用于图1所示实施环境中，执行图3、图4、图5、图6和图7任一所示的实现流式源数据解析的方法的全部或者部分步骤。所述装置包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行：

拉取流式源数据，并缓存，所述流式源数据是流式地上报至数据源的数据；

调用与缓存的所述流式源数据相匹配的数据解析插件，所述数据解析插件是预先配置的；

通过调用的所述数据解析插件处理所述缓存的流式源数据得到目标数据；

向指定目的地分发所述目标数据，所述目标数据通过所述分发进行数据落地。

该实施例中的装置的处理器执行操作的具体方式已经在有关该实现流式源数据解析的方法的实施例中执行了详细描述，此处将不做详细阐述说明。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围执行各种修改和改变。本发明的范围仅由所附的权利要求来限制。

Claims (12)

1.一种实现流式源数据解析的方法，其特征在于，所述方法包括：

拉取流式源数据，并缓存，所述流式源数据是流式地上报至数据源的数据；

调用与缓存的所述流式源数据相匹配的数据解析插件，所述数据解析插件是预先配置的；

通过调用的所述数据解析插件处理所述缓存的流式源数据得到目标数据；

向指定目的地分发所述目标数据，所述目标数据通过所述分发进行数据落地。

2.根据权利要求1所述的方法，其特征在于，所述通过调用的所述数据解析插件处理所述缓存的流式源数据得到目标数据之后，所述方法还包括：

根据所述目标数据对应的流式源数据，得到所述目标数据所属数据单元的标识信息；

按照所述标识信息将所述目标数据写入数据单元；

将所述数据单元中的目标数据组装成消息文件，并建立所述消息文件与所述标识信息之间的映射关系，所述消息文件用于进行目标数据的分发。

3.根据权利要求2所述的方法，其特征在于，所述向指定目的地分发所述目标数据，包括：

根据所述消息文件映射的标识信息得到指定目的地；

向指定目的地分发所述消息文件，通过所述消息文件的分发使所述消息文件中组装的目标数据被分发至指定目的地。

4.根据权利要求3所述的方法，其特征在于，所述向指定目的地分发所述消息文件，通过所述消息文件的分发使所述消息文件中组装的目标数据被分发至指定目的地之后，所述方法还包括：

在所述消息文件被确认分发至目的地之后剔除所述消息文件，未被确认的消息文件则被积压等待重传；

根据积压的所述消息文件限制所述流式源数据的拉取，直至被积压的所述消息文件在数量上低于阈值之后消除所述限制。

5.根据权利要求2所述的方法，其特征在于，所述将所述数据单元中的目标数据组装成消息文件，包括：

通过配置的数据大小和超时时间控制所述数据单元中目标数据的组装，如果所述数据单元中目标数据达到配置的数据大小或超时，则将所述数据单元中的目标数据组装成消息文件。

6.根据权利要求2所述的方法，其特征在于，所述向指定目的地分发所述目标数据之后，所述方法还包括：

所述目标数据的后端处理中，接收通过所述消息文件分发的目标数据；

根据所述目标数据所属数据单元的标识信息，将所述目标数据写入所述数据单元进行缓存；

打包所述数据单元中的目标数据得到承载所述目标数据的本地文件；

将所述本地文件加入上传队列，将所述本地文件上传至所属数据单元对应的存储***。

7.一种实现流式源数据解析的装置，其特征在于，所述装置包括：

数据拉取模块，用于拉取流式源数据，并缓存，所述流式源数据是流式地上报至数据源的数据；

插件调用模块，用于调用与缓存的所述流式源数据相匹配的数据解析插件，所述数据解析插件是预先配置的；

数据处理模块，用于通过调用的所述数据解析插件处理所述缓存的流式源数据得到目标数据；

分发模块，用于向指定目的地分发所述目标数据，所述目标数据通过所述分发进行数据落地。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

标识获得模块，用于根据所述目标数据对应的流式源数据，得到所述目标数据所属数据单元的标识信息；

数据写入模块，用于按照所述标识信息将所述目标数据写入数据单元；

消息文件组装模块，用于将所述数据单元中的目标数据组装成消息文件，并建立所述消息文件与所述标识信息之间的映射关系，所述消息文件用于进行目标数据的分发。

9.根据权利要求8所述的装置，其特征在于，所述分发模块包括：

目的地获得单元，用于根据所述消息文件映射的标识信息得到指定目的地；

文件分发单元，用于向指定目的地分发所述消息文件，通过所述消息文件的分发使所述消息文件中组装的目标数据被分发至指定目的地。

10.根据权利要求9所述的装置，其特征在于，所述装置还包括：

文件分发确认模块，用于在所述消息文件被确认分发至目的地之后剔除所述消息文件，未被确认的消息文件则被积压等待重传；

拉取限制模块，用于根据积压的所述消息文件限制所述流式源数据的拉取，直至被积压的所述消息文件在数量上低于阈值之后消除所述限制。

11.根据权利要求8所述的装置，其特征在于，所述消息文件组装模块进一步用于通过配置的数据大小和超时时间控制所述数据单元中目标数据的组装，如果所述数据单元中目标数据达到配置的数据大小或超时，则将所述数据单元中的目标数据组装成消息文件。

12.根据权利要求8所述的装置，其特征在于，所述装置还包括：

数据接收模块，用于所述目标数据的后端处理中，接收通过所述消息文件分发的目标数据；

数据缓存模块，用于根据所述目标数据所属数据单元的标识信息，将所述目标数据写入所述数据单元进行缓存；

打包模块，用于打包所述数据单元中的目标数据得到承载所述目标数据的本地文件；

上传模块，用于将所述本地文件加入上传队列，将所述本地文件上传至所属数据单元对应的存储***。