数仓建模系列：构建总线矩阵时，业务过程是到底个啥，这里摊牌了

• 目录
  • 背景
    • 理解和识别业务过程常见错误
  • 业务过程本质
  • 总结

背景

最近笔者参与并完成了数据中台从0到1的建设，当然数据中台如何定义争论也很多，这里笔者此篇文章不去讨论，但数据仓库是数据中台能否解决数据复用、数据共享、数据服务和数据快速迭代等这些相对通用问题的关键一环，这是不可否认的。此篇文章来讲述在构建数据中台过程中数据仓库维度建模部分时，会犯的一些错误，其中重点讲述一些对理解业务过程的常见错误以及正确地理解何为业务过程，因为业务过程准确理解和识别是维度建模进行的关键步骤。

现有较为流行数据中台构建方法论是一般沿用阿里系那套（当然也有其他大厂做，方法论类似）做法，其中数据仓库构建部分也是使用OneData数仓建模方法论。这里关于OneData数仓做一点说明，其不是除Innmon 3NF范式建模、Kimball维度建模以及Valut建模方法之外新数仓建模方法论，OneData建模方法论本质上是Kimball维度建模方法论结合平台系统，划分数据域，标准化了建模流程、固化了建模动作验证并保证模型元素（数据域，业务过程、来源表、表和指标中文和英文名称、计算口径等）唯一性的一种实践。如定义数据域、原子指标、业务限定、统计周期、派生指标和衍生指标等，在数据仓库模型的基础上进行“拖拉拽”生成相关指标，并平台层面验证相关指标的一致性和唯一性（所属数据域，业务过程、来源表、中文和英文名称、计算口径等一致性且不重复）。下面给出来引用《大数据之路》书中的名词术语解释：

关于原子指标、业务限定、统计周期、派生指标和衍生指标定义上述都有讲不再展开，这里重点解释一下数据域，数据域的定义是来自阿里出版《大数据之路》中的概念。解释一下，因为业务过程是收集或生成KPI指标的，其对应的事实表是用来做数据分析的。所以，数据域指面向业务分析,将业务过程或者维度进行抽象的集合。基于OneData建模方法论是需要划分数据域（至于如何划分数据域，笔者会写文章进行分享），在假设划分好数据域的前提下，OneData或Kimball维度建模方法论大致流程如下：

• 业务调研与需求分析（业务过程和指标分析需求）
• 识别业务过程，整理业务过程与系统表映射表
• 构建数据仓库总线矩阵（业务过程和维度的矩阵）
• 分析需求拆解，具体指标拆解等
• 维度模型设计，维度表与事实表设计
• 维度模型开发物理实现
• ......

由上述流程可见，业务过程是很重要的概念，是数仓建模工程师向业务部门人员在进行业务调研与需求分析步骤中，主动了解业务、学习业务和理解业务与收集需求的关键点，因为业务人员更关注自己部门职能的关键业务运营动作，如营销域：素材上传、素材打标签、创建广告、广告曝光等业务过程，而不关心业务系统中哪张表，业务系统底层怎么实现等具体细节问题。

识别业务过程常见错误

这里给出在重构数据仓库构建总线矩阵时，识别业务过程的两种不合理的思路：

• 数据仓库建模工程师整理出现有ODS表清单，邀请架构同学和相关系统开发人员参与，按照ODS清单一一进行命名业务过程。这种思路存在的问题是
  • 首先，直接绕开业务人员，没有从业务人员的业务视角出发，进而不清楚业务运营全局流程及过程中参与的业务对象。
  • 其次，因无业务人员的参与，也没有收集业务人员关心的核心指标（KPI），也就无法知道哪些是关键业务过程，更无法识别出业务过程优先级等。
  • 最后，ODS表清单中表，有的不一定是业务过程或含有多个业务过程，太抓系统开发细枝末节，这是从系统开发的角度出发。
