数据中台和业务中台的构建方法、装置、设备及存储介质与流程

1.本技术涉及市场营销数据处理技术领域，涉及但不限于一种数据中台和业务中台的构建方法、装置、设备及计算机可读存储介质。


背景技术：

2.随着新能源汽车企业的兴起，智能化和全面的用户体验成为新能源汽车品牌区别于传统品牌的重要竞争力，甚至在新兴品牌中，客户端(c端)用户运营和以用户(而非渠道或经销商)为核心考量的业务流程，成为基本要求。
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.将所述主维表、用户相关维表和业务相关维表确定为所述用户数据中台与所述业务分析中台的公共维度表。
28.在一些实施例中，所述方法还包括：
29.业务分析中台接收服务终端发送的第一请求消息，所述第一请求消息用于获取报表服务数据；
30.根据所述应用汇总数据，确定所述报表服务数据；
31.将所述报表服务数据携带于第一响应消息中发送至所述服务终端，以使所述服务终端利用所述报表服务数据生成业务报表。
32.在一些实施例中，所述方法还包括：
33.业务分析中台接收业务终端发送的第二请求消息，所述第二请求消息用于获取业务分析数据；
34.根据所述业务明细数据、轻度汇总数据、应用汇总数据、主维表、用户相关维表和业务相关维表，确定所述业务分析数据；
35.将所述业务分析数据携带于第二响应消息中发送至所述业务终端，以使所述业务终端利用所述业务分析数据进行业务分析。
36.本技术实施例提供一种数据中台和业务中台的构建装置，所述装置包括：
37.获取模块，用于获取用于构建数据中台的第一源数据和用于构建业务中台的第二源数据，所述数据中台包括用户数据中台，所述业务中台包括业务分析中台；
38.融合模块，用于对所述第一源数据和所述第二源数据进行数据融合处理，得到原始数据；
39.第一确定模块，用于根据所述原始数据，确定用户特征数据和业务分析数据；
40.第二确定模块，用于根据所述原始数据、所述用户特征数据和所述业务分析数据确定所述用户数据中台与所述业务分析中台的公共维度表；
41.第一构建模块，用于基于所述用户特征数据构建得到用户数据中台；
42.第二构建模块，用于基于所述业务分析数据和所述公共维度表构建得到业务分析中台。
43.本技术实施例提供一种电子设备，包括：处理器、存储器、通信接口和通信总线，所
述处理器、所述存储器和所述通信接口通过所述通信总线完成相互间的通信；
44.所述存储器用于存放至少一可执行指令，所述可执行指令使所述处理器执行上述数据中台和业务中台的构建方法的步骤。
45.本技术实施例提供一种计算机可读存储介质，所述存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行上述数据中台和业务中台的构建方法的步骤。
46.本技术实施例提供的数据中台和业务中台的构建方法，首先获取用于构建用户数据中台的第一源数据和用于构建业务分析中台的第二源数据，对第一源数据和第二源数据进行数据融合处理，得到原始数据，根据原始数据确定用户特征数据和业务分析数据，并根据原始数据、用户特征数据和业务分析数据确定用户数据中台与业务分析中台的公共维度表；基于用户特征数据构建得到用户数据中台，并基于业务分析数据和公共维度表构建得到业务分析中台。如此，无需多次接入源数据，通过一次性接入第一源数据和第二源数据得到用户数据中台和业务分析中台共用的原始数据，相比现有技术中用户数据中台和业务分析中台分别接入源数据构建中台，不仅能够缩短多个中台的构建时长，节约构建成本，而且将多个数据源融合能够去除冗余的、不一致的数据，在减少占用内存的同时，能够确保业务从营到销转换过程地无缝连接。
附图说明
47.在附图(其不一定是按比例绘制的)中，相似的附图标记可在不同的视图中描述相似的部件。附图以示例而非限制的方式大体示出了本文中所讨论的各个实施例。
48.图1为本技术实施例提供的数据中台和业务中台的构建方法的一种实现流程示意图；
49.图2为本技术实施例提供的数据中台和业务中台的构建方法的另一种实现流程示意图；
50.图3为本技术实施例提供的数据中台和业务中台的构建方法的又一种实现流程示意图；
51.图4a为传统技术中建设用户数据平台的架构示意图；
52.图4b为传统技术中建设分析数据平台的架构示意图；
53.图5为本技术实施例中对“用户”概念定义的示意图；
54.图6为本技术实施例中建设用户数据中台和业务分析数据相融合平台的架构示意图；
55.图7为本技术实施例提供的数据中台和业务中台的构建装置的一种组成结构示意图；
56.图8为本技术实施例提供的电子设备的一种组成结构示意图。
具体实施方式
57.为了使本技术的目的、技术方案和优点更加清楚，下面将结合附图对本技术作进一步地详细描述，所描述的实施例不应视为对本技术的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本技术保护的范围。
58.在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可
以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。
59.在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本技术实施例能够以除了在这里图示或描述的以外的顺序实施。
60.除非另有定义，本文所使用的所有的技术和科学术语与属于本技术的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本技术实施例的目的，不是旨在限制本技术。
61.对本技术实施例进行详细说明之前，先对相关技术中方法进行说明。
62.相关技术中，在品牌导入期就会开始用户运营能力的建设，在该场景下的对数据平台的能力需求，偏向于用户数据中台，核心挑战在于用户身份的识别，用户画像和标签体系的搭建以及用户触达能力的加强。随着业务发展，电商、售前、销售、售后等以销售为目的，服务为核心的业务环节开始运行。这个场景下，对数据平台的能力需求，偏向于传统数据仓库应对业务分析。由于建立时机和建立主体的差异，相关技术中用户运营能力和业务分析能力是单独建设的，建设时存在冗余数据，不仅增加数据建设成本，而且不利于数据融合，影响业务从营到销的转换过程。
63.为了解决上述技术问题，本技术实施例提供一种数据中台和业务中台的构建方法。下面结合实现本技术实施例的装置对本技术实施例提供的方法进行说明。图1为本技术实施例提供的数据中台和业务中台的构建方法的一种实现流程示意图，如图1所示，该数据中台和业务中台的构建方法包括以下步骤：
64.步骤s101，获取用于构建数据中台的第一源数据和用于构建业务中台的第二源数据。
65.本技术实施例可以由数据中台和业务中台的构建装置执行。数据中台和业务中台的构建装置首先获取构建多个中台需要用到的源数据，不同中台的源数据可能存在相同的数据。本技术实施例中，数据中台可以包括用户数据中台，业务中台可以包括业务分析中台。
66.下面以新能源汽车营销场景，对构建用户数据中台和业务分析中台进行说明。在品牌导入期，主要由市场部门或用户发展中心开始用户运营能力的建设，采集各类用户相关数据，将此阶段采集的所有数据作为第一源数据。随着业务发展，数据分析部门基于电商、售前、销售、售后等以销售为目的、服务为核心的业务环节开始建设企业数据仓库，采集该些数据作为第二源数据。在汽车营销场景中，第一源数据和第二源数据可以包括从以下至少一个采集的数据：广告/检测、应用程序(app，application)/内容管理系统(cms，content management system)，行为埋点、网站、电商、社群、售前、销售、工单、车机、业务主数据和财务分析。
67.步骤s102，对第一源数据和第二源数据进行数据融合处理，得到原始数据。
68.由于第一源数据和第二源数据是由不同部门针对不同需求独立获取的数据，中间存在冗余、不一致的数据，为了便于汽车运营阶段至汽车销售阶段的无缝连接，对第一源数据和第二源数据进行数据融合处理，得到原始数据，该原始数据包括不同部门在不同阶段、
针对不同需求采集的用户类数据和业务类数据。在一些实施例中，该步骤s102可以通过以下步骤来实现：
69.步骤s1021，对第一源数据和第二源数据进行规范化处理，得到规范数据。
70.这里的规范化处理包括融合处理和结构化处理。数据中台和业务中台的构建装置获取到第一源数据和第二源数据后，对第一源数据和第二源数据进行融合，得到融合数据，该融合数据为一致数据，即融合过程中去除不一致数据，确保融合数据是一致的，不会存在冲突；然后将融合数据进行结构化处理，得到规范数据。结构化处理得到的规范数据也称作行数据，是由二维表结构来逻辑表达和实现的数据，严格地遵循数据格式与长度规范，主要通过关系型数据库进行存储和管理。
71.本技术实施例中，为了便于存储，将非结构化数据(例如word文档、可扩展标记语言xml文件、超文本标记语言html文件、图片、音频等数据)结构化处理，使其能够利用二维表结构来存储。在存储时，可以将规范数据存储在数据贴源层。
72.步骤s1022，对规范数据进行抽取、转换和加载处理，得到原始数据。
73.对规范数据进行抽取(extract)、交互转换(transform)、加载(load)处理，使其从来源段存储至目的端，该目的端即为数据贴源层。在实现时，可以结合实际应用场景，采用informatica、kettle、datastage或其他工具对规范数据进行抽取、转换和加载(etl，extract-transform-load)处理。
74.本技术实施例中，由于经过规范化处理为规范数据，使得用户数据和业务数据共用一个数据贴源层，能够节约成本；并且，在数据贴源层中，重复数据只存储一次，可以去除不一致数据，节省存储空间。
75.步骤s103，根据原始数据，确定用户特征数据和业务分析数据。
76.描述用户的数据和描述业务的数据是不同的，基于属性的区别，从原始数据中确定出哪些数据是与用户相关的用户特征数据，哪些数据是与业务相关的业务分析数据。例如用户a的身份证号、手机号、性别、住址、消费力、喜好、app账号等等，都是该用户a的特征数据；车辆b的生产商、销售网址、车辆标识码、出厂指导价格、建议销售价格、优惠政策等等，都是该车辆b的业务分析数据。
77.在一些实施例中，根据原始数据确定业务分析数据可以通过以下步骤来实现：根据原始数据，提取业务明细数据；根据业务明细数据，提取轻度汇总数据；根据轻度汇总数据，提取应用汇总数据；将业务明细数据、轻度汇总数据和应用汇总数据确定为业务分析数据。
78.这里，业务明细数据、轻度汇总数据和应用汇总数据是对业务分析数据的不同级别的抽象。原始数据中存储有所有数据，比如存在100条业务原始数据，业务明细数据表中存储业务明细数据，经过步骤s102的处理，使得业务数据条数减少，明细数据表中可能剩下95条数据，明细数据表中存储的每条业务数据，包括与该业务相关的所有明细数据。继续对明细数据表中的95条业务明细数据进行轻度汇总分类，例如得到50条轻度汇总数据，将其存储在轻度汇总表中。然后，可以根据不同的应用，对轻度汇总数据进行进一步分层处理，得到应用汇总数据，例如，按照销售地址，对不同区域地址的业务数据进行分类汇总，或者，按照汽车类型，对不同类型的汽车的销售业务数据进行分类汇总，假如预设有5种不同的应用，则将50条轻度汇总数据按照该5种应用分层汇总为5条数据，存储至应用汇总表中。
79.在一些实施例中，根据原始数据确定用户特征数据可以通过以下步骤来实现：根据原始数据，提取用户标识映射关系；根据用户标识映射关系和业务明细数据，提取用户标签；将用户标识映射关系和用户标签确定为用户特征数据。
80.这里，用户标识映射关系可以由身份标识(id，identity document)子系统从原始数据中提取，将原始数据输入至id子系统，识别出所有用户id、设备id等与用户相关的id，如手机号、app的id号、用来定义网络设备的位置的媒体存取控制位址(mac，media access control address)地址等等，id子系统对识别得到的所有id去重，根据用户id、设备id及其相关联的各类id(如电商平台id号、社区号等)之间的对应关系，确定出用户标识映射关系，存储至用户标识映射关系表中。
81.用户标签可以由标签子系统来提取，用户标签是对用户进行画像得到的标签，本技术实施例中，为了提取出更加精确的用户标签，可以结合业务明细数据对用户进行画像，将用户标识映射关系和业务明细数据输入至标签子系统进行用户标签的提取，最后输出用户标签，将用户标签存储至用户标签表中。例如某用户的标签为喜欢红色(用户特征)、发烧友(购买过发烧友级别的音响)、有2个小孩(根据用户标识映射关系分析得到的)、喜欢纯电动车(明细数据表中存在该用户租赁纯电动汽车的业务明细数据)。当处理推荐汽车相关的业务时，可以向该用户精准地推荐红色、音响高端配置、7座的纯电动汽车。
82.在实际应用中，可以和相关技术一样，仅根据用户标识映射关系进行用户画像，提取出用户标签。例如某用户的标签为喜欢红色(用户特征)、有2个小孩(根据用户标识映射关系分析得到的)。当处理推荐汽车相关的业务时，可以向该用户推荐红色、7座的汽车。
83.步骤s104，根据原始数据、用户特征数据和业务分析数据确定用户数据中台与业务分析中台的公共维度表。
84.本技术实施例中，公共维度表可以根据以下步骤来确定：根据原始数据，提取主维表；根据用户特征数据，确定用户相关维表；根据业务分析数据，确定业务相关维表；将主维表、用户相关维表和业务相关维表确定为用户数据中台与业务分析中台的公共维度表。
85.该公共维度表包括主维表和相关维表，主维表中可以存储各数据表的主键。其中相关维表包括用户相关维表和业务相关维表，用户相关维表中存储用户数据库表的索引，用户数据库表中存储用户特征数据；业务相关维表中存储业务数据库表的索引，业务数据库表中存储业务分析数据。
86.本技术实施例中，建立一个包括用户数据库表中主键和业务数据库表中主键的公共维度表，该公共维度表相当于一个公共索引表。当用户数据中台需要使用业务分析数据处理用户数据时，可以根据该公共维度表查询出至哪一数据表查询所需业务数据；当业务分析中台需要使用用户特征数据处理业务数据时，可以根据该公共维度表查询出至哪一数据表查询所需用户数据，如此实现不同源数据共用原始数据，确保业务从营到销转换过程地无缝连接。
87.步骤s105，基于用户特征数据构建得到用户数据中台。
88.根据用户标识映射关系和用户标签构建用于处理用户业务的用户数据中台，利用该用户数据中台，可以以用户为中心，进行全业务系统的检测，实现智慧洞察、触达和零售，为用户提供便捷。
89.步骤s106，基于业务分析数据和公共维度表构建得到业务分析中台。
90.根据业务分析数据和公共维度表构建用于处理业务分析的业务分析中台，利用该业务分析中台，可以实现以业务为中心的数据处理与应用。
91.本技术实施例提供的数据中台和业务中台的构建方法，包括获取用于构建数据中台的第一源数据和用于构建业务中台的第二源数据，数据中台包括用户数据中台，业务中台包括业务分析中台；对第一源数据和第二源数据进行数据融合处理，得到原始数据；根据原始数据，确定用户特征数据和业务分析数据，并根据原始数据、用户特征数据和业务分析数据确定用户数据中台与业务分析中台的公共维度表；基于用户特征数据构建得到用户数据中台，并基于业务分析数据和公共维度表构建得到业务分析中台。如此，无需多次接入源数据，通过一次性接入第一源数据和第二源数据得到用户数据中台和业务分析中台共用的原始数据，相比现有技术中用户数据中台和业务分析中台分别接入源数据构建中台，不仅能够缩短多个中台的构建时长，节约构建成本，而且将多个数据源融合能够去除冗余的、不一致的数据，在减少占用内存的同时，能够确保业务从营到销转换过程地无缝连接。
92.在图1所示实施例的基础上，本技术实施例再提供一种数据中台和业务中台的构建方法。图2为本技术实施例提供的数据中台和业务中台的构建方法的另一种实现流程示意图，如图2所示，该方法包括以下步骤：
93.步骤s201，获取用于构建数据中台的第一源数据和用于构建业务中台的第二源数据。
94.其中数据中台可以包括用户数据中台，业务中台可以包括业务分析中台。
95.步骤s202，对第一源数据和第二源数据进行数据融合处理，得到原始数据。
96.步骤s203，根据原始数据，确定用户特征数据和业务分析数据。
97.步骤s204，根据原始数据、用户特征数据和业务分析数据确定用户数据中台与业务分析中台的公共维度表。
98.步骤s205，基于用户特征数据构建得到用户数据中台。
99.步骤s206，基于业务分析数据和公共维度表构建得到业务分析中台。
100.本技术实施例中的步骤s201至步骤s206，与图1所示实施例中的步骤s101至步骤s106一一对应，步骤s201至步骤s206的实现方式，分别参见步骤s101至步骤s106的详细说明。
101.步骤s207，利用构建得到的业务分析中台接收服务终端发送的第一请求消息。
102.这里的第一请求消息用于获取报表服务数据。本技术实施例中的业务分析中台可以提供报表服务功能。数据中台和业务中台的构建装置利用业务分析中台接收服务终端发送的用于获取报表服务数据的第一请求消息，对该第一请求消息进行解析，得到解析结果，该解析结果用于确定需要查询哪些数据。
103.步骤s208，根据应用汇总数据，确定报表服务数据。
104.根据解析结果，从应用汇总数据中，查询得到所需的报表服务数据。
105.步骤s209，将报表服务数据携带于第一响应消息中发送至服务终端，以使服务终端利用报表服务数据生成业务报表。
106.数据中台和业务中台的构建装置根据查询得到的报表服务数据生成第一响应消息，将该第一响应消息发送至服务终端。服务终端接收到第一响应消息并对其进行解析，得到报表服务数据，然后利用报表服务数据生成不同内容的业务报表。
107.在实际应用中，服务终端可以结合业务类型，生成用户报表、内容报表、电商报表、销售报表以及售后报表等不同内容的业务报表，满足不同业务报表需求。
108.在图1所示实施例的基础上，本技术实施例再提供一种数据中台和业务中台的构建方法。图3为本技术实施例提供的数据中台和业务中台的构建方法的又一种实现流程示意图，如图3所示，该方法包括以下步骤：
109.步骤s301，获取用于构建数据中台的第一源数据和用于构建业务中台的第二源数据。
110.其中数据中台可以包括用户数据中台，业务中台可以包括业务分析中台。
111.步骤s302，对第一源数据和第二源数据进行数据融合处理，得到原始数据。
112.步骤s303，根据原始数据，确定用户特征数据和业务分析数据。
113.步骤s304，根据原始数据、用户特征数据和业务分析数据确定用户数据中台与业务分析中台的公共维度表。
114.步骤s305，基于用户特征数据构建得到用户数据中台。
115.步骤s306，基于业务分析数据和公共维度表构建得到业务分析中台。
116.本技术实施例中的步骤s301至步骤s306，与图1所示实施例中的步骤s101至步骤s106一一对应，步骤s301至步骤s306的实现方式，分别参见步骤s101至步骤s106的详细说明。
117.步骤s307，利用构建得到的业务分析中台接收业务终端发送的第二请求消息。
118.这里的第二请求消息用于获取业务分析数据。本技术实施例中业务分析中台可以提供业务分析功能。数据中台和业务中台的构建装置利用业务分析中台接收业务终端发送的用于获取业务分析数据的第二请求消息，对该第二请求消息进行解析，得到解析结果，该解析结果用于确定需要查询哪些数据。
119.步骤s308，根据业务明细数据、轻度汇总数据、应用汇总数据、主维表、用户相关维表和业务相关维表，确定业务分析数据。
120.根据解析结果，从业务明细数据、轻度汇总数据、应用汇总数据、主维表、用户相关维表和业务相关维表中，查询得到所需的业务分析数据。
121.步骤s309，将业务分析数据携带于第二响应消息中发送至业务终端，以使业务终端利用业务分析数据进行业务分析。
122.数据中台和业务中台的构建装置根据查询得到的业务分析数据生成第二响应消息，将该第二响应消息发送至业务终端。业务终端接收到第二响应消息并对其进行解析，得到业务分析数据，然后利用业务分析数据进行不同类型的业务处理。
123.在实际应用中，业务终端可以结合业务类型，进行用户分群、社群关键意见消费者(koc，key opinion consumer)、销售效能、电商选品、收益管理等业务处理，实现各自不同业务。
124.下面，将说明本技术实施例在一个实际的应用场景中的示例性应用。
125.随着国内新能源汽车企业的兴起，智能化和全面用户体验成为新能源汽车品牌区别于传统品牌的重要竞争力，甚至在新兴品牌中，c端用户运营和以用户(而非渠道或经销商)为核心考量的业务流程，成为了一种基本能力。为此，需要建立起以用户为中心的数据体系，以科学化的管理和提升用户运营效率和用户体验。对新兴新能源汽车企业，一般在品
牌导入期，即会开始用户运营能力的建设，传统企业的线索搜集工作被提前，被更具洞察的用户数据中台、更具粘性的用户社群等优化提升。这个场景下的对数据平台的能力需求，偏向于用户数据中台，核心挑战在于用户身份的识别，用户画像和标签体系搭建，用户触达能力的加强。
126.随着业务发展，电商、售前、销售、售后等以销售为目的，服务为核心的业务环节开始运行。这个场景下，对数据平台的能力需求，偏向于传统数据仓库应对业务分析，挑战在于迅速地对接多个业务系统，整合并在对接数据越来越复杂，业务不断迭代地情况下，依然保持数据结构地相对稳定，为下游分析应用提供一致地接口。
127.图4a为传统技术中建设用户数据平台的架构示意图，图4b为传统技术中建设分析数据平台的架构示意图，如图4a和图4b所示，传统技术中，前述两种能力建设是独立的，主要原因为：1)建立先后有差异，用户数据中台的理念在企业被大量接受，和市面上产品的成熟度达到一定应用规模，都是在近几年；而传统的企业数据仓库早已建设。2)主导团队不同，用户数据能力建设基本由营销导向的团队建设(如市场部门，用户发展中心等)，而企业数据仓库大多由纯分析部门甚至互联网技术(internet technology)部门所主导。由于用户数据平台和分析数据平台是独立建设的，该两个平台是分两次接入源数据的，在处理业务时，两个平台之间无合力，影响新能源汽车从营到销的转换过程。
128.在实际应用中，显然可以发现，这两种数据建设是有共通之处的，作为数据类产品，不管是相关技术建设，还是部分的设计理念，是相通的。另外更重要的，对新兴新能源汽车企业而言，时间就是生命，从营到销的转换过程是非常迅速无缝的。因此在分析能力建设上，需要摒弃两种数据平台独立的做法，可以由业务部门统一主导，搭建以用户为核心的用户中台和业务分析平台融合的数据平台。图5为本技术实施例中对“用户”概念定义的示意图，如图5所示，可以看到“用户”是横跨所有核心业务场景的。
129.图6为本技术实施例中建设用户数据中台和业务分析数据相融合平台的架构示意图，下面结合图6对本技术实施例的方法进行说明。
130.数据贴源层ods共用，ods目的是保留原始数据，解耦业务系统。一般分析型系统都需要，而在融合的方案下，可以公用一个ods层，节约成本，也去除数据不一致。
131.用户数据平台(图6中虚线框部分)的id子系统，和标签子系统，作为维度表，丰富业务分析最关键的用户维度数据。其中id子系统的输入是所有原始数据中可识别的用户id、设备id(如手机号、企业用户id、设备号、app op enid)，输出为映射去重的唯一用户/设备标识(记为oneid)和与之相关的各类id；而标签子系统在oneid的基础上，根据业务数据中用户行为等数据，构建和输出用户标签。
132.业务分析数据(图6中灰色部分)，会尽最大可能打通所有业务端，主要体现在数据清洗和公共维度表的提取后，不同数据源相同维度的分析可互通。而dwd数据标准化层的用户行为部分的数据，也可以作为用户数据平台标签子系统的输入，这样用户标签和业务分析可以使用同一套源数据确保统一，并且也省去二次清洗的过程。业务分析数据进一步解耦为dws轻度汇总层，和针对部分业务建立的分析数据层ads。
133.本技术实施例是根据在业务过程中的融合用户数据中台，和业务分系平台的实践，提炼出来的从营到销的业务分析型数据平台分层设计。其创造性地在分层架构设计上，将两类数据产品共有地能力提炼、解耦，关键思路为：提取两类数据产品共用的数据分层，
用户数据中台的部分数据对业务分析输出，业务分析建模过程中也对用户数据中台输出。额外地，在架构设计之外，因为前述的技术相通性和沟通成本的节约，融合的数据平台建设成本可以小于单独构建两次的成本，达到节约成本的效果，同时从时间上保障业务的无缝衔接。
134.基于前述的实施例，本技术实施例提供一种数据中台和业务中台的构建装置，该装置包括的各模块、以及各模块包括的各单元，可以通过计算机设备中的处理器来实现；当然也可通过具体的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(cpu，central processing unit)、微处理器(mpu，microprocessor unit)、数字信号处理器(dsp，digital signal processing)或现场可编程门阵列(fpga，field programmable gate array)等。
135.本技术实施例再提供一种数据中台和业务中台的构建装置，图7为本技术实施例提供的数据中台和业务中台的构建装置的一种组成结构示意图，如图7所示，所述数据中台和业务中台的构建装置700包括：
136.获取模块701，用于获取用于构建数据中台的第一源数据和用于构建业务中台的第二源数据，所述数据中台包括用户数据中台，所述业务中台包括业务分析中台；
137.融合模块702，用于对所述第一源数据和所述第二源数据进行数据融合处理，得到原始数据；
138.第一确定模块703，用于根据所述原始数据，确定用户特征数据和业务分析数据；
139.第二确定模块704，用于根据所述原始数据、所述用户特征数据和所述业务分析数据确定所述用户数据中台与所述业务分析中台的公共维度表；
140.第一构建模块705，用于基于所述用户特征数据构建得到用户数据中台；
141.第二构建模块706，用于基于所述业务分析数据和所述公共维度表构建得到业务分析中台。
142.在一些实施例中，所述融合模块702，还用于：
143.对所述第一源数据和所述第二源数据进行规范化处理，得到规范数据；
144.对所述规范数据进行抽取、转换和加载处理，得到原始数据。
145.在一些实施例中，所述第一确定模块703，还用于：
146.根据所述原始数据，提取业务明细数据；根据所述业务明细数据，提取轻度汇总数据；根据所述轻度汇总数据，提取应用汇总数据；将所述业务明细数据、所述轻度汇总数据和所述应用汇总数据确定为业务分析数据。
147.在一些实施例中，所述第一确定模块703，还用于：
148.根据所述原始数据，提取用户标识映射关系；根据所述用户标识映射关系和所述业务明细数据，提取用户标签；将所述用户标识映射关系和所述用户标签确定为用户特征数据。
149.在一些实施例中，所述第二确定模块704，还用于：
150.根据所述原始数据，提取主维表；根据所述用户特征数据，确定用户相关维表；根据所述业务分析数据，确定业务相关维表；将所述主维表、用户相关维表和业务相关维表确定为所述用户数据中台与所述业务分析中台的公共维度表。
151.在一些实施例中，所述数据中台和业务中台的构建装置700，还可以包括：
152.第一接收模块，用于利用构建得到的业务分析中台接收服务终端发送的第一请求消息，所述第一请求消息用于获取报表服务数据；
153.第三确定模块，用于根据所述应用汇总数据，确定所述报表服务数据；
154.第一发送模块，用于将所述报表服务数据携带于第一响应消息中发送至所述服务终端，以使所述服务终端利用所述报表服务数据生成业务报表。
155.在一些实施例中，所述数据中台和业务中台的构建装置700，还可以包括：
156.第二接收模块，用于利用构建得到的业务分析中台接收业务终端发送的第二请求消息，所述第二请求消息用于获取业务分析数据；
157.第四确定模块，用于根据所述业务明细数据、轻度汇总数据、应用汇总数据、主维表、用户相关维表和业务相关维表，确定所述业务分析数据；
158.第二发送模块，用于将所述业务分析数据携带于第二响应消息中发送至所述业务终端，以使所述业务终端利用所述业务分析数据进行业务分析。
159.这里需要指出的是：以上数据中台和业务中台的构建装置实施例项的描述，与上述方法描述是类似的，具有同方法实施例相同的有益效果。对于本技术装置实施例中未披露的技术细节，本领域的技术人员请参照本技术方法实施例的描述而理解。
160.需要说明的是，本技术实施例中，如果以软件功能模块的形式实现上述方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本技术各个实施例所述方法的全部或部分。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read only memory)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本技术实施例不限制于任何特定的硬件和软件结合。
161.相应地，本技术实施例提供一种计算机可读存储介质，该存储介质中存储有至少一可执行指令，所述可执行指令使处理器执行上述实施例中提供的数据中台和业务中台的构建方法中的步骤。
162.本技术实施例提供一种电子设备，图8为本技术实施例提供的电子设备的一种组成结构示意图，根据图8示出的电子设备800的示例性结构，可以预见电子设备800的其他的示例性结构，因此这里所描述的结构不应视为限制，例如可以省略下文所描述的部分组件，或者，增设下文所未记载的组件以适应某些应用的特殊需求。
163.图8所示的电子设备800包括：一个处理器801、至少一个通信总线802、用户接口803、至少一个外部通信接口804和存储器805。其中，通信总线802配置为实现这些组件之间的连接通信。其中，用户接口803可以包括显示屏，外部通信接口804可以包括标准的有线接口和无线接口。其中，所述处理器801配置为执行存储器中存储的数据中台和业务中台的构建方法的程序，以实现上述实施例提供的数据中台和业务中台的构建方法中的步骤。
164.以上电子设备和存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本技术电子设备和存储介质实施例中未披露的技术细节，请参照本技术方法实施例的描述而理解。
165.应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的
特定特征、结构或特性包括在本技术的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本技术的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本技术实施例的实施过程构成任何限定。上述本技术实施例序号仅仅为了描述，不代表实施例的优劣。
166.需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个
……”
限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。
167.在本技术所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。
168.上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。
169.另外，在本技术各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
170.本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、rom、磁碟或者光盘等各种可以存储程序代码的介质。
171.或者，本技术上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本技术实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台设备执行本技术各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、rom、磁碟或者光盘等各种可以存储程序代码的介质。
172.以上所述，仅为本技术的实施方式，但本技术的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本技术揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本技术的保护范围之内。因此，本技术的保护范围应以所述权利要求的保护范围为准。