CN114666753A - 信令流数据处理方法、位置信息服务方法及电子设备 - Google Patents

Abstract

本申请公开了一种信令流数据处理方法、位置信息服务方法及电子设备，涉及通信领域。其中，流数据处理框架按照时序持续获取待处理的信令数据，信令数据中包括第一用户号码、第一时间信息以及第一位置标识；根据第一用户号码对预设的全量号码位置哈希表HTable进行哈希寻址；在HTable中存在与第一用户号码匹配的第二用户号码，且目标位置元组中的第二位置标识与第一位置标识相同、第二时间信息小于第一时间信息的情况下，将与第一用户号码匹配的第二用户号码对应的位置元组中的第二时间信息更新为第一时间信息。

Description

信令流数据处理方法、位置信息服务方法及电子设备

技术领域

本申请涉及通信领域，尤其涉及一种信令流数据处理方法、位置信息服务方法及电子设备。

背景技术

XDR信令数据(XDR，X Data Record)的应用是运营商大数据应用的一个重要内容，例如信令数据在商圈分析、应急安保、城市规划、智慧旅游、智慧交通等领域均有应用。

目前的传统方法里，由于没有对信令位置数据的后续流程进行全程流处理，仅是每隔一段时间获取一次全量号码的位置快照数据，再存入到Hadoop分布式文件系统(Hadoop Distributed File System，HDFS)中，导致在供后续各种应用进行数据查询、调用时，存在数据处理环节繁多、时效性差、无法实现持续效果、耗时不稳定、资源消耗大等诸多问题。

发明内容

本申请实施例提供一种信令流数据处理方法、位置信息服务方法及电子设备，以至少解决前述的数据处理环节繁多、时效性差、无法实现持续效果、耗时不稳定、资源消耗大等诸多问题。

为了解决上述问题，本申请是这样实现的：

第一方面，本申请实施例提供一种信令流数据处理方法，应用于流数据处理框架，所述方法包括：

按照时序持续获取待处理的信令数据，所述信令数据中包括第一用户号码、第一时间信息以及第一位置标识；

根据所述第一用户号码对预设的全量号码位置哈希表HTable进行哈希寻址；其中，所述HTable中保存有以第二用户号码为键的位置元组，每个所述位置元组中包括与所述第二用户号码对应的第二时间信息和第二位置标识；

在所述HTable中存在与所述第一用户号码匹配的第二用户号码，且目标位置元组中的第二位置标识与所述第一位置标识相同、第二时间信息小于所述第一时间信息的情况下，将与所述第一用户号码匹配的第二用户号码对应的位置元组中的第二时间信息更新为所述第一时间信息，其中，所述目标位置元组是与所述第一用户号码匹配的第二用户号码对应的位置元组。

作为一种可能的实现方式，根据所述第一用户号码对预设的全量号码位置哈希表HTable进行哈希寻址的步骤之后，所述方法还包括：

在所述HTable中存在与所述第一用户号码匹配的第二用户号码，且所述目标位置元组中的第二位置标识与所述第一位置标识不相同、第二时间信息小于所述第一时间信息的情况下，根据所述信令数据中的第一位置标识和第一时间信息对所述目标位置元组进行更新。

作为另一种可能的实现方式，根据所述第一用户号码对预设的全量号码位置哈希表HTable进行哈希寻址的步骤之后，所述方法还包括：

在所述HTable中不存在与所述第一用户号码匹配的第二用户号码的情况下，以所述第一用户号码为键，在所述HTable中创建位置元组，该位置元组包括所述第一位置标识和第一时间信息。

作为又一种可能的实现方式，所述方法还包括：

在所述HTable中存在位置标识更新的情况下，根据更新的所述位置标识，将号码信息同步更新至预设的全量位置号码哈希集合HSet中。

作为又一种可能的实现方式，所述方法还包括：

在所述HTable中存在新增号码键的情况下，根据所述新增号码键对应的位置信息，将所述新增号码键对应的用户号码同步更新至预设的全量位置号码哈希集合HSet中。

作为又一种可能的实现方式，根据所述新增号码键对应的位置信息，将所述新增号码键对应的用户号码同步更新至预设的全量位置号码哈希集合HSet中，包括：

