一种应用于大数据CDP领域的通用数据模式及其应用

摘要

本申请提供了一种特别适用于大数据CDP领域的通用数据模式及其应用。所述通用数据模式继承数据范式，所述数据范式继承数据类别或者自我继承。本申请将逻辑层和物理层分离，使得概念模型更容易迁移；可以一个逻辑模型对应多个存储层信息，使得业务定义和实现逻辑的分离，例如事件定义和标签定义。本申请引入SCV数据层，使得客户身份策略更加灵活，试算和重算的成本大大降低。本申请的通用数据模式针对客户数据平台领域进行抽象，能够降低建模实践落地成本。

说明书

技术领域

本发明涉及应用于大数据CDP领域的通用数据模型及其应用。

背景技术

客户数据平台(customer data platform，CDP)系统主要是收集不同来源的客户数据并形成统一的围绕客户的不同数据视图，并分享给其他营销系统。在本领域中，申请人首次发现应用于大数据营销领域的现有通用模型并不适宜用于CDP领域，因为现有通用模型还存在以下问题：

(1)现有通用模型中的数据范式概念不清。数据范式中既包含对基本数据技术分类(如记录型，时序性)的抽象，又包含对数据业务分类(如profile，document)的抽象，两种数据分类混同。(2)现有通用数据模型的逻辑层和物理层耦合。对于数据表或业务对象来讲，分类逻辑描述和物理描述。逻辑描述主要描述业务含义，比如一个字段逻辑定义为productName，但物理上可能存放在attr1这个列。通常情况下，表的逻辑描述和物理描述是相同的，但也有特殊情况，比如事件类型的定义，每一个事件类型，都有一定数量的字段描述事件携带的信息，这些事件数据会保存在行为事件表中，而同一行为事件表可以保存多个事件类型的事件数据，所以对于事件类型来讲，每个事件类型就是逻辑描述，而行为事件表就是物理描述。(3)事件类型定义、标签数据元数据没有通用数据模型(GDM)定义。因为逻辑层和物理层没有分开，所以事件类型和标签数据没有GDM的描述。(4)数据的DW层和SCV层耦合在一起。个人子档案与来自渠道的模型数据共用一张表。在渠道数据的模型表上增加了字段来记录与个人主档的关系。这种耦合带来了数据的DW层和SCV层耦合问题，DW层和SCV层共用同一张表会带来很大的不灵活性：①当身份配置出现失误，重新调整难度大，无法把SCV层直接清理掉再根据DW层数据重新生成。②无法根据不同身份策略用DW层数据生成不同的统一客户视图(SCV)。(5)行为事件、业务单据没有保留原始数据。行为事件和业务单据在通过API进入时会携带一组身份，这组身份并没有保留在ODS层，也没有保留在DW层，当档案的数据出现错误，无法根据原始数据重新计算。(6)身份策略固化。身份策略通常跟运营场景有很大关系，比如对于1对1的沟通场景，b2b的沟通场景和广告投放场景，身份打通的要求是不同的。目前的身份策略主要是针对1对1沟通场景，对其他场景适配性不好。

发明内容

为了克服上述技术缺陷，本发明的第一个方面提供一种应用于大数据CDP领域的通用数据模式，所述通用数据模式继承数据范式，所述数据范式继承数据类别或者自我继承，

通用数据模式＝1*数据范式+m*通用数据字段，

所述数据范式＝1*数据类别+n*通用数据字段，

其中，m和n均是正整数，所述数据类别描述的是数据的技术分类，所述数据范式描述的是数据的业务分类。

进一步地，所述数据类别包括记录型数据和时序型数据；记录型数据用于描述个体的属性信息，记录型数据没有时间分区列，即不会随着时间的增长而有明显增多；时序型数据有时间分区列，数据量会随时间的增长而不断增多。

进一步地，每一个数据范式定义了一类业务对象和一类业务语义；业务语义能够提供一类功能，数据范式通过功能提示的方式使所述功能被动态配置。

进一步地，所述通用数据模式进一步包括UID字段，所述UID字段是通过身份服务动态计算生成的。

进一步地，所述通用数据模式进一步包括统一客户身份规则，所述统一客户身份规则包括按时间优先级的合并策略和按渠道优先级的合并策略。

本申请的第二个方面提供一种使用上述通用数据模式构建CDP中数据分层的数据表的方法，所述数据分层包括贴源层、模型层、统一客户视图层以及服务层，所述方法依次包括步骤：

步骤S1：新建通用层数据模式：选择某一个数据范式来构建一个数据模式；

步骤S2：新建贴源层数据表：首先选择已经建好的所述通用数据模式来约束数据，然后引用一个或多个表结构来设定数据表中数据的物理存储信息，并存储模式字段到表结构字段间的映射关系；

