在基于Dataphin构建与管理企业数据中台之前,首先需要确定数仓构建的目标与需求,进行全面的业务调研。您需要了解真实的业务需求是什么,以及确定整个业务系统能解决什么问题。

业务调研

充分的业务调研和需求分析是数据仓库建设的基石,直接决定数据仓库能否建设成功。在数仓建设项目启动前,您需要请相关的业务人员介绍具体的业务,以便明确各个团队的分析员、运营人员的需求,沉淀出相关文档。

您可以通过调查表、访谈等形式详细了解以下信息:
  1. 用户的组织架构和分工界面。例如,用户可能分为数据分析、运营、维护部门,各个部门对数仓的需求不同,您需要对不同部门分别进行调研。
  2. 用户的整体业务架构,各个业务模块之间的联系与信息流动的流程。梳理出整体的业务数据框架。
  3. 各个已有的业务系统的主要功能及获取的数据。
本教程以A公司的电商业务为例,梳理出业务数据框架如下图所示。A公司的电商业务板块分为招商、供应链、营销、服务四个板块,每个板块的需求和数据应用都不同。在您构建数仓之前,需要明确构建数仓服务的业务板块类型、每个板块具体满足什么业务需求。A公司业务数据框架
此外,您还需要进一步了解各业务板块中已有的业务流程。业务流程通常与业务板块紧密耦合,对应一个或多个表及其所属数据源,可以作为构建数仓的原始数据来源。下表展现的是一个营销业务板块的业务流程模块。
业务流程 A公司电商营销管理
商品管理 Y
用户管理 Y
购买流程 Y
交易订单 Y
用户反馈 Y
说明 Y表示包含该功能模块,N表示不包含。

本教程中,假设用户是电商营销部门的营销数据分析师。数据需求为最近一天某个商品类目(例如厨具)在各省的销售总额、该类目销售额Top10的商品名称、各省用户购买力分布(人均消费额)等,用于营销分析。最终的业务需求是通过营销分析完成该商品类目的精准营销,提升销售总额。通过业务调研,我们将着力分析营销业务板块的交易订单功能模块。

需求分析

在未考虑数据分析师、业务运营人员的数据需求的情况下,单纯根据业务调研建设的数据仓库,可能可用性较差。完成业务调研后,您需要进一步收集数据使用者的需求,进而对需求进行深度思考和分析,并改进数据仓库。

需求分析的途径有两种:
  • 通过与分析师、业务运营人员的沟通获知需求。
  • 对报表系统中现有的报表进行研究分析。
在需求分析阶段,您需要沉淀出业务分析或报表中的指标,以及指标的定义和粒度。粒度可以作为维度的输入。建议您思考下列问题,对后续的数据建模将有巨大的帮助:
  • 业务数据是根据什么(维度、统计粒度,简称“粒度”,是维度或维度组合)汇总的,衡量标准是什么?例如,“省份”或者“类目”是维度,订单数是原子指标。
  • 基于上个问题,进一步思考明细数据层的事实模型和公共可引用的维度模型、汇总数据层的汇总模型应该如何设计?是否有公共使用,命名及逻辑相似的统计指标,目前已经重复建设使用,需要通过上述设计规范化?
举例: 数据分析师需要了解A公司电商业务中最近1天厨具类目的成交金额。
  1. 当获知这个需求后,您需要分析:根据什么(维度)汇总、汇总什么(原子指标)、汇总的范围有多大(业务范围即业务限定,时间范围即统计周期)。例如,类目是统计粒度(基于维度),成交金额的总和是原子指标。该案例中,粒度应该是“类目”,“类目为厨具”是业务限定,最近1天是统计周期。
    说明 本例从类目为统计粒度的角度,分析需求处理。您可以在即席查询中定义汇总模型的筛选过滤条件,设定统计粒度的维度属性值为厨具,以免汇总模型数据稀疏。在真实业务场景下,可以根据业务需求、使用频度、复用性及汇总层数据计算存储进行考虑,拆解分析。例如,本例中还可以定义全表为粒度,只是该粒度中无需维度,然后定义业务限定是类目为厨具,其他保持不变,如无特殊数据情况,也可得到相同数据结果,只是计算存储过程消耗可能有不同。上述案例,不同路径,组合定义出来的派生指标,可能是相同结果,但是命名、计算逻辑实现可能略有不同。目前Dataphin上对于该类派生指标,认为是不同业务场景的指标,不进行强制去重。
  2. 基于上述拆解,您还需要进一步思考并设计明细数据层的事实模型(原子指标中成交金额的数据来源)、公共可引用的维度模型(统计粒度的来源,且需要与成交金额所属事实模型有关联关系)和汇总数据层模型(原子指标、业务限定、统计周期的拆解和定义方式)。

需求调研的分析产出通常是记录业务需求的规范定义文档(派生指标、原子指标、业务限定、统计周期、统计粒度(即维度))。结合业务调研情况,您可以进一步产出设计明细逻辑模型设计文档(维度模型、事实模型)与概念模型设计文档(维度、业务过程及其关系)。