在所述HSet中不存在以所述第一位置信息为键的号码集合的情况下，以所述第一位置标识为键、以所述第一用户号码为集合元素，在所述HSet中创建一个号码集合，以将所述位置标识键补全至所述HSet中；

或者，

在所述HSet中存在以所述第一位置信息为键的号码集合、但该号码集合中不存在第一用户号码为元素的情况下，以所述第一用户号码添加到所述号码集合，以将所述位置标识及其下附着的最新号码信息同步至所述HSet中。

作为又一种可能的实现方式，根据所述新增号码键对应的位置信息，将所述新增号码键对应的用户号码同步更新至预设的全量位置号码哈希集合HSet中，包括：

在所述HSet中分别以变更前的第二位置标识为来源键、第一位置标识为目标键，将所述第一用户号码从来源键对应的号码集合中转移到目标键对应的号码集合，以及将所述第一位置标识及其下附着的号码信息同步至所述HSet。

作为又一种可能的实现方式，所述方法还包括：

在所述HSet中存在信息变更的情况下，将变更的信息按预定规格输出至预设的第一级位置变更消息队列中，形成用户号码位置变更日志，或者，再对所述变更的信息按用户号码和位置标识进行分区，输出至后级的多条消息队列，供后续按需利用。

作为又一种可能的实现方式，所述预定规格包括：[用户号码，来源位置标识，目标位置标识，第一时间信息]，其中，所述来源位置标识可以为空值或非空值。

作为又一种可能的实现方式，所述获取待处理的信令数据包括：

从分布式消息队列中消费所述待处理的信令流数据，其中，所述队列中的待处理的信令流数据是由网络设备采集汇聚得到。

第二方面，本申请实施例还提供一种位置信息服务方法，包括：根据预设的全量位置号码哈希集合HSet、全量号码位置哈希表HTable以及位置变更消息队列，执行以下任意一项，以及推送执行结果给应用端：

在获取到指定用户号码的情况下，以所述指定用户号码为输入参数查询所述HTable，得到与所述指定用户号码对应的最新位置信息并输出；

在获取到指定位置标识的情况下，以所述指定位置标识为输入参数查询所述HSet，得到与所述指定位置标识所附着的用户号码信息并输出；

在获取到指定位置标识集合的情况下，通过订阅消费和过滤处理位置变更消息队列的日志流，持续不断取得漫入指定区域中的用户号码，所述指定区域是所述指定位置标识集合对应的区域；

在获取到指定用户号码的情况下，通过订阅消费和过滤处理位置变更消息队列的日志流，得到与所述指定用户号码对应的用户时空轨迹；

在获取到指定区域对应的位置标识的情况下，以所述指定位置标识为输入参数查询所述HSet，统计得到位于所述指定区域的用户数；

其中，所述HTable中保存有以用户号码为键形成的多个位置元组，每个所述位置元组中包括与所述用户号码对应的最新位置标识和时间信息；所述HSet中保存有以位置标识为键形成的不同号码集合，每个所述号码集合中保存有位置标识对应小区当前所附着的用户号码信息。

第三方面，本申请实施例还提供一种电子设备，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如第一方面信令流数据处理方法的步骤，或第二方面所述的位置信息服务方法的步骤。

第四方面，本申请实施例还提供一种计算机可读存储介质，所述计算机可读存储介质上存储计算机程序，所述计算机程序被所述处理器执行时实现如第一方面所述的信令流数据处理方法或第二方面所述的位置信息服务方法的步骤。

本申请实施例采用的上述至少一个技术方案能够达到以下有益效果：

本申请实施例提供的信令流数据处理方法、位置信息服务方法及电子设备中，流数据处理框架在获取到待处理的信令数据时，可基于预设的全量号码位置哈希表HTable对信令数据进行处理，如根据信令数据中包括的位置标识和时间信息对HTable中对应的位置元组进行更新，使得HTable始终保存有用户号码的最新信息，从而解决在供后续各种应用进行数据查询、调用时数据批处理环节繁多、时效性差、无法达到持续效果、耗时不稳定等问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请一示例性实施例提供的一种信令流数据处理方法的流程示意图。

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

图3为本申请一示例性实施例提供的一种位置信息服务方法的流程示意图。

