CN112494933A

CN112494933A - 游戏数据仓库构建方法及装置

Info

Publication number: CN112494933A
Application number: CN202011418404.4A
Authority: CN
Inventors: 张嘉茗
Original assignee: Shanghai Bilibili Technology Co Ltd
Current assignee: Shanghai Bilibili Technology Co Ltd
Priority date: 2020-12-07
Filing date: 2020-12-07
Publication date: 2021-03-16
Anticipated expiration: 2040-12-07
Also published as: CN112494933B

Abstract

本说明书提供游戏数据仓库构建方法及装置，其中所述游戏数据仓库构建方法包括：获取至少两个游戏日志数据，每个所述游戏日志数据与一个游戏对应；按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合；其中，所述公共数据指标包括所述至少两个游戏日志数据对应的共性数据指标和个性数据指标。如此，可以按照一定的数据仓库模型，对不同数据源的游戏日志数据进行采集、整理，将不同来源的游戏日志数据汇总至一张业务报表中，避免了重复计算的资源浪费，无需重复存储，大大提升了开发效率。

Description

游戏数据仓库构建方法及装置

技术领域

本说明书涉及数据处理技术领域，特别涉及一种游戏数据仓库构建方法。本说明书同时涉及一种游戏数据仓库构建装置，一种计算设备，以及一种计算机可读存储介质。

背景技术

随着计算机技术的快速发展，人们的娱乐需求也越来越高，越来越多的人们喜欢在空余时间玩游戏，各式各样的游戏应运而生。为了进行游戏研发、分析和改进，游戏开发商往往需要基于大量的游戏日志数据进行决策制定。

现有技术中，往往是通过构建数据仓库的方式，汇总大量的游戏日志数据，提供给游戏开发商查询，以支持游戏开发商制定决策。目前，构建游戏数据仓库一般是针对不同的游戏，汇总得到多个查询表提供给游戏开发商。

然而，上述游戏数据仓库的构建方法，针对不同数据源的游戏日志数据，需要分开进行处理，无法综合处理不同来源的游戏日志数据，造成了重复计算的资源浪费，重复存储严重，开发效率较低。

发明内容

有鉴于此，本说明书实施例提供了一种游戏数据仓库构建方法。本说明书同时涉及一种游戏数据仓库构建装置，一种计算设备，以及一种计算机可读存储介质，以解决现有技术中存在的资源浪费、重复存储严重和开发效率较低等问题。

根据本说明书实施例的第一方面，提供了一种游戏数据仓库构建方法，包括：

获取至少两个游戏日志数据，每个所述游戏日志数据与一个游戏对应；

按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合；

其中，所述公共数据指标包括所述至少两个游戏日志数据对应的共性数据指标和个性数据指标。

根据本说明书实施例的第二方面，提供了一种游戏数据仓库构建装置，包括：

获取模块，被配置为获取至少两个游戏日志数据，每个所述游戏日志数据与一个游戏对应；

聚合模块，被配置为按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合；

根据本说明书实施例的第三方面，提供了一种计算设备，包括：

存储器和处理器；

所述存储器用于存储计算机可执行指令，所述处理器用于执行所述计算机可执行指令，以实现下述方法：

根据本说明书实施例的第四方面，提供了一种计算机可读存储介质，其存储有计算机可执行指令，该指令被处理器执行时实现任意所述游戏数据仓库构建方法的步骤。

本说明书提供的游戏数据仓库构建方法，获取至少两个游戏日志数据，每个所述游戏日志数据与一个游戏对应；按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合；其中，所述公共数据指标包括所述至少两个游戏日志数据对应的共性数据指标和个性数据指标。这种情况下，可以按照一定的数据仓库模型，对不同数据源的游戏日志数据进行采集、整理，将不同来源的游戏日志数据汇总至一张业务报表中，避免了重复计算的资源浪费，无需重复存储，大大提升了开发效率；并且，提供了不同来源、跨部门、完全一致的业务报表数据，提高了数据仓库的查询效率，通过数据仓库可以满足游戏开发商各个业务部门多样化的数据需求，为游戏开发商决策提供全面的数据支持，从而提升用户游戏体验，降低用户流失率。

附图说明

图1是本说明书一实施例提供的一种游戏数据仓库构建方法的流程图；

图2是本说明书一实施例提供的一种设计游戏数据仓库的流程图；

图3是本说明书一实施例提供的一种游戏数据仓库的核心架构图；

图4是本说明书一实施例提供的一种游戏数据仓库构建装置的结构示意图；

图5是本说明书一实施例提供的一种计算设备的结构框图。

