CN111159273B - 数据流处理方法、装置、服务器及存储介质 - Google Patents

Abstract

本申请提供一种数据流处理方法、装置、服务器及存储介质。本申请提供的数据流处理方法，首先获取第一数据流，其中，第一数据流包括地域性特征信息，然后对第一数据流配置规则参数以生成第二数据流，规则参数用于表征流任务的筛选条件，再根据地域性特征信息以及规则参数将第二数据流进行树形结构分级，以使特征值根据树形结构与第二数据流进行关联，而特征值用于表征静态标签表数据。从而，减少了实时数据的处理量，提高了处理效率，优化了处理方式，满足了实时流表关联需求，保证了数据处理系统的运行稳定性。

Description

数据流处理方法、装置、服务器及存储介质

技术领域

本申请涉及数据处理技术领域，尤其涉及一种数据流处理方法、装置、服务器及存储介质。

背景技术

随着大数据技术的快速发展，以及各种实时场景类应用需求的不断涌现，使得大数据技术的应用从批量处理为主逐渐向以实时处理为主演进。主流Kafka和Sparkstreaming具有提供海量、复杂、多源、异构的数据处理源，以及对其进行接入、清洗并保证数据质量的能力。数据源首先通过高吞吐能力的Kafka，然后使用Spark streaming进行消费对接完成后，再存入Hbase数据库，或者与数据表关联后再存入Hbase数据库，以完成对实时数据的流处理。

现有技术中，因实时数据的数据源不同，使得数据结构不同，以及针对该实时数据的业务需求不同，使得筛选规则不同。不同数据源的实时数据需要编写不同的筛选规则以满足业务需求，从而导致数据峰值高达近千万每秒的数据流的处理量变得更为庞大，导致数据在处理以及入库过程中出现诸多问题。

例如在入库过程中，采用传统的应用程序接口(Application ProgrammingInterface，简称API)代码进行入库代码编写变得复杂，以及对于数据库的读与写需要拆分为不同进程，则需要多节点部署程序，造成程序部署以及节点监控变得复杂。在数据处理过程中，因需要将工参表内的经纬度、用户标签表等表数据与实时数据实现流表关联以达到业务需求，而由于表数据通常数据量也较大，无法将其预读入内存，在常规的关联方式下，扫描表数据速度通常太慢，导致两者的关联无法满足实时处理需求。

发明内容

本申请提供一种数据流处理方法、装置、服务器及存储介质，用以解决现有实时数据处理量庞大、数据入库复杂以及与表数据关联无法满足实时处理需求等技术问题。

第一方面，本申请提供一种数据流处理方法，包括：

获取第一数据流，所述第一数据流包括地域性特征信息；

对所述第一数据流配置规则参数以生成第二数据流，所述规则参数用于表征流任务的筛选条件；

根据所述地域性特征信息以及所述规则参数将所述第二数据流进行树形结构分级，以使特征值根据所述树形结构与所述第二数据流进行关联，所述特征值用于表征静态标签表数据。

一种可能的设计中，所述对所述第一数据流配置规则参数以生成第二数据流之前，还包括：

根据所述第一数据流以及所述流任务确定所述规则参数，所述流任务包括业务需求。

一种可能的设计中，所述根据所述地域性特征信息以及所述规则参数将所述第二数据流进行树形结构分级之后，还包括：

根据所述业务需求以及所述树形结构通过预设流处理语言对所述第二数据流进行处理以获得处理结果，所述处理结果用于表征所述流任务的实现结果。

一种可能的设计中，将所述规则参数存入所述预设第一数据库，所述预设第一数据库为MySQL数据库；和/或

将所述处理结果以及所述树形结构存入预设第二数据库，所述预设第二数据库为Hbase数据库；和/或，

将所述静态标签表数据存入预设第三数据库，所述预设第三数据库为Hive数据库。

可选地，所述MySQL数据库包括JSON字符串；

通过所述JSON字符串对所述规则参数进行操作处理，所述操作处理包括新建所述规则参数、修改所述规则参数以及终止所述规则参数中的至少一种。