图4为本申请一示例性实施例提供的电子设备的结构示意图。

具体实施方式

为使本申请的目的、技术方案和优点更加清楚，下面将结合本申请具体实施例及相应的附图对本申请技术方案进行清楚、完整地描述。显然，所描述的实施例仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

如图1所示，为本申情的一示例性实施例提供的信令流数据处理方法的流程示意图，该信令流数据处理方法可以由电子设备执行，具体可以由安装于电子设备上的软件和/或硬件执行，如流数据处理框架等，该流数据处理框架作为计算引擎，可支持多线程并行处理，且其计算复杂度可降低至O(1)，由此实现对信令数据的高效、实时处理。可选地，电子设备可以是分布式集群中的服务器，如运营商服务器等。本实施例给出的信令流数据处理方法至少可以包括如下步骤。

S110，按照时序持续获取待处理的信令数据。

其中，时序可以是基于毫秒、秒、分等时间单元确定。信令数据中可以包括第一用户号码、第一时间信息、第一位置标识及其他字段信息等，第一用户号码可以但不限于是手机号码等，第一位置标识可以但不限于是全球小区识别码(Cell Global Identifier，CGI)，即第一用户号码所在的小区(或基站等)编码，第一时间信息可以指用户终端上的最新的信令业务发生时间。

示例性地，本实施例给出的信令数据可以如表1所示。

表1

作为一种实现方式，S110中的获取待处理的信令数据可以包括：流数据处理框可以从分布式消息队列(如Kafka等)中消费待处理的信令流数据，其中，分布式消息队列中的待处理的信令流数据可以由网络设备采集汇聚得到，或者，信令流数据还可以由位于行政区域内的基站直接上报得到，本实施例中，行政区域可以是省级行政区、市级行政区、县级行政区等。

本实施例中，由于采用Kafka等分布式消息队列对基站上报的信令数据进行集中汇聚、共享，因此，即便基站在单位时间内上报的信令数量暴增导致计算负荷饱和，本实施例也可通过Kafka对暴增信令数据起到缓冲作用，从而确保信令数据的连续性。此外，如果流数据处理框架计算负荷超饱和，如Kafka中积压的信令数据的数量超过阈值，流数据处理框架还可在尽可能确保数据连续性的前提下，丢弃部分积压的信令，使得信令数据的处理(实时位置缓存)可以迅速回归到正常运行状态。

需要说明的是，在相关技术中，由于信令数据拍照(采样)频率为几分钟，且只取一个周期内每个用户号码最后的终端位置，一旦用户终端高速穿越目标区域时，则可能会出现捕捉不到信令数据，而出现漏采样现象，如果目标区域范围越小，终端移动速率越大，漏采样现象越明显。对此，本申请中基于Kafka和流数据处理框架和分布式键值缓存对基站实时上报的信令数据进行实时处理，能够有效避免前述相关技术中存在的信令漏采样问题，有效确保了位置轨迹数据的完整和连续，为运营商等大数据应用内提供了高速精准的数据支持。

S120，根据第一用户号码对预设的全量号码位置哈希表(HTable)进行哈希寻址。

其中，HTable中保存有以第二用户号码为键的位置元组，每个位置元组中包括与第二用户号码对应的第二时间信息和第二位置标识，需要理解的是，前述的第一用户号码、第二用户号码中的“第一”、“第二”仅是用于区分，便于描述，并无实质含义。

本实施例中，HTable/Hset可以保存在分布式键值内存数据库中(如REDIS)，在此不做限制。另外，HTable的实际形式可根据需求进行灵活设计，例如，作为一种可能的实现方式，HTable可以以表2的形式预设在REDIS缓存数据库中。

表2

S130，在HTable中存在与第一用户号码匹配的第二用户号码，且目标位置元组中的第二位置标识与第一位置标识相同、第二时间信息小于第一时间信息的情况下，将与第一用户号码匹配的第二用户号码对应的位置元组中的第二时间信息更新为第一时间信息。

其中，目标位置元组是与第一用户号码匹配的第二用户号码对应的位置元组。另可以理解的是，前述的第二时间信息小于第一时间信息是指第二时间信息早于第一时间信息，例如，假设第二时间信息为2020年11月1日10：00，第一时间信息为2020年11月5日14：00，那么，可判定第二时间信息小于第一时间信息。