• 数仓建模工程师整理出现有报表需求或指标，基于ODS表直接计算产生指标。这种思路存在的问题是
  • 首先，直接绕过业务人员，也跳过了业务过程识别，也跳过构建总线矩阵...
  • 其次，从具体需求出发，无法保证模型的可扩展性、也无法保证模型的通用型。
  • 最后，更没有全局模型设计思想，会导致大量重复建设...

上述两种方法都只是对维度建模及业务过程的理解片面而导致的，维度建模不是不顾整体模型设计，为产指标而做指标；业务过程不是架构部门和数据仓库工程师按照现有ODS层表清单来硬拍的。正确方式是在深入业务调研或访谈，倾听业务用户在说些什么，因为他们争吵着要分析的绩效指标是由业务过程来收集或生成的。

业务过程本质

在设计一个维度模型时,遵循 Kimball方的读者通常会复述四个关键决策:识别业务过程、粒度、维度和事实。尽管这听上去很直接,但团队通常会在第一步就犯错误。由于业务过程这个词看起来在不同的背景下具有不同的含义,因此他们会力求表述清晰。因为在设计一个数据模型时,业务过程声明是首先需要处理的一个基础,所以我们希望在此背景下消除这种混乱的情况。

关于业务过程，这里给出Kimball官方给出的定义：

“Business processes are the operational activities performed by your organization, such as taking an order, processing an insurance claim, registering students for a class, or snapshotting every account each month. Business process events generate or capture performance metrics that translate into facts in a fact table. Most fact tables focus on the results of a single business process. Choosing the process is important because it defines a specific design target and allows the grain, dimensions, and facts to be declared. Each business process corresponds to a row in the enterprise data warehouse bus matrix.”

大致翻译如下：

“业务过程是组织执行的经营活动，例如接受订单、处理保险索赔、注册学员上课或每月对每个帐户进行快照。业务过程事件生成或收集度量，这些度量转化为事实表中的事实。大多数事实表关注单个业务过程的结果。选择过程是很重要的，因为它定义了一个特定的设计目标，并允许声明粒度、维度和事实。每个业务过程对应于企业数据仓库总线矩阵中的一行”

在设计一个维度模型时,对于一个维度建模者来说，业务过程是一个事件或活动,它会生成或收集指标。这些指标就是组织的绩效测量值。业务过程通常具有以下关键特征：

• 业务过程通常会受到一个业务系统的支持。如结算业务过程是由一个结算系统支持的，其他业务过程也同样如此。
• 业务过程会生成或收集具有唯一粒度性和维度性的唯一测量值,这些值会用于判定组织绩效（KPI）。有时这些指标来自业务过程的一个直接结果。这些测量值会是推导出来的结果。无论如何,业务过程都要交付可以被各种分析过程所使用的绩效指标。
• 业务过程常常会被表述为行为动词，因为它们通常表示业务执行的活动。 它们具有相关的维度,这些维度都形如描述与该过程相关的谁、什么、哪里、何时、为何以及如何的名词。例如,会根据日期、顾客、服务产品等来分析结算业务过程结果。
• 业务过程通常是由一个输入来触发并且生成需要被监控的输出结果。例如,一个被认可的购物交易就是订单过程的输入,会产生一份销售订单及其相关的指标。在这种情况下,业务过程就是销售订购;将存在一个订单事实表,它具有销售订单作为可能的退化维度,以及订单金额和数量作为事实尝试想象一下从输入到一个业务过程之中从而产生数据指标的普遍流程。

其他几点相关好理解，重点对第二点业务过程收集或生成KPI指标进行说明，如果一个业务过程没有收集或生成一个组织当前或将来最关心的KPI指标，其也没数据分析意义继而也不是业务用户关心活动事件，也不算一个业务过程，更没有在数据仓库总线矩阵存在的必要。在识别过程时，可以参考上述几点特征作为判断一个业务动作是否为业务过程的标准。

总结

业务过程是受到业务系统支持的，会生成或收集组织的绩效指标（KPI），由用户动作、运营动作或系统动作触发的事件。注意，业务过程是企业的业务活动中一个不可拆分的行为事件,如下单、支付、退款都是业务过程。