可选地，所述Hbase数据库包括：

通过多列族以及生存期TTL进行版本控制；以及

通过区域服务器Region Server将所述特征值根据所述树形结构与所述第二数据流进行所述关联。

可选地，所述Hive数据库包括ORC文件格式；

通过所述ORC文件格式将所述特征值根据所述树形结构与所述第二数据流进行所述关联。

第二方面，本申请提供一种数据流处理装置，包括：

获取模块，用于获取第一数据流，所述第一数据流包括地域性特征信息；

第一处理模块，用于对所述第一数据流配置规则参数以生成第二数据流，所述规则参数用于表征流任务的筛选条件；

第二处理模块，用于根据所述地域性特征信息以及所述规则参数将所述第二数据流进行树形结构分级，以使特征值根据所述树形结构与所述第二数据流进行关联，所述特征值用于表征静态标签表数据。

一种可能的设计中，所述第一处理模块，还用于：

根据所述第一数据流以及所述流任务确定所述规则参数，所述流任务包括业务需求。

一种可能的设计中，所述第二处理模块，还用于：

根据所述业务需求以及所述树形结构通过预设流处理语言对所述第二数据流进行处理以获得处理结果，所述处理结果用于表征所述流任务的实现结果。

一种可能的设计中，所述第一处理模块包括第一处理单元，所述第一处理单元，用于将所述规则参数存入所述预设第一数据库，所述预设第一数据库为MySQL数据库；和/或

所述第二处理模块包括第二处理单元，所述第二处理单元，用于将所述处理结果以及所述树形结构存入预设第二数据库，所述预设第二数据库为Hbase数据库；和/或，

所述装置还包括第三处理模块，所述第三处理模块，用于将所述静态标签表数据存入预设第三数据库，所述预设第三数据库为Hive数据库。

可选地，所述MySQL数据库包括JSON字符串；

所述第一处理单元，还用于：

通过所述JSON字符串对所述规则参数进行操作处理，所述操作处理包括新建所述规则参数、修改所述规则参数以及终止所述规则参数中的至少一种。

可选地，所述装置还包括第四处理模块，所述第四处理模块，用于：

通过多列族以及生存期TTL进行版本控制；以及

通过区域服务器Region Server以使所述特征值根据所述树形结构与所述第二数据流进行所述关联。

可选地，所述Hive数据库包括ORC文件格式；

所述第三处理模块，还用于：

通过所述ORC文件格式以使所述特征值根据所述树形结构与所述第二数据流进行所述关联。

第三方面，本申请提供一种服务器，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面及可选的方案涉及的数据流处理方法。

第四方面，本申请提供一种存储有计算机指令的非瞬时计算机可读存储介质，所述计算机指令用于使所述计算机执行第一方面及可选的方案涉及的数据流处理方法。

本申请提供一种数据流处理方法、装置、服务器及存储介质，首先获取第一数据流，其中，第一数据流包括地域性特征信息，然后对第一数据流配置规则参数以生成第二数据流，规则参数用于表征流任务的筛选条件，再根据地域性特征信息以及规则参数将第二数据流进行树形结构分级，以使特征值根据树形结构与第二数据流进行关联，而特征值用于表征静态标签表数据。从而，减少了实时数据的处理量，提高了处理效率，优化了处理方式，满足了实时流表关联需求，保证了数据处理系统的运行稳定性。

附图说明

图1为本申请实施例提供的数据流处理方法的一种应用场景图；

图2为本申请实施例提供的一种数据流处理方法的流程示意图；

图3为本申请实施例提供的一种树形结构示意图；

图4为本申请实施例提供的一种数据流处理装置的结构示意图；

图5为本申请实施例提供的另一种数据流处理装置的结构示意图；

图6为本申请实施例提供的再一种数据流处理装置的结构示意图；

图7为本申请实施例提供的一种服务器的结构示意图。

通过上述附图，已示出本公开明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本公开构思的范围，而是通过参考特定实施例为本领域技术人员说明本公开的概念。

