生物识别数据的统一管理方法及服务端与流程

1.本发明属于数据管理技术领域，具体涉及一种生物识别数据的统一管理方法及服务端。


背景技术：

2.对于生命体征数据平台的输入数据来说，往往存在有多种输入方式，比如restful api，文件批量导入等。
3.这些输入方式，对数据的结构、格式和类型都有明确的定义。当输入新的体征数据时，就要对现有的结构、格式和类型从新定义，其中，如果整个设计是一个所有体征类型共享的接口，就需要对已有的结构、格式和类型进行修改更新。如果设计是每个体征类型分别单独的接口，就需要新设计一个单独的接口来实现。
4.由于不同类设备采集的体征数据，其结构、格式和类型都会有所不同，所以管理方式也不一致，因此对生命体征数据平台集成各类设备的数据进行管理带来了一定的挑战：每当有新的设备采集体征数据时，都要根据其输入的新体征数据进行开发和测试，从而造成了额外的开发、测试及时间周期。即现有技术对于生命体征数据的管理方法存在拓展性较差的问题。


技术实现要素：

5.本发明的目的是提供一种生物识别数据的统一管理方法及服务端，以提高生命体征数据的扩展性。
6.为了解决上述技术问题，本发明公开了一种生物识别数据的统一管理方法，包括以下步骤：
7.接收客户端上传的事件体征数据，所述事件体征数据为客户端将体征设备采集的生物识别数据按照事先约定的事件数据格式转化而成；
8.将所述事件体征数据中对应生物识别数据的事件内容保留原格式存储在数据库中。
9.进一步地，所述事件体征数据包括固定的数据属性、根据体征设备所采集的生物识别数据所转化而成的事件内容以及与所述生物识别数据对应的上下文数据。
10.进一步地，所述事件内容可根据生物识别数据的体征类型不同而定义。
11.进一步地，所述将所述事件体征数据中对应生物识别数据的事件内容保留原格式存储在数据库中具体为：
12.将所述事件体征数据转换成数据库所支持的数据格式，其中，所述事件体征数据中对应生物识别数据的事件内容以原格式存储在数据库中。
13.进一步地，所述接收客户端上传的事件体征数据具体为：
14.接收并验证客户端上传的事件体征数据，在验证正确之后将所述事件体征数据推送至消息队列；
15.从消息队列中提取客户端上传的事件体征数据。
16.为了解决上述技术问题，本发明公开了一种生物识别数据的统一管理服务端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现以下步骤：
17.接收客户端上传的事件体征数据，所述事件体征数据为客户端将体征设备采集的生物识别数据按照事先约定的事件数据格式转化而成；
18.将所述事件体征数据中对应生物识别数据的事件内容保留原格式存储在数据库中。
19.进一步地，所述事件体征数据包括固定的数据属性、根据体征设备所采集的生物识别数据所转化而成的事件内容以及与所述生物识别数据对应的上下文数据。
20.进一步地，所述事件内容可根据生物识别数据的体征类型不同而定义。
21.进一步地，所述将所述事件体征数据中对应生物识别数据的事件内容保留原格式存储在数据库中具体为：
22.将所述事件体征数据转换成数据库所支持的数据格式，其中，所述事件体征数据中对应生物识别数据的事件内容以原格式存储在数据库中。
23.进一步地，所述接收客户端上传的事件体征数据具体为：
24.接收并验证客户端上传的事件体征数据，在验证正确之后将所述事件体征数据推送至消息队列；
25.从消息队列中提取客户端上传的事件体征数据。
26.本项发明将体征设备采集的生物识别数据按照事先约定的事件数据格式转化而成为事件体征数据，使得体征数据输入到云端是以事件的数据结构进行输入，从而在结构上可以灵活包含各类不同体征数据的统一格式，无需针对不同类型的体征数据进行专门的开发适配，以提高生命体征数据的扩展性。
附图说明
27.图1为本发明实施例的生物识别数据的统一管理方法的流程示意图；
28.图2为本发明实施例的生物识别数据的统一管理方法与现有技术在数据处理过程中的区别示意图；
29.图3为本发明实施例的生物识别数据的统一管理方法中服务端与客户端的交互示意图；
30.图4为本发明实施例的生物识别数据的统一管理服务端的结构示意图。
31.1、生物识别数据的统一管理服务端；2、存储器；3、处理器。
具体实施方式
32.下面通过实施例对本发明做进一步的详细说明，以令本领域技术人员参照说明书文字能够据以实施。
33.应当理解，本文所使用的诸如“具有”，“包含”以及“包括”术语并不排除一个或多个其它元件或其组合的存在或添加。
34.实施例一
35.如图1至图3所示，生物识别数据的统一管理方法，包括以下步骤：
36.s1、接收客户端上传的事件体征数据，事件体征数据为客户端将体征设备采集的生物识别数据按照事先约定的事件数据格式转化而成；
37.在本实施例中，生物识别数据即为体征数据，由此，本实施例中的事件体征数据包括固定的数据属性、根据体征设备所采集的生物识别数据所转化而成的事件内容以及与生物识别数据对应的上下文数据。
38.其中，固定的数据属性即对于不同类型的体征设备都具有的共性部分，在本实施例中，固定的数据属性包括但不限于：设备id((identity document，身份标识号)、事件类型、数据采集时间、固件版本、硬件版本、设备电池电量
……
。其中，事件类型即为体征数据的类型，比如体温、心电、血压、血氧等。
39.其中，事件内容可根据生物识别数据的体征类型不同而定义，且可以用非事先约定的name/value对(名/值对，一种为映射关系的数据结构)来表述，比如：
40.(1)、体温是：“temperature“：36.6；
41.(2)、血压是：“systolic”:120；“diastolic”:80；
42.(3)、心电是：“ecg”:[10,20,10,5,0,
……
]。
[0043]
其中，temperature即为体温；systolic为收缩压，其英文全称为systolic pressure，此处为选首个英文单词进行表示；diastolic为舒张压，其英文全称为diastolic blood pressure/dp，此处为选首个英文单词进行表示；ecg为英文全程electrocardiogram的英文缩写，意为心电图。
[0044]
其中，上下文数据是根据事件类型进行灵活编制，以适应不同类型的体征数据。在本实施例中，上下文数据也是用非事先约定的name/value对来表述。
[0045]
如图3所示，对于体征数据来说，是从移动设备的客户端到云数据的服务端，对于客户端来说，主要有如下步骤：
[0046]
在客户端中，按照事先约定的事件数据格式，把获取的体征设备上的体征数据，用json((javascript object notation，js对象简谱，它是一种轻量级的数据交换格式)的形式准备好。
[0047]
客户端把准备好的json格式的事件体征数据，通过云端提供的restful(representational state transfer，一种网络应用程序的设计风格和开发方式)数据接口，推送到云端的接口网关。在此过程中事件数据一直保持json格式不变。
[0048]
其中，客户端将json格式的事件体征数据推送到云端的接口网关所采用的输入形式也可以为csv(comma-separated values，逗号分隔值)/excel文件等等。
[0049]
对于服务端来说，步骤s1接收客户端上传的事件体征数据具体为：
[0050]
s11、接收并验证客户端上传的事件体征数据，在验证正确之后将事件体征数据推送至消息队列；
[0051]
即服务端的接口网关收到json格式的事件体征数据，进行数据格式的验证，验证无误后，仍然以json的形式推送进入云端的消息队列；
[0052]
s12、从消息队列中提取客户端上传的事件体征数据。
[0053]
即服务端的事件体征数据在消息队列中被提取出来准备进行消费。
[0054]
s2、将事件体征数据中对应生物识别数据的事件内容保留原格式存储在数据库
中。
[0055]
在本实施例中，步骤s2具体为：
[0056]
将事件体征数据转换成数据库所支持的数据格式，其中，事件体征数据中对应生物识别数据的事件内容以原格式存储在数据库中。
[0057]
即对于服务端，将从消息队列中提取出来的事件体征数据进行数据格式的轻度转换，从json转换成可以进入nosql(not only sql，非关系型的数据库)数据库的形式，以保存到数据中。这个转换只是一个简单的从json到数据库表的转换，其中涵盖体征数据的“event data”,直接保留json格式，放入数据库。
[0058]
而对于nosql数据库中的数据，可以被查询，比如按设备id查询，查询结构可以直接以“event data”的形式返回到客户端。
[0059]
其中，数据库表的设计举例如下：
[0060][0061]
其中，设备id、事件类型、采集时间、设备电量、硬件版本、固件版本即对应上述的数据属性，是将json格式的数据转换成nosql数据库的形式进行保存，而事件体征数据还是保留了json格式，由此在查询时可以直接返回。
[0062]
从上表可以看到，具体的事件内容，可以根据体征数据的类型不同，进行自适配，由此完全可以随时把新的体征类型纳入进来。
[0063]
由此，结合图2可知，本实施例的数据管理与现有技术的区别，从数据的导入，数据处理通道(pipeline),以及数据服务进行说明如下：
[0064]
(1)数据导入：本实施例的技术方案和现有技术相比，本实施例的技术方案因为采用了一个比较灵活的事件数据形式来表达体征数据(json),所以可以随时接入新的未知的体征数据，而现有技术的数据形式都是固定的，所以新的未知的体征数据需要数据接入端进行更新和调整。
[0065]
(2)数据通道：数据导入云端之后，会以体征事件数据的格式，保存在云端的数据库中，接受查询和数据归档这些操作。同时，数据本身，会经过一些清理和处理，被放入到对应数据服务平台的数据湖中，在数据湖中，体征数据会以一个统一模式(unified schema)体现，来为数据分析和算法提供基础数据服务。而现有技术还是采用固定形式进行存储，不利于后续的数据分析等等。
[0066]
(3)数据服务：事件数据，或者数据湖中的统一数据，都可以为其他应用和第三方提供各类数据服务，包括规则引擎、高级查询、商业智能和人工智能等应用。唯灵的设计，受益于事件数据和统一的模式，相对于现有技术来说，能提供更好的服务给第三方应用。
[0067]
由此，当基于服务端开发出的生命体征数据服务平台，对于新的生命体征数据，以事件和结构化的形式能够直接接入，无需针对不同类型的体征数据进行专门的开发适配，以提高生命体征数据的扩展性。
[0068]
实施例二
[0069]
如图2所述，生物识别数据的统一管理服务端1，包括存储器2、处理器3及存储在存储器2上并可在处理器3上运行的计算机程序，所述处理器3执行所述计算机程序时实现上述实施例一中的步骤。
[0070]
尽管本发明的实施方案已公开如上，但其并不仅仅限于说明书和实施方式中所列运用，它完全可以被适用于各种适合本发明的领域，对于熟悉本领域的人员而言，可容易地实现另外的修改，因此在不背离权利要求及等同范围所限定的一般概念下，本发明并不限于特定的细节和这里示出与描述的实施例。