具体实施方式

在下面的描述中阐述了很多具体细节以便于充分理解本说明书。但是本说明书能够以很多不同于在此描述的其它方式来实施，本领域技术人员可以在不违背本说明书内涵的情况下做类似推广，因此本说明书不受下面公开的具体实施的限制。

在本说明书一个或多个实施例中使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本说明书一个或多个实施例。在本说明书一个或多个实施例和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本说明书一个或多个实施例中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本说明书一个或多个实施例中可能采用术语第一、第二等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本说明书一个或多个实施例范围的情况下，第一也可以被称为第二，类似地，第二也可以被称为第一。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

首先，对本说明书一个或多个实施例涉及的名词术语进行解释。

数据仓库：英文名称为Data Warehouse，可简写为DW或DWH。数据仓库，是为企业所有级别的决策制定过程，提供所有类型数据支持的战略集合，是单个数据存储，出于分析性报告和决策支持目的而创建。为需要业务智能的企业，提供指导业务流程改进、监视时间、成本、质量以及控制。数据仓库是决策支持系统(dss)和联机分析应用数据源的结构化数据环境，研究和解决从数据库中获取信息的问题。数据仓库是一个面向主题的、集成的、相对稳定的、反映历史变化的数据集合，用于支持管理决策，表是数据仓库的重要组成部分，一个表记录由关键字(key)、度量和属性数据组成。

数据集市：Data Mart，也叫数据市场，是一个从操作的数据和其他的为某个特殊的专业人员团体服务的数据源中收集数据的仓库。从范围上来说，数据是从企业范围的数据库、数据仓库，或者是更加专业的数据仓库中抽取出来的。数据集市的重点就在于它迎合了专业用户群体的特殊需求，在分析、内容、表现，以及易用方面。数据集市的用户希望数据是由他们熟悉的术语表现的。

ETL：是英文Extract-Transform-Load的缩写，用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据，ETL是BI(商业智能)项目重要的一个环节。

STG：数据缓冲层，Staging Area的缩写，是缓存来自数据库抽取、消息、日志解析落地的临时数据，结构与业务系统保持一致；负责对垃圾数据、不规范数据进行清洗转换。

ODS：操作数据层，Operational Data Store的缩写，定位于业务明细数据保留区，负责保留数据接入时点后历史变更数据，数据原则上全量保留。

DWD：明细数据层，Data Warehouse Detail的缩写，是整合后的业务过程明细数据，负责各业务场景垂直与水平数据整合、常用公共维度冗余加工，以及明细业务标签信息加工。

DWS：汇总数据层，Data Warehouse Summary的缩写，按照主题对共性维度指标数据进行轻度、高度聚合。

DIM：维度数据层，Dimension的缩写，对维度进行统一标准化定义，实现维度信息共享。

ADS：应用数据层，Application Data Store的缩写，主要用于各产品或各业务条线个性化的数据加工，例如，商业化产品数据、搜索推荐、风控等。

宽表模型：基于某个实体分析对象而建立的一个逻辑数据体系，由实体的维度、描述信息、以及基于这个实体一系列度量组成。

事实表：每个数据仓库都包含一个或者多个事实表。事实表通常包含大量的行，事实表的主要特点是包含数字数据(事实)，并且这些数字信息可以汇总，以提供有关单位作为历史的数据，每个事实表包含一个由多个部分组成的索引，该索引包含作为外键的相关性维度表的主键，而维度表包含事实记录的特性。事实表不应该包含描述性的信息，也不应该包含除数字度量字段及使事实与维度表中对应项的相关索引字段之外的任何数据。

维度表：数据仓库中的表，其条目描述事实表中的数据。维度表包含创建维度所基于的数据。例如，事实表中存放实际数据，包括游戏账号、登录时间、支付金额、支付时间等；维度表中存放用户账号、游戏产品、、游戏渠道、区域维表等。

接下来，对本说明书的应用场景进行解释说明。

为了进行游戏研发、分析和改进，游戏开发商往往需要基于大量的游戏日志数据进行决策制定。目前，往往是通过构建数据仓库的方式，汇总大量的游戏日志数据，提供给游戏开发商查询，以支持游戏开发商制定决策。

数据仓库的发展经历了2个阶段，简单报表阶段和数据集市阶段。其中，简单报表阶段，工程师可以通过写shell脚本连接数据库，提取数据计算指标，再将结果存入数据库，通过前端报表展示，这个阶段主要是提供基础的日常报表，以及简单的辅助决策的汇总数据。数据集市阶段，引入数据ETL工具，封装各个数据库的连接，将数据抽取和转换统一使用数据库来表示，进行多维报表的展现，提供对特定业务指导的数据，以及特定的领导决策数据。