具体实施方式

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

本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例例如能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

目前，关于大数据技术涌现出各种实时场景类应用需求，使得大数据技术的实时处理逐渐成为重中之重。对于实时数据的处理流程而言，主流的处理流程为首先通过高吞吐能力的Kafka接入数据源，然后使用Spark streaming进行消费对接完成后，再存入Hbase数据库，或者与表数据关联后再存入Hbase数据库，以完成对实时数据的流处理。然而，因实时数据的数据源不同，使得数据结构不同，以及针对该实时数据的业务需求不同，使得筛选规则不同。不同数据源的实时数据需要编写不同的筛选规则以满足业务需求，从而导致数据的处理量变得更为庞大，进而使得数据在入库过程中以及入库之后都会出现诸多问题。例如，数据的入库代码编写变得复杂，并且对于数据库的读写进程需要拆分，则需要在多节点部署程序，导致部署程序以及节点监控均变得复杂。此外，在处理过程中，由于表数据的数据量也较大，无法将其预读入内存，在常规的关联方式下，扫描表数据速度通常太慢，导致两者的关联无法满足实时处理需求。

针对现有技术中存在的上述问题，本申请提供一种数据流处理方法、装置、服务器及存储介质，首先获取第一数据流，其中，第一数据流包括地域性特征信息，然后对第一数据流配置规则参数以生成第二数据流，规则参数用于表征流任务的筛选条件，再根据地域性特征信息以及规则参数将第二数据流进行树形结构分级，以使特征值根据树形结构与第二数据流进行关联，而特征值用于表征静态标签表数据。从而，减少了实时数据的处理量，提高了实时数据处理效率，优化了处理方式，满足了实时流表关联需求，保证了实时数据处理系统的运行稳定性。

下面以具体地实施例对本申请的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

图1为本申请实施例提供的数据流处理方法的一种应用场景图，本申请实施例提供的数据流处理方法可以由一个服务器或服务器集群执行，可以根据所要处理的实时数据量和/或业务需求进行设置，对此，本申请实施例不作限定。如图1所示，本申请实施例提供的数据流处理方法由服务器11执行，其中，图1中仅以一个服务器为例示出。所要进行实时处理的数据源，即第一数据流来自于终端12、终端13、终端14在运行过程中所产生的数据流，其中，该终端12、终端13以及终端14可以为手机、智能手表、可穿戴设备、平板电脑、车载终端中的任意一种，该终端具备实时数据获知能力。图1中终端12、终端13以及终端14均以手机为例示出。可以理解的是，图1示例性地示出了部分终端，而在实际工况中，第一数据流来自于多个终端。

可以理解的是，上述中的服务器11与终端12、终端13、终端14之间通过基站15所提供的通讯信号进行交互，以实现本申请实施例提供的数据流处理方法。其中，对于所涉及的通讯信号所属的网络制式本申请实施例不作限定。例如，可以适用于全球移动通讯(GlobalSystem of Mobile communication，简称GSM)、码分多址(Code Division MultipleAccess，简称CDMA)、宽带码分多址(Wideband Code Division Multiple Access，简称WCDMA)、时分同步码分多址(Time Division-Synchronous Code Division MultipleAccess，简称TD-SCDMA)、长期演进(Long Term Evolution，简称LTE)系统及5G等网络制式。另外，基站15可以是GSM或CDMA中的基站(Base Transceiver Station，简称BTS)和/或基站控制器，也可以是WCDMA中的基站(NodeB，简称NB)和/或无线网络控制器(Radio NetworkController，简称RNC)，还可以是LTE中的演进型基站(Evolutional Node B，简称eNB或eNodeB)，或者中继站或接入点，或者5G网络中的基站(gNB)等，本申请实施例对此不作限定