前述方法实施例中，流数据处理框架基于预设的HTable对信令数据进行处理，如对保存在HTable中的位置元组中的时间信息和位置标识进行实时刷新，使得HTable中始终保存着用户号码的最新信息，以为后续各种应用进行数据查询、调用提供可靠准确的数据支持。同时，本实施例中采用哈希寻址的方式进行用户号码的查询，还可提高查询效率以及查询数据的实时性。

应注意，在根据第一用户号码对预设的HTable进行哈希寻址时，除前述S130中的HTable更新示例之外，作为一种可能的实现方式，方法还可包括如下两种更新示例。

(1)在HTable中存在与第一用户号码匹配的第二用户号码，且目标位置元组中的第二位置标识与第一位置标识不相同、第二时间信息小于第一时间信息的情况下，根据信令数据中的第一位置标识和第一时间信息对目标位置元组进行更新。

可以理解，在此实现方式中，由于第二位置标识与第一位置标识不相同，可判定信令数据对应的终端等发生了位置变化，因此，需要根据信令数据中包括的第一位置标识和第一时间信息对目标位置元组进行更新，由此，确保HTable中保存的用户号码的最新信息。

(2)在HTable中不存在与第一用户号码匹配的第二用户号码的情况下，以第一用户号码为键，在HTable中创建位置元组。

其中，HTable中不存在与第一用户号码匹配的第二用户号码，可判定HTable中未记载第一用户号码的相关信息，因此，为了确保HTable中保存信息的全面性，可基于第一用户号码在HTable创建位置元组，该位置元组包括第一位置标识和第一时间信息。

进一步，除了前述的以用户号码为键构建的HTable之外，本实施例提供的信令流数据处理方法，还可包括如下示例1和示例2中所述的实现方式。

示例1，在HTable中存在新增号码键的情况下，根据新增号码键对应的位置信息，将新增号码键对应的用户号码同步更新至预设的全量位置号码哈希集合HSet中。

示例2，在HTable中存在位置标识更新的情况下，根据更新的位置标识，将号码信息同步更新至预设的全量位置号码哈希集合(HSet)中。其中，HSet中保存有以位置标识为键形成的多个位置集合，每个位置集合中包括零或多个一个号码元组，每个号码元组可以是[用户号码]或[用户号码，时间信息]，也就是，号码元组可以包括用户号码和时间信息。应注意的是，以CGI为键的HSet中，每个CGI对应的位置集合中都存储着当前基站下最新的用户号码(以业务发生为基准)。

一种实现方式中，HSet的实现形式可如图表3所示。

表3

示例1的实现方式中，前述将新增号码键对应的用户号码同步更新至预设的全量位置号码哈希集合HSet中的过程可以通过以下(1)或(2)实现，从而确保新增号码在HSet中的同步新增。

(1)在HSet中不存在以第一位置标识为键的号码集合的情况下，以第一位置标识为键、以第一用户号码为集合元素，在HSet中创建一个号码集合，以将位置标识键补全至HSet中。

(2)在HSet中存在以第一位置信息为键的号码集合、但号码集合中不存在第一用户号码为元素的情况下，以第一用户号码添加到号码集合，以将位置标识及其下附着的最新号码信息同步至HSet中。

示例2的实现方式中，前述将位置标识变更的号码同步更新至预设的全量位置号码哈希集合HSet中的过程还可以包括：在HSet中分别以变更前的第二位置标识为来源键、第一位置标识为目标键，将第一用户号码从来源键对应的号码集合中转移到目标键对应的号码集合(通过REDIS的SMOVE指令)，以将第一位置标识及其下附着的号码信息同步至HSet，由此可以确保号码位置标识变化在HSet中的同步变更。

前述实现方式中，通过对HSet的更新(如号码的同步新增或同步变更)，既能确保HTable中的信息与HSet中数据的同步性，还可以使得位置集合中存储的当前小区或基站等下的用户号码的时间信息为最新时间，以为后续的数据调用提供高速精准的支撑。