然而，简单报表阶段中，数据的清洗和转化没有统一的方法，无法综合使用不同数据源的数据，代码很难管理和维护，并且随着需求的增加，严重影响开发效率。数据集市阶段中，尽管通过引入ELT工具，解决了不同数据源联合使用的问题，但是没有统一的规范标准管理，即虽然数据仓库可以存储不同来源的数据，但是每个来源的数据单独存储于一张业务报表中，造成了重复计算的资源浪费；且数据的层次和粒度不清晰，重复存储严重；取数门槛高，口径复杂不易计算。

例如，如果需要游戏A、游戏B和游戏C的游戏日志数据，则需要单独针对游戏A、游戏B和游戏C的游戏日志数据分别进行划分汇总，以分别提供游戏A、游戏B和游戏C对应的业务报表给业务需求方，但游戏A、游戏B和游戏C中有些游戏日志数据的指标是相同的，如游戏A、游戏B和游戏C中可能都包括登录数据、充值数据等，需要分别在游戏A、游戏B和游戏C对应的业务报表进行存储，即需要重复存储3次。

因而，为了节省存储资源，提高开发效率，本说明书提供了一种的游戏数据仓库构建方法，可以获取至少两个游戏日志数据，每个所述游戏日志数据与一个游戏对应；然后按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合；其中，所述公共数据指标包括所述至少两个游戏日志数据对应的共性数据指标和个性数据指标。如此，可以按照一定的数据仓库模型，对不同数据源的游戏日志数据进行采集、整理，将不同来源的游戏日志数据汇总至一张业务报表中，避免了重复计算的资源浪费，无需重复存储，大大提升了开发效率。

在本说明书中，提供了一种游戏数据仓库构建方法，本说明书同时涉及一种游戏数据仓库构建装置，一种计算设备，以及一种计算机可读存储介质，在下面的实施例中逐一进行详细说明。

图1示出了根据本说明书一实施例提供的一种游戏数据仓库构建方法的流程图，具体包括以下步骤：

步骤102：获取至少两个游戏日志数据，每个所述游戏日志数据与一个游戏对应。

需要说明的是，可以从数据库中获取至少两个游戏日志数据，其中，不同的游戏日志数据对应于不同的游戏，也即至少两个游戏日志数据的数据来源均不相同。具体实现时，可以通过ETL将游戏日志数据从不同的来源端抽取(extract)出来，再经游戏数据仓库的数据缓冲层STG进行数据清洗转换，并经游戏数据仓库的操作数据层ODS保留业务明细数据。

具体实现时，可以根据获取到的至少两个游戏日志数据构建公共底层数据，也即构建一个针对不同来源、不同结构的各类游戏研发数据的公共底层数据，后续对该不同游戏、不同结构的公共底层数据进行聚合。

本实施例一个可选的实施方式中，由于至少两个游戏日志数据的来源端不同，因而需要针对至少两个游戏日志数据提前设置可以进行统一的数据指标，也即，按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合之前，还包括：

确定所述至少两个游戏日志数据对应的共性数据指标和个性数据指标，所述共性数据指标为所述至少两个游戏日志数据均包括的数据指标，所述个性数据指标为所述至少两个游戏日志数据中至少一个游戏日志数据不包括的数据指标；

根据所述共性数据指标和所述个性数据指标，设置所述公共数据指标。

需要说明的是，可以将各个不同来源的游戏日志数据都有的数据指标抽象为共性数据指标，将与共性数据指标相对应的数据存储至该共性数据指标对应的位置，避免不同游戏日志数据中相同数据指标的数据重复存储；将某些游戏特有的数据指标抽象为个性数据指标，将与个性数据指标相对应的数据存储至该个性数据指标对应的位置，避免某些游戏日志数据不同于其他游戏日志数据的个性化数据被丢掉。也就是说，在预先设置至少两个游戏日志数据对应的公共数据指标时，需要结合至少两个游戏日志数据对应的共性数据指标和个性数据指标，进行统一规范定义。

本实施例一个可选的实施方式中，根据所述共性数据指标和所述个性数据指标，设置所述公共数据指标，包括：

采集并分析业务方的业务需求；

确定所述业务需求对应的参考数据指标；

根据所述参考数据指标、所述共性数据指标和所述个性数据指标，设置所述公共数据指标。

具体的，参考数据指标是指业务需求方后期查询需要的数据指标。