参照图1，本申请实施例提供的数据流处理方法，首先服务器11获取终端12、终端13、终端14在运行过程中产生的第一数据流，通常服务器11中内置有流处理平台，例如通过开源流处理平台Kafka接入数据源，其中第一数据流包括地域性特征信息，然后，服务器11对第一数据流配置规则参数，以生成第二数据流，而规则参数用于表征流任务的筛选条件，再者，服务器11根据地域性特征信息以及规则参数将第二数据流进行树形结构分级，使得表征静态标签表数据的特征值依据树形结构与第二数据流进行关联。从而，减少了实时数据的处理量，提高了处理效率，优化了处理方式，满足了实时流表关联需求，保证了数据处理系统的运行稳定性。

图2为本申请实施例提供的一种数据流处理方法的流程示意图，如图2所示，本实施例提供的数据流处理方法由服务器或服务器集群执行，该方法包括：

S201：获取第一数据流。

其中，第一数据流包括地域性特征信息。

通过流处理平台，例如开源流处理平台Kafka接入数据源，即获取第一数据流。例如所获取的第一数据流来自于手机端，该手机端为能够正常运行的终端，则所获取的第一数据流可以为上网消息、位置信息、归一化信令、业务用量、流量信控、开关机状态、语音通话、位置更新等各种实时数据源。不同的数据源，具有不同的数据结构，例如对于上网消息以及实时位置信息而言，两者属于不同的数据源，上网消息可能包括上网时长、上网所在地例如上网的端口IP地址等信息，其数据结构包括时长以及IP地址。而对于实时位置信息而言，该信息可能包括某个时刻该终端所处的地理位置，地理位置可以包括经纬度信息等，相比可见，两者不同的数据源，具有不同的数据结构，换言之，来自于不同数据源的第一数据流具有异构性。

而不论数据结构有何不同，所获取的第一数据流包括地域性特征信息，其中，地域性特征信息能够将当前所获取的第一数据流与其来源进行对应，可以理解为，通过第一数据流所包括的地域性特征信息将第一数据流与产生该实时数据源的终端进行对应。通常，地域性特征信息可以为终端的电话号码、IP地址等唯一能够识别终端的标识码信息。对此，本申请实施例不作限定。

S202：对第一数据流配置规则参数以生成第二数据流。

其中，规则参数用于表征流任务的筛选条件。

获取到第一数据流之后，对第一数据流配置规则参数，以生成第二数据流，其中，规则参数用于表征流任务的筛选条件。

对第一数据流进行处理，以实现业务需求，可以理解为进行流任务。其中，因业务需求不同，则需要通过筛选条件对第一数据流进行处理，使其满足流任务下游的业务需求。换言之，对第一数据流配置规则参数，规则参数能够表征流任务对第一数据流的筛选条件，配置有规则参数的第一数据流即为第二数据流。

可见，在对第一数据流配置规则参数以生成第二数据流之前，确定规则参数。一种可能的实现方式中，根据第一数据流以及流任务确定规则参数，其中，流任务包括业务需求。

可以理解的是，对第一数据流进行数据处理的目的为满足流任务下游的业务需求，其中流任务包括业务需求，需要通过筛选条件对第一数据流进行筛选以满足业务需求。值得被理解的是，将表征流任务筛选条件的所有参数均定义为规则参数，则在对第一数据流配置规则参数以生成第二数据流之前，根据第一数据流以及流任务确定规则参数，其确定规则参数的进程与流任务进程并行进行，不影响第一数据流的正常流任务进行。

可选地，将根据第一数据流以及流任务确定的规则参数存入预设第一数据库，预设第一数据库为MySQL数据库。

将根据第一数据流以及流任务所确定的规则参数存入预设第一数据库，使得规则参数独立于流任务所存储的数据库，减小了数据量的同时不影响流任务的实时处理进程。

其中，预设第一数据库可以为MySQL数据库。MySQL数据库是一种开放源代码的关系型数据库管理系统，能够使用最常用的数据库管理语言，例如结构化查询语言(Structured Query Language，简称SQL)进行数据库管理。