进一步，作为一种可能的实现方式，在HSet中存在信息变更的情况下，可将变更的信息按预定规格输出至预设的第一级位置变更消息队列中，形成用户号码位置变更日志，或者，再对变更的信息按用户号码和位置标识进行分区，输出至后级的多条消息队列，供后续按需利用。

其中，预定规格可根据实际需求设定，例如，预定规格可以包括：[用户号码，来源位置标识，目标位置标识，第一时间信息]，其中，来源位置标识可以为空值或非空值，本实施例在此不做限制。

需要注意的是，在前述给出的各方法实施例中，经流数据处理框架处理后的中间数据以及HTable、HSet等可以保存在Redis中，供后续各种应用通过其它接口查询出目标区域的号码。其中，基于Redis副本复制机制，可以实现读写分离以将查询操作的计算隔离，通过适当调增整个计算集群的处理节点数，即可缩减查询处理耗时。

另外，实际应用中，还可将Redis中所涉及的所有读操作封装到一个专用位置数据源服务中，并通过OPENAPI平台进行开放，根据应用层需要发起对REDIS实时位置缓存的请求，以文件形式输出区域号码快照[CGIs|MOBILENUMs]，或以消息形式输出区域号码变更日志[MOBILENUM|OldCGI|NewCGI|CurTime]等，本实施例对此不做限制。

基于前述各实施例给出的信令流数据处理方法，下面结合图2对其实现流程进行再次说明，内容如下。

S201，按照时序持续获取待处理的信令数据，信令数据中包括第一用户号码、第一时间信息以及第一位置标识。

S202，根据第一用户号码对预设的HTable进行哈希寻址。

S203，HTable中是否存在与第一用户号码匹配的第二用户号码，若存在，则执行S204，反之，则执行S209。

S204，目标位置元组中的第二位置标识与第一位置标识是否相同，若相同，则执行S205，反之，则执行S207。

S205，目标位置元组中的第二时间信息是否小于第一时间信息，若小于，则执行S206。

S206，将与第一用户号码匹配的第二用户号码对应的位置元组中的第二时间信息更新为第一时间信息。

S207，目标位置元组中的第二时间信息是否小于第一时间信息，若小于，则执行S208。

S208，根据信令数据中的第一位置标识和第一时间信息对目标位置元组进行更新。

S209，以第一用户号码为键，在HTable中创建位置元组。

S210，在HTable中存在新增号码键的情况下，根据新增号码键对应的位置信息，将新增号码键对应的用户号码同步更新至预设的全量位置号码哈希集合HSet中；

或者，在所述HTable中存在位置标识更新的情况下，根据更新的所述位置标识，将号码信息同步更新至预设的全量位置号码哈希集合HSet中。

S211，在HSet中存在信息变更的情况下，将变更的信息按预定规格输出至预设的第一级位置变更消息队列中，形成用户号码位置变更日志，或者，再对所述变更的信息按用户号码和位置标识进行分区，输出至后级的多条消息队列，供后续按需利用。

需要说明的是，关于前述S201-S211的实现过程可参照前述各方法实施例中的相关描述，为避免重复，本实施例在此不再赘述。另外，本实施例给出的信令流数据处理可以包括前述流程S201-S211的全部或部分步骤，本实施例在此不做限制。

在前述给出的信令流数据处理方法中，结合以用户号码为键形成的HTable以及以位置标识为键形成的HSet对待处理的信令数据进行处理，能够进一步为后续各种应用的数据查询、调用提供快速精准的数据支持，且具有较高的查询效率。同时，本实施例基于HTable和HSet实现对每一条信令数据的处理，能捕获到更丰富的用户的位置变化信息，避免了可能由于用户终端的高速移动导致的信令位置数据漏采样问题，确保了信令位置数据的全面性。

此外，本实施例中基于流数据处理框架、分布式键值缓存、分布式消息队列实现的信令流数据处理方法，能够有效利用流式处理架构、内存计算、并行计算技术，确保信令流数据处理的实时效果。例如，由于都是内存计算，除了消费Kafka和输出请求结果给后续环节，没有磁盘IO。同时，本实施例中算法处理逻辑可通过对号码分区实现高并行处理，Kafka、流数据处理框架、Redis都是部署为易扩展、高吞吐的分布式集群，整个信令处理环节可实现极高的实时性。