需要说明的是，对游戏日志数据进行汇总后生成的业务报表，是要提供给游戏开发商，供游戏开发商决策使用，因而在对游戏日志数据进行汇总时，应该按照游戏开发商的需求进行汇总，也即在预先设置公共数据指标时应该结合业务方的业务需求，从而将预设的公共数据指标与业务方对数据指标的需求达成统一。

本实施例一个可选的实施方式中，根据所述参考数据指标、所述共性数据指标和所述个性数据指标，设置所述公共数据指标，包括：

将所述共性数据指标和所述个性数据指标确定为第一数据指标；

确定所述第一数据指标中与所述参考数据指标相同的第二数据指标；

将所述第二数据指标设置为所述公共数据指标。

需要说明的是，游戏日志数据中包括的数据指标有很多，其中可能包括业务方不需要的数据指标，后续无需汇总相关数据，因而在预先定义数据指标时，无需包括业务方不需要的数据指标，避免存储过多冗余数据，进一步节省存储资源，提高开发效率。

示例的，对游戏开发商的需求进行分析，确定出游戏开发商后续查询需要的参考数据指标为X1、X2、X3、X4、X5、X6、X7、X8、X9和X10，假设游戏A、游戏B、游戏C对应的共性数据指标为X1、X2、X6、X8、X9、X11、X11，游戏A的个性数据指标为X3，游戏B的个性数据指标为X5，游戏C的个性数据指标为X4、X7。因而，结合游戏开发商的需求对应的参考指标以及游戏A、游戏B、游戏C对应的公有指标和私有指标，预先设置公共数据指标为X1、X2、X3、X4、X5、X6、X7、X8、X9。

本实施例一个可选的实施方式中，确定所述至少两个游戏日志数据对应的共性数据指标和个性数据指标，包括：

对所述至少两个游戏日志数据进行指标提取，确定所述至少两个游戏日志数据对应的至少两个原子指标；

将所述至少两个游戏日志数据中每个游戏日志数据均包括的原子指标确定为所述共性数据指标；

将所述至少两个原子指标中除所述共性数据指标外的原子指标确定为所述个性数据指标。

需要说明的是，游戏日志数据在存储时，并没有经过拆分、提取处理，因而需要先对游戏日志数据进行指标提取，从而确定出游戏日志数据包括有哪些数据指标。

示例的，游戏日志数据为新增用户第30日累计充值金额，对该游戏日志数据进行指标提取，确定出原子指标是充值金额，其它信息都属于原子指标的修饰。

本实施例一个可选的实施方式中，根据所述共性数据指标和所述个性数据指标，设置所述公共数据指标之后，还包括：

将所述共性数据指标和所述个性数据指标作为统一事实表的不同列，构建得到统一事实表。

需要说明的是，可以将确定出的共性数据指标和个性数据指标放入统一事实表，即定义至少两个游戏日志数据对应的统一事实表，该统一事实表的不同列为预先定义的公共数据指标，后续可以根据该统一事实表进行数据汇总。也就是说，可以构建数据指标的命名规范(同一数据指标名称相同)、口径一致和算法统一的数据指标字典，为上层数据产品、应用和服务提供共性数据指标；同时将共性数据指标和个性数据指标进行抽象，抽取统一规范定义，确定业务分析需要衡量的数据指标，生成统一事实表。

本实施例一个可选的实施方式中，按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合之前，还包括：

确定所述至少两个游戏日志数据对应的业务过程；

确定所述业务过程的分析粒度；

根据所述分析粒度和所述业务过程构建统一维度表。

需要说明的是，业务过程可以为游戏用户的登录、绑定、游客转化升级、支付等过程，在业务过程分析中，需要预判分析需要细分的程度，从而决定选择的分析粒度。粒度是维度的一个组合，例如，对于游戏用户的登录过程而言，粒度可以是游戏级别，也可以是游戏、渠道的组合级别。实际实现时，可以通过游戏数据仓库中的维度数据层DIM对维度进行统一标准化定义，实现维度信息共享。

另外，选择好分析粒度之后，就可以基于此分析粒度设计统一维度表，统一维度表包括维度属性，用于分析时进行分组和筛选。例如，游戏用户登录事实表中，粒度为游戏级别，相关的维度有用户、客户端、设备、区域等。

本实施例一个可选的实施方式中，获取至少两个游戏日志数据之后，还包括：

将所述至少两个游戏日志数据中属于相同属性的游戏日志数据划分至同一主题域，得到至少一个主题域。