步骤S3：新建模型层数据表：首先选择已经建好的所述通用数据模式来约束数据，然后引用一个或多个表结构来设定数据表中数据的物理存储信息，并存储模式字段到表结构字段间的映射关系；

步骤S4：新建统一客户视图层数据表：首先对已经建好的所述通用数据模式引入UID字段和统一客户身份规则字段作为变更后的通用数据模式，并引用该变更后的通用数据模式来约束数据，然后引用一个或多个表结构来设定数据表中数据的物理存储信息，并存储模式字段到表结构字段间的映射关系；

步骤S5：新建服务层数据表：首先选择已经建好的所述通用数据模式来约束数据，然后引用一个或多个表结构来设定数据表中数据的物理存储信息，并存储模式字段到表结构字段间的映射关系。

进一步地，所述UID字段是通过身份服务动态计算生成的，所述统一客户身份规则包括按时间优先级的合并策略和按渠道优先级的合并策略。

进一步地，所述贴源层记录的是对源数据进行简单加工后的数据；所述模型层记录的是对贴源层输出数据进行去重加工之后的干净数据；统一客户视图层记录的是通过身份服务打通来自不同渠道的数据后形成的关联在一起的并且能够直接供实时查询的统一客户视图数据；服务层记录的是从统一客户视图层或者模型层输出的并且能够直接供实时查询的数据。

本申请的第三个方面提供一种为数据表创建数据视图的方法，其包括：

步骤S1：首先选择一张采用权利要求6～8中任一项所述方法构建得到的数据表，所述数据表包含可映射字段；

步骤S2：将数据表中的可映射字段映射成新的字段，从而为所述数据表创建一个或多个数据视图(数据表中的数据可以包含不同类型的数据，对数据表中的每种类型的数据生成一个数据视图，因此，一张数据表可以对应于一个或多个数据视图)，并在建数据视图的同时自动创建所述数据视图对应的通用数据模式。

采用了上述技术方案后，与现有技术相比，具有以下有益效果：

为了解决数据范式技术分类和业务分类不清的问题，同时为了解决现有通用数据模型的逻辑层和物理层耦合的问题，引入了两个基本组件：数据类别(Kind)和数据模式(Schema)。本申请提供了一种特别适用于大数据CDP领域的通用数据模式，本申请将逻辑层(即数据模式)和物理层(即表结构)分离，使得概念模型更容易迁移；可以一个逻辑模型对应多个存储层信息，使得业务定义和实现逻辑的分离，例如事件定义和标签定义。本申请引入SCV数据层，使得客户身份策略更加灵活，试算和重算的成本大大降低。本申请的通用数据模式针对客户数据平台(CDP)领域进行抽象，能够降低建模实践落地成本。

附图说明

图1为本申请的客户数据平台的数据分层及数据流向的示意图；

图2为使用通用数据模式构建CDP中的各个数据分层数据表的流程图；

图3为本申请采用逻辑层(即数据模式)和物理层(即表结构)分离的方式构建数据表或数据视图的原理示意图；

图4为使用通用数据模式构建CDP中数据分层的数据表的界面；

图5为图4中的数据模式下拉菜单展开后的示例图；

图6为构建统一客户视图层数据表的原理示意图。

具体实施方式

以下结合附图与具体实施例进一步阐述本发明的优点。本领域技术人员应当理解，下面所具体描述的内容是说明性的而非限制性的，不应以此限制本发明的保护范围。在本文中使用的术语“包括”及其变形表示开放性包括，即“包括但不限于”。应当理解，尽管在本公开可能采用术语“第一”、“第二”等来描述各种对象，这些术语仅用来将同一类型的对象彼此区分开，可以指代不同的或相同的对象，而不能理解为指示或暗示相对重要性。

本申请中的应用于大数据CDP领域的通用数据模式继承数据范式，而数据范式继承数据类别或者自我继承。本申请中的“继承”是指模型对象之间的关系，基于某个模型进行扩展得到一个新的模型。

通用数据模式＝1*数据范式+m*通用数据字段，

所述数据范式＝1*数据类别+n*通用数据字段，

其中，m和n均是正整数，所述数据类别描述的是数据的技术分类，所述数据范式描述的是数据的业务分类。示例地，通用数据字段包括但不限于：文本类型、小数类型、整数类型、日期、时间、手机号码和电子邮箱等。

为了区分不同的通用数据模式，下述实施例1中的通用数据模式称为第一通用数据模式，下述实施例2中的通用数据模式称为第二通用数据模式。

实施例1使用通用数据模式构建CDP中数据分层的数据表