进一步，基于前述各实施例给出的信令流数据处理方法，如图3所示，本申请一示例性实施例还提供一种位置信息服务方法，该方法包括如下步骤。

S310，根据预设的HTable、HSet以及位置变更消息队列，执行预定操作，以及推送执行结果给应用端。

其中，预定操作包括以下(1)-(5)任意一项。

(1)在获取到指定用户号码的情况下，以指定用户号码为输入参数查询HTable，得到与指定用户号码对应的最新位置信息并输出。

(2)在获取到指定位置标识的情况下，以指定位置标识为输入参数查询HSet，得到与指定位置标识所附着的用户号码信息并输出。

一种实现方式中，当需要计算获取某个指定区域中的当前用户号码时，可以通过Redis的SMEMBERS命令对Redis中的HSet进行哈希寻址，从而输出对应的查询结果。

(3)在获取到指定位置标识集合的情况下，通过订阅消费和过滤处理位置变更消息队列的日志流，持续不断取得漫入指定区域中的用户号码，指定区域是指定位置标识集合对应的区域。

作为一种可能的实现方式，可以订阅发布方式输出终端位置变更日志，使应用层能实现流处理，并持续不断捕获区域外漫入的目标用户号码。例如，在热力图应用中，应用层通过订阅终端位置变更日志(即全量位置变更日志)，并在其中的视图子层维护一个【CGI|实时用户号码数】缓存模型，即可根据变更的信息直接高速渲染图层，实现秒级变化的效果。

(4)在获取到指定用户号码的情况下，通过订阅消费和过滤处理位置变更消息队列的日志流，得到与指定用户号码对应的用户时空轨迹。

(5)在获取到指定区域对应的位置标识的情况下，以指定位置标识为输入参数查询HSet，统计得到位于指定区域的用户数。

其中，前述(1)-(5)中，HTable中保存有以用户号码为键形成的多个位置元组，每个位置元组中包括与用户号码对应的最新位置标识和时间信息；HSet中保存有以位置标识为键形成的不同号码集合，每个号码集合中保存有位置标识对应小区当前所附着的用户号码信息，关于HTable和HSet的详细描述可参照前述相关描述，为避免重复，在此不再赘述。

基于前述方法实现的位置数据信息服务中，可实现统一、集中的业务管理，能够确保位置信息服务具有较高的安全性。例如，本实施例可允许用户通过GIS地图定义目标地理区域，然后以极低时延向进入指定区域的人群持续地推送短信，使得整体延迟降低到最低，如最快可达到30秒内。

除前述的位置信息服务之外，下面以实时靶向短信业务场景为例对本实施例给出的位置信息服务进行介绍。

(1)在需要对指定区域中的用户号码持续发送短信时(实现类似基站短信的效果)，可基于HSet获取位于当前指定区域中的全量用户号码，具体为：短信应用匹配出指定区域的CGI后，通过封装了前述数据源服务的API提交，数据源服务程序将接收到的指定区域的CGI，作为键对HSet进行遍历，得到位于指定区域中的用户号码。

应注意的是，对于新漫入到指定区域的用户号码，可通过以下两种方式获取。一种是根据计算资源的能力和实际业务需求，设置查询频率(例如30秒/次)，并以轮询的方式周期性地获取指定区域内的全量实时号码，再结合之前已获取的用户号码进行去重过滤处理，得到指定区域中的全量用户号码。另一种是为应用侧订阅区域号码变更日志，并通过流处理的方式直接获取新漫入的用户号码，然后再进行去重过滤处理，得到指定区域中的全量用户号码。

前述两种方式中，第一种主要用于中间层的接口统一开放平台未部署实现消息化(如WebSocket)的场景，第二种适合绝大多数应用直连服务端或接口平台支持消息化的场景。

(2)对前述获取的指定区域中的全量用户号码，可根据应用侧的活动参数配置对全量用户号码进行处理，如去重、频次控制(即多长时间允许重复发送一次)、黑白名单、标签筛选、归属地筛选、常驻地号码筛选等，形成每个活动的目标号码流输出到发送队列中。

(3)将发送队列中的用户号码通过CMPP协议提交至外部的短信网关，并按照预定规则实现短信发送，该预定规则包括控制发送时间、周期、发送暂停/继续/终止、关联短信内容等，本实施例对此不做限制。