需要说明的是，数据仓库是面向主题的，也即数据仓库中的数据是按照一定的主题域进行组织，主题是指用户使用数据仓库进行决策时所关心的重点方面，一个主题通常与多个操作型信息系统相关。因而，在获取至少两个游戏日志数据之后，并对该至少两个游戏日志数据进行聚合之前，还应该先对至少两个游戏日志数据进行主题划分，得到至少一个主题域，然后再基于不同的主题域对至少两个游戏日志数据进行数据聚合。

步骤104：按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合。

其中，所述公共数据指标包括所述至少两个游戏日志数据对应的共性数据指标和个性数据指标。具体实现时，由于根据获取到的至少两个游戏日志数据构建了公共底层数据，因而按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合，实际上就是按照预先定义的公共数据指标，将不同游戏、不同结构的公共底层数据按预先定义的公共数据指标整合到一起，同时划分不同业务主题，按事件再向上聚合，做专题的数据支撑，统一数据出口，从而节省计算成本，快速、全面地支撑游戏研发数据的分析应用场景。

需要说明的是，由于公共数据指标是预先针对至少两个游戏日志数据抽象定义的，因而按照预先定义的公共数据指标，可以将不同来源的游戏日志数据进行聚合，从而将不同来源的游戏日志数据汇总至一张业务报表中，避免了重复计算的资源浪费，无需重复存储，大大提升了开发效率。实际应用中，按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合，生成一个业务报表之后，可以通过应用数据层ADS向需求方提供相应服务。

本实施例一个可选的实施方式中，在将至少两个游戏日志数据进行聚合时，还可以结合预先构建的统一维度表，也即按照预先定义的公共数据指标，将至少两个游戏日志数据进行聚合，包括：

根据所述统一维度表，按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合。

需要说明的是，在针对至少两个游戏日志数据预先构建统一维度表和统一事实表之后，就可以基于统一维度表和统一事实表，将至少两个游戏日志数据进行聚合，公共数据指标即是指统一事实表中每一列对应的数据指标。

本实施例一个可选的实施方式中，根据所述统一维度表，按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合，包括：

对所述至少两个游戏日志数据进行垂直整合和水平整合，得到所述至少两个游戏日志数据对应的宽表模型；

采用维度退化，将不同维度放入所述宽表模型的不同列中；

基于所述宽表模型，将所述至少两个游戏日志数据进行聚合。

需要说明的是，可以通过游戏数据仓库的明细数据层DWD，将维度退化至事实表中，减少事实表和维度表的关联，提高明细数据表的易用性；然后，通过游戏数据仓库的汇总数据层DWS，加强公共数据指标的维度退化。另外，可以采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性，减少重复加工。具体实现时，可以引入宽表模型(基于维度的扩展)，对至少两个游戏日志数据进行垂直与水平方式整合，同时采用退化维度的方式，将不同维度的度量放入事实表的不同列中，实现业务全流程视图的构建，提升宽表模型的易用性、查询效率。

本实施例一个可选的实施方式中，对所述至少两个游戏日志数据进行垂直整合和水平整合，包括：

将所述至少两个游戏日志数据中来自不同游戏且属于同一业务的数据进行整合；

将所述至少两个游戏日志数据中属于不同时间节点且属于同一业务的数据进行整合。

需要说明的是，水平整合就是将同一业务多数据源的数据整合到一个模型中，如果多数据源业务数据存在交集，则需要按照预设的业务规则选取一份保留，避免整合后的业务数据交叉。另外，一次完整的业务流转通常要经历多个环节，各节点信息产生的时间不同、储存的事实表不同，垂直整合就是将同一业务中各时间节点的数据整合至业务全流程宽表模型中。

另外，还可以预先确定业务分析粒度，从而构建统一的维度表，引入宽表模型，增强了指标的复用，模型分层、粒度清晰，精简了事实表的聚合计算量，通过数据分域、模型分层，节省了研发的时间和成本。

图2示出了本说明书一实施例提供的一种设计游戏数据仓库的流程图，具体包括以下步骤：

步骤202：对业务方的业务需求进行需求调研。

具体实现时，可以通过对业务方进行需求分析、系统调研、表级分析、字段级分析和数据验证，从而确定业务需求对应的参考数据指标。也就是说，首先需要收集和理解业务方需求，就特定需求的数据指标达成统一，在对需求中涉及到的业务系统或系统模块所承担的功能进行梳理后进行表字段级分析，并对数据进行验证，确保现有数据能够支持业务需求。

