01
业务数据化全景图
这里业务数据化，不聊数据怎么赋能业务、怎么驱动业务甚至数据重塑业务、怎么对业务数据化从而使企业降本增效；也不聊 怎么通过业务数据化达到企业数字化转型。这些都是从CIO、CTO或CEO视角去陈述为什么需要业务数据化。而是以一个一线实施者数据工程师视角去聊聊业务数据化，这里数据工程师可以是数据架构师、数据开发工程师、数据模型设计师角色。
上图是业务数据化在数据工程师视角的全景图，是由逻辑线与物理线串联而成；逻辑线是以全局视野统一业务认知、了解业务流程，对业务需求进行分析，从而产出总线矩阵与指标清单；再通过模型设计产出逻辑模型向上承接总线矩阵与指标清单，向下约束物理模型设计，最终实现业务与数据建设统一。
02
逻辑线
逻辑线首先是通过业务调研与需求分析来熟悉业务与掌握需求，构建总线矩阵与梳理指标清单，再进行体系化建模。
全局业务认知
数据工程师作为技术人员，思维侧重方法中心，容易过于重视方法，而忽略问题；容易一看到问题，马上就想答案。数据工程师在负责企业业务数据化项目（数据中台、数仓、模型设计等等）时，先不急于搭建底层存储、计算、调度技术栈，也不用急于是敲定是使用ER模型还是维度模型建模。而是先以“问题中心”尽快对企业业务进行全职认知，找到“用户需求”，回到why和what；然后”方法中心“，进行模型设计与底层平台建设。
因此数据工程师需要介入到业务调研阶段，对业务有全局认知，可以勾画出如下图业务流程图。
在业务认知过程中，需要清晰有哪些角色参与到业务流程中来，如上图有消费者、零售商和上游供应商。同时需要了解有哪些要素在业务流程中流动及流动方向，如上图主要有三要素，分别是商品、资金以及信息，这三要素的流动即物流，资金流和信息流。
构建总线矩阵
在进行充分业务调研和需求调研后，就要构建总线矩阵；总线矩阵作为业务视角到数据视角桥梁，基于业务本身，对业务逻辑进行抽象，从而指定与规范模型设计。构建业务过程需要做两件事情：明确每个数据域下有哪些业务过程；业务过程与哪些维度相关，并定义每个数据域下的业务过程和维度。如下图所示是供应链管理业务过程示例。
维护好指标清单
指标是业务与数据交汇点，业务目标和策略的执行情况需要通过指标来分析；指标是数据工程师物理线产出物，也是作为数据需求启动数据建模与数据数据开发关键输入物。在数据类项目中经常会遇到这些指标问题
相同指标名称，口径不一致问题
相同指标口径，名称不一致问题
指标口径描述不清晰问题
指标命名难以理解问题
这些问题都是因为没有维护好指标清单，缺乏指标建设体系与对指标进行统一管理，从而导致指标混乱，增加沟通与开发成本。
分享一些怎么维护好指标清单经验
规范化定义指标
为了提高指标管理的效率，需要按照业务线、主题域和业务过程三级目录方式管理指标（业务线是顶级目录）
拆分原子指标和派生指标
原子指标是某一业务事件行为下的度量，是业务定义中不可再拆分的指标，具有明确业务含义的名词，如支付金额。
统计周期、统计粒度、业务限定、原子指标，组成派生指标。如下图，其中修饰类型就是包括统计周期、统计粒度、业务限定
规范指标命名
对于原子指标，指标名称适合用“动作 度量”的命名方式（比如注册用户数、购买用户数），标识的命名用英文简写或者汉语拼音缩写比较好。
对于派生指标，指标名称应该严格遵循“时间周期 统计粒度 修饰词 原子指标”的命名方式，标识命名要用“修饰词 _ 原子指标 _ 时间周期”的方式。
体系化模型设计
通过对业务流程抽象形成总线矩阵，接着需要进行模型设计将业务视角转化为数据。体系化建模将割裂的数据规范定义、模型设计以及最终物理模型实现连接在一起；从而避免因为缺乏规范与约束带来的“烟囱式”开发，在浪费技术资源的同时造成数据重复且不可信。
分享一些体系化建模经验
主题域划分
一个逻辑模型由哪些记录和字段组成，应该遵循最基本的软件设计方法论的高内聚低耦合原则；将业务相关或相近、粒度相同的数据设计为一个逻辑或者物理模型，并且归类同一主题域。主题域划分尽量涵盖所有业务，保持相对稳定性，还具备一定可扩展性（新加入主题域，不影响已经划分的主题域的表）。
主题域划分没有客观原则，主要是根据数据工程师的行业经验与业务理解来划分，以下是一个主题域划分例子：
一致性维度
如果不同数据域在计算过程使用维度不一致，就会导致交叉探查存在问题。当存在重复的维度，但维度属性或维度属性值不一致时会导致交叉探查无法进行或交叉探查结果错误。
比如需要将日志数据域统计的商品维度的最近一天的pv和uv，与交易数据域统计的商品维度的最近一天的下单GMV，进行交叉探查，计算转化率；假设对于日志数据域，统计使用的是商品维度1，对于交易数据域，统计使用的是商品维度2。商品维度1包含维度属性BC类型，而商品维度2无此属性，侧无法在BC类型上进行交叉探查。
规范事实表设计
事实表作为数据工程体系化建模的核心，需要紧紧围绕着业务过程来设计，通过获取描述业务过程的度量来表达业务过程，包含引用的维度与业务过程有关的度量。
分享一些事实表设计方法：
选择业务过程及确定事实表类型
在明确了业务需求之后，接下来需要进行详细的需求分析，对业务的整个生命周期进行分析，明确关键业务步骤，从而选择与需求有关的业务过程。
上图是泛零售行业订单流转的业务过程有四个：创建订单、买家付款、卖家发货、买家确认收货。选择了业务过程以后，相应的事实表类型也随之确定了。
声明粒度
粒度声明是事实表建模非常重要的一步，意味精确定义了事实表每一行所表示的业务含义，粒度传递的是与事实表度量有关的细节层次。明确的粒度能确保对事实表中行的意思理解不会产生混淆，保证所有的事实按照同样的细节层次记录。
确定维度
完成粒度声明以后，也就意味着确定了主键，对应的维度组合以及相关的维度字段就可以确定了，应该选择能够描述清楚业务过程所处的环境的维度信息。比如订单付款事务事实表中，粒度为子订单，相关的维度有买家、卖家、商品、收货人信息、业务类型、订单时间等等。
确定事实
事实可以通过回答'过程的度量是什么'来确定。应该选择与业务过程有关的所有事实，且事实的粒度要与声明的事实表粒度一致。事实有可加性、半可加性、非可加性三种类型，需要将不可加性事实分解为可加性。
写在最后
结语
联系客服