当预设第一数据库为MySQL数据库时，MySQL数据库包括对象简谱(JavaScriptObject Notation，简称JSON)字符串，则通过JSON字符串对确定规则参数，换言之，通过JSON字符串对规则参数进行操作处理，其中操作处理包括新建规则参数、修改规则参数以及终止规则参数中的至少一种。可以理解的是，JSON字符串能够通过完全独立于编程语言的文本格式来存储和表示数据，因而，使得确定规则参数进程简洁又清晰。

通过对上述所列举实施例的描述，可见，本申请实施例提供的数据流处理方法中，对所获取的第一数据流配置规则参数以生成第二数据流时，与第一数据流的流任务进程并行进行了规则参数的确定，将根据第一数据流以及流任务所确定的规则参数配置于第一数据流以生成第二数据流，而不影响第一数据流的正常流任务进程，针对数据源结构以及筛选条件不同的第一数据流，本申请实施例提供的数据流处理方法只需将已确定的规则参数配置于第一数据流即可，而不影响第一数据流的流任务进程，不同于现有技术中对第一数据流配置规则参数需在流任务进程中进行，以及当获取到多种异构数据源时，需要遍历所有的数据，对第一数据流的流任务进程造成影响。

S203：根据地域性特征信息以及规则参数将第二数据流进行树形结构分级，以使特征值根据树形结构与第二数据流进行关联。

其中，特征值用于表征静态标签表数据。

在对第一数据流配置规则参数以生成第二数据流之后，根据第一数据流所包括的地域性特征信息以及规则参数将第二数据流分级为树形结构，使得，表征静态标签表数据的特征值能够依据树形结构与第二数据流进行关联。

树形结构指的是数据元素之间存在着“一对多”的树形关系的数据结构，是一类重要的非线性数据结构。其中的数据元素具有层次的嵌套结构。因第一数据流包括有地域性特征信息，该地域性特征信息能够将所获取的第一数据流通过地域的不同进行划分，因而，根据地域性特征信息能够将第二数据流分级为树形结构。

以第一数据流为位置信息为例进行说明。由于流任务所包括的业务需求，首先对该位置信息配置规则参数，以生成针对位置信息的第二数据流，则根据位置信息所包括的地域性特征信息进行树形结构分级，分级得到的树形结构如图3所示，图3为本申请实施例提供的一种树形结构示意图，参照图3所示，位于该树形结构“树根”位置的数据元素是以全国为单位的位置信息，仅次于“树根”位置的下一层则是省份和/或直辖市为单位的位置信息，具体地，根据地域性特征信息以持有终端的用户到访地为单位将第二数据流进行归类，此处的到访地则可以为省份和/或直辖市，换言之，即将同属于相同省份和/或直辖市的归为同一目录，目录名称可以为省份和/或直辖市的名称。在当前每个目录下，还可以继续根据每个省份和/或直辖市的下一层城市或商圈为单位将当前目录下的第二数据流归类，当前目录以北京为例，则以北京的商圈为单位将第二数据流继续归类，例如西单商圈、北京南站等。在本申请实施例中，将分级时采用的分级单位统称为电子围栏，电子围栏的下层再进行分级则产生了电子围栏分支。因而，上述描述中的全国、省份和/或直辖市以及下层城市或商圈都为电子围栏，参照图3所示，全国单位内的第二数据流即为第一级电子围栏内的第二数据流，省份和/或直辖市单位内的第二数据流即为第二级电子围栏内的第二数据流，下层城市或商圈单位内的第二数据流即为第三级电子围栏内的第二数据流。地域性特征信息为唯一能够识别终端的标识码信息，因此，当树形结构已分级至第三级时，第三级内的第二数据流又能够根据终端的归属地进行归类，例如电话号码的归属地，其中归属地为省份和/或直辖市，其归类所涉及的电子围栏又复用了第二级电子围栏，可见，本申请实施例提供的树形结构能够分级复用电子围栏。

根据地域性特征信息能够确定树形结构的电子围栏，而电子围栏的级数则由规则参数确定，换言之，将第二数据流按照树形结构分级，直到每个电子围栏的单个分支上的数据元素能够满足流任务所包括的业务需求，则分级结束。规则参数表征第一数据流满足于流任务所包括的业务需求的筛选条件，即电子围栏的级数由规则参数确定，根据地域性特征信息以及规则参数将第二数据流进行树形结构分类。