需要说明的是，上述对业务方的业务需求进行调研的过程，就是指游戏数据仓库的概念设计阶段，涉及业务建模、领域建模。业务建模是指生成业务模型，主要解决业务层面的分解和程序化，在业务调研过程中完成，业务调研包括：需求方的组织架构和分工界面，如需求方可能分为数据分析、运营和维护部门人员，各个部门对游戏数据仓库的需求不同，需要对不同部门分别进行调研；需求方的整体业务架构，各个业务板块之间的联系和信息流动的流程，需要梳理出整体的业务数据框架；各个已有的业务板块的主要功能及获取的数据。领域建模是指生成领域模型，主要是对业务模型进行抽象处理，在需求分析阶段生成领域概念模型，需求分析阶段，需要确定出业务分析或任务报表中的公共数据指标以及公共数据指标的定义和粒度。

步骤204：对游戏数据仓库的模型进行模型设计。

实际应用中，对游戏数据仓库的模型进行模型设计，首先需要对游戏日志数据进行主题划分，然后依次生成逻辑模型和物理模型，之后进行模型评审。具体实现时，可以根据需求和业务调研结果对模型进行初步归类，选择合适的主题域进行模型存放；确定主题后进入游戏数据仓库的模型的设计阶段，逻辑模型设计过程要考虑总线结构构建、模型规范定义，即预先定义统一的数据指标；物理模型设计以逻辑模型为基础，兼顾存储性能等因素，对逻辑模型进行物理化，是逻辑模型的最终物理实现，物理模型在一般情况下与逻辑模型保持一致。

需要说明的是，生成逻辑模型主要是将领域模型的概念实体以及实体之间的关系进行数据库层次的逻辑化，重点是描述游戏日志数据以及游戏日志数据之间的逻辑关系；生成物理模型，主要是解决逻辑模型针对不同关系型数据库的物理化以及性能等具体的技术问题。

图3是本说明书一实施例提供的一种游戏数据仓库的核心架构图，如图3所示，设计好的游戏数据仓库包括数据源，数据获取，数据处理、整合，数据服务等阶段。其中，数据源包括研发日志、游戏事件、游戏快照和广告，通过数据交换工具进行数据获取；然后通过贴源数据层(数据缓冲层STG、操作数据层ODS)、公共数据层(明细数据层DWD、汇总数据层DWS、维度数据层DIM)和应用数据层ADS对数据进行处理与整合。之后，提供报表查询、数据产品和分析挖掘等数据服务。

本说明书中可以构建一个针对不同来源、不同结构的各类游戏研发数据的公共数据层，将不同游戏的不同结构的研发数据按公共维度整合到一起，同时划分不同业务主题，按事件再向上聚合，做专题的数据支撑，统一数据出口，从而节省计算成本，快速、全面地支撑游戏研发数据的分析应用场景。

另外，游戏数据仓库的模型设计完成后需要进入评审，并进行事实表和维度表设计(Mapping设计)，也即维度表、事实表的数据模型图绘制，具体实现时可通过PowerDesigner软件作图(一种数据库建模工具)。

步骤206：对生成的游戏数据仓库的模型进行开发测试。

需要说明的是，生成游戏数据仓库的模型后还需要进行开发测试，具体包括脚本开发、单元测试、集成测试和业务测试。游戏数据仓库的模型的计算脚本的代码实现过程，其中包含了数据映射、脚本实现、测试验证等开发过程。另外，单元测试完成后需要通知需求方一起对游戏数据仓库的模型进行业务验证，对验证问题做收集，返回验证游戏数据仓库的模型设计的合理性。

步骤208：将游戏数据仓库的模型上线。

需要说明的是，将游戏数据仓库的模型上线包括打包上线、模型监控和模型发布。完成验证后的游戏数据仓库的模型就可以在线上生产环境进行部署，上线后需要为游戏数据仓库的模型配置监控，及时掌握为需求方提供数据服务的状况。

本说明书中可以按照一定的数据仓库模型，对不同数据源的游戏日志数据进行采集、整理，将不同来源的游戏日志数据汇总至一张业务报表中，避免了重复计算的资源浪费，无需重复存储，大大提升了开发效率；并且，提供了不同来源、跨部门、完全一致的业务报表数据，提高了数据仓库的查询效率，通过数据仓库可以满足游戏开发商各个业务部门多样化的数据需求，为游戏开发商决策提供全面的数据支持，从而提升用户游戏体验，降低用户流失率。

与上述方法实施例相对应，本说明书还提供了游戏数据仓库构建装置实施例，图4示出了本说明书一实施例提供的一种游戏数据仓库构建装置的结构示意图。如图4所示，该装置包括：

