数仓架构流程一

第一章 数仓架构之业务调研

---

---

数仓架构之调研

调研主要是两个方向：业务调研和规范制定

---

业务调研

业务调研是一件梳理全公司的一件事，是涉及到公司极度敏感信息的一件事，所以在整个进程中都是需要公司高层全力支持和配合的，只有这样，才能把控全公司的数据建设，整个过程中的产出也需要严防数据泄露，保护公司机密。

1、调研的方向

1.1公司组织架构梳理

也许大家觉得这第一步很奇怪，竟然调研还会涉及到组织架构的调研，其实关于架构调研有几点原因：
1.为后期业务和系统梳理做好基础工作，因为后期涉及到业务和系统调研会和各个部门各个组打交道，得知道这过程中与谁沟通，谁负责，需要谁来推进，虽然说这过程中上级会清楚，但是整个工作拆分开后项目组内的人不一定会清楚；
2.了解组织架构划分会大致对公司的数据产出、数据分类等有个大体的了解，能够为后期工作打下基石

1.2 公司业务梳理

第二步的业务梳理是后期建模极度依赖的产物，在这一步中，我们要做的就是细化所有业务，将业务流程化的展现出来：

1.2.1 调研目的

首先需要确定数仓构建的目标与需求，进行全面的业务调研。您需要了解真实的业务需求是什么，以及确定整个业务系统能解决什么问题，需要解决什么问题。

1.2.2 调研产出

调研是需要有产出的，不是听过之后就算完成，需要从会议的内容中总结得到组织架构图、业务流程图、总线矩阵、核心需求等。

1.2.3 反复总结归纳打磨1.2.2中产出物

2、调研的方法

充分的业务调研和需求分析是数据仓库建设的基石，直接决定数据仓库能否建设成功。

调研问题参考

调研的方法主要是组织会议以及访谈的形式对不同部门分别进行调研。

2.1 需要得到的信息有：

1. 用户的组织架构和分工界面。 例如，用户可能分为数据分析、运营和维护部门人员，各个部门对数据仓库的需求不同，您需要对不同部门分别进行调研。
2. 用户的整体业务架构，各个业务板块之间的联系和信息流动的流程。 您需要梳理出整体的业务数据框架。
3. 各个已有的业务板块的主要功能及获取的数据。

2.2 公司业务梳理需求分析的途径有：

• 通过与分析师、业务运营人员的沟通获知需求。
• 对报表系统中现有的报表进行研究分析。
• 公司业务系统梳理。

2.3 分析业务过程、确定维度

业务系统中，通过埋点或日常积累的方式，获取了充足的业务数据。为梳理数据之间的逻辑关系和流向，需要理解用户的业务过程及数据系统。

您可以采用过程分析法，列出整个业务过程涉及的每个环节，包括技术、数据、系统环境等。分析完企业的工作职责范围（部门）后，借助工具通过逆向工程抽取业务系统的真实模型。您可以参考业务规划设计文档和业务运行（开发、设计、变更等）相关文档，从以下几方面分析数据仓库涉及的源系统及业务管理系统：

• 每个业务会生成哪些数据，存在于什么数据库中。
• 对业务过程进行分解，了解过程中的每一个环节会产生哪些数据，数据的内容是什么。
• 数据在什么情况下会更新，更新逻辑是什么。

业务过程可以是单个业务事件（例如交易的支付、退款），也可以是某个事件的状态（例如当前的账户余额），还可以是一系列相关业务事件组成的业务过程。具体取决于您分析的是某些事件过去的发生情况、当前状态，或是事件流转效率。分析业务过程的流程如下：

• 选择粒度。在业务过程事件分析中，您需要预判所有分析需要细分的程度和范围，从而决定选择的粒度。
• 设计维表。选择好粒度之后，您需要基于此粒度设计维表，包括维度属性等，用于分析时进行分组和筛选。
• 确定衡量指标。

2.4 同时进行数据盘点：

数据盘点即指标技术侧梳理，是根据指标内容，了解业务系统现在的数据情况，如数据字典，数据量等，形成原始系统的数据资产目录。
数据盘点是体力活，一方面要哄着知道数据结构的老大们告诉我们真实的情况（因为很多表和字段描述估计没记录下来），一方面需要一个一个表去盯。

2.5 建议关注的问题：

在需求分析阶段，您需要沉淀出业务分析或报表中的指标，以及指标的定义和粒度。粒度可以作为维度的输入。建议您思考下列问题，对后续的数据建模将有巨大的帮助：

• 业务数据是根据什么（维度、统计粒度，简称“粒度”，是维度或维度组合）汇总的，衡量标准是什么？例如，“省份”或者“类目”是维度，订单数是原子指标。
• 基于上个问题，进一步思考明细数据层的事实模型和公共可引用的维度模型、汇总数据层的汇总模型应该如何设计？是否有公共使用，命名及逻辑相似的统计指标，目前已经重复建设使用，需要通过上述设计规范化？

3、调研的产出

3.1 组织架构图

常规的组织架构图，不同在于每个部门及岗位上都有对应的负责人姓名。这个方便于当你想知道某一块业务逻辑时方便找到对应的人。

3.2 数据资产盘点

数据盘点是根据指标内容，了解业务系统现在的数据情况，如数据字典，数据量等，形成原始系统的数据资产目录。
该步骤是数据建模工程师介入指标开发的切入点，也是业务分析师与数据建模工程师交接的重要步骤。

3.2.1 数据盘点工作清单

盘点项	盘点内容
应用系统盘点	应用系统清单，登录地址，登录帐号、密码等
应用系统数据库盘点	应用系统数据库清单，登录地址，登录帐号、密码、分区分库原则等
数据表盘点	数据表、描述、ER关系、数据量、数据增量等
应用系统盘点	盘点数据字段的内容，包括重复度，数据空值率，枚举值含义等
数据模型收集	包括概念、物理、逻辑、主题等模型

3.2.2 应用系统及应用数据库盘点

3.2.3 数据表盘点

3.2.4 数据字段盘点

3.3 业务大图

每个公司业务都是不一样的，没啥好说的，主要内容就是公司包含哪些业务流程，包括这些流程的数据走向，系统走向，前后衔接。

3.4 总线矩阵（重要）

3.4.1 定义维度

在划分数据域、构建总线矩阵时，需要结合对业务过程的分析定义维度。
比如：

作为维度建模的核心，维度在企业级数据仓库中必须具有唯一性。维度在每个业务板块内必须具有唯一性，即每个维度在所属业务板块内有且只有一种定义。例如上图的省份维度，对于营销业务板块内的任何业务过程所传达的信息都是一致的。

3.4.2 构建总线矩阵

明确每个数据域下有哪些业务过程后，即可构建总线矩阵。您需要明确业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。如下所示是A公司电商板块交易功能的总线矩阵，我们定义了购买省份、购买城市、类目名称、类目ID、品牌名称、品牌ID、商品名称、商品ID、成交金额等维度。

3.5 主题域划分或者数据域划分与定义

数据域是指面向业务分析，将业务过程或维度进行抽象的集合。为保障整个体系的生命力，数据域需要抽象提炼，并长期维护更新，但不轻易变动。划分数据域时，需满足以下两点：

• 能涵盖当前所有的业务需求。
• 能在新业务进入时，无影响地被包含进已有的数据域中和扩展新的数据域。