将第二数据流按照树形结构进行分级之后，用于表征静态标签表数据的特征值则能够根据树形结构与第二数据流中对应的数据元素进行关联。其中，静态标签表数据例如工参表内的经纬度、用户标签等数据，用户标签可以理解为当前终端所属的用户的实名制信息，例如用户的性别、年龄等标签数据。将表征此类静态标签表数据的特征值与第二数据流进行关联，换言之，将静态标签表数据与动态的流数据实现关联，为完成流任务的业务需求所必须的步骤。

可见，将第二数据流进行树形结构分级，使得特征值根据树形结构与第二数据流进行关联。具体为，特征值与树形结构中对应的数据元素直接进行关联。与现有技术相比，无需遍历第二数据流中所有的数据，使得数据峰值高达近千万每秒的数据流的处理量得到极大地降低，也不存在因表数据的扫描太慢导致流表关联无法满足实时处理进程等问题。

值得说明的是，对于数据源不同的其他第一数据流，在对其配置有规则参数之后，都可以根据地域性特征信息以及规则参数进行树形结构分级。

可选地，在根据地域性特征信息以及规则参数将第二数据流进行树形结构分级之后，根据业务需求以及树形结构通过预设流处理语言对第二数据流进行处理以获得处理结果，处理结果用于表征流任务的实现结果。

将第二数据流进行树形结构分级之后，通过预设流处理语言根据树形结构以及业务需求对第二数据流进行处理，可以理解为通过预设流处理语言，例如SQL来操作第二数据流，按照业务需求不同根据树形结构对第二数据流中对应的数据元素进行处理和/或转发，以获得处理结果，该处理结果即为流任务的实现结果。可见，在该步骤中，对于第二数据流的处理是按照业务需求依据树形结构对相对应的数据元素进行处理和/或转发，而无需遍历所有的第二数据流，从而，降低了数据处理量。

本实施例提供的数据流处理方法，首先获取第一数据流，第一数据流包括有地域性特征信息，然后对第一数据流配置规则参数生成第二数据流，其中，规则参数用于表征流任务的筛选条件，再根据地域性特征信息以及规则参数将第二数据流进行树形结构分级，以使表征静态标签表数据的特征值根据树形结构与第二数据流进行关联。从而，针对数据峰值高达近千万每秒的数据流，极大地降低了的数据处理量，提高了处理效率，优化了处理方式，满足了实时流表关联需求，保证了数据处理系统的运行稳定性。

在上述实施例的基础上，可选地，将处理结果以及树形结构存入预设第二数据库，预设第二数据库为Hbase数据库。

将对第二数据流进行处理所获得的处理结果以及树形结构均存入预设第二数据库，其中，预设第二数据库为Hbase数据库。Hbase数据库全称为Hadoop Database，其为一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，具有低时延的优点，将处理结果以及树形结构存入Hbase数据库实现并发查询需求，以满足实时处理进程。

一种可能的实现方式中，Hbase数据库包括：

通过多列族以及生存期TTL进行版本控制；以及

通过区域服务器Region Server以使特征值根据树形结构与第二数据流进行关联。

具体地，在Hbase数据库中，通过多列族以及生存期(Time To Live，简称TTL)进行版本控制，实现数据的变更管理。以及通过区域服务器(Region Server)水平扩展实现高吞吐的写入与高并发的查询，以使特征值根据树形结构与第二数据流进行关联。

值得说明的是，也可以根据所要处理的实时数据的数据量以及其他特性设置其他预设第二数据库，对此，本申请实施例不作限定。

本实施例提供的预设第二数据库为Hbase数据库，实现了数据库中保存有数据的多份最新记录，支持几百万至上千万级别秒级数据写入以及高并发的随机查询。克服了现有技术中数据入库需拆分读写进程，多节点部署程序以及监控等技术问题，降低了数据处理复杂程度，优化了处理方式。

