在基于Dataphin构建与管理企业数据中台之前，首先需要确定数仓构建的目标与需求，进行全面的业务调研。您需要了解真实的业务需求是什么，以及确定整个业务系统能解决什么问题。
业务调研
充分的业务调研和需求分析是数据仓库建设的基石，直接决定数据仓库能否建设成功。在数仓建设项目启动前，您需要请相关的业务人员介绍具体的业务，以便明确各个团队的分析员、运营人员的需求，沉淀出相关文档。
您可以通过调查表、访谈等形式详细了解以下信息：
- 用户的组织架构和分工界面。例如，用户可能分为数据分析、运营、维护部门，各个部门对数仓的需求不同，您需要对不同部门分别进行调研。
- 用户的整体业务架构，各个业务模块之间的联系与信息流动的流程。梳理出整体的业务数据框架。
- 各个已有的业务系统的主要功能及获取的数据。
本教程以A公司的电商业务为例，梳理出业务数据框架如下图所示。A公司的电商业务板块分为招商、供应链、营销、服务四个板块，每个板块的需求和数据应用都不同。在您构建数仓之前，需要明确构建数仓服务的业务板块类型、每个板块具体满足什么业务需求。
此外，您还需要进一步了解各业务板块中已有的业务流程。业务流程通常与业务板块紧密耦合，对应一个或多个表及其所属数据源，可以作为构建数仓的原始数据来源。下表展现的是一个营销业务板块的业务流程模块。
| 业务流程 | A公司电商营销管理 |
| 商品管理 | Y |
| 用户管理 | Y |
| 购买流程 | Y |
| 交易订单 | Y |
| 用户反馈 | Y |
说明 Y表示包含该功能模块，N表示不包含。
本教程中，假设用户是电商营销部门的营销数据分析师。数据需求为最近一天某个商品类目（例如厨具）在各省的销售总额、该类目销售额Top10的商品名称、各省用户购买力分布（人均消费额）等，用于营销分析。最终的业务需求是通过营销分析完成该商品类目的精准营销，提升销售总额。通过业务调研，我们将着力分析营销业务板块的交易订单功能模块。
需求分析
在未考虑数据分析师、业务运营人员的数据需求的情况下，单纯根据业务调研建设的数据仓库，可能可用性较差。完成业务调研后，您需要进一步收集数据使用者的需求，进而对需求进行深度思考和分析，并改进数据仓库。
需求分析的途径有两种：
- 通过与分析师、业务运营人员的沟通获知需求。
- 对报表系统中现有的报表进行研究分析。
在需求分析阶段，您需要沉淀出业务分析或报表中的指标，以及指标的定义和粒度。粒度可以作为维度的输入。建议您思考下列问题，对后续的数据建模将有巨大的帮助：
- 业务数据是根据什么（维度、统计粒度，简称“粒度”，是维度或维度组合）汇总的，衡量标准是什么？例如，“省份”或者“类目”是维度，订单数是原子指标。
- 基于上个问题，进一步思考明细数据层的事实模型和公共可引用的维度模型、汇总数据层的汇总模型应该如何设计？是否有公共使用，命名及逻辑相似的统计指标，目前已经重复建设使用，需要通过上述设计规范化？
举例： 数据分析师需要了解A公司电商业务中最近1天厨具类目的成交金额。
- 当获知这个需求后，您需要分析：根据什么（维度）汇总、汇总什么（原子指标）、汇总的范围有多大（业务范围即业务限定，时间范围即统计周期）。例如，类目是统计粒度（基于维度），成交金额的总和是原子指标。该案例中，粒度应该是“类目”，“类目为厨具”是业务限定，最近1天是统计周期。
说明 本例从类目为统计粒度的角度，分析需求处理。您可以在即席查询中定义汇总模型的筛选过滤条件，设定统计粒度的维度属性值为厨具，以免汇总模型数据稀疏。在真实业务场景下，可以根据业务需求、使用频度、复用性及汇总层数据计算存储进行考虑，拆解分析。例如，本例中还可以定义全表为粒度，只是该粒度中无需维度，然后定义业务限定是类目为厨具，其他保持不变，如无特殊数据情况，也可得到相同数据结果，只是计算存储过程消耗可能有不同。上述案例，不同路径，组合定义出来的派生指标，可能是相同结果，但是命名、计算逻辑实现可能略有不同。目前Dataphin上对于该类派生指标，认为是不同业务场景的指标，不进行强制去重。
- 基于上述拆解，您还需要进一步思考并设计明细数据层的事实模型（原子指标中成交金额的数据来源）、公共可引用的维度模型（统计粒度的来源，且需要与成交金额所属事实模型有关联关系）和汇总数据层模型（原子指标、业务限定、统计周期的拆解和定义方式）。
需求调研的分析产出通常是记录业务需求的规范定义文档（派生指标、原子指标、业务限定、统计周期、统计粒度（即维度））。结合业务调研情况，您可以进一步产出设计明细逻辑模型设计文档（维度模型、事实模型）与概念模型设计文档（维度、业务过程及其关系）。