在前述(1)-(3)中，为保证实时性效果，用户号码的处理可基于Redis实现。

请参阅图4，为根据一示例性实施例提供的一种电子设备40的框图，该电子设备40可至少包括处理器41，用于存储处理器41可执行指令的存储器42。其中，处理器41被配置为执行指令，以实现如上述实施例中的信令流数据处理的方法或信息推送方法的全部步骤或部分步骤。

处理器41、存储器42之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。

其中，处理器41用于读/写存储器中存储的数据或程序，并执行相应地功能。

存储器42用于存储程序或者数据，如存储处理器41可执行指令。该存储器42可以是，但不限于，随机存取存储器(Random Access Memory，RAM)，只读存储器(Read OnlyMemory，ROM)，可编程只读存储器(Programmable Read-Only Memory，PROM)，可擦除只读存储器(Erasable Programmable Read-Only Memory，EPROM)，电可擦除只读存储器(Electric Erasable Programmable Read-Only Memory，EEPROM)等。

进一步，作为一种可能的实现方式，电子设备40还可包括电源组件、多媒体组件、音频组件、输入/输出(I/O)接口、传感器组件以及通信组件等。

电源组件为电子设备40的各种组件提供电力。电源组件可以包括电源管理系统，一个或多个电源、以及其他与为电子设备40生成、管理和分配电力相关联的组件。

多媒体组件包括在电子设备40和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件包括一个前置摄像头和/或后置摄像头。当电子设备40处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件被配置为输出和/或输入音频信号。例如，音频组件包括一个麦克风(MIC)，当电子设备40处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器42或经由通信组件发送。在一些实施例中，音频组件还包括一个扬声器，用于输出音频信号。

I/O接口为处理组件和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启动按钮和锁定按钮。

传感器组件包括一个或多个传感器，用于为电子设备40提供各个方面的状态评估。例如，传感器组件可以检测到电子设备40的打开/关闭状态，组件的相对定位，例如组件为电子设备40的显示器和小键盘，传感器组件还可以检测电子设备40或电子设备40一个组件的位置改变，用户与电子设备40接触的存在或不存在电子设备40方位或加速/减速和电子设备40的温度变化。传感器组件可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件被配置为便于电子设备40和其他设备之间有线或无线方式的通信。电子设备40可以接入基于通信标准的无线网络，如WiFi，运营商网络(如2G、3G、4G或5G)，或它们的组合。在一个示例性实施例中，通信组件经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，电子设备40可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

应当理解的是，图4所示的结构仅为电子设备40的结构示意图，该电子设备40还可包括比图4中所示更多或者更少的组件，或者具有与图4所示不同的配置。图4中所示的各组件可以采用硬件、软件或其组合实现。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器42，上述指令可由电子设备40的处理器41执行以完成上述信令流数据处理方法或信息推送方法。例如，非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

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

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

Claims (10)

1.一种信令流数据处理方法，其特征在于，应用于流数据处理框架，所述方法包括：

按照时序持续获取待处理的信令数据，所述信令数据中包括第一用户号码、第一时间信息以及第一位置标识；

根据所述第一用户号码对预设的全量号码位置哈希表HTable进行哈希寻址；其中，所述HTable中保存有以第二用户号码为键的位置元组，每个所述位置元组中包括与所述第二用户号码对应的第二时间信息和第二位置标识；

在所述HTable中存在与所述第一用户号码匹配的第二用户号码，且目标位置元组中的第二位置标识与所述第一位置标识相同、第二时间信息小于所述第一时间信息的情况下，将与所述第一用户号码匹配的第二用户号码对应的位置元组中的第二时间信息更新为所述第一时间信息，其中，所述目标位置元组是与所述第一用户号码匹配的第二用户号码对应的位置元组。

2.根据权利要求1所述的方法，其特征在于，根据所述第一用户号码对预设的全量号码位置哈希表HTable进行哈希寻址的步骤之后，所述方法还包括：

在所述HTable中存在与所述第一用户号码匹配的第二用户号码，且所述目标位置元组中的第二位置标识与所述第一位置标识不相同、第二时间信息小于所述第一时间信息的情况下，根据所述信令数据中的第一位置标识和第一时间信息对所述目标位置元组进行更新。