获取模块402，被配置为获取至少两个游戏日志数据，每个所述游戏日志数据与一个游戏对应；

聚合模块404，被配置为按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合；其中，所述公共数据指标包括所述至少两个游戏日志数据对应的共性数据指标和个性数据指标。

可选的，所述装置还包括：

第一确定模块，被配置为确定所述至少两个游戏日志数据对应的共性数据指标和个性数据指标，所述共性数据指标为所述至少两个游戏日志数据均包括的数据指标，所述个性数据指标为所述至少两个游戏日志数据中至少一个游戏日志数据不包括的数据指标；

设置模块，被配置为根据所述共性数据指标和所述个性数据指标，设置所述公共数据指标。

可选的，设置模块进一步被配置为：

采集并分析业务方的业务需求；

确定所述业务需求对应的参考数据指标；

可选的，设置模块进一步被配置为：

将所述第二数据指标设置为所述公共数据指标。

可选的，第一确定模块进一步被配置为：

可选的，所述装置还包括：

第一构建模块，被配置为将所述共性数据指标和所述个性数据指标作为统一事实表的不同列，构建得到统一事实表。

可选的，装置还包括：

第二确定模块，被配置为确定所述至少两个游戏日志数据对应的业务过程；

第三确定模块，被配置为确定所述业务过程的分析粒度；

第二构建模块，被配置为根据所述分析粒度和所述业务过程构建统一维度表；

相应的，聚合模块404进一步被配置为：

可选的，聚合模块404进一步被配置为：

采用维度退化，将不同维度放入所述宽表模型的不同列中；

可选的，聚合模块404进一步被配置为：

可选的，所述装置还包括：

划分模块，被配置为将所述至少两个游戏日志数据中属于相同属性的游戏日志数据划分至同一主题域，得到至少一个主题域。

本说明书提供的游戏数据仓库构建装置，可以按照一定的数据仓库模型，对不同数据源的游戏日志数据进行采集、整理，将不同来源的游戏日志数据汇总至一张业务报表中，避免了重复计算的资源浪费，无需重复存储，大大提升了开发效率；并且，提供了不同来源、跨部门、完全一致的业务报表数据，提高了数据仓库的查询效率，通过数据仓库可以满足游戏开发商各个业务部门多样化的数据需求，为游戏开发商决策提供全面的数据支持，从而提升用户游戏体验，降低用户流失率。另外，还可以预先确定业务分析粒度，从而构建统一的维度表，引入宽表模型，增强了指标的复用，模型分层、粒度清晰，精简了事实表的聚合计算量，通过数据分域、模型分层，节省了研发的时间和成本。

上述为本实施例的一种游戏数据仓库构建装置的示意性方案。需要说明的是，该游戏数据仓库构建装置的技术方案与上述的游戏数据仓库构建方法的技术方案属于同一构思，游戏数据仓库构建装置的技术方案未详细描述的细节内容，均可以参见上述游戏数据仓库构建方法的技术方案的描述。

图5示出了根据本说明书一实施例提供的一种计算设备500的结构框图。该计算设备500的部件包括但不限于存储器510和处理器520。处理器520与存储器510通过总线530相连接，数据库550用于保存数据。

计算设备500还包括接入设备540，接入设备540使得计算设备500能够经由一个或多个网络560通信。这些网络的示例包括公用交换电话网(PSTN)、局域网(LAN)、广域网(WAN)、个域网(PAN)或诸如因特网的通信网络的组合。接入设备540可以包括有线或无线的任何类型的网络接口(例如，网络接口卡(NIC))中的一个或多个，诸如IEEE802.11无线局域网(WLAN)无线接口、全球微波互联接入(Wi-MAX)接口、以太网接口、通用串行总线(USB)接口、蜂窝网络接口、蓝牙接口、近场通信(NFC)接口，等等。

在本说明书的一个实施例中，计算设备500的上述部件以及图5中未示出的其他部件也可以彼此相连接，例如通过总线。应当理解，图5所示的计算设备结构框图仅仅是出于示例的目的，而不是对本说明书范围的限制。本领域技术人员可以根据需要，增添或替换其他部件。

计算设备500可以是任何类型的静止或移动计算设备，包括移动计算机或移动计算设备(例如，平板计算机、个人数字助理、膝上型计算机、笔记本计算机、上网本等)、移动电话(例如，智能手机)、可佩戴的计算设备(例如，智能手表、智能眼镜等)或其他类型的移动设备，或者诸如台式计算机或PC的静止计算设备。计算设备500还可以是移动式或静止式的服务器。