如图1所示，现有的通用数据模型一般应用于ODS层(贴源层)、DW层(模型层)和DS层(服务层)而本发明首次引入SCV层(统一客户视图层)。因此，本申请的客户数据平台中的数据分层包括贴源层、模型层、统一客户视图层以及服务层。

所述贴源层记录的是从数据源进来的接近原始数据，只是做了简单的加工，如脱敏，校验等。实时数据会保存在Kafka中，离线数据会保存在hive表中。离线数据是一般是分批次保存的。为方便数据处理，Spark程序通常不是直接读源库操作，而是将源库的数据下载到本地后再操作，下载到本地的数据被称为landing层，以原始数据的格式保存。landing层的数据需要支持自动过期。

所述模型层记录的是经过去重，加工之后的干净数据。DW取Data Warehouse之意。

统一客户视图层记录的是通过身份服务(ID service)打通来自不同渠道的数据后形成的关联在一起的并且能够直接供实时查询的统一客户视图数据。

服务层记录的是从统一客户视图层或者模型层输出的并且能够直接供实时查询的数据。记录是供外部使用的数据，如AI的特征数据表，分析的数据宽表。

如图2所示，使用第一通用数据模式构建CDP中数据分层的数据表的方法依次包括步骤1-步骤5。

数据表是数据的集合。如图3-图5所示，一个数据表除了使用数据模式(schema)来约束数据外，还需要定义数据的存储位置，比如，对应数据库的类型，主键，分区等信息。这些信息是数据表的物理信息，用表结构(table structure)来记录。除此之外，数据表还需要存储模式字段到表结构字段建的映射关系。有时一张数据表要使用多张物理表来存储数据，比如客户数据使用customer和customer_attribute两张表来存储数据。为了处理这种情况，一个数据表关联多个表结构。

数据表是基于schema创建的，所以创建数据表前要先创建schema，或者选择已经存在的schema，选择schema之后，再设定相关的物理存储信息，如底层数据库、主键和分区列等。数据表的字段名可以保持与schema的字段名保持一致。

数据表＝1*数据模式+1*表结构。

优选地，数据表＝1*数据模式+1*表结构+X*基本信息，

其中，X为正整数。示例地，基本信息包括但不限于名称、ID、图标、描述等。

本申请中的数据模式是指适用于某一行业的某一业务对象数据的通用数据模型，示例地，如图5所示，汽车行业的业务对象分为客户、汽车、人车关系、购车订单，则相应地，针对前述每一业务对象的数据构建一个第一通用数据模式，第一通用数据模式分为客户模型、汽车模型、人车关系模型、购车订单模型。

数据模式的演进：

当schema还没有被应用到数据表时，schema的字段可以自由变更。一旦schema创建了数据表，它的变更必须是兼容性的。且其变更会直接反映在数据表上。

兼容性变更不包括以下操作：(1)删除一个字段；(2)引入新的必填字段；(3)重命名现有字段；(4)更改现有字段的类型。

步骤1：新建通用层数据模式：选择某一个数据范式来构建一个数据模式(schema)。

选择某一个“数据范式”，来构建一个“数据模式”，数据模式中包含字段类型，大小，范围等约束，这是一个逻辑描述，其中没有具体的表信息。数据模式(schema)是对具体数据表的逻辑描述，类似于Java里的类。通过数据模式中字段类型，大小，范围等的约束，可以规范化数据的定义，起到一定的数据校验能力。数据模式还可以作为数据描述输出到外部系统，让其他系统可以辨识数据格式，让数据交换更简单。数据模式之间可以建立关联关系，比如，通过在源schema的某个字段上设置一个到目标表主键的查找关系，就能创建1对多关系。

所述数据类别(Kind)描述的是数据的技术分类。所述数据类别包括记录型数据(record)和时序型数据(timeseries)。记录型数据用于描述个体的属性信息，个体可以是人，也可以是物，如产品，门店。记录型数据没有时间分区列，即不会随着时间的增长而有明显增多。时序型数据记录个体在某一时刻的行为动作、交易等，有时间分区列，数据量会随时间的增长而不断增多。

所述数据范式(Pattern)描述的是数据的业务分类。每一个数据范式定义了一类业务对象，如档案范式和单据等。每个数据范式定义了一类业务语义，其提供了一类功能，比如，档案范式具有打标签的能力。它的灵活性体现在，只要基于现有的数据范式创建数据表，该表与生俱来就具备一定的能力。数据范式还可以通过功能提示(hint)的方式，让其功能可按需配置。比如，虽然可为档案范式打标签，但是否需要打标签，是可以动态配置的。数据范式通过功能提示的方式使所述功能被动态配置。