可选地，将静态标签表数据存入预设第三数据库，预设第三数据库为Hive数据库。

Hive数据库是基于Hadoop的一个数据仓库工具，能够用于进行数据提取、转化、加载等操作。将静态标签表数据存入Hive数据库，以使其与第二数据流进行流表关联。

一种可能的实现方式中，Hive数据库包括ORC文件格式，通过ORC文件格式将特征值根据树形结构与第二数据流进行关联。

ORC(Optimized Row Columnar)文件格式是一种Hadoop生态圈中的列式存储格式，具体为，将数据按行分块，每块按照列进行存储，具有占用空间小、压缩快以及快速存取等特点。通过ORC文件格式以使特征值根据树形结构与第二数据流进行关联，能够满足实时流表关联需求。

值得说明的是，也可以根据所要处理的实时数据所要关联的静态标签表数据的数据量以及其他特性设置其他预设第三数据库以及选用其他文件格式，对此，本申请实施例不作限定。

本实施例提供的预设第三数据库为Hive数据库，将静态标签表数据存入Hive数据库，Hive数据库选用ORC文件格式，从而通过ORC文件格式以使特征值根据树形结构与第二数据流进行关联，以满足实时流表关联需求。

图4为本申请实施例提供的一种数据流处理装置的结构示意图，如图4所示，本实施例提供的数据流处理装置400，包括：

获取模块401，用于获取第一数据流。

其中，第一数据流包括地域性特征信息。

第一处理模块402，用于对第一数据流配置规则参数以生成第二数据流。

其中，规则参数用于表征流任务的筛选条件。

第二处理模块403，用于根据地域性特征信息以及规则参数将第二数据流进行树形结构分级，以使特征值根据树形结构与第二数据流进行关联，其中，特征值用于表征静态标签表数据。

本实施例提供的数据流处理装置400与上述图2所示的方法实施例的实现原理以及效果类似，在此不再赘述。

一种可能的设计中，第一处理模块402，还用于：

根据第一数据流以及流任务确定规则参数，其中，流任务包括业务需求。

一种可能的设计中，第二处理模块403，还用于：

根据业务需求以及树形结构通过预设流处理语言对第二数据流进行处理以获得处理结果，其中，处理结果用于表征流任务的实现结果。

可选地，第一处理模块402，包括：

第一处理单元，用于将规则参数存入预设第一数据库，其中，预设第一数据库为MySQL数据库。

可选地，MySQL数据库包括JSON字符串，第一处理单元，还用于：

通过JSON字符串对规则参数进行操作处理，其中，操作处理包括新建规则参数、修改规则参数以及终止规则参数中的至少一种。

可选地，第二处理模块403，包括：

第二处理单元，用于将处理结果以及树形结构存入预设第二数据库，其中，预设第二数据库为Hbase数据库。

可选地，图5为本申请实施例提供的另一种数据流处理装置的结构示意图，如图5所示，本实施例提供的数据流处理装置400，还包括：

第三处理模块404，用于将静态标签表数据存入预设第三数据库，其中，预设第三数据库为Hive数据库。

可选地，Hive数据库包括ORC文件格式，第三处理模块404，还用于：

通过ORC文件格式以使特征值根据树形结构与第二数据流进行关联。

可选地，图6为本申请实施例提供的再一种数据流处理装置的结构示意图，如图6所示，本实施例提供的数据流处理装置400，还包括：第四处理模块405，用于：

通过多列族以及TTL进行版本控制；以及

通过区域服务器以使特征值根据树形结构与第二数据流进行关联。

上述各实施例中的装置400与前述方法实施例的实现原理以及效果类似，在此不再赘述。

图7为本申请实施例提供的一种服务器的结构示意图，如图7所示，本实施例提供的电子设备700包括：

至少一个处理器701；以及

与至少一个处理器通信连接的存储器702；其中，

存储器702存储有可被至少一个处理器701执行的指令，该指令被至少一个处理器701执行，以使至少一个处理器701能够执行上述实施例中的数据流处理方法的各个步骤，具体可以参考前述方法实施例中的相关描述。

