CN110674231A - 一种面向数据湖的用户id集成方法和*** - Google Patents

一种面向数据湖的用户id集成方法和*** Download PDF

Info

Publication number
CN110674231A
CN110674231A CN201910952703.7A CN201910952703A CN110674231A CN 110674231 A CN110674231 A CN 110674231A CN 201910952703 A CN201910952703 A CN 201910952703A CN 110674231 A CN110674231 A CN 110674231A
Authority
CN
China
Prior art keywords
user
data
event
attributes
integration
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201910952703.7A
Other languages
English (en)
Inventor
阮备军
朱建秋
钱肖鲁
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Shanghai Zhi Zi Information Polytron Technologies Inc
Original Assignee
Shanghai Zhi Zi Information Polytron Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Shanghai Zhi Zi Information Polytron Technologies Inc filed Critical Shanghai Zhi Zi Information Polytron Technologies Inc
Priority to CN201910952703.7A priority Critical patent/CN110674231A/zh
Publication of CN110674231A publication Critical patent/CN110674231A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/28—Databases characterised by their database models, e.g. relational or object models
    • G06F16/284—Relational databases
    • G06F16/285—Clustering or classification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution
    • G06F16/24564—Applying rules; Deductive queries
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2457—Query processing with adaptation to user needs
    • G06F16/24578—Query processing with adaptation to user needs using ranking
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2458—Special types of queries, e.g. statistical queries, fuzzy queries or distributed queries
    • G06F16/2462—Approximate or statistical queries

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Databases & Information Systems (AREA)
  • Data Mining & Analysis (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computational Linguistics (AREA)
  • Probability & Statistics with Applications (AREA)
  • Fuzzy Systems (AREA)
  • Mathematical Physics (AREA)
  • Software Systems (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

本发明公开了一种面向数据湖的用户ID集成方法和***，属于互联网技术领域。该用户ID集成方法和***适用于基于数据湖的各类大数据平台建设。具体的，本发明实施例采用了通用的数据结构、计算过程和集成接口，大幅度降低了针对特定的问题手工定制“用户ID集成”程序、数据结构和计算程序的人力成本和失误风险。另外，本发明实施例从消息***读入来自多个数据源的，包含用户ID关联信息的记录，把属于同一用户的不同标识或者ID，按照提前设定的规则，自动动态关联起来，赋予唯一的全局标识，同时把ID间的关联变化通过消息***实时反馈给应用***。后者依赖这些信息，关联分散的用户数据，实现数据湖上的用户数据集成。

Description

一种面向数据湖的用户ID集成方法和***
技术领域
本发明涉及互联网技术领域，具体是一种面向数据湖的用户ID集成方法和***。
背景技术
海量的访客、用户或者客户(后续统称“用户”)数据让关系数据库时代的数据仓库技术变得捉衿见肘。针对此问题，数据湖(Data Lake)方案采用了一种全新的大数据管理和应用方法，提倡先存储，后分析(应用)，降低数据整合和维护成本。基于Apache Hado op的分布式存储和计算集群是目前最流行的数据湖运行环境。遗憾的是，开发效率依旧差强人意。每个数据应用项目必须从头开始，效率太低，还是需要自动化某些关键工作，加速后期的各类数据分析和应用。
“用户标识集成”、“唯一标识用户”或者“统一标识用户”便是其中的一项关键工作。其主要内容是：需要把来自多个数据源的属于同一用户的不同标识(后续简称“用户身份标识(IDentity，ID)”)动态关联起来。后续工作可以根据这种统一的关联，再集成属于同一用户的数据。用户ID可以是用于识别设备的，譬如Web浏览器端设置在Cookie内的虚拟ID(访客ID、User-ID或者账户ID等)、苹果iOS的IDFA(Identifier For Adve rtisers，IDFA)、Android***的Android ID、设备的媒体访问控制(Medium Access Cont rol，MAC)地址和国际移动设备识别码(International Mobile Equipment Identity，IMEI)；用户ID也可以是识别线下个体和团体的，例如身份证号、护照号、手机号和座机号等；用户ID还可以是识别***账户的，例如微信、QQ、网站、APP和企业内部各类管理***的内部用户账号的ID。
传统用户ID集成的方法是：为每个企业手工定制一套针对应用的“用户ID集成”程序、数据结构和规则，然后在数据湖上计算和维护这些ID之间的关系。其中的开发和测试程序，费时费力，容易出错。当有新的用户ID类型加入时，必须修改程序和规则，然后重新测试和部署。此类基础工作迫切需要有一个适应基于数据湖计算的，具有通用的数据结构、计算过程和集成接口的用户ID集成方法或者***。
与此问题相关的是数字营销领域内的“跨媒体整合“和“跨屏识别“技术。它们解决的是如何跨越设备和媒体识别个体的问题，提高营销定位的精度。一般分成两步：首先采用各类方法(预定义规则或者机器学习技术)寻找和识别用户ID之间存在的关联；然后基于这些关联，统一标识用户。鉴于数字营销领域内用户数据的不完整性，它们重点关注在第一步，即如何在特定类型的数据中寻找和识别可能的ID关联，忽略了后续统一标识遇到的实际的技术问题和挑战，具体问题包括：
1.由于企业的数据是有差异的，ID关联约束也是不同的，故如何在统一标识算法中嵌入企业自定义的约束和规则？
2.ID间的关联会经常发生变化，基于机器学习模型预测的关系尤为如此。如何动态跟踪这些变化，调整统一标识？
3.“统一用户标识”如何在数据湖环境中为大数据应用，如数据仓库(Data Warehouse)、持续数据保护(Continuous Data Protection，CDP)和数据管理平台(Data Management Platform，DMP)等大数据应用，提供灵活的对接和集成方式，让应用程序能根据自己的特点，集成用户数据？
发明内容
本发明的目的在于提供一种面向数据湖的用户ID集成方法和***，以解决上述背景技术中提出的问题。
为实现上述目的，本发明实施例提供如下技术方案：
一种面向数据湖的用户ID集成方法，其包括以下步骤：
从数据湖中的一个或者多个数据源中采集原始用户数据，并构造ID事件；
将ID事件输入和存储在一个支持永久存储的第一分布式消息队列中；
从第一分布式消息队列中读取ID事件，生成ID联接记录，并更新ID图；
根据ID联接属性，从ID图中获取有效的ID联接记录；
针对有效的ID联接记录，获取ID图中的连通分量，并将获取的连通分量组成一个用户ID组，同时更新ID映射表；
将ID映射表中的用户ID与用户ID组的映射记录存储在一个支持永久存储的第二分布式消息队列中。
本发明实施例采用的一种优选方案，所述的ID事件包括数据来源标识、发生的时间、事件的类型和单一的用户ID。
本发明实施例采用的另一种优选方案，所述的ID事件包括数据来源标识、发生的时间、事件的类型和两个关联的用户ID。
本发明实施例采用的另一种优选方案，所述的ID联接属性包括多组来源属性，所述的来源属性包括数据来源ID、基于ID事件计算的统计指标以及数据源层面的生效状态，所述的数据源层面的生效状态判断两个用户ID之间的关联是否有效。
本发明实施例采用的另一种优选方案，所述的ID联接属性还包括全局属性，所述的全局属性包括ID联接的生效状态以及基于来源属性和ID事件计算的统计指标，所述的ID联接的生效状态判断ID联接记录是否有效。
本发明实施例还提供了一种面向数据湖的用户ID集成***，其包括：
构造模块，用于从数据湖中的一个或者多个数据源中采集原始用户数据，并构造ID事件；
第一存储模块，用于将ID事件输入和存储在一个支持永久存储的第一分布式消息队列中；
关联模块，用于从第一分布式消息队列中读取ID事件，生成ID联接记录，并更新ID图；
判断模块，用于根据ID联接属性，从ID图中获取有效的ID联接记录；
集成模块，用于针对有效的ID联接记录，获取ID图中的连通分量，并将获取的连通分量组成一个用户ID组，同时更新ID映射表；
第二存储模块，用于将ID映射表中的用户ID与用户ID组的映射记录存储在一个支持永久存储的第二分布式消息队列中。
本发明实施例的提供的上述技术方案，相比于现有技术，具有以下技术效果：
本发明实施例提供了一种面向数据湖的通用的、自动化统一用户ID的方法及***，其适用于基于数据湖的各类大数据平台建设。具体的，本发明实施例采用了通用的数据结构、计算过程和集成接口，大幅度降低了针对特定的问题手工定制“用户ID集成”程序、数据结构和计算程序的人力成本和失误风险。另外，本发明实施例从消息***读入来自多个数据源的，包含用户ID关联信息的记录，把属于同一用户的不同标识或者ID，按照提前设定的规则，自动动态关联起来，赋予唯一的全局标识，同时把ID间的关联变化通过消息***实时反馈给应用***。后者依赖这些信息，关联分散的用户数据，实现数据湖上的用户数据集成。
附图说明
图1为一个用户拥有多个ID标识的示意图。
图2为ID事件生产过程的示意图。
图3为一种面向数据湖的用户ID集成方法的逻辑结构示意图。
图4为ID联接记录形成的ID图的结构示意图。
图5为ID映射表的结构示意图。
图6为计算ID事件的流程示意图。
图7为更新ID图的计算流程示意图。
图8为三类业务规则的关系示意图。
图9为搜索受影响用户ID的执行流程示意图。
图10为寻找用户ID所在的用户ID组的执行流程示意图。
图11为更新ID映射表的执行流程示意图。
图12为一种面向数据湖的用户ID集成***的结构示意图。
图中：100-用户、105-用户所使用的网站和App、110-用户在使用网站和App的过程中产生的一个或者多个ID、120-ID之间的关系、200-ID Event清单输出过程、205-ID Event生产、210-保存下来的与用户ID相关的各类数据、215-ID Event清单、300-用户ID集成引擎、305-ID Event生产过程、310-管理员、315-大数据应用、320-ID Event队列、325-ID融合服务、330-ID映射表、335-业务规则、340-ID映射变更事件消息队列、345-ID图、350-数据湖、400-ID图样例、405-用户ID a和b之间的一条边、410-用户ID间的关联的统计数据和生效状态、415-用户ID a和b之间的一条边、420-ID联接属性、425-全局属性、430-来源属性、435-统计指标、500-一个ID图的内部结构、505-ID映射表的样例、510-用户ID j、601～635为ID融合服务定时执行的计算流程、701～735为更新/生成ID-Link记录的计算过程、810-SLA规则、815-GLA规则、820-LDS规则、825-SLA Status、835-GLA Status、910～930为受影响用户ID集合的计算过程、1010～1035为用户ID组的计算过程、1110～1135为更新ID映射表的计算过程。
具体实施方式
下面的具体实施例是结合本说明书中提供的附图对本申请的技术方案作出的具体、清楚的描述。其中，说明书的附图只是为了用于将本申请的技术方案呈现得更加清楚明了，并不代表实际生产或使用中的形状或大小，以及也不能将附图的标记作为所涉及的权利要求的限制。
另外，在本申请的描述中，所采用到的术语应当作广义的理解，对于本领域的技术人员而言，可以根据实际的具体情况来理解术语的具体含义。譬如，本申请中所采用的术语“设置”和“设有”，可以定义为接触式设置或者未接触式设置等；所采用的术语“连接”和“相连”可以定义为固定连接或者可活动连接的机械连接，也可定义为电性连接等；所采用的方位词术语均是以附图为参考或者根据以实际情况以及公知常识所定义的方向为准。
实施例1
该实施例提供了一种面向数据湖的用户ID集成方法，其包括以下步骤：
(1)从数据湖中的一个或者多个数据源中采集原始用户数据，并构造ID事件；
(2)将ID事件输入和存储在一个支持永久存储的第一分布式消息队列中；
(3)从第一分布式消息队列中读取ID事件，生成ID联接记录，并更新ID图；
(4)根据ID联接属性，从ID图中获取有效的ID联接记录；所述的ID联接属性包括多组来源属性和全局属性，所述的来源属性包括数据来源ID、基于ID事件计算的统计指标以及数据源层面的生效状态，所述的数据源层面的生效状态判断两个用户ID之间的关联是否有效；所述的全局属性包括ID联接的生效状态以及基于来源属性和ID事件计算的统计指标，所述的ID联接的生效状态判断ID联接记录是否有效。
(5)针对有效的ID联接记录，获取ID图中的连通分量，并将获取的连通分量组成一个用户ID组，同时更新ID映射表；
(6)将ID映射表中的用户ID与用户ID组的映射记录存储在一个支持永久存储的第二分布式消息队列中。
其中，参照附图1，100为用户本身，105为用户所使用的网站和App，110为用户在使用网站和App的过程中产生的一个或者多个ID，120为通过某些方法从这些日志数据中分析出新的用户ID和各类用户ID之间的关系。如果用户ID之间的对照规则是确定，可以根据这些规则，直接登记或者抽取。如果用户ID之间的关系无法直接根据规则确定，可以采用复杂的机器学习的方法，基于用户行为数据或者ID的特征，预测多个用户ID是否属于同一用户的概率，然后基于这些预测结果，建立用户ID之间的关系。需要说明的是，该实施例不包括这些抽取和分析方法，但是这些抽取和分析方法的结果可以作为本发明的数据输入。
具体的，该实施例输入数据是“ID事件(ID Event)”，ID事件是指发现新的用户ID、新ID关系或者变更用户ID之间关系的数据记录。ID事件可以在数据湖上通过信息***中各类登记、抽取和分析方法获得。其中，所述的ID事件包括数据来源标识、发生的时间、事件的类型和用户ID，用户ID可以为单一的用户的ID，也可以为两个关联的ID。
参照附图2，210为保存下来的与用户ID相关的各类数据，ID事件生产方法按照现有技术的规则或者分析方法，215为输出的ID事件清单。其中，ID事件清单包含了各类ID事件。具体的，ID事件清单至少包括五个属性，其结构化定义为：<id1，id2，timestamp，type，source>，其中id1是主用户ID，id2是与之关联的从用户ID。如果没有id2，则表示发现一个新的用户ID。timestamp是事件发生的日期和时间(图2采用了UNIX时间戳)，type是IDEvent的类型，包括“new(新增)”和“remove(删除)”两种，图2中用“new”和“remove”表示。source是ID Event的来源ID，用以唯一标识数据源头，可以用数据表名、文件名或者***名等代表。
此外，还可以对用户ID进行规范化，使得不同类型、不同应用产生的不同用户的ID不存在相同或者冲突的情况。具体的，可以为每个应用领域分配了不同的类型ID，作为原始用户ID的前缀，中间用下划线分开。譬如，原始用户ID是手机号“13810091001”，用户手机号分配类型ID是1001，规范化后的用户ID就变成：“1001_13810091001”。
参照附图3，该图显示的是实现该实施例方法的一种“用户ID集成引擎”的逻辑结构。具体的，用户ID集成引擎先将产生的ID Event，输入到第一分布式信息队列(ID Event队列)；接着，通过ID融合服务从ID Event队列中读取ID Event，生成ID-联接记录，b并更新ID图(ID-Graph)；然后根据业务规则，从ID图中产生ID映射记录，更新ID映射表；再接着，ID融合服务发送ID映射变更事件到第一分布式信息队列(ID映射变更事件队列)中，通知多个大数据应用；大数据应用收到变更事件后，可以根据ID映射表，重新计算应用数据，比如说评价用户价值的指标。此外，管理员可以根据业务需求和专家知识配置业务规则。
为了适应数据湖中数据计算规模大、高并发、扩展性要求高的特点，用户ID集成引擎必须用支持永久存储的分布式消息***(比如Apache Kafka或者RabbitMQ等)实现ID映射变更事件到消息队列和ID Event队列。ID映射表和ID图必须采用支持持久key-value存储和访问的高性能No-SQL数据库(通常是Hbase)。
参照附图4，图4是ID图的结构说明，其中400是它的一个样例。节点a-i是不同的规范化后的用户ID。用户ID之间用无向边联系在一起，称为ID联接(ID-Link)。ID-Link上的长方形框代表每条边有相应的属性，称为ID联接属性(Link Attributes)。形成边的两个用户ID，被称为ID1和ID2。405代表用户ID a和b之间的一条边，420是它的联接属性。ID联接属性保存用户ID间的关联的统计数据和生效状态。如410显示，ID联接属性分成了两大类：来源属性(Source Link Attributes，SLA)和全局属性(Global Link Attribu tes，GLA)。每个ID节点均有一组统计数据：联接密度统计指标LDS(Link Density Stat istics)。这组统计数据针对的是与此ID关联的所有ID。
具体的，来源属性SLA保存来自特定数据源的，关于ID-Link的统计数据和生效状态。好的f-list设计加上业务规则能有效处理事件顺序混乱的情况。一个ID-Link会存在多个SLA，数量与ID Event中的数据源(source)数量一致。来源属性SLA的定义如下，<source，f-list，SLA-status>，其中source是ID Event的数据来源ID，f-list是一组关于这个联接的统计指标，SLA-status是生效状态。生效状态如果是“true”，则表示此数据来源层面确定这两个用户ID之间的关联是有效的。关联是否有效取决于业务规则和f-list上的数值。f-list的指标是基于ID Event计算的，本发明不限定f-list的具体指标和计算方法。在某一个实现样例中，f-list采用了以下统计指标：
1.关联事件出现的次数
2.关联事件出现的天数
3.最后出现的日期和时间
4.最早出现的日期和事件
5.删除事件的出现的次数
6.最近出现的事件类型(删除/关联)
另外，全局属性GLA保存基于SLA的数据计算的统计数据和生效状态。一个ID-Link只存在一个GLA，其具体定义如下：<f-list，GLA-status>，f-list是一组关于这个关联的统计指标，GLA-status是ID-Link的生效状态。生效状态如果是“true”，则表示确定这两个用户ID之间的ID-Link有效。f-list的指标是基于SLA和ID-Event计算的，本发明不限定f-list的具体指标和实现方法。在某个实现样例中，f-list采用了以下统计指标：
1.生效状态是“true”的SLA数量
2.关联事件出现的总次数
3.关联事件出现的总天数
4.删除事件出现的次数
5.最近出现的日期和时间
6.最早出现的日期和事件
GLA-Status的取值由业务规则和f-list上的数值决定。如果GLA-Status等于true，则代表此ID-Link是有效的，否则，认为ID-Link无效。
此外，f-list统计程序是计算SLA和GLA的统计指标的程序，分别称为：gf-list统计程序和sf-list统计程序。此程序根据ID-Event的属性和类型，更新对应ID-Link的统计指标(f-list)。本发明不限定f-list统计程序的实现方式，可定制开发，满足不同应用场景的需求。联接密度统计指标LDS(Link Density Statistics)与某个ID相关，针对的是与此ID关联的所有ID。本发明不限定LDS的具体指标和实现方法。在某个实现样例中，LDS包括了以下类型的统计指标：
1.有效的ID数量(GLA的status＝1)
2.有效的某个类型的ID数量(GLA的status＝1)
3.所有的ID数量
4.某个类型的ID的数量。
***可以用这些指标，检查某个ID的多个关联是否符合业务规则。
对于业务规则，图3中的业务规则的作用是：根据GLA，SLA和LDS的统计数据，确定ID-Link上的GLA和SLA的status值(true/false)。业务规则按照使用的统计指标的不同，分为三类：SLA规则、GLA规则和LDS规则。业务规则允许有多条，每条规则均采取IF…THEN…的产生式规则，具体格式如下：IF boolean-function THEN DO Action。其中boolean-function可以根据以下参数进行判定的布尔函数：
1.SLA、GLA或者LDS的统计指标
2.边的用户ID
3.用户ID的类型
如果是true，则执行动作Action。本发明不限定boolean-function具体如何判定，只限定输出是一个布尔值(true/false)。一个实现样例采用的是布尔表达式，比如针对图4的2个表达式：
1.ID1＝a AND ID2＝b AND f-list.OccTimes>＝3
2.ID1.type＝1001AND ID2.type＝1002AND f-list.OccDays>1
其中表达式1针对的是边<a，b>，OccTimes是边的关联次数。表达式2针对的是用户ID类型是1001和1002的所有边，OccDays是边的关联天数。
不同类型规则有不同的action：SLA规则的action是设置SLA中的status，称为SLA-Action；GLA规则是设置GLA的status，称为GLA-Action；LDS规则设置当前ID的所有ID-Link的GLA的status，称为GLA-Action。SLA-Action和GLA-Action逻辑简单，不需要定制，但是LDS-Action的逻辑可以很复杂，应该允许定制开发。LDS-Action需要根据LDS的数据，重新对所有的ID-Link的GLA-Status进行调整。比如，业务要求一个中国手机号不能关联一个以上的身份证号。为此，可能设置这样的LDS规则：IF有效的身份证类型的ID数量>1THENremove_old_links。
其中remove_old_links是定制的函数，其逻辑是：最新出现的ID-Link的GLA-Status为true，其余设置为false。
不同类型的业务规则执行顺序如附图8显示。本发明不限定同一类型的规则之间的执行顺序。同一类型的中每个规则可以设置一个执行优先权值，管理员可以设置这个优先权值。***先对规则按照优先权值排序，然后按照优先权从高到底执行。
本发明不限定业务规则的具体实现方法，开发者可以根据***环境和工程要求，设计合适的实现方法。我们的一个实现样例是用脚本引擎(Script Engine)解释和执行业务规则。定制函数也用脚本语言实现。另外一个样例的定制函数直接用可编译语音例如java实现。此外，还可以基于关系数据库的实现：用关系表存储boolean-function的参数和Action名称，完全由特定的代码转换到规则，并执行相关的Action。
参照附图5，图5的500是一个ID-Graph的内部结构，黑色属性框标注的是GLA-Status是”true”的边。我们称这些是有效ID-Link。用虚线圈出了500内部基于有效边形成的4个用户ID的连通子图(连同分量Connected Component)，***称为用户ID组。***为这些用户ID组赋予唯一的ID，分别是G1-G4。用户ID j没有进入ID-Graph，因为它没有关联其他的ID。***也会为用户ID组赋予一个唯一的ID，这些虚拟的ID我们称为GID。它指向的是一个“个体”。这个“个体”可能是个人，也可能是家庭或者某个小群体。图5中表格505便是ID映射表的样例，存储了用户ID和GID之间的映射关系。图2中的外部大数据应用可以根据ID映射表，合并属于同一用户但是具有不同用户ID的分散数据。
对于ID映射表的更新，当ID映射表发生变化时，ID融合服务需要通知图3中的外部大数据应用。每条通知称为ID映射变更事件，具体定义是：<GID，event-type>，其中event-type是事件类型，具体的定义和执行动作定义如下：
1.new:新出现一个GID，融合这个GID对应的用户ID的数据。
2.removed:GID对应的组被合并、***或者删除掉了，解除这个GID对应的融合数据。
收到GID变更事件后，应用程序根据事件类型，查ID映射表，把用户ID的数据融合到一起。本发明没有规定如何处理“数据融合”，只规定了ID映射变更事件对应的执行动作。应用程序要自己决定如何“融合数据”或者“解除融合”。建议以下3种常见方法。
1.事后索引
这是最简单的方式，原有的用户数据保留在原地不变，对ID映射变更事件不处理。只有在使用数据时，才会基于用户ID查询ID-Mapping Table，获取GID，然后查询有相同GID的其他用户ID，最终合并多个用户ID对应的数据。我们的一个应用案例采用这种方法，定时批量计算KPI。
2.即时标记
原有的用户数据保留在原地不变，但是每条用户ID记录上增加GID标记。当出现有新GID出现时，就读取ID-Mapping Table对应的用户ID，用新GID标记这些用户ID的数据记录；当某个GID的事件类型是“removed”，就在数据记录中清除老的GID。使用数据时，属于同一个GID的多个数据记录可以合起来一起处理。我们的一个应用案例用这种方法解决客户订单库中的统一用户标识问题。
3.即时聚合
原有的用户数据保留在原地不变，按照GID提前聚合多个用户ID的数据。当出现一个新的GID的时候，就读取ID-Mapping Table对应的用户ID，找出这些ID对应的数据记录，然后聚合这些数据；当某个GID的事件类型是“removed”，就直接删除这个GID对应的聚合记录或者打上删除标记(等待后续清理)。实时KPI计算应用可以采用这种方法。
对于ID融合服务，ID融合服务从ID Event队列中读取ID Event，生成ID-联接记录，更新ID图，后续统称ID-Graph。然后根据业务规则，从ID-Graph中产生ID映射记录，更新ID映射表。ID融合服务发送ID映射变更事件到队列中，通知多个相关的外部大数据应用。内部的具体流程如附图6显示。
ID融合服务会定时执行图6的计算流程。其输入的是ID映射表，ID-Graph、ID-Event队列和业务规则。先从ID-Event队列中读取事件，然后更新或者生成ID-Graph中各类用户ID之间的联接，同时会根据业务规则计算SLA和GLA的status。更新完成后，在ID-Mapping Table中搜索哪些用户ID受了新事件的影响，针对这些受影响的ID，可以重新计算关联到一起的用户ID组。最后针对这些新的ID组，生成新的GID，更新ID映射表，同时把GID更事件发送到ID映射变更事件队列。
参照附图7，图7是过程更新/生成ID-Link记录(UPDATE_ID_GRAPH)的计算过程。先从ID-Graph中查出与ID-Event中e.id1和e.id2匹配的ID-Link，如果已有的联接不存在，就为当前事件创建一个新的ID-Link，并初始化相关数据。然后更新SLA，基于SLA s和ID-Linkd执行SLA-Rule。类似的步骤，更新GLA，执行GLA-Rule。最后更新每个ID的LDS，并执行LDS-Rules。SLA-Rule、GLA-Rule和LDS-Rule执行的最终结果会影响SLA-Status和GLA-Status。
参照附图9，图9显示了根据ID集合S，在ID-Mapping Table中搜索影响的用户ID。为了提高计算效率，使用新ID-Event数据中包含的用户ID集合S作为搜索的起始点。首先从T中查出S中用户ID对应的GID(915)；然后再根据的查到的GID集：G，从T中查询到所有与之关联的用户ID，并把受影响的映射关系<用户ID，GID>放入集合P。最后把集合P和用户ID集合S中新用户ID并到一起。P是重新计算GID和用户ID映射关系的初始集。
参照附图10，从受影响的用户ID集开始，寻找出这些用户ID所在的用户ID组。这个计算过程类似与从一个顶点(用户ID)集从发，从无向图中找出所有的连通分量(或连通分支)。因为已有多种方法解决这个问题，所以本发明不限定具体的实现方案，实施者可以根据自己的技术和设备条件，选择合适的计算方法。该实施例是采用了如图10的计算流程，它采用了并行搜索直接连通的用户ID，然后统一合并后续用户ID组的方法。
参照附图11，图11是针对这些新生成的用户ID组，赋予新的GID，并更新ID映射表，同时把GID更事件发送到ID映射变更事件队列。其中，图11中的1115-11130是生成新GID的过程。1115和1120负责为用户ID组赋予一个新的GID。1125则搜索ID映射表，建立老GID和新GID的关系。1130的功能是根据新老GID的关系，去掉结构没有变化用户ID组(也就是说新老GID覆盖是同一组用户ID)。最后，1135为新GID发送新增事件到ID映射变更事件队列，也为老GID发送删除事件到同一队列。收到GID变更事件后，应用程序可以根据事件类型，采用适当的方式查询ID映射表，把用户ID的数据融合到一起。
实施例2
参照附图12，该实施例提供了一种面向数据湖的用户ID集成***，用于实现上述方法，具体的，该用户ID集成***包括构造模块、第一存储模块、关联模块、判断模块、集成模块和第二存储模块。其中，构造模块，用于从数据湖中的一个或者多个数据源中采集原始用户数据，并构造ID事件；第一存储模块，用于将ID事件输入和存储在一个支持永久存储的第一分布式消息队列中；关联模块，用于从第一分布式消息队列中读取ID事件，生成ID联接记录，并更新ID图；判断模块，用于根据ID联接属性，从ID图中获取有效的ID联接记录；集成模块，用于针对有效的ID联接记录，获取ID图中的连通分量，并将获取的连通分量组成一个用户ID组，同时更新ID映射表；第二存储模块，用于将I D映射表中的用户ID与用户ID组的映射记录存储在一个支持永久存储的第二分布式消息队列中。
其中，所述的ID事件包括数据来源标识、发生的时间、事件的类型和用户ID，用户ID可以为单一的用户的ID，也可以为两个关联的ID。所述的ID联接属性包括多组来源属性和全局属性，所述的来源属性包括数据来源ID、基于ID事件计算的统计指标以及数据源层面的生效状态，所述的数据源层面的生效状态判断两个用户ID之间的关联是否有效；所述的全局属性包括ID联接的生效状态以及基于来源属性和ID事件计算的统计指标，所述的ID联接的生效状态判断ID联接记录是否有效。该用户ID集成***实现用户ID集成的方法如上述实施例1所述。
综上所述，本发明实施例提供了一种面向数据湖的通用的、自动化统一用户ID的方法及***，其适用于基于数据湖的各类大数据平台建设。具体的，本发明实施例采用了通用的数据结构、计算过程和集成接口，大幅度降低了针对特定的问题手工定制“用户ID集成”程序、数据结构和计算程序的人力成本和失误风险。另外，本发明实施例从消息***读入来自多个数据源的，包含用户ID关联信息的记录，把属于同一用户的不同标识或者ID，按照提前设定的规则，自动动态关联起来，赋予唯一的全局标识，同时把ID间的关联变化通过消息***实时反馈给应用***。后者依赖这些信息，关联分散的用户数据，实现数据湖上的用户数据集成。
需要说明的是，上述实施例只是针对本申请的技术方案和技术特征进行具体、清楚的描述。而对于本领域技术人员而言，属于现有技术或者公知常识的方案或特征，在上面实施例中就不作详细地描述了。
当然，本申请的技术方案不只局限于上述的实施例，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，从而可以形成本领域技术人员可以理解的其他实施方式。

Claims (10)

1.一种面向数据湖的用户ID集成方法，其特征在于，包括以下步骤：
从数据湖中的一个或者多个数据源中采集原始用户数据，并构造ID事件；
将ID事件输入和存储在一个支持永久存储的第一分布式消息队列中；
从第一分布式消息队列中读取ID事件，生成ID联接记录，并更新ID图；
根据ID联接属性，从ID图中获取有效的ID联接记录；
针对有效的ID联接记录，获取ID图中的连通分量，并将获取的连通分量组成一个用户ID组，同时更新ID映射表；
将ID映射表中的用户ID与用户ID组的映射记录存储在一个支持永久存储的第二分布式消息队列中。
2.根据权利要求1所述的一种面向数据湖的用户ID集成方法，其特征在于，所述的ID事件包括数据来源标识、发生的时间、事件的类型和单一的用户ID。
3.根据权利要求1所述的一种面向数据湖的用户ID集成方法，其特征在于，所述的ID事件包括数据来源标识、发生的时间、事件的类型和两个关联的用户ID。
4.根据权利要求1所述的一种面向数据湖的用户ID集成方法，其特征在于，所述的ID联接属性包括多组来源属性，所述的来源属性包括数据来源ID、基于ID事件计算的统计指标以及数据源层面的生效状态，所述的数据源层面的生效状态判断两个用户ID之间的关联是否有效。
5.根据权利要求4所述的一种面向数据湖的用户ID集成方法，其特征在于，所述的ID联接属性还包括全局属性，所述的全局属性包括ID联接的生效状态以及基于来源属性和ID事件计算的统计指标，所述的ID联接的生效状态判断ID联接记录是否有效。
6.一种面向数据湖的用户ID集成***，其特征在于，包括：
构造模块，用于从数据湖中的一个或者多个数据源中采集原始用户数据，并构造ID事件；
第一存储模块，用于将ID事件输入和存储在一个支持永久存储的第一分布式消息队列中；
关联模块，用于从第一分布式消息队列中读取ID事件，生成ID联接记录，并更新ID图；
判断模块，用于根据ID联接属性，从ID图中获取有效的ID联接记录；
集成模块，用于针对有效的ID联接记录，获取ID图中的连通分量，并将获取的连通分量组成一个用户ID组，同时更新ID映射表；
第二存储模块，用于将ID映射表中的用户ID与用户ID组的映射记录存储在一个支持永久存储的第二分布式消息队列中。
7.根据权利要求6所述的一种面向数据湖的用户ID集成***，其特征在于，所述的ID事件包括数据来源标识、发生的时间、事件的类型和单一的用户ID。
8.根据权利要求6所述的一种面向数据湖的用户ID集成***，其特征在于，所述的ID事件包括数据来源标识、发生的时间、事件的类型和两个关联的用户ID。
9.根据权利要求6所述的一种面向数据湖的用户ID集成***，其特征在于，所述的ID联接属性包括多组来源属性，所述的来源属性包括数据来源ID、基于ID事件计算的统计指标以及数据源层面的生效状态，所述的数据源层面的生效状态判断两个用户ID之间的关联是否有效。
10.根据权利要求9所述的一种面向数据湖的用户ID集成***，其特征在于，所述的ID联接属性还包括全局属性，所述的全局属性包括ID联接的生效状态以及基于来源属性和ID事件计算的统计指标，所述的ID联接的生效状态判断ID联接记录是否有效。
CN201910952703.7A 2019-10-09 2019-10-09 一种面向数据湖的用户id集成方法和*** Pending CN110674231A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201910952703.7A CN110674231A (zh) 2019-10-09 2019-10-09 一种面向数据湖的用户id集成方法和***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201910952703.7A CN110674231A (zh) 2019-10-09 2019-10-09 一种面向数据湖的用户id集成方法和***

Publications (1)

Publication Number Publication Date
CN110674231A true CN110674231A (zh) 2020-01-10

Family

ID=69081121

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201910952703.7A Pending CN110674231A (zh) 2019-10-09 2019-10-09 一种面向数据湖的用户id集成方法和***

Country Status (1)

Country Link
CN (1) CN110674231A (zh)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111488261A (zh) * 2020-03-11 2020-08-04 北京健康之家科技有限公司 用户行为分析***、方法、存储介质及计算设备
CN112395321A (zh) * 2020-12-03 2021-02-23 恩亿科(北京)数据科技有限公司 用户id关联方法、***及批式、流式数据处理方法
CN113626482A (zh) * 2021-08-17 2021-11-09 北京深演智能科技股份有限公司 基于***融合id表的查询方法和装置
CN114339729A (zh) * 2020-09-30 2022-04-12 阿里巴巴集团控股有限公司 设备标识的生成方法及装置、电子设备、存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104346377A (zh) * 2013-07-31 2015-02-11 克拉玛依红有软件有限责任公司 一种基于唯一标识的数据集成和交换方法
CN109271382A (zh) * 2018-08-17 2019-01-25 广东技术师范学院 一种面向全数据形态开放共享的数据湖***
CN109298840A (zh) * 2018-11-19 2019-02-01 平安科技（深圳）有限公司 基于数据湖的数据集成方法、服务器及存储介质

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN104346377A (zh) * 2013-07-31 2015-02-11 克拉玛依红有软件有限责任公司 一种基于唯一标识的数据集成和交换方法
CN109271382A (zh) * 2018-08-17 2019-01-25 广东技术师范学院 一种面向全数据形态开放共享的数据湖***
CN109298840A (zh) * 2018-11-19 2019-02-01 平安科技（深圳）有限公司 基于数据湖的数据集成方法、服务器及存储介质

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111488261A (zh) * 2020-03-11 2020-08-04 北京健康之家科技有限公司 用户行为分析***、方法、存储介质及计算设备
CN114339729A (zh) * 2020-09-30 2022-04-12 阿里巴巴集团控股有限公司 设备标识的生成方法及装置、电子设备、存储介质
CN112395321A (zh) * 2020-12-03 2021-02-23 恩亿科(北京)数据科技有限公司 用户id关联方法、***及批式、流式数据处理方法
CN113626482A (zh) * 2021-08-17 2021-11-09 北京深演智能科技股份有限公司 基于***融合id表的查询方法和装置

Similar Documents

Publication Publication Date Title
CN110674231A (zh) 一种面向数据湖的用户id集成方法和***
US20110016451A1 (en) Method and system for generating test cases for a software application
US10108415B2 (en) Maintaining the integrity of process conventions within an ALM framework
RU2607991C2 (ru) Способ и система технического осмотра и соответствующий им машиночитаемый носитель данных
CN111552607A (zh) 应用程序的健康评估方法、装置、设备及存储介质
US20230040635A1 (en) Graph-based impact analysis of misconfigured or compromised cloud resources
CN111752945B (zh) 一种基于容器和层次模型的时序数据库数据交互方法和***
CN113760677A (zh) 异常链路分析方法、装置、设备及存储介质
CN113220904A (zh) 数据处理方法及数据处理装置、电子设备
CN114416703A (zh) 数据完整性自动监控方法、装置、设备及介质
CN114385551B (zh) 日志分时管理方法、装置、设备及存储介质
CN110109906B (zh) 数据存储***及方法
CN113556368A (zh) 用户识别方法、装置、服务器及存储介质
CN114185761A (zh) 日志采集方法、装置及设备
CN111090401B (zh) 存储设备性能预测方法及装置
CN115329011A (zh) 数据模型的构建方法、数据查询的方法、装置及存储介质
CN112579552A (zh) 日志存储及调用方法、装置及***
JP5206268B2 (ja) ルール作成プログラム、ルール作成方法及びルール作成装置
CN106095511A (zh) 一种服务器升级方法和装置
CN112182413B (zh) 一种基于教学大数据的智能推荐方法及服务器
CN111352824B (zh) 测试方法、装置及计算机设备
Mijumbi et al. MAYOR: machine learning and analytics for automated operations and recovery
JP5741717B2 (ja) 情報処理方法、装置及びプログラム
CN114691700A (zh) 一种基于kafaka集群的智慧园区的检索方法
CN117389908B (zh) 接口自动化测试用例的依赖关系分析方法、***及介质

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
WD01 Invention patent application deemed withdrawn after publication
WD01 Invention patent application deemed withdrawn after publication

Application publication date: 20200110