步骤2：新建贴源层数据表：首先选择已经建好的所述第一通用数据模式来约束数据，然后引用一个或多个表结构来设定数据表中数据的物理存储信息，并存储模式字段到表结构字段间的映射关系。

选择已经建好的“数据模式”并选择数据表的存储模式，分区大小等相关的表存储信息，在个阶段，数据表的定义中会包含对数据模式的引用和存储信息的记录。

步骤3：新建模型层数据表：首先选择已经建好的所述第一通用数据模式来约束数据，然后引用一个或多个表结构来设定数据表中数据的物理存储信息，并存储模式字段到表结构字段间的映射关系。

选择已经建好的“数据模式”，并选择数据表的存储模式，分区大小等相关的表存储信息，在个阶段，数据表的定义中会包含对数据模式的引用和存储信息的记录。

步骤4：新建统一客户视图层数据表：首先对已经建好的所述第一通用数据模式引入UID字段和统一客户身份规则字段作为变更后的第一通用数据模式，并引用该变更后的第一通用数据模式来约束数据，然后引用一个或多个表结构来设定数据表中数据的物理存储信息，并存储模式字段到表结构字段间的映射关系。

如图6所示，其中scv_loyalty_member,scv_wechat_fans，scv_order和scv_sensors_event的数据都是从相应的dw表复制过去的，schema也几乎完全一样，除了scv表多了一个_uid字段。该字段的值是通过身份服务计算出来的。这里的scv_union_customer是个人主档案，scv_loyalty_member和scv_wechat_fans是个人子档案。scv的数据除了保存在hive表中便于SQL查询外，还会同步到hbase中，供Open API实时查询。

所述UID字段是通过身份服务动态计算生成的，所述统一客户身份规则包括按时间优先级的合并策略和按渠道优先级的合并策略。

步骤5：新建服务层数据表：首先选择已经建好的所述第一通用数据模式来约束数据，然后引用一个或多个表结构来设定数据表中数据的物理存储信息，并存储模式字段到表结构字段间的映射关系。

当配置多个子档案表的字段到主档案的同一个字段时，就会发生数据冲突，解决这种冲突就需要用到合并策略。合并策略有两种：(1)按时间优先级：后更新覆盖先更新，或保留先更新。(2)按渠道优先级：为不同子档案设置不同的优先级，高优先级覆盖优先级低。

时间优先级比较好解决，下面我们讨论一下渠道优先级的解决方法：比如两个子档案分别来自会员系统和线索系统，示例如下表1：第一通用数据模式包括会员ID字段、姓名字段和手机号字段。会员子档案的优先级为2，线索档案的优先级为1，会员优先级大于线索。此时因为会员的手机号为空，而线索的手机号不为空，所以还是需要使用线索的手机号；会员的姓名字段不为空，所以要用会员的姓名。合并后的记录如下表：

表1按渠道优先级的合并策略示例

实施例2为数据表创建数据视图

当一种数据表里存放多种类型的数据时，为每种类型的数据创建一张数据视图就变得有意义。比如客户事件表里会保存多种类型的事件，为每种类型的事件创建一张数据视图，让操作事件更容易。创建数据视图的原始数据表要包含可映射字段，否则创建的数据视图与原数据表就没有区别，数据视图也就没有任何意义。

数据视图对应的数据schema是在建数据视图的过程中自动创建的，这点与数据表要求先创建schema不一样，需要注意。创建数据视图时，要先选择一张数据表。数据视图可以将数据表中的可映射字段映射成一个新的字段。数据视图的字段包括源数据表中不可映射字段和被该数据视图映射的字段。

步骤S1：首先选择一张实施例1中获得的数据表，数据表包含可映射字段；

步骤S2：为所选择的源数据表中每种类型的数据创建一张数据视图，将数据表中的可映射字段映射成一个新的字段以作为被该数据视图映射的字段，数据视图的字段包括被该数据视图映射的字段，在生成数据视图的同时自动创建数据视图的第二通用数据模式。

举一个例子，有一张客户事件数据表dw_customer_event，其中data_happened是不可映射字段，attr1和attr2是可映射字段。基于dw_customer_event创建下单事件视图，该视图将attr1映射成商品字段product，把attr2字段映射成品类字段category。下单事件视图包含data_happened,product,category三个字段。

应当注意的是，本发明的实施例有较佳的实施性，且并非对本发明作任何形式的限制，任何熟悉该领域的技术人员可能利用上述揭示的技术内容变更或修饰为等同的有效实施例，但凡未脱离本发明技术方案的内容，依据本发明的技术实质对以上实施例所作的任何修改或等同变化及修饰，均仍属于本发明技术方案的范围内。