值得说明的是，当执行本申请实施例提供的数据流处理方法为服务器集群时，则集群中的处理器以及存储器同样被配置为如图7所示实施例中的服务器以执行本申请实施例提供的数据流处理方法的各个步骤，在此，本实施例不作赘述。

在示例性实施例中，本申请实施例提供了一种存储有计算机指令的非瞬时计算机可读存储介质，计算机指令用于使计算机执行上述各实施例中数据流处理方法的各个步骤。例如，可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由权利要求书指出。

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

Claims (10)

1.一种数据流处理方法，其特征在于，包括：

获取第一数据流，所述第一数据流包括地域性特征信息；所述第一数据流为来自于终端的数据流，所述地域性特征信息为终端的唯一的标识码信息；

对所述第一数据流配置规则参数以生成第二数据流，所述规则参数用于表征流任务对第一数据流的筛选条件，所述流任务包括业务需求；

根据所述地域性特征信息以及所述规则参数将所述第二数据流进行树形结构分级，以使特征值根据所述树形结构与所述第二数据流进行关联，所述特征值用于表征静态标签表数据；所述静态标签表数据表征经纬度和使用终端的用户的用户标签。

2.根据权利要求1所述的数据流处理方法，其特征在于，所述对所述第一数据流配置规则参数以生成第二数据流之前，还包括：

根据所述第一数据流以及所述流任务确定所述规则参数，所述流任务包括业务需求。

3.根据权利要求2所述的数据流处理方法，其特征在于，所述根据所述地域性特征信息以及所述规则参数将所述第二数据流进行树形结构分级之后，还包括：

根据所述业务需求以及所述树形结构通过预设流处理语言对所述第二数据流进行处理以获得处理结果，所述处理结果用于表征所述流任务的实现结果。

4.根据权利要求3所述的数据流处理方法，其特征在于，

将所述规则参数存入预设第一数据库，所述预设第一数据库为MySQL数据库；和/或

将所述处理结果以及所述树形结构存入预设第二数据库，所述预设第二数据库为Hbase数据库；和/或，

将所述静态标签表数据存入预设第三数据库，所述预设第三数据库为Hive数据库。

5.根据权利要求4所述的数据流处理方法，其特征在于，所述MySQL数据库包括JSON字符串；

通过所述JSON字符串对所述规则参数进行操作处理，所述操作处理包括新建所述规则参数、修改所述规则参数以及终止所述规则参数中的至少一种。

6.根据权利要求4所述的数据流处理方法，其特征在于，所述Hbase数据库包括：

通过多列族以及生存期TTL进行版本控制；以及

通过区域服务器Region Server以使所述特征值根据所述树形结构与所述第二数据流进行所述关联。

7.根据权利要求4所述的数据流处理方法，其特征在于，所述Hive数据库包括ORC文件格式；

通过所述ORC文件格式以使所述特征值根据所述树形结构与所述第二数据流进行所述关联。

8.一种数据流处理装置，其特征在于，包括：

获取模块，用于获取第一数据流，所述第一数据流包括地域性特征信息；所述第一数据流为来自于终端的数据流，所述地域性特征信息为终端的唯一的标识码信息；

第一处理模块，用于对所述第一数据流配置规则参数以生成第二数据流，所述规则参数用于表征流任务对第一数据流的筛选条件，所述流任务包括业务需求；

第二处理模块，用于根据所述地域性特征信息以及所述规则参数将所述第二数据流进行树形结构分级，以使特征值根据所述树形结构与所述第二数据流进行关联，所述特征值用于表征静态标签表数据；所述静态标签表数据表征经纬度和使用终端的用户的用户标签。

9.一种服务器，其特征在于，包括：

至少一个处理器；以及

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行权利要求1-7中任一项所述的数据流处理方法。

10.一种存储有计算机指令的非瞬时计算机可读存储介质，其特征在于，所述计算机指令用于使所述计算机执行权利要求1-7中任一项所述的数据流处理方法。