其中，处理器520用于执行如下计算机可执行指令，以实现下述方法：

上述为本实施例的一种计算设备的示意性方案。需要说明的是，该计算设备的技术方案与上述的游戏数据仓库构建方法的技术方案属于同一构思，计算设备的技术方案未详细描述的细节内容，均可以参见上述游戏数据仓库构建方法的技术方案的描述。

本说明书一实施例还提供一种计算机可读存储介质，其存储有计算机指令，该指令被处理器执行时以用于实现所述游戏数据仓库构建方法的步骤。

上述为本实施例的一种计算机可读存储介质的示意性方案。需要说明的是，该存储介质的技术方案与上述的游戏数据仓库构建方法的技术方案属于同一构思，存储介质的技术方案未详细描述的细节内容，均可以参见上述游戏数据仓库构建方法的技术方案的描述。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

所述计算机指令包括计算机程序代码，所述计算机程序代码可以为源代码形式、对象代码形式、可执行文件或某些中间形式等。所述计算机可读介质可以包括：能够携带所述计算机程序代码的任何实体或装置、记录介质、U盘、移动硬盘、磁碟、光盘、计算机存储器、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、电载波信号、电信信号以及软件分发介质等。需要说明的是，所述计算机可读介质包含的内容可以根据司法管辖区内立法和专利实践的要求进行适当的增减，例如在某些司法管辖区，根据立法和专利实践，计算机可读介质不包括电载波信号和电信信号。

需要说明的是，对于前述的各方法实施例，为了简便描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本说明书并不受所描述的动作顺序的限制，因为依据本说明书，某些步骤可以采用其它顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定都是本说明书所必须的。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其它实施例的相关描述。

以上公开的本说明书优选实施例只是用于帮助阐述本说明书。可选实施例并没有详尽叙述所有的细节，也不限制该发明仅为所述的具体实施方式。显然，根据本说明书的内容，可作很多的修改和变化。本说明书选取并具体描述这些实施例，是为了更好地解释本说明书的原理和实际应用，从而使所属技术领域技术人员能很好地理解和利用本说明书。本说明书仅受权利要求书及其全部范围和等效物的限制。

Claims

1.一种游戏数据仓库构建方法，其特征在于，包括：

2.根据权利要求1所述的游戏数据仓库构建方法，其特征在于，所述按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合之前，还包括：

3.根据权利要求2所述的游戏数据仓库构建方法，其特征在于，所述根据所述共性数据指标和所述个性数据指标，设置所述公共数据指标，包括：

采集并分析业务方的业务需求；

确定所述业务需求对应的参考数据指标；

4.根据权利要求3所述的游戏数据仓库构建方法，其特征在于，所述根据所述参考数据指标、所述共性数据指标和所述个性数据指标，设置所述公共数据指标，包括：

将所述第二数据指标设置为所述公共数据指标。

5.根据权利要求2所述的数据仓库构建方法，其特征在于，所述确定所述至少两个游戏日志数据对应的共性数据指标和个性数据指标，包括：

6.根据权利要求2-5任一所述的数据仓库构建方法，其特征在于，所述根据所述共性数据指标和所述个性数据指标，设置所述公共数据指标之后，还包括：

7.根据权利要求1-5任一所述的游戏数据仓库构建方法，其特征在于，所述按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合之前，还包括：

确定所述至少两个游戏日志数据对应的业务过程；

确定所述业务过程的分析粒度；

根据所述分析粒度和所述业务过程构建统一维度表；

相应的，所述按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合，包括：

8.根据权利要求7所述的游戏数据仓库构建方法，其特征在于，所述根据所述统一维度表，按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合，包括：

采用维度退化，将不同维度放入所述宽表模型的不同列中；

9.根据权利要求8所述的游戏数据仓库构建方法，其特征在于，所述对所述至少两个游戏日志数据进行垂直整合和水平整合，包括：

10.根据权利要求1-5任一所述的游戏数据仓库构建方法，其特征在于，所述获取至少两个游戏日志数据之后，还包括：

11.一种游戏数据仓库构建装置，其特征在于，包括：

聚合模块，被配置为按照预先定义的公共数据指标，将所述至少两个游戏日志数据进行聚合；其中，所述公共数据指标包括所述至少两个游戏日志数据对应的共性数据指标和个性数据指标。

12.一种计算设备，其特征在于，包括：

存储器和处理器；

13.一种计算机可读存储介质，其特征在于，其存储有计算机指令，该指令被处理器执行时实现权利要求1至10任意一项所述游戏数据仓库构建方法的步骤。