3.根据权利要求1所述的方法，其特征在于，根据所述第一用户号码对预设的全量号码位置哈希表HTable进行哈希寻址的步骤之后，所述方法还包括：

在所述HTable中不存在与所述第一用户号码匹配的第二用户号码的情况下，以所述第一用户号码为键，在所述HTable中创建位置元组，该位置元组包括所述第一位置标识和第一时间信息。

4.根据权利要求2或3所述的方法，其特征在于，所述方法还包括：

在所述HTable中存在位置标识更新的情况下，根据更新的所述位置标识，将号码信息同步更新至预设的全量位置号码哈希集合HSet中。

5.根据权利要求2或3所述的方法，其特征在于，所述方法还包括：

在所述HTable中存在新增号码键的情况下，根据所述新增号码键对应的位置信息，将所述新增号码键对应的用户号码同步更新至预设的全量位置号码哈希集合HSet中。

6.根据权利要求5所述的方法，其特征在于，根据所述新增号码键对应的位置信息，将所述新增号码键对应的用户号码同步更新至预设的全量位置号码哈希集合HSet中，包括：

在所述HSet中不存在以所述第一位置信息为键的号码集合的情况下，以所述第一位置标识为键、以所述第一用户号码为集合元素，在所述HSet中创建一个号码集合，以将所述位置标识键补全至所述HSet中；

或者，

在所述HSet中存在以所述第一位置信息为键的号码集合、但该号码集合中不存在第一用户号码为元素的情况下，以所述第一用户号码添加到所述号码集合，以将所述位置标识及其下附着的最新号码信息同步至所述HSet中。

7.根据权利要求5所述的方法，其特征在于，根据所述新增号码键对应的位置信息，将所述新增号码键对应的用户号码同步更新至预设的全量位置号码哈希集合HSet中，包括：

在所述HSet中分别以变更前的第二位置标识为来源键、第一位置标识为目标键，将所述第一用户号码从来源键对应的号码集合中转移到目标键对应的号码集合，以及将所述第一位置标识及其下附着的号码信息同步至所述HSet。

8.根据权利要求6或7所述的方法，其特征在于，所述方法还包括：

在所述HSet中存在信息变更的情况下，将变更的信息按预定规格输出至预设的第一级位置变更消息队列中，形成用户号码位置变更日志，或者，再对所述变更的信息按用户号码和位置标识进行分区，输出至后级的多条消息队列，供后续按需利用。

9.一种位置信息服务方法，其特征在于，包括：

根据预设的全量号码位置哈希表HTable、全量位置号码哈希集合HSet以及位置变更消息队列，执行以下任意一项，以及推送执行结果给应用端；

在获取到指定用户号码的情况下，以所述指定用户号码为输入参数查询所述HTable，得到与所述指定用户号码对应的最新位置信息并输出；

在获取到指定位置标识的情况下，以所述指定位置标识为输入参数查询所述HSet，得到与所述指定位置标识所附着的用户号码信息并输出；

在获取到指定位置标识集合的情况下，通过订阅消费和过滤处理位置变更消息队列的日志流，持续不断取得漫入指定区域中的用户号码，所述指定区域是所述指定位置标识集合对应的区域；

在获取到指定用户号码的情况下，通过订阅消费和过滤处理位置变更消息队列的日志流，得到与所述指定用户号码对应的用户时空轨迹；

在获取到指定区域对应的位置标识的情况下，以所述指定位置标识为输入参数查询所述HSet，统计得到位于所述指定区域的用户数；

其中，所述HTable中保存有以用户号码为键形成的多个位置元组，每个所述位置元组中包括与所述用户号码对应的最新位置标识和时间信息；

所述HSet中保存有以位置标识为键形成的不同号码集合，每个所述号码集合中保存有位置标识对应小区当前所附着的用户号码信息。

10.一种电子设备，其特征在于，包括处理器、存储器及存储在所述存储器上并可在所述处理器上运行的计算机程序，所述计算机程序被所述处理器执行时实现如权利要求1至8中任一项所述的信令流数据处理方法，或者所述计算机程序被所述处理器执行时实现如权利要求9所述的位置信